Integrating Enterprise Architecture – practical thoughts

1902 Glider from rear

Learning to fly. We didn’t get the Dreamliner right away.

It is hard to get excited about enterprise architecture frameworks these days…or maybe it’s just me. Of course, the framework-centric “certification industry” is in full gear producing “certified architects” but just like many other infatuations this one will pass too. There is already evidence that the enterprise architecture frameworks are entering disillusionment phase where the notions of sliver-bullet approach to enterprise architecture have failed (see Gartner Hype Cycle for Enterprise Architecture). With any luck, the streamlined, practical and value oriented approach to enterprise architecture will emerge from the through of disappointment.

Does it mean that the architecture frameworks failed to deliver? Yes and No.
Yes, because they failed to deliver the silver bullet. However, in all fairness, most frameworks never claimed that they had all the answers. In fact, they usually state that the best approach is to take those elements that work for your organization, and tailor them to the organization’s specific needs. In that sense, the frameworks failed to deliver what they never promised. No, because they provided a way to conduct discussions about the enterprise architecture function in a structured fashion. As flawed as they may be, they do embody some collective architecture experience, which can be considered a best practice.

I can’t shake the feeling that many mainstream enterprise architecture frameworks are a better fit for smaller-size companies or for individual segments of a large enterprise. They seem to be assuming the process and the flow of information that are mostly undisrupted by conflicting priorities. They seem to underestimate the complexity and cost of managing architecture information on a larger scale. This is ironic because enterprise architecture by definition makes more sense for large, complex environments where aligning change to strategic goals truly is a “full-time job”.

Implementation and application of some architecture framework as the foundation of the enterprise architecture function is usually a good idea but doing it in context of a large enterprise can be challenging. There are distributed decision centers, often fragmented architectural information, large number of stakeholders,  and many, many moving parts. In this context a lot of energy goes into efforts that aim to integrate the disparate processes and information so that the enterprise architecture function can be executed in a coherent manner that is worthy of the enterprise scale. Enterprise architecture frameworks don’t provide complete answers to this challenge. Instead, they give us a picture of a somewhat idealistic future state with the hope that we figure out how to get there.

Situation like this may call for a pragmatic approach to implementing the function of enterprise architecture. To be perfectly clear, “pragmatic” doesn’t mean devoid of structure and solid footing. It means “systematic”, “gradual” and “environment-appropriate”. It means not taking the frameworks literally but applying what fits YOUR organization, and pushing for change at the pace that does not overwhelm. One way to articulate this approach is through the set of guiding thoughts that may sound like this:

  • Know why you want enterprise architecture TODAY. Focus on generating value for business sooner rather than later. Enterprise architecture usually enables good things in the future but may struggle to deliver immediate benefit. Find the immediate one! It may be in the least expected area, like using architecture models for impact analysis or project team onboarding. If you can realize short-term benefits and point to quick wins with architecture, you will be able to gain enough support to realize other, lofty goals.
  • Be mindful about how much architecture information you can manage. Enterprise architecture function has to be sustainable.  Cost-benefit analysis must be done upfront and may lead to compromises in how you describe architecture.  Favor breadth over depth and don’t be tempted by desire for more detail unless you have clear understanding of how it will contribute to the net value for business.
  • Models developed organically in silos will not blend well. Out-of-the-box modeling languages are too ambiguous to allow consistent integration across siloes. Consider focusing on a subset of element types first and establish a set of rules on top of a standard modeling language.
  • Build on the existing foundation. You already have processes. Use them, tweak them, repurpose them. Big change is expensive.
    You already have a language. It is the one that the business uses. Use it where you can and don’t force the business into enterprise architecture vernacular. Remember that the business cares about value and not about your cool architecture framework.
  • Establish architecture taxonomy first. Considering the previous bullet, build and publish the catalogs of common architectural elements like processes, applications or services. Make sure to have enterprise-wide agreement to use the catalogs when discussing those common elements.  Again, don’t force the architecture language on all stakeholders. Instead, use theirs and translate internally.
  • Establish information ownership and governance. Controlled management of change inspires trust. Whether it applies to catalogs of apps, services, or models, change must be managed to ensure that the information is reliable. However, don’t go overboard with control as it may create perception of bloated bureaucracy. Focus your control efforts on big-ticket items that are used to link information across many sources. Examples of that could be an application portfolio or a service portfolio.
    Interests of all stakeholders must be represented when the change is proposed. For that reason, establish the role a data steward and position it to facilitate stakeholder collaboration and consensus building.
  • It’s about information, not about the tools. Invest in information and ensure it is expressed in a standard way. Exiting standards like BPMN, ArchiMate or UML may be a good start. Standard-based approach increases the chance of portability of the underlying data between different tools. Start with simple set of tools and once you learn how to manage the information you will be in better position to introduce some big, expensive tool down the road, if you really need one. Vendors of “Cadillac” tools want you to believe that their offering will solve the enterprise architecture problems. Their approach often requires big upfront investment and managing information in a way prescribed by the tool. The problem is that if you don’t know what you want it will be very easy for the vendors to sell you anything. Learn where the value is first.
  • It’s about people. People don’t like change but will lie about it. You may quickly realize that in most people’s minds change is good only when it is someone else who has to change. This may be amplified in highly siloed environments where organizational and ownership structures have been fossilizing over the long periods of time.
    Securing the executive support for the enterprise architecture initiative goes a long way. Strong and firm leadership from the top with clear messaging about the value proposition is a must. Without it, you will get nods and smiles but not much cooperation. The executive support can be thought of as a stick in a “carrot and stick” combo. The carrot takes us back to the first bullet of this rambling, which talks about short-term benefits. Build bottom-up advocacy by showing immediate benefits from the integrated enterprise architecture information and play into people’s self-interest.

It goes without saying that the above thoughts may not apply to every situation. However, I suspect that at least some of them may be worth considering whenever the implementation of the enterprise architecture function is undertaken.
Enterprise architecture function on a large scale can be very challenging. Chances are that if you are reading this post, you have tried or are trying to advance the enterprise architecture in your own environment.  What are your experiences? What approach really worked for you? What didn’t? I would love to hear from you.