3 steps for building your architecture organization in an Agile@Scale context

But things are changing. As IT departments undertake Agile transformations, new opportunities are being created for your architects to close the gap.

This is important because proximity and cultural alignment between architects and development teams allow:

• Faster time to market, by reducing the time necessary to take architectural decisions
• Quality improvement, by sharing architectural tools and guidelines more efficiently
• IS efficiency, by ensuring solutions reusability and mutualization at IS level

At Capgemini Invent, we recommend transforming this situation by building an architecture organization in an Agile@Scale context. This should be built on three key steps:

Step 1: Set up a decentralized and federated architecture organization:

First, identify current and future platforms/perimeters and assess the architectural skills needed in each one (e.g. Data, Digital, Core Business…).

Second, dedicate tight architectural teams (traditionally called Design Authorities) to each perimeter, primarily in charge of defining and communicating a common architectural vision to their perimeter on each layer: business, applicative, data and technical. Devoting architects to teams within a perimeter helps manage architectural consistency more effectively, while bringing architects closer to teams’ context and constraints.

Third, maintain a cross-disciplinary pool of architecture skills, composed of enterprise architects and product architects with transversal expertise (Cloud, DevOps…) who can be quickly mobilized according to changing needs or priorities.

Fourth, ensure a common vision for IS evolution by federating all architects and Tech Leads into a strong Design Community via a dedicated governance structure and tools, carrying in common the IS architecture framework.

By establishing a decentralized and federated architecture organization, IT provides itself with the means to ensure a rapid response to architecture choices, while maintaining consistency. However, this organization would remain a dead letter if it were not accompanied by practices that promote greater agility in architecture choices.

Step 2: Transform the architecture culture and working methods to leave enough free space for teams to improve innovation and time to market

An Agile architecture culture is based on a key principle: balancing intentional architecture covering architectural frameworks, tools and anticipatory initiatives that enhance solution performance, and emergent design, bringing architecture construction closer to Agile teams to extend it progressively based on priority needs.

In a nutshell, Agile architects propose a minimum viable architecture built on solid foundations, evolving over time to take on board changing business needs.

To ensure this, four key cultural shifts should be applied:

• Involve the architect in the life of the Agile team, from build to run:
  • The Agile architect is involved early on, right from the Design Thinking stage.
  • Architects often participate in Agile and Agile@Scale events (Sprint Planning, Sprint Demo, PI Planning, System Demo), principally until the foundations of the solution are stabilized.
  • This allows the architect to become familiar with the solution use cases and the team’s constraints, to lay the appropriate architectural foundations more easily and accurately.
• Evolving from a solitary architect’s posture to a co-constructor’s posture:
  • Most architectural decisions should be the result of a discussion between architects, Tech Lead and the developers involved. For example, the decision to use specific frameworks such as Angular or React for a portal should not only be taken by the architect.
  • Noteworthy architecture decisions should be shared with the Design community for guidance and to ensure reusability.
  • Major architectural decisions should be taken and validated in architectural committees, sometimes involving the IT management board. This applies, for instance, when the team considers where to host sensitive data, or when a new solution needs to be implemented.
• Make the Agile team progressively autonomous on architecture evolutions:
  • The co-construction shift allows the Agile team to progressively master the solution and gain autonomy.
  • When the solution gains maturity and its foundations start to stabilize, the architect leaves more autonomy to the team.
  • The Agile team’s Tech Lead is key to this shift. As the architect’s main interlocutor, this role is the guarantor of the team’s empowerment.
• Think of your enterprise architecture as a ramp, by building it gradually according to Business priorities:
  • Besides architectural foundations, most architectural evolutions must be made progressively, as an anticipation of priority needs. These choices must, however, respect architectural principles and rules.
  • In rare cases when business value needs to be delivered quickly, the solution can be non-compliant with the target vision for a period of time, knowing that this will induce a technical debt to be dealt with in the future.
  • For instance, a team manipulating customer data can decide not to host it in the brand new shared zone if it is not yet fully functional, and store it instead on its own zone, optimized for its use case, regardless of architectural principles.

Step 3: Progressively capitalize on Agile to redefine architects’ roles and address the typical issues they face 

• Enterprise architects steer the evolution of the IS together with the Business, by adopting an economic vision:
  • Aligning the architecture with the business strategy, by translating the strategic business themes into principles and rules for the IS.
  • Collaborating with the Business to define the major technological evolutions (Enabler Epic) to bring to the IS.
  • Ensuring transversal IS coherence of the developed solutions.
• System Architects define their perimeter’s architectural and technological target:
  • Designing their perimeter’s IT building blocks (capabilities) roadmap.
  • Defining the perimeter’s architectural and technological target: urban planning, business models, data-management, capabilities and governance.
• Product Architects design solutions from build to run and empower development teams on architectural choices:
  • Intervening through the whole build and run phases, adapting to product mode principles: you design it, you run it.
  • Ensuring Agile teams’ understanding of initial architecture design and associated architecture resources (e.g. patterns, tools simplifying developer’s life…).

With your Agile@Scale architecture up and running, you hold the keys to breaking the distance separating your architects from your development teams, thereby increasing time to market, quality and efficiency.  However, accelerating the response to business needs also implies building an Agile architecture in the IS sense of the term (micro-services, APIs, DevOps, modularity…).

It’s a key subject for CIOs wishing to regain mastery over their rapidly evolving information system.

---

Co-author

Côme Richard

Consultant | IT Strategy and Transformation

Capgemini Invent

Romain Villar

Principal | Head of Digital Architecture

Capgemini Invent