Responding to Change: EA & Agility

EA doesn't institute agility. When adopted and executed properly, it helps structure an enterprise so that it can move with agility if it chooses to do so. The practice of Enterprise Architecture enables a company to respond to change.

When you read this, read it aloud and try using air quotes in real life wherever you see me use double quotes in the text. It’ll be more puzzling, exasperating and/or amusing that way.

I was having a conversation the other day with a colleague. The topic was a particular project that wasn’t moving very quickly due to issues understanding in clear detail the nature of the business problem. This colleague said “we really need to institute some agility here.”

I’ll give you a moment to digest.

This colleague was implying you could basically just “pick up” agility and, you know, start “doing” it.  It’s almost as if he believed that the entire concept was as simple as a 12 step program in a self-help book or a installable runtime from github. Agility isn’t something you randomly insert into a project whenever it seems to be incapable of responding to change or runs into “trouble”. Nor does agility “speed up” the regular SDLC if agility wasn’t there to begin with.

After that conversation, which by the way ended with the colleague exhorting my enterprise architecture team to “do something” about the lack of agility, I Googled “agile architecture” and got some interesting results:

  • Business Agility using ArchiMate with TOGAF
  • Agile Architecture: Strategies for Scaling Agile Development
  • Agile Architecture – Scaled Agile Framework
  • Agile Enterprise Architecture
  • In Search of Agile Architecture

The colleague also referred to himself as a “scrud master” so I guess I shouldn’t have been surprised. But I digress.

 

Isn’t EA already agile?

You can try different Google search combinations of agile and architecture and business and agility, etc. The results are often similar. Parts of the Interwebs believe agility is a methodology, a framework, a tool. I suppose the inherent difference is between Agile and agile, or Agile and agility. That is, the commercialized lifecycle management approach complete with certifications and books and whatnot, versus a state of being. I contend you’re either agile or you’re not. Regardless of whether you use Agile or not.

There is also an accompanying viewpoint in many of those search results that Enterprise Architecture as it is practiced follows TOGAF or Zachman or what have you, and is inherently “vertical” and “top down” and therefore can be “made” agile by using Agile. The suggestion appears to be that agility can be modeled in the same sense that EA is depicted. I understand the need to have pretty diagrams and charts within your architecture framework that attempts to model EA and its practices. Think FEA’s three-dimensional cube – very pretty to behold. But even so, it seems to me that being agile isn’t simply a matter of looking at a colorful chart of boxes and arrows and using Agile.

I think the disconnect comes down to a fundamental misunderstanding about what it means to be agile. Agility isn’t about simply “speeding up” a development lifecycle or making things move faster in general. If it were, it’d be called “Speedification” or perhaps “Fastiness” – I’m still taking submissions. It is almost like confusing speed and velocity. No agility isn’t always about speed. Agility is about possessing the ability to rapidly and nimbly respond to change. That change could be business, technology, market conditions, macro-economic, personnel or an act of God. A response to change may, in fact, be a response that temporarily slows things down as efforts are re-oriented. The point is being able to clearly identify the offending change and execute a response strategy based on the changed conditions in order to seek some advantage from the change (or at least prevent the change from negatively impacting your business).

 

It is called ENTERPRISE architecture.

EA is aptly named. It isn’t vertical only. It is by its very nature both vertical and horizontal. It is all-encompassing. EA is omnipresent. It should be called OA.

EA doesn’t “institute” or “do” agility and while it is compatible with Agile, it doesn’t mean that if you use Agile that you will be agile. When adopted and executed properly, EA helps structure an enterprise so that it can move with agility in the situations it chooses to do so. The practice of Enterprise Architecture enables a company to respond to change with agility.