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.
Very insightful. I couldn't agree more.
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.
The word 'value' interests me. I do not have an Agile background but if it purely means dollar value or it's equivalent measure in user (consumer) demand I'm not sure I like the idea. I appreciate the concept of priorities when architecting and enhancing systems but what bothers me is that users may have requirements that need to be properly met by fundamental and costly time (money) architectural changes, but a kludge is made time and time again because there is no way to 'value' upgrading the systems bones or even rebuilding completely. An Enterprise Architect or technical specialist of some kind could make an intelligent decision, not users requesting additional 'valuable' features. Is this properly covered by an Agile approach I wonder?
"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.
Hi Nancy,
Well, reality often conflicts with our models of reality. The folks from above have a right to express their desire for control. However, control is often counterproductive. The EA is quite rightly in the middle, as you point out. Our role, in addition to conveying what we do, is to challenge the "controls" in such a way that allows the folks from above to recieve the benefits that they were hoping for, while allowing the people who get things done to get things done in the way that works best. Optimization can be local.
Realize that the notion of central control often runs counter to the notion of federated management. Usually, the "edges" of an organization (where work is actually done) will give some credence to the goals that the central authority wants to accomplish. They will rarely implement the controls that the central authority imposes in order to achieve those goals.
EA is not here to be a central IT police officer. We are here to bring the goals to value through execution. If the only way to do that is through federated management in an organization that resists federated management, it may be the ROLE of EA to bring about federated management rather than to enforce controls that cannot produce optimum results.
We have to do the right thing, especially when it is difficult.
With respect and regards, Nick
Hi Nick,
I just stumbled across your Blog because I was searching for the combination of EA and Agile PM. I come from the world of development, crossed Software Architecture and now landed in IT Project Management. I am coming now more in touch with EA now, since it is actually just about to start in our organisation and knowing the stuff more or less only from paper out of interest, I am starting now to get closer.
And having said that, I am not yet in an Agile or EA camp. And would (naively?) never had the idea that those camps argue with each other thinking they are opposite creatures.
Actually, when I heard that I might get a role in EA soon, I was approached because I said that our EA could use some Agile injection. Specifically the techniques to break big deliverables down into smaller ones and getting through them in sprint sessions with a dedicated focus on a specific subject and goal is what many planners are missing. It is also a reason that many peope feel disconnect between EA and the rest (at least in our organisation, might be due to the fact that EA is new).
Bosses are still a bit insecure with what EA is actually doing, becuse "it always worked well without" (which is not true, you guessed it) and folk getting things done feel that there will be no more things being done because EA will take all the ressources away to draw diagrams.
To summarise: to high level and abstract for the guy doing stuff and too much jargon and intangibles for the guy planning stuff.
And then Agile (or other similar PM or IT techniques) come in, are adapted slightly and manage to make the abstract concrete and to slowly and steadily integrate EA ideas into real projects. Making the project team believe in it and making the sponsors see tangibles.
So I am grateful that there seems to be, apart from the two camps you started with, in fact a growing camp of agile EA folk. And I'd be happy to put my tent around there somewhere.
Daniel
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.