Enterprise Architecture Is Dead; Long Live Enterprise Architecture

During my years working on the sell side of IT, one of the most common refrains from both customers and my colleagues has been, “We need Enterprise Architects.”?Interestingly, this statement often came from organizations that had a substantial Enterprise Architecture organization.?But even where Enterprise Architects existed, it seems that the incumbents lacked a certain respect.?So where are all the Enterprise Architects??And why is it that no one can find them?

I don’t think it will come as a big surprise to anyone in the industry, but my belief is that Enterprise Architecture is one of the most poorly understood and poorly executed functions in technology.?More controversially, I believe that EA needs a fundamental rethinking, to re-align properly for digital organizations and those aspiring to become digital organizations.

But before we go too far down the road of transforming EA, let’s consider what Enterprise Architecture is, and perhaps most importantly, what it is not.?Again, thinking back on the conversations I have had with colleagues, my impression is that Enterprise Architect is a synonym for “clever person.”?This is especially the case when I hear something like, “We need Enterprise Architects, but not those Enterprise Architects.”?There is a notion in many people’s mind that an EA is a super architect, one that can build solutions across functional domains, or drive value in complex implementations.?I would argue that people who do that are actually solution architects.?And the solution architects that can solution across domains or build complex systems are the very best of the best in that discipline.?EA represents something different to me.

“Enterprise Architecture sits at the intersection of business and IT.”?I think I’ve heard that a million times, but what does that actually mean??Let’s drill down a bit to investigate.?First off, what would we expect the business to bring to an EA discussion??This may seem like an odd question for a technology practitioner to ask, but one of our most consistent professional weaknesses has been our inability to ask for what we need from the business (and relatedly, to complain when the business fails to be clairvoyant enough to provide it). For the most part, I see these discussions start with capabilities, so I would expect the business to arrive with a view of the business capabilities needed to execute against the strategic vision of the company.?For instance, if the company’s strategic vision is to increase customer intimacy, I would expect that business to articulate what business capability is required to get there, something like, “We need mass personalization of offers.”

The next step is where I generally see EA go off the rails. ?Most EA organizations will then consider what technology capabilities are required to deliver the business capabilities.?The EA team then dutifully puts into their EA “future-state” diagram a data and analytics platform and a new customer engagement platform.?Now, the EA team has a proper, business aligned roadmap which will deliver a technology capability to support a business capability, and hence deliver on the strategic vision of the organization.?Done and dusted.

I wish.?Unfortunately, I often observe is that there is little or no grounding of either the business capability or the technology capability in the drivers that create value for the organization.?Value is not driven directly from business or IT capability.?Value derives from some of the more fundamental business aspects of delivery: things like optimized components of the value chain; or contributing to business unit revenue/profit targets; and most importantly, delivering specific use cases that monetize the business capability for organizations.?Since EA does not directly address these in most cases, EA is generally seen as an ivory tower exercise which fails add value.?Hence the call for “not those enterprise architects,” and for super solution architects to save the day.

EA also generally has a mandate to act as a governance checkpoint (or even governance control) for new initiatives.?Since the EA diagrams are not seen as useful, when EA vetoes or asks for a modification of an initiative because it contradicts the EA roadmap, very few people see this as credible.?The result is that EA is seen as a barrier, the “no” team, rather than a function that adds value to the organization. The result is often that the business gets whatever it wants, regardless of whether the solution scales, is secure, is duplicative of current functionality, etc.

So how can we transform EA so that it is grounded in real value drivers and governs effectively to implement those value drivers effectively??I think the answer lies in articulating use cases.?The common language between the business and IT is not focused on capabilities, i.e., what we are able to do, but rather on use cases, i.e., what we are going to deliver for customers.

Use cases have technology capabilities which are needed to deliver. Those capabilities are delivered by specific IT systems leveraging particular data types.?Positioning use cases between the business capabilities and technology capabilities creates an anchor in the organization where EA can demonstrate the value of the technology: what it does, not what it can do.

In addition to anchoring in value, leveraging use cases creates a tangible method of evaluating the EA.?Instead of looking at whether technology capabilities make possible business capabilities, the question is whether technology capabilities deliver use cases effectively.?This prevents over-engineering since the use cases define specific features either included or excluded.

Finally, this also enhances the governance role for EA as it creates a basis for a discussion around technology substitution.?If the business insists on a particular technology platform to achieve its goals, if that platform is not part of the roadmap, the probative question is not what capabilities does the platform bring (which leads inevitably to the classic “my software is better than your software” discussion), but rather whether the technology in the roadmap can deliver the specific use cases identified as value-generating by the business.?Can the platform support the necessary features to deliver the use case??That’s the question that adds value, and where EA can really make a difference in terms of governance as well as design.

The current configuration of most EA teams does not support this kind of thinking. ?Most EA teams I see adopt the “super architect” model.?The best of the domain architects are put together in a team and told to collaborate.?Even when this works reasonably well, there are two massive disadvantages: (1) use cases for the technology capabilities are often unclear and therefore any kind of analysis is abstract, time consuming, and divorced from tangible business value; and (2) the very best domain solution architects are removed from delivering solution architecture. Taking the very best in your organization and asking them to address something with an unclear business value linkage is unlikely to yield good results for you or your business.

I suggest an alternative: align the EA organization against two axes.?The first axis is aligned against the value chain elements of organization.?For each of these elements there is an enterprise architect assigned whose primary responsibility is working with the business stakeholders to articulate the use cases that demonstrate the required business capabilities, and to articulate IT capabilities that can deliver those.?The EA is responsible to identify re-use opportunities within the existing platform as well as ensuring the use cases are specific in how they link to value drivers and business capabilities. ?This is not a “super architect” role.?The EAs need to understand technology, but need to be equally conversant in the business, understanding the value chain and business capabilities, so that the use cases make sense and can be effectively and efficiently delivered. In fact, because this is such a radical overhaul of the traditional EA role, I suggest over-indexing on the business skills of the EAs, at least until the organization develops a confidence that EA has become a useful function.

The second axis is the governance axis.?For these people, technical skills are critical, but the EAs focused on governance also need to be able to leverage the domain architecture capabilities outside of the EA team.?The objective is to minimize the number of people required for the governance function and to keep the best domain architects in the domain where they excel.?Inevitably, this means a matrixed set of responsibilities for the domain architects which can add complications to the typical organizational chart.?The benefit is that the domain architects can no longer blame the EA team for being out of touch or not really understanding the domain.?In effect, these domain architects become the EAs, at least in terms of governance, but they still retain their roles in the domains.?This ensures that the quality of domain architecture remains high as governance becomes more effective.

Very few EA teams look like this now. But as organizations begin to deepen their commitment to digital, deepen their commitment to agile, work to get the most value out of their architecture teams, and optimize their workforce given the constraints of the current labor market in technology, EA needs to change.?Enterprise architects should not be misunderstood as “clever people” or a distanced governance function, the "no" team.?They need to demonstrate value in every interaction.?An Enterprise Architecture function focused on use cases while leveraging domain architects for governance can add tremendous value to an organization.?With technology becoming more deeply ingrained in every business activity, Enterprise Architecture needs to adapt or die.