Enterprise architecture in the agile era: Less policing, more coaching

When Adrian Jones became the sole enterprise architect for fast growing diagnostics giant SYNLAB in 2018 he knew the traditional, bureaucratic approach to EA he had seen in the past wouldn’t work.

Jones, SYNLAB’s group head of enterprise architecture, needed to quickly gather and analyze enough information to deploy new systems across hundreds of sites and more than 20,000 employees in 40 countries, and to digitize services such as lab tests to make them much easier for its customers to access.

Within 15 months, half the time Jones reckons a traditional EA process would have taken, insights from SYNLAB’s EA effort are helping the €2.6 billion company better manage its application and technical risk and to assess its technical debt (the cost of pending work required to maintain its applications and IT infrastructure). EA insights also helped SYNLAB roll out new services such as a COVID testing program to help the European football league safely return to play, says Jones. 

This is enterprise architecture in the age of agile. Rather than spend months or years modeling and cataloguing a business’ technology and business processes in an often-futile attempt to enforce product standards, agile EA practitioners and vendors seek to work more closely with teams developing “products” such as applications for employees or customers. They try to deliver value quickly, work closely with product teams, and develop architectural principles rather than an inflexible list of platforms product developers are permitted to use.

Not your father’s EA

EA was designed to identify, understand, and maximize the cost-effectiveness of the IT infrastructures companies created in their march from mainframes to distributed computing. This requires central repositories of information about their IT infrastructure and the applications and business processes they support. But too often, according to critics, EA focuses on cost-cutting and control over innovation, describing technology rather than the business processes that leverage it. And in an era when businesses must change ever more quickly, its pace too often acts as an impediment to transformation.

A Forrester Research survey found that 55% of clients still practice older forms of EA, which includes “treating enterprise architecture as glorified asset management, with a focus on cost control rather than maximizing IT capabilities for the good of employees, customers, and business partners.”

Traditional EA had a “very strong focus on technical architecture,” says Marcus Blosch, a vice president at Gartner, “trying to control everything in command-control mode.” Traditional EA “got itself into trouble, and many users still think of in that way.”

Deliver value quickly

One principle of agile EA is not to boil the ocean by collecting every bit of information about an organization before providing insights or recommendations, says Gordon Barnett, principal analyst at Forrester. To speed the process, agile EA practitioners refer to a “minimum viable architecture” or “just enough architecture” to meet an urgent business problem, making frequent changes to the EA process as needed. But, Barnett warns, the key is to choose the right elements to include to ensure that such a minimal architecture doesn’t limit its future usefulness.

For organizations that are heavily reliant on SaaS applications and the cloud, “a minimum viable architecture helps hold together that distributed ecosystem” with technology standards and more collaborative governance models, even if it doesn’t provide a central repository of the distributed assets that now support the business, Gartner’s Blosch adds.

At SYNLABS Jones began by concentrating on “the key pieces of information we needed to understand the business in terms of the application portfolio” and narrowed his search to, at most, “20 pieces of information about an application.” He then used the survey capabilities in Ardoq’s EA tool to capture additional data such as the cost and risk of the systems on which their businesses rely “to get [users] engaged … to give them something back immediately.”

He also used the surveys to allow users to provide information about their own technical and process portfolios and used Ardoq to enter that data into the repository even while interviewing users. This quickly gave users “a very clear view of their existing architecture, which they could use to model the future desired state,” he says.

One example was examining the blood sample collection process in one country. “I was able to play back to them, ‘Here’s what we understand of your system,’’’ says Jones. “They were completely blown away by that. It was the first time they had a top-down view of the entire process.”

Coach, don’t enforce

Since an agile transformation effort began two-and-a-half years ago, EA at consulting firm McKinsey & Co. has been less “an enforcer of standards and a keeper of metrices and diagrams” than an “enabler” and partner working with and across agile teams focusing on business outcomes, says Michael Sioufas, director of enterprise architecture.

“We don’t necessarily want to say, ‘Teams must do this or that,’ in a prescriptive tone. We give them tools [such as best practice frameworks], guidance and help them leverage those tools as much as possible,” he says.

Forrester’s Barnett says the principles encouraged by an EA group might reflect, for example, whether “an organization is operating in a very price-sensitive market,” which means “We will put cost at the center of all our architecture decisions.” For a different business, he says, quality might be a driving principle.

Such principles also enable product groups or business units to choose the tools that best meet their needs. For example, says Barnett, “for a high volume [business intelligence] data warehouse maybe you should use Oracle, but if a small office, maybe an Excel database. You might have hybrid clouds, with criteria for when people should use each one.”

Such efforts can falter, however, if “EAs do not want to empower delivery teams, and delivery teams do not want to be guided by EA,” says Barnett, adding that few organizations have effective processes for retraining EA staff as the automation of traditional EA processes frees them for more consultative roles.  

Another feature of agile EA is “digital labs” that, at global mining company Vale, serve as sources of experimentation in areas such as robotics, and the internet of things, says Marcelo Menard, Vale’s global enterprise architecture manager. These labs, along with developing a worldwide network of IT vendors for specialized needs, are part of a new EA approach that has helped Vale’s EA group to shift from being “a kind of police” to “one of the main teams driving innovation,” he says.

Power to the product groups   

McKinsey’s EA group has scrapped traditional enterprise architecture review boards, says Sioufas, in favor of a decentralized model that examines the epics (collections of user stories) on which agile teams are working, focusing on “where help is most needed and where there is a lot of overlap or synergies within the architectural product teams.”

Keeping an organization’s inventory of IT assets up to date can be a major challenge, especially with cloud-based, composable applications built from containers and APIs that are used only when needed. Blosch says that business units can be tasked with performing these updates, and be free to decide which components to update based on the needs of that unit.

Agile EA at work

Sioufas, who works as a domain architect for the consulting firm’s HR and finance groups, says McKinsey’s decentralized EA structure and use of various tools and frameworks “helps us to have a lot more insight across the different business domains we’re working in.”

When teams discover problems such as weak API security, conduct system consolidation, or manage technical debt, they tackle these tasks with “architectural swarms” of experts who gather much as an agile team would to meet the challenge. “We treat it as a mini sprint — a quick problem statement: What is the issue, which people do we need to get, what outcomes are we trying to achieve, and how do we measure success?” says Sioufas.

At Vale, its EA practice helped the company respond quickly to sudden changes driven by COVID, such as enabling remote inspections of equipment and the shift to remote working. EA helped Vale identify “the capabilities and processes we need to improve” as well as the processes it needed to automate, says Menard. Replacing formerly siloed repositories of architectural information maintained by individual lines of business with a “a single source of truth” for IT assets and applications helps Vale avoid duplication and prioritize IT projects, he says.

Whatever its past shortcomings, backers say, EA isn’t going away because it can’t. However agile an organization is, it has an enterprise architecture in the form of the hardware, software, and workflows that drive the business.  By adopting agile EA principles, EA practitioners can track, describe, and recommend changes to that architecture quickly and clearly enough to adapt it for ever changing business needs.