It’s a Journey – Don’t stop believing.

Aside

Not sure if I should be depressed or relieved after reading the The Enterprise Architecture Paradox. On one hand it smacks of futility of EA efforts and illustrates the frustrations of EA work, on the other it proves that we are not alone in our “journey”. For the time being we need to keep pushing and continue to realize those invisible wins. Don’t Stop Believing! Worth reading.

Surviving Enterprise Models – breadth over depth

It was with great interest that I read Nick Malik’s post “What makes models interesting“. In his post, Nick speaks about his EBMM model but the fundamental concepts of approaching modeling and the questions it poses are more universal and applicable to all kinds of enterprise modeling. Whether it is EBMM, ArchiMate, UML, or any other “notation du jour” there is always that temptation to add more to the model. I think it is human nature. After we model something with a given standard, we become familiar with the contents of the model and over time it starts to feel as too obvious to be useful. This in turn leads to temptation to “improve” it. Sometimes improvements are warranted and sometimes they aren’t. If they are driven by desire to answer some specific questions that contribute to enterprise value, then great, but if they are driven primarily by model purity or general quest for more detail then you may be well advised to take a pause. We don’t want to model just for the sake of modeling. Instead, we want to use the models for strategic and tactical planning, for architecture alignment across the enterprise, for optimization of operations etc. Just to be sure, I’m talking about enterprise models here. Models that aim to illustrate where the enterprise is and where the enterprise is going. Those who have been exposed to enterprise architecture at a large organization know what I’m talking about. They also know how challenging that is. The reason I’m making that distinction is because when dealing with models that describe specific solution you may want to get to whatever level of detail is appropriate to explain the solution to your audience. If you try the same for the enterprise-level models you may find that it is extremely difficult to tie everything together.

I know that some will question the wisdom of even having the enterprise-wide models and will tell me that I am better off to focus on a specific area or on a specific problem. Well, in the end it all comes down to what questions I am trying to answer doesn’t it? So back to the questions… The questions that we ask at the enterprise level are different from questions asked during implementation of a solution. Some of the enterprise-level questions may be:

  • Where are the undesirable system redundancies?
  • What systems rely on non-standard technology?
  • Which systems cost more to operate?
  • Which critical business processes are supported by high availability applications/services?

Some of the solution-level questions may be:

  • What type of interface is used to access a service?
  • Is service consumed synchronously or asynchronously?
  • What components are used to build an application?

All good questions, but not all of them can or should be answered with the same model. In other words, models have to be fit for purpose. Attempts to mix different concerns usually end in a mess. …And then there is this pesky law of diminishing returns. How much work do we want to put into the upkeep of the models? More detail means every time that detail changes the model should be updated, right? Now take that to the scale of a large enterprise with many system inter-dependencies and it translates into a massive amount of work. Detection of those changes alone is a challenge too because in a large enterprise change tends to be constant and occur in many places at the same time.

If we assume that the architects are the keepers of the models, we need to ask ourselves how much of their time should be spent on keeping the models useful. Useful models should be current and given the breadth and rate of change it implies a significant effort. It seems that architect’s time would be better spent on model driven analysis and planning (a.k.a. architecting). Otherwise, we are approaching the territory of modeling for the sake of modeling, where we devote most of the energy to maintaining the models and not having time to actually use them.

So what practical advice can we employ for enterprise-level modeling? Here are my suggestions:

  1. Ask yourself what questions are you trying to answer with the model and prioritize them. Set out to build models for a few high-priority questions first.
  2. Establish a set of modeling rules that you can apply on top of your favorite modeling notation. This approach will keep you at the consistent level and promote discipline needed to build enterprise-wide models incrementally.
  3. Resist putting more detail into models at least until you can be sure what it takes to maintain them at the current level.
  4. Keep verifying that  the models help you answer the questions for which they were built and adjust accordingly.
  5. Rinse and repeat, starting with step 1.

Happy modeling!