In a recent conversation about implementing Agile and DevOps in an organization, our group stumbled into the the question of “Common Platforms” – more specifically, “are common platforms (Tools, technologies, architectures, solutions) helpful or detrimental to a team’s agility in an Agile operating environment?”. There were plenty of opinions in the room — as seems to be the case these days with any discussion related to Agile and DevOps — and the general opinion of the group was that common platforms would constrain a team’s ability to innovate quickly and are fundamentally antithetic to the principles of Agile. On the surface, this position seems rather puristic in nature and seem to ignore the practical operational trade-offs an organization needs to make in order to meet many of its conflicting/competing priorities.
- What is the importance, if any, of common platforms and solutions in an Agile operating environment?
- Do common solutions — technologies, platforms and tools really stifle innovation?
- Can we empower teams while still setting guardrails around tools and technologies the teams can use?
- What is the role of Enterprise Architecture (EA) and technical governance in an Agile/DevOps driven world?
In order to discuss this topic effectively, we need to first address the role of EA and Governance in Agile. Scaled Agile Framework (SAFe) defines a layered model of Agile adaptation across the enterprise and defines the role of Enterprise Architect as “The Enterprise Architect promotes adaptive design, and engineering practices and drives architectural initiatives for the portfolio. Enterprise Architects also facilitate the reuse of ideas, components, services, and proven patterns across various solutions in a portfolio”. The second part of the above set of sentences is of particular interest and relevance here. One of the key responsibilities of EA has been ensuring teams are developing business solutions using standardized toolset, architecture patterns and components/services, while creating common business solutions when/where possible. Enterprise Architects view all artifacts (systems, platforms, solutions, tools, etc.) with an enterprise wide lens and work with system architects and business owners/portfolio managers to ensure implementations are in alignment with organizational objectives. As shown in Figure 1 below, EA typically sits between the program and portfolio layers in a traditional organization or often completely in the portfolio/enterprise layer, and only engages with the teams on the ground (that are actually delivering actionable functionality to users) when the teams come to them for architecture/technical governance reviews and/or architecture exceptions.
An Enterprise Agile Operational Model (Inspired by concepts from SAFe)
While the importance and relevance of EA’s role is no different under the Agile umbrella, the traditional model of disconnected, fragmented engagement between EA and implementation teams is not effective and does not produce the desirable results. One change, I would argue, that needs to be made to this layered model in Figure 1 above is the addition of a dotted line between EA, System Architects (in Program layer) and Dev Teams – thus ensuring there is close, continuous collaboration between implementation teams and technical governance teams. EA’s role in an Agile model changes from that of an enforcer to that of a collaborator, facilitator, aggregator and mediator. Changes in technological, political, economic, competitive landscapes and other factors often push businesses in directions beyond the scope of Agile Teams. Enterprise Architects can provide the strategic technical direction needed to stay in tight alignment with changing business objectives that can improve results across multiple Agile teams. Aspects of this strategy may include recommendations for development and delivery of common platforms, components, technology stacks, APIs, interoperability standards, hosting strategies, etc. among others. Furthermore, in an Agile enterprise, some of the responsibilities that have typically been associated with EA are now delegated to the team level. Teams are expected to ensure their solutions align with user needs and business objectives, while continuously delivering value to their customers. However, the context within which teams typically make decisions is very “localized” to the teams and they typically do not have visibility over the decisions being made by other teams within a program and/or portfolio. According to SAFe’s layered organization model, it is the responsibility of Program and Portfolio teams to ensure capabilities created by teams in the lower levels are integrated into a broader operational instruments such as Program Increments (PI) or Release Trains (RT).
Giving autonomy to development teams does not mean that they should or get to pick their own tools and technologies, while completely ignoring the tools and technologies other teams in the rest of the organization are using. In the new normal of Lean, Agile and DevOps driven operational environment, I would argue that it’s the concepts and principles teams follow that have more impact on the eventual outcomes than the tools and technologies themselves. For instance, does a team get to say they would like to deploy their app on Google Cloud where as the organization is moving towards using AWS as the standard cloud provider? Does a team get to pick their own configuration management and automation tool such as Chef or Puppet while rest of the org is using Ansible? Appropriate answer here is that it depends on the impact of that decision and the context around it. As a general rule, it’s important to have common solutions at the enterprise level (such as AWS and Ansible) so that you can standardize operating environment, skill sets, processes, etc. — but have enough flexibility in the governance model to allow deviations from those standards when needed. Perhaps the team has a legitimate reason to want to use a different tool or move to a different cloud provider. The point here is not that we should eliminate all guard rails and governance structures to enable a team to do that – but rather that we should be making those governance processes much more collaborative and agile so that these decisions, which typically get mired in the bureaucracy of EA approvals/denials, can be made quickly and radiated to the rest of the organization. In an Agile operation model, the role of EA and subsequently the role of common solutions is to provide those guardrails, while enabling teams to deviate from these guardrails when warranted by the business and solution context.
EA’s role in an Agile model changes from an enforcer to a collaborator, facilitator, aggregator and mediator.
Organizations embarking on Agile transformation journey should consider the following five critical components to ensure they are striking a sound balance between standardization (common platforms), governance and innovation/team empowerment.
1. Establish Key Architecture Principles as Guardrails
Establish architecture principles to drive the overall architecture context for guiding implementations across the enterprise. For instance “Open Source First”, “Common Business Solutions”, “Integrated Security”, “Adapt DevSecOps”, “Layered, Loosely-coupled Architectures”, etc. provide high level guidance and guardrails for the teams to work within. These principles will ensure Agile teams do not stray too far away from business objectives in the name of agility and innovation.
2. Create Reference Architectures and Evolve through an Architecture Runway
Establish and document reference architectures when/where applicable to capture best practices, patterns and services at the enterprise level. Drive architecture implementation through an enterprise level architecture backlog so that individual implementation teams have enough runway to rollout their solutions at any point in time. Leverage architecture/design spikes to explore new concepts, tools and technologies to reduce the risk of solution implementation at a team level.
3. Promote Common Solutions and Platforms
Identify, establish and promote common solutions (Services, Components, APIs, tools, platforms and technologies) to reduce duplication. Provide guardrails and guidelines relative to common tools and technologies to teams, while actively engaging the teams to understand their needs and incorporating the feedback into common solutions. Promote REST based APIs to increase agility of solution implementations.
4. Position EA as Collaborator and Facilitator – not as an Enforcer
Ensure EA engages with implementation teams early and often, disseminating information from the enterprise view and collect feedback to refine enterprise level artifacts. Enterprise architects must work closely with System Architects and implementation teams to ensure they are enabling the careful balance needed between autonomy and governance. The mission remains the same — but the process, approach and tools now are different. EA can no longer be effective in its traditional enforcer role – and needs to become an aggregator, observer, facilitator and disseminator of information across multiple teams.
5. Establish/follow an Agile Governance Model
Align governance model with Agile implementation model. Adapt multiple engagement models to monitor and observe compliance in Agile teams instead of waiting for the teams to engage EA for technical governance. Implement processes with quick turn around time to eliminate roadblocks and obstacles. Primary goal of the new EA is to be nimble and responsive to the needs of the teams on the ground, while ensuring solution implementations are in alignment with customer/business objectives.
A careful orchestration of governance and team autonomy is required to ensure teams have the ability to innovate (if that requires new tools and technologies) while still collaborating with EA and leveraging enterprise level common solutions as much as possible. In cases where a complete departure from enterprise guidelines is required, orgs need to ensure that the governance processes in place are Agile enough to enable teams and EA to respond and address the scenario and make decisions quickly. In an ideal world, we perhaps do not need the EA function altogether – in a world where the teams are empowered to operate with complete authority, independence and accountability. Until then – during this transition and transformation period – we still need EA to act as a facilitator, aggregator and collaborator — and help minimize risk, manage cost, build capabilities at an enterprise level, while ensuring the implementations and technology choices are in alignment with business objectives.