Earlier this month, author, IT strategist, and pyromaniac Charles Betz wrote a column for The Data Administration Newsletter that asked the question, “Is Agile killing enterprise architecture?”
Not satisfied with a minor campfire, I figured I’d fan the flames, so I posted links to the article to several EA-focused groups on LinkedIn. Little did I know at the time the conflagration that would result. Clearly this question found some dry combustibles.
Time to fetch the gasoline and provide my take on this question. What could possibly go wrong?
Definitions and Elbows – Everybody’s Got a Couple
Over the years I’ve written on numerous topics, but the one topic that’s sure to get the most comments is enterprise architecture (EA) – especially if the definition of EA is in question. It seems there’s nothing an enterprise architect likes to do more in this world than opine on what EA is and what it isn’t.
Perhaps EA is IT portfolio management. Yes, someone has got to keep track of all the applications, servers, and other miscellanea cluttering up the enterprise’s data centers and clouds. Even better, keep track of when everything is going out of date, and while you’re at it, make a note of how everything talks to everything else.
IT portfolio management is important to be sure, but is it EA?
Or perhaps the core of EA is some set of diagramming activities – or modeling, or planning, or visualizing, or documenting, or some other word that boils down to drawing pretty pictures. Everybody loves pretty pictures to be sure. If your three-year-old draws one for you, it’s definitely going on the fridge. But is it EA?
Or maybe EA is essentially governance. If someone from a line of business wants something from IT, they have to pass the request by the EA gatekeepers first. After all, nobody wants duplication or spaghetti integration, right? Been there, done that, got the T-shirt. So nothing gets done until EA gives it the stamp of approval.
If that’s the definition of EA, then the first thing we should do is burn that sucker to the ground. There’s no way any organization will ever be agile if there’s a whole department in charge of roadblocks. If Agile is up to the task, then more power to it.
My Kingdom for a Capital A
But wait, you say! In that last sentence, I used the word Agile in one place and agile in another, and the meanings were entirely different. The simple act of capitalizing the first letter took a basic business concept and turned it into a religious argument.
Agile-with-a-capital-A, of course, refers to the Agile Manifesto, and the software development methodologies like Scrum that follow its precepts. How do you know if your developers are following Scrum? Simple. If they have meetings standing up, they’re following Scrum.
These standups as they’re called are an important Scrum doctrine. And as with any religious mandate, if you screw it up you’re in for a world of hurt.
Or perhaps, worshipping the dogmata of the Church of Agile is missing the entire point. The aforementioned Manifesto, after all, called for an iconoclastic approach to software development.
If the rules and regulations and paperwork and all the rest of the folderol that comes with traditional software development are getting in the way, then chuck them out.
We have peeled this onion sufficiently to understand what we’re really asking when we wonder whether Agile is killing EA. If EA amounts to a bunch of documentation, and if Agile calls for chucking out all the documentation, then certainly Agile is calling for the demise of EA.
But those are two enormously hairy IFs. Certainly if some company’s EA means nothing more than a lot of paperwork that gets in the way of basic goals like working software that keeps customers happy, then we can only hope Agile drives a nail into that coffin.
On the other hand, sometimes paperwork is a good thing. Only an overly dogmatic reading of the Agile Manifesto would lead one to conclude that we don’t need no stinkin’ documentation.
Taking a more iconoclastic view of Agile, therefore, would indicate that rather than killing EA, Agile might actually help us separate the EA wheat (the good bits) from the chaff (all the paperwork or governance-laden bottlenecks that are doing us more harm than good anyway).
EA: The Good Bits
Fair enough. Let’s pour all of EA into our Agile sieve and see what comes out the bottom. Surely EA isn’t completely useless?
Here’s the rub: a lot of what passes for EA is in reality either useless, or may be useful but isn’t really EA (like IT portfolio management). So before we can theorize what our Agile sieve might yield, we must first define what EA should be.
Skip the gasoline, folks – let’s just chuck dynamite on that fire! There’s only one question that sends architects into a tizzy more than the “what is EA” question – and that’s the “what should EA be” question. And yet, in spite of years of arguing, we really have no consensus on this question whatsoever.
This question is so intractable because it has three dimensions. First, we must ask: of all the practices anybody in the enterprise might undertake, which are the ones they should undertake.
Second, of all those desirable practices, which ones do we want to lump under the EA banner, rather than falling into some other category?
The third dimension is the trickiest of all: the dimension of change. As business needs evolve, how should the practice of EA keep up?
Just because we might identify a particular practice today as something that EAs should do, that doesn’t necessarily mean that we’ll want to keep doing it – and it also doesn’t necessarily mean that we’ll want to keep calling that practice EA, regardless of whether someone should still be doing it.
No wonder so many people are calling for EA’s demise.
The Intellyx Take: Rethinking the Agile Sieve
In the end, ‘Is Agile killing EA?’ is the wrong question. We don’t really care what EA has been or should have been up to this point in time. Water under the bridge.
And the right question? Perhaps it’s ‘How can Agile help us transform EA into what we need it to be?’
Of course, that question falls short as well. Perhaps Agile can help, perhaps not. Clearly, dogmatic Agile can’t help us with this question. We must also ask what Agile should be as well.
Instead of thinking about Agile, we must seek to become agile. How can our companies deal better with change overall?
The true question, therefore: How do we transform EA to help our organizations become more agile?
Ladies and gentlemen, start your fires.
Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Erik Olson.
Jason – I concur with the trust of your argument. My take is that folk (and organisations) tend to follow the buzz-theme’s of the day / period – and then institutionalise them in the hope they the new buzz theme will fix their problems. In so doing an ‘internal’ industry (often egged on by consultants / vendors) gets established – and generally little real value emerges. Also we see new words being applied to old-themes so that under a new veneer, ‘new’ buzz themes appear.
Instead what is important is to understand the key principles behind the theme – and where appropriate, apply/shape the principle to the particular challenge of that organisation.
For me ‘Enterprise Architecture’ is about creating the high-level framework for what is needed within the organisation (in the context of the organisational strategy, operating model, customer propositions, organisational culture etc.). It needs to be kept simple with as little documentation as possible. It also needs to be reviewed regularly to ensure it remains appropriate to the evolving nature of the specific organisation. As a framework it should then guide the particular project / new investment projects / programmes which are taken forward. ‘Agile’ is about the process of delivering minimum viable new capabilities (within that overall framework) to enable both rapid deployment and more importantly rapid appraisal of these new capabilities to help guide further iteration / development of those capabilities. This learning may require some re-appraisal of the overall framework.
In both cases, the level of documentation should be the minimum necessary to be appropriate to the task in-hand – and in the context of what is necessary to maintain effective subsequent operations.
Neither ‘Agile’ nor “EA’ by themselves provide silver bullets. Common sense pragmatism which develops from a deeper understanding of the core principles or architecture and project management is in my view what is necessary to deliver real value.