Ban the Word “Alignment” From Your Architecture

Something about the typical language of enterprise architecture is starting to bug me. The overuse of the word “alignment”. When people are asked to describe what enterprise architecture is all about, they often answer with the phrase “it’s about the alignment of IT with business strategy”. But is that enough? Should it be something more? Architectures fit into hierarchies of plans. Typically in enterprise architecture we say that our enterprise architectures must align with our business strategy, that our solution architectures must align with our enterprise architecture, our security must align with our enterprise security architecture, that our application architectures must align to our application architecture etc. etc.

Because when we say something aligns with something else, what are we really saying? We are saying that they don’t fundamentally disagree. That they don’t contradict one another. But is that what we really want from different parts of our architectures? Is that what we really want to say about the relationship between our organisation’s strategy and its IT architecture – that they aren’t inconsistent? Is that enough? Isn’t that just a cop-out?

In this case, as in many others, I think that how we talk about architectures (our discourse) reveals something important about our practice of architecture. It reveals how we are thinking about architecture and what we are doing to a certain extent.

Too often when people use the word “alignment” it just means that what they are doing isn’t obviously undermining the higher level objective. If we believe that through architecture we are trying to drive better outcomes for business from our use of IT, then we must demand more than just alignment. What we need, and therefore what we should demand, what we should describe and what we should talk about is:

  • Our architecture delivering higher level outcomes.
  • Our architecture contributing to higher level outcomes.
  • Our architecture supporting higher level outcomes.
  • Our architecture enabling higher level outcomes.

If your architecture doesn’t do any of these then you should have a damn good excuse (and there may well be one – tactical, temporary or risk mitigation architectures can often ignore these things for very good reasons). Otherwise, you should be able to demonstrate how it is doing one of these things, because that is how you will be demonstrating the value of your architecture.

Whatever we say (and do) about our architectures, I think we will be better off when we ban the word alignment.


9 Responses to “Ban the Word “Alignment” From Your Architecture”

  1. Like the post. Sometimes it helps not to have English as your native toungh, because it forces you the think more about the meaning of the English terms you use. In Danish (my native toungh) there isn’t a good translation for “alignment”, so I’ve always used the alternatives suggested in the post.

  2. True, too many conveniently, define and convey EA to the fluffy realm of strategy.
    EA alignment though essentially means transforming the enterprise (technology for instance) to perform what the business needs on an operational, tactical and strategic scale. And hence it is one of the key reasons to do EA,

    Any architecture in itself serves for better or worse, the business purpose and “higher level outcomes” because architecture is and describes the structure of the enterprise. If this structure is not “aligned” to the business purpose (for instance a school can hardly double as a residential building) the enterprise would barely deliver.

    Architecture, on the other hand, does not deliver by itself higher level outcomes (as goals) because it is only “architecture”, i.e. structured information about the enterprise. The EA architect, depending on case, maybe asked to contribute to higher level outcomes but that’s a different matter.

  3. Agree that ‘alignment’ is overused and misused, and that ‘supporting higher level outcomes’ is a better alternative. You say that the terms we use to describe architecture reveal much about how we think as architects — ‘alignment’ conjurs up images of a blueprint in which technology and business strategy are separate, and one (technology architecture) is created to serve the other (business strategy) once the latter is determined and bedded down. This separation reveals classical waterfall thinking. Technology architecture and business strategy can no longer be ’cause and effect’. I prefer to think of business strategy and technology as being intermingled, co-dependent to the point where you cannot do one without the other. There is no such thing as ‘alignment’ in a symbiotic relationship.

    • Hi Paul,
      The blueprint metaphor doesn’t spring to mind for me. But what that illustrates, I think, is that we should be wary of metaphors (as Richard rightly points out in another comment) as their interpretation can vary so wildly. For some organisations it is as you say – there is no separation. But for some organisations the separation is real, and it exists, I don’t think every organisation is quite as mature as you are suggesting – though it is where many should be.

  4. Great post. When people talk vaguely about the “alignment” or “gap” between business and technology, I am never sure if this is just a rhetorical metaphor, or if is it supposed to have a literal meaning. Here’s my challenge to the alignment brigade: I’m not interested in “business-IT alignment” unless it can be expressed as a percentage.

    • Thanks Richard – your post is exactly the sort of thing what I was thinking of. I’ve taken a different (non-operational) interpretation of “alignment” but the underlying concern we have with the discourse and the practice is the same – the term is empty or useless.

  5. “Is that what we really want to say about the relationship between our organisation’s strategy and its IT architecture – that they aren’t inconsistent? Is that enough? Isn’t that just a cop-out?”

    While not sufficient, it is necessary. Whether it’s a major milestone or a non-event would depend on the organization. Regardless, it’s certainly not a stopping point.

    • Thanks for the comment Gene. While I agree it is a necessary condition of a good architecture, my point is that it is a very weak statement – and in many cases we can see it is post-hoc and that instead of the strategy driving the architecture, we see the architecture being described in relation to the strategy after the fact.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: