What Needs to Happen for Enterprise Architecture to be “Agile”?

Let’s start with a given.

In most businesses today that are adopting agile:

• Agile is not mandated, defined, or driven by any technology function.
• Agile is not mandated, defined or driven by the architecture function.
• Agile is being mandated, defined, and driven by the business.

Agile is almost an act of revolution by the business. They want to get something done without the “Frozen Middle” spoiling the fun and slowing things down.

So our context is: “Where agile is mandated, defined, driven, and governed by the business, how — and where — should the architecture function participate in that agile process?”

This perception has been determined by recent professional work where agile is mandated, owned and operated by the business. I think this is the emergent preferred model for businesses globally. (Tell me if you see different market directions in Europe or North America.)

Sadly, in this paradigm, traditional architecture is at risk of becoming a “reactive order taker”.

The business will say: “We need something that will allow us to deliver x. Quickly!”

Architecture will say: “We need more time to consider and understand” or “We can’t currently support that, because x”.

So the business goes out and sources — internally or externally — whatever technology and services they require to deliver a solution quickly. And the business and the agile teams call that agile.

But the architecture function (and IT Services Operations function, even if they’re now in the cloud) is left to deal with the inevitable subsequent architecture debt of new digital solutions and information that do not integrate with pre-existing services. Or that create duplicating or conflicting business process and information.

Unfortunately, Service Designers, UX Designers, Business Analysts, and SMEs, working on Epics, PIs, and ARTs rarely have visibility of the broader, end-to-end, portfolio of enterprise services and strategic directions sufficient to tell the ART teams “Hey, wait, we already have that API, or service, or technology” or “That API will be available in six months”.

ART teams typically are working in a silo mandated by an Epic Owner. That Epic Owner is typically the General Manager of a business unit. A silo.

If there are multiple owners of an Epic, we often end up having the same old problems we’ve always had of “shared accountability” — there is no real single business executive willing to assume complete business ownership, accountability, and risk.

I see a problem. This problem is, indeed, reminiscent of the challenges created by “end-user computing” that we (those of us old enough) experienced in the ’80s and ’90s. Ungoverned end-user computing created an “enterprise integration nightmare”. In fact, enterprise architecture is largely a response to that historical problem of enterprise integration.

Agile is great for creating new digital services and experiences quickly, but the broader perspective (interoperability across existing or intended services) that should be provided by an enterprise architecture function is often missing.

To support an agile enterprise, enterprise architecture needs to provide a framework of infrastructure into which new services can be quickly and easily designed and realised.

There are “Architecture Epics” that require large amounts of capital investment, and involve high-impact to all business units and many capabilities and solutions. And that can take several years to deploy.

Agile tends to focus on designing and realising digital solutions. Agile is often unaware of the need for, or existence of, “enabling enterprise infrastructure”.

Agile is hot. Agile is immediate. Agile is human-centred. Agile is about the business delivering innovative services for customers. Agile is intentionally flexible and — to a degree — unplanned (or intentionally not over-planned).

Architecture, on the other, hand is cold. Governance is cold. Auditability and performance measurement are cold. Budgets and OPEX governance are cold.

Architecture is the grumpy old person who always used to tell you that you can’t do something you really wanted to do when you were a kid.

Architecture is your lawyer or tax accountant telling you how risky something is, saying “there may be consequences if you do this, and you need to be aware of them before you do this.”

Agile says “Let’s just do it and see what happens.”

Agile is exhilarating. Agile is young. Architecture is the dead hand of caution, prudence, and anticipating consequences.

Agile is great for small start-ups. Agile is just what you want for creating an app. Getting agile to work for large enterprises — with all the complexity that exists within large organisations — is challenging. But there are large organisations trying it.

Long-term strategies and roadmaps for enabling infrastructure are definitely cold. This is true even for organisations that have sought to follow Gartner’s “Two Speed” pattern. Much of the agile top tier of enabling infrastructure ends up being dependent on, constrained by, and often tightly coupled with, the supporting legacy operational platforms needed to run very large organisations.

The enterprise architecture framework needs to be designed and provisioned with agile design and delivery in mind.

However, the architecture function often is unable to obtain capital funding to provision common, consistent, contemporary infrastructure.

This is a dilemma that everyone in business and technology is working to understand. It’s not going to be easy. There will be blood.