A few years ago I was introduced to the concept of bodystorming. Basically this is acting out in person how a product might be used as a way of coming up with product ideas and requirements. I tried it out at a coach retreat, but didn’t really have any ah-ha moments that made me want to use it with a client.
Then yesterday driving home from a client, I was thinking about ways to visualise and simplify their incredible complex architecture with over 40 different subsystems. I had an idea! What if we bodystormed the architecture?
Each person can act as a component, or group of components (depending on how many people you have and how complex your architecture is). Each person gets a stack of index cards to represent the type of messages their component(s) send.
People stand around in a way that represents the components relationships to each other. i.e. if 2 components share a database they stand close together. If something is deployed on a different server to the rest they stand further away.
One (or more) people represent the users of the system. They have a bunch of cards indicating the types of things users do.
Maybe also try have a few people just observing.
The people representing users then decide to initiate an action. They have to walk over the the component they would interact with and hand them the card to represent that action. Now people move and pass messages the way the system would. Hopefully ending up with the result being passed back to the user by someone.
Do this for a couple of requests and even try things like multiple simultaneous requests from different users.
Now reflect. What happened? What patterns did you notice? Was anyone particularly busy? Was anyone completely idle? Did stuff pass back and forwards between people who were far apart? Was there a simpler way to get the right message back? Did anyone get confused about what they were supposed to do?
What does that say about your architecture? Are there some things you could change to streamline it? simplify it? Does everyone have the same understanding of how the system works? Did anyone say it ‘should’ do this, but actually it does that?
You could take it one step further and make some changes to the way people are arranged based on how you’d like to improve the system and then play the same scenario’s again and see if the impact you expect is achieved.
I haven’t tried this technique yet, but I suspect you could use it for a couple of things:
- Knowledge Sharing – particularly with a large system to get a shared understanding of how it actually works.
- Refactoring – be able to visualise the state of your system and then try out how it might work if you re-architected it without writing any code.
- Deployment Strategy – use this to decide how best to deploy components based on frequently they interact.
I think the strength of this technique lies in making tangible something that is often very intangible – software architecture.
If you are based in Cape Town, and the idea of trying this excites you, give us a call. I’d be keen to help facilitate the session to see how the idea works in practice. I’ll do it for free just for the learning experience 😉