I'm an architect. As most architects, I like to design things and conceptualize ideas. But a common pitfall for us architects is that we design things that are very clear for... other architects. Other audiences are often left puzzled or confused. This is commonly referred to as the ivory tower phenomenon. I'm also a result driven pragmatist; I love to realize ideas. To make something happen, you first need to convince the stakeholder or sponsor that provides the budget to realize your idea. In this post I'd like to share my experience in architectural models that have proven to work for me.
Don’t you love it when you can present a very complex idea in an easily understandable way? Seeing that your audience gets it? I really do because I believe that an essential step in convincing people of an idea is making sure they really understand it. This also enables a shared vision of the expected benefits on a company-wide level.
The worst thing that could happen to me is that I'd come up with a beautiful design that is loved by my fellow architects but ultimately fails to be picked up simply because the beneficiary doesn't understand it. Don't get me wrong: I'm not against standard modeling techniques or architectural frameworks that have proven themselves. I'm a very big fan of them. I just wouldn't show them to my business stakeholder or anyone who isn't into architecture for that matter.
The success of an architectural design can be measured by the people that reuse it.
In my case, the full architecture of the program fitted on an A5 and still expressed the essence (and benefits) of the change we were to realize. My 'moment de gloire' was when the project sponsor (chief HR&O) explained the reason (why) of the project and how we were going to make it happen, by making use of this simple model.
These are the steps I followed and that worked for me:
- Know your information. Create a business information model.
Sharing a common vocabulary is essential for any project to be successful. The discussions that take place during the exercise are already profitable. The end result is definitely worth the investment as the knowledge will be reused throughout the full project lifecycle and will prevent tremendous mistakes.
I could easily write a blog post on information modeling only, maybe I will some day.
- Once you know your information, agree on responsibilities.
Based on your information model, you can easily and unambiguously indicate who is responsible for each concept or entity.
For a lot of concepts, this is a no-brainer (e.g. who would argue that anyone other than HR is responsible for managing the employee contract?). The true value lies in the concepts that tend to lean towards other business units and for which the ownership is not immediately clear (e.g. we had some good discussions on who is responsible for the 'executed work' concept as it is a base for remuneration).
- Focus on the benefit you are seeking.
This is what we were seeking: increased business agility so that the company can introduce changes faster. Key for enabling that is a loose coupling between the human resources business processes and software and those of the operational units.
The model I wanted to come up with would need to express as simple as possible who would be responsible for what information and what interactions are necessary.
- Use examples in your model.
The model should express the idea and leave as little room for interpretation as possible. If you stick to just 'concepts', this won't work. Add an example to the concepts that matter, this will increase the stakeholders’ feeling of familiarity. Something you really need at this stage in the project. It is of vital importance that from the beginning you have a shared understanding of the key changes you are introducing.
- Simplify again.
The model I had created, was presented by a quadrant that showed the split in responsibility between the HR department and the other business units and their main interactions. Each part of the quadrant held the key information concepts and an example. By reading it clockwise (following the interactions) you get a clear idea of the E2E process and information flow.
The last step in simplification I took was to express the main responsibility of each quadrant in a single phrase.
Both versions of 'the quadrant' are still used frequently to:
- Position the decisions at the steering committee level.
- Introduce context in change meetings.
- Explain the essentials of more complex and detailed designs.
A good architectural model is based on qualitative analysis and can be backed up by complex designs. Real value is created when all people involved in 'the change to be realized' understand it. This can only be achieved by simplification.
In the next post in this series, we’ll talk about the integration aspect by adding another level of detail.