It’s been around for over a decade, and, frankly, in most enterprises, all it’s made are enemies.
It’s “enterprise architecture” — or, as other parts of the business know it, “those damned do nothing laggards”.
Architects are far too often seen as swaggering into meetings, ready to tell everyone else what to do and how to do it, then taking forever to actually deliver anything.
Resolve binds the enterprise has put itself in? Think through value propositions so as to fatten the bottom line? Keep an eye on the total cost to own and operate the asset portfolio? Actually advance the enterprise towards a well-crafted future state?
Surely you jest. It just doesn’t happen anywhere near often enough.
There’s a couple of reasons why. First of all, in most enterprises, enterprise architecture is an add-on. The core is still the fixed development/maintenance team, aligned with a portion of the business. They think they are in the business of researching the future state, figuring out the steps to get there from here, and, of course, design and deliver all required solutions.
Then you have the unit that got overlaid on the organization just ahead of architecture: the relationship managers (or client managers). They, too, see their raison d’être as understanding business needs, researching solutions, and advocating for them.
So the typical enterprise now has three different units in the IT group all figuring they should determine the future. Did that help clear up some of the doubts about the claim that architects have made a few enemies?
But those enemies are not just within IT, adding friction and cost to everything that’s done. (Let’s leave aside who’s responsible for adding the friction at this point, and simply say that it exists, is palpable, and the trail of delays and costs run up is easy to find.)
No, they’re out in the business areas, too, where nowadays there’s generally an investment in so-called business analysts who — believe it or not — think it’s their responsibility to determine the future and how we get there from here.
What enterprise architecture is supposed to be doing is laying out the big picture. If anyone should be carrying forward ideas like “here’s our roadmap to reduce the total cost to own and operate our portfolio (TCOO)”, or “here’s the analysis on why we want to remove all the mods from these packages and what it means to the enterprise’s cost and value profile going forward”, or “here’s the notion of building intermediate data forms and a data bus to insulate connected portfolio elements, each on its own vendor-created change cycle, to minimize change costs in the future”, it should be the architectural team.
Instead, what I see as a consultant is architecture groups more concerned with turf wars than actually making a difference.
In one large financial services organization, for instance, it was the development/maintenance team leader who drove a multi-year removal of all mods from their ERP system, leading to massive future cost savings, a rapid change cycle forward, and more architectural progress toward a unified information architecture than ten years of the EA group had managed to make.
In another utility operator, architectural progress was made by the person responsible for the infrastructure, who took on the project of application replacement leading to a whole platform removal, the TCOO improvement from virtualization, and the rationalization of the portfolio from 600+ elements to 150. The enterprise architects were still in meetings three years later claiming it couldn’t be done.
A decade ago, META Group’s Enterprise Planning and Architecture Service (EPAS) laid out the core enterprise architecture process flow. Create or update a future state definition based on the core enterprise business strategy. Figure out a statement of change required and prioritize it. Ensure the changes advance the business, information and technology (TCOO) architectural principles agreed from the governance process. This informs the project portfolio. Solution architects then merge business analysis and qualitative requirements with that delta statement to come up with a set of specifics associated with that project to design a solution to bring the future state closer.
Why isn’t it happening? (The flow through to the bottom line bears no relationship to the ROIs projected, after all, something you can find out by looking at the quarterlies for any public company and asking what the minimum ROI to get popped off the backlog was in their firm.)
Now you may say, at this point, why hang getting those results on the architects? It’s a good question, because project management, a general lack of deployment support, and a refusal to measure in the business to improve results all play their part in that failure to achieve results, too.
But there is an old Yiddish expression: “the fish rots from the head”. EA is supposed to be the head of the process advancing the future.
On that score, it’s failing.
It will start succeeding when architects come into the meeting prepared to discuss the deltas, be firm about the rules required to manage TCOO, and arrive willing to deal in a complex state of work (where safe-to-fail experiments are used to resolve disagreements amongst the business-relationship manager-solution team-architecture table rather than endless complicated work domain discussion that alienates everyone and racks up cost and delay).
Until then, expect EA to be an continuing expensive drag on getting anywhere from here.