By Christian Lilley, Klaas Ole Kürtz, Henning Soller, and Christian Stüer
Since the early days of IT, the importance of the architecture function has been appreciated. It could be described as the art of making sure the many systems, products, and platforms within an organization work together seamlessly; critical concerns such as security, reliability, and operability are incorporated; and business change requirements are delivered within the expected time frame and cost parameters. An effective architecture function also aims to generate efficiency and scaling benefits by platforming reusable assets and defining common patterns.
As a result, some organizations have established architecture as a stand-alone department. Even many hollow IT organizations—those that contract out all hands-on product development—have kept architecture in house, viewing it as essential and nonfungible.
Especially in highly regulated industries, the architecture function is often seen as inseparable from essential governance and compliance requirements. However, reducing the role of architecture to a compliance function or separating it from day-to-day operations confines its value to a policing entity or an abstract function in an ivory tower.
This notion of architecture as a discrete and separate function is further challenged in a digital enterprise: architecture does not have a natural home in the idealized model of a flat, distributed agile-delivery organization made up of developers, designers, testers, and product owners. Some agile proponents view the discrete architecture function as a silo that interferes with the natural flow of information and problem solving between agile teams and their engineers. It can even create a learned helplessness in development teams, depriving them of the ability to flex their architectural muscles and learn by doing.
Nonetheless, adopting comprehensive architectural goals and standards allows organizations to establish shared objectives, agreed-upon guidelines, and a common language. We therefore believe every software organization benefits from an empowered architecture function, regardless of its structure. (For more on the role of enterprise architects in today’s digital environment, see “How enterprise architects need to evolve to survive in a digital world.”)
How can companies simultaneously ensure adequate stewardship of architecture across the organization without losing the benefits of agility and distributed problem solving? IT leaders can arrive at the right outcome by answering three primary questions.
How should the architecture function be designed in an agile enterprise?
The architecture function is generally based on one of two fundamental models: central and federated (exhibit).
The central model involves a large-scale central architecture team that defines the process and artifacts required for approval of new work and ensures adherence by development teams. In this model, development teams themselves may have few or no qualified solution architects, as this role is consolidated within the central architecture team. Further, centralized teams for related roles, such as infrastructure, operations, and security, are also held apart from the development function. Control and governance are typically the primary concerns of the central enterprise architecture team.
By contrast, the federated model generally relies upon a guild or “community of practice” of solution architects embedded into individual development teams. The guild may be complemented by a small central architecture team or architecture center of excellence (CoE). The federated model’s enterprise architects facilitate only the most high-level planning and artifact creation and act as on-demand service providers to support distributed teams.
In this model, which is more commonly associated with cross-functional DevOps culture, the roles of solution and enterprise architects are generally broader in an effort to integrate the related concerns of infrastructure, operations, and security in product-oriented teams. This kind of architect role is focused more on facilitation and enablement than control, as the number of solution architects in a federated environment typically dwarfs the number of enterprise architects.
Today, we see modern agile organizations most commonly adopt the federated model. This approach increases the likelihood that the central architecture team will spend its time where it should, staying closely involved with the remediation of challenges identified in the teams, such as infrastructure or development. In addition, the concept of central standards and maintaining a chapter of architects is much more closely aligned with the principles of agile than the models where most of the capacity is hosted in a central team. In addition, the model ensures that the architects will be evaluated against the goals of the individual products they support, thereby ensuring they really focus on improving practical performance and reducing complexity.
In the classical agile setup, the federated model’s CoE team reports to the CEO, head of digital, or CTO. The CoE’s solution architects collaborate closely with the operational architects involved in the agile teams, from infrastructure to product development. In all cases, these operational architects balance the requirements of the team against the overarching architecture guidelines, interpreting and translating the guidance to the specific situation and allowing the product owner or equivalent role to make the right decisions for the company.
What is the right structure for the architecture function?
The small, central, and mostly federated model replicates the chapter-and-squad structure of the organization. In some companies, a hybrid model acts as a translator between the agile and traditional worlds, by, for example, managing the different speeds and trade-offs that come with this model.
The federated solution architects are organized as a chapter across the organization, with a common role profile differentiated by the craftmanship required at different levels of expertise, from novice to expert architect. The central architecture team maintains the artifacts and facilitates the meetings of the organization’s guild of architects. The solution architects and the enterprise architects typically report to the same chapter head for architecture and work according to common standards.
This structure also applies to a multicountry setup, where the central architecture function needs to drive the common language and usage of tools across the organization to ensure synergies and cross-country exchange of code, software assets, or data.
Whom do I need in the architecture function?
In the past, the architecture function focused on conceptual thinking and the aggregation of refined artifacts to drive the company’s architecture discussions. In the new federated model, the architecture function must also have strong engineering skills in architecture and coding.
Therefore, an E-shaped profile, someone with expertise in several disciplines—such as conceptual thinking, vendor selection, coding, and infrastructure—enables the integration and support of the development teams. This combination is typically hard to find and requires a lengthy search process. It is essential to first define the function’s structure and role profiles and then aim for the best candidates rather than trying to fill open positions as quickly as possible.
The last point is essential, particularly given the talent shortage on the architecture side and the large difference in performance between typical and expert architects.
Christian Lilley is an associate partner in McKinsey’s Washington, DC, office; Klaas Ole Kürtz is a practice manager in the Hamburg office; Henning Soller is a partner in the Frankfurt office; and Christian Stüer is a partner in the Abu Dhabi office.