Yeah sure. How exactly are we going to do this again?

Previously I've pleaded for simple architectural designs that are easily understood by all stakeholders. This way the idea gets the support it needs. As a project evolves into the ICT design and development phase, both idea and design will need to be made more tangible. This is especially true when it comes to making it all work together. The purpose stays the same: to avoid ambiguity. The means? Keep it again as simple as possible by focusing on what really matters.

The introduction of this series mentioned our context in which several project teams that use different methodologies and have specific and scattered knowledge, need to work together to deliver a shared scope within an ambitious timing.

The challenges to achieve this from an ICT point of view are immense. Coming from a purely custom-built ICT landscape with over fifty point-to-point interfaces and evolving to a best of breed landscape with custom built and package solutions - whilst also optimizing the integration architecture - is far from easy. It didn't take long for the team to face a hurdle, although not everyone was immediately aware of it.

When it comes to connecting several applications that need to work together to support the business processes, it is of vital importance that it is clear to everyone:

• Which application is responsible for which functionality.
• Which application manages the business concepts (information master).
• What copies of information are needed in other applications (information slaves).
• How the information will be transferred from one application to another.
• When information needs to be transferred.

The hurdle

No matter how much time was spent in project meetings, talking to one another or creating and validating software designs; we still regularly discovered that some of the questions above remained unanswered or (even worse) teams had a different idea whilst thinking they were aligned on the matter.

The root cause of the hurdle was the lack of an integrated solution design that is shared across project teams. If you're a critic, you might say: “how is it possible that this didn't exist from the beginning?”. In my experience I've never seen a company that has an extended application integration architecture readily available to be used by a project. I'm sure they exist but I haven’t met them in my world so far. When asking colleagues, they seem to share the same experience. If you’re the person that is lucky enough to have everything readily available at the start of the project, stop reading now and share your designs with the world!

How to overcome the hurdle

If you faced the same kind of challenge as our team did, keep reading. This is how we created a high level integration architecture design that answered all of the design questions above:

• Focus on what matters: the applications, their components and the main functionality within those components.
• Make clear what business information is created, managed or used by a functionality (stick to the lingo you've introduced in your business information model).
• Make clear how information is provided to the functionality (e.g. synchronous web service call, file interface, data copy in cache,...).
• Make the role of middleware (think ESB) in the integration clear.
• Keep it simple. We're looking at a deliverable that needs to be valuable for both business and ICT people.
• Add a glossary. A picture holds a thousand words but some accompanying textual explanation is often necessary. We want to avoid ambiguity after all.
• Make it look good. Don't cram everything on a single sheet if it becomes a spaghetti-like drawing.
  Tip: Split your integration scope in parts that make sense from a business point of view.
• Use a presentation mode that everyone can understand and add a legend for the symbols you are using. Again, keep it simple. If you use a standard notation language (like UML or Archimate), keep it as simple as possible and never assume that the reader knows what a symbol or specific kind of arrow means.

The model

ihrm overall integration architecture

The creation of this model in all its simplicity has taken me some time but it has proven to be a worthwhile investment. Once you have this kind of model, you can use it for a lot of things. Here are some examples:

• Verify scope completeness.
• Align amongst project teams
• Help new project team members get a head start. (happens all the time in big programs)
• Define use case boundaries.
• Get inspiration for project iterations scope (more on that in a future post ).

If this doesn't convince you, just ask the opposite question. What if I didn't create this model? When would the consequences have become clear and what would have been the impact at that time?

See you in a next post where we will talk about effectively defining the scope of a project iteration when using an E2E iterative approach.