All Effective Enterprise Architects Are Agile

I explained to one of my clients recently that there is a perception of animosity between the Enterprise Architecture community and the Agile community.  Both sides make assumptions about the other, often assumptions that are simply unfair.  For example, many in the EA community think of “agile practices” as an opportunity to develop software without any architecture at all, while many in the agile software development community think of architecture as one of the “big design up front” guys who oppose their principles and practices.  Of course, it is not difficult to find people who fit those unfair descriptions, but I’d like to point out how these two viewpoints are similar.

I believe that effective Enterprise Architecture must be approached from an agile standpoint. 

First off, what does it mean to be agile?  We can always look to the agile manifesto for some guidance, but more recent publications do a good job of filling in some of the details as well.  I include a number of things in the notion of “being agile.”  These are not just from the agile manifesto, but also Kanban and the Theory of Constraints, Systems Thinking, Six Sigma, Scrum, eXtreme Programming, and value stream analysis.

• A focus on performing high-value activities, and removing low-value activities.
• A focus on empowering the people who make things to make decisions about how those things should be made.
• A focus on developing small increments of actual value on a frequent basis and getting direct feedback on them.
• A focus on making sure that one thing is “done” before moving to the next, so that we reduce “debt” as we go.
• A focus on modern practices that remove ‘deployment impedance’ like test driven development and continuous integration.

I follow the terminology of Sam Guckenheimer in calling this the “Agile Consensus.” 

We have to recognize that the "agile consensus” is an approach, not a methodology.  It is a way of thinking about dealing with problems.  More importantly, it is a way for dealing with complex problems.  The diagram below comes from Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey.

When we look at the problems that software is being used to address, and if we look at the process of writing software itself, we have to recognize that both areas of problems typically fall into the category of “complex.”  Not always.  Some software is simply configured and configured simply.  Some problems that software addresses are simple problems.  However, most of the discussions around software development are fueled by people addressing complex problems because that is where most of the software development community works.  It is the bread and butter of software development: solving complex problems in a complex way.

Enterprise architecture also deals with complex problems.  EA models and information are also complex to build and manage.  In this way, EA is very similar to software development.  EA solves complex problems in a complex way.

In order for EA to be effective, it has to use the same mentality as agile software development.

When I speak with enterprise architects who are actually doing the job of EA, big themes quickly arise:

• do the work that is highly valuable and don’t do the work that the business doesn’t value
• build consensus where it actually lives, not where the “people from above” believe that it does
• deliver value quickly and in increments that your stakeholders understand
• leave your repository in a good state of completeness with all the data that others need to use it
• build in the deliverable artifacts into the business processes that need it, so that you get immediate feedback

If this looks like the list above, that is intentional.  I am trying to point out that Enterprise Architects use agile ideas, even if they often don’t use the term “agile” to convey the message. 

Why use these techniques?  They work for complex problems. 

Can someone think of a more complex problem than helping to move an organization towards their goals? 

EA addressed complex problems.  Agile thinking helps them to do it.

Comments

• Anonymous
  January 15, 2013
  Very insightful.  I couldn't agree more.

• Anonymous
  January 15, 2013
  At least in The Netherlands, some enterprise architects explicitly call themselves agile (myself included). Significant visibility of agile ea for example in Rotterdam harbour and Dutch Department of Defence.

• Anonymous
  January 17, 2013
  The comment has been removed

• Anonymous
  January 29, 2013
  "build consensus where it actually lives, not where the “people from above” believe that it does" That's not always done as easily as said. It's important to make sure the "people from above" have a clear understanding of what enterprise architects do so they can better understand what needs to be done. When there is a disconnect between the two one party ends up fighting with the other for control.

• Anonymous
  January 29, 2013
  The comment has been removed

• Anonymous
  January 30, 2013
  The comment has been removed

• Anonymous
  January 30, 2013
  Glad to meet you Daniel.  If there is anything I can do to support your journey, don't hesitate to reach out to me via this blog or on Linkedin.