All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.
Enterprise Architect Abstract
In systems of enterprise scale, poor strategic technical planning, communication, and visibility can cause poor overall business systems performance, making significant redesign of multiple systems necessary. Poor economics and poor business systems performance are a likely result. To prevent this, enterprise-class systems are well served by having some amount of intentional Architectural Runway built into their larger systems, and the larger system-of-systems, to support current and near-term business needs. In addition, some architectural governance—for example, to drive common usability and system behavioral constructs across the enterprise’s solutions—is beneficial. To address parts of this problem, SAFe highlights the role of System and Solution Architects in providing much of this guidance at the Program and Value Stream levels.
At the Portfolio Level, the challenge is even larger. Mergers and acquisitions, changes in underlying technologies, emerging standards, competitive changes, and other factors often drive enterprises in directions that are outside the purview of Agile Programs. Enter the SAFe Enterprise Architect as a responsible authority with the requisite knowledge to work across value streams and programs and help provide strategic technical direction that can optimize enterprise outcomes. Aspects of this strategy can include recommendations for development and delivery technology stacks, interprogram system collaboration, interoperability of solutions, APIs, and hosting strategies. These strategies are most effective when enterprise architects foster incremental implementation while maintaining a solid connection to the team’s work.
Summary Role Description
The Enterprise Architect works with business stakeholders and Solution and System Architects to drive holistic technology implementation across Value Streams. The enterprise architect relies on continuous feedback, fosters adaptive design and engineering practices, and drives collaboration of programs and teams around a common technical vision.
The enterprise architect is focused primarily on the following responsibilities:
- Maintain a high-level, holistic vision of enterprise solutions and development initiatives
- Help define key technical initiatives that support Budgets via Enabler Epics
- Participate in the strategy for building and maintaining the enterprise Architectural Runway
- Understand and communicate Strategic Themes and other key business drivers for architecture to system architects and nontechnical stakeholders
- Drive architectural initiatives in the Portfolio Kanban system and participate in Epic analysis where applicable
- Influence common modeling, design, and coding practices
- Collect, generate, and analyze innovative ideas and technologies that are applicable across the enterprise
- Facilitate the reuse of ideas, components, and proven patterns
- Synchronize the following across solutions whenever applicable:
- System and data security and quality
- Production infrastructure
- Solution User Experience governance
- Scalability, performance, and other NFRs
Enterprise Architecture Strategy
The enterprise’s ability to embrace organizational change is a key competitive advantage, and the enterprise architectural strategy is a principal constituent. Figure 1 illustrates five key aspects of such a strategy.
Choice of technology. The choice of technologies that will best support current Budgets is one key element of the strategy. Supporting activities include research and prototyping, understanding applicability and scope, and assessing maturity of innovative new technologies.
System/Solution Architecture Strategy. The enterprise architect works closely with solution and system architects to ensure that individual program and product strategies align with enterprise objectives. Emergent solutions to local problems should be consistent with the strategy. When that is not the case, the decision should be made explicitly, and the contraindicator may well influence enterprise strategy.
Development and Deployment Infrastructure Strategy. Development and deployment infrastructure is unnoticed when it fulfills its function properly. However, the strategy for building and maintaining the infrastructure is a key challenge, one that overlaps with system architect responsibilities. Some of these include the reuse of configuration patterns, common physical infrastructure, knowledge sharing between Value Streams, Agile Release Trains (ARTs), and—especially—System Teams. In addition, some of the development and deployment infrastructure will likely overlap with internal IT systems, and the enterprise architect can help provide direction there as well.
Interprogram Collaboration. Various and differing aspects of architecture work happen in different teams and programs. Thus it is helpful to ensure that common technology, common design practices, and common infrastructure are used where applicable. However, it is also important to ensure that value streams and programs have sufficient degrees of freedom, or there will be little innovation. Thus, both common and variable architectural aspects should be actively shared among the ARTs via joint design workshops, Design Communities of Practice, etc.
Implementation Strategy. The importance of an effective, Agile, incremental implementation strategy can hardly be overstated. Building the technical foundation for business epics into the architectural runway must be an incremental process based on continuous technical learning and fast feedback, such that architecture and business functionality grow synchronously over time. This is aided by the ability of Agile Teams and programs to refactor as necessary and to preserve multiple possible design options wherever practical. Achievement comes in part through the use of abstraction and generalization, which helps avoid binding specificity too early and thereby preserves architectural flexibility for future business needs.
Respect for People and Gemba Kaizen
The Lean concept of “Go and see” (aka Gemba – “the real place”) creates a healthy environment in which everyone operates on facts, not assumptions. This is particularly important for enterprise architects, who operate one (or two!) steps removed from day-to-day development activities. Thus the enterprise architect is well served by maintaining personal connections to each value stream, ART, and architect at these levels; receiving feedback on current enterprise-wide initiatives; participating in value stream or program-level design CoPs; and attending demos whenever critical redesign or foundation work is in process. Developers and testers will better trust the strategy that is driven by a person who knows their current challenges and context. In the same way, the enterprise architect will better trust the teams that provide full visibility of current context.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 20.
 Bloomberg, Jason. The Agile Architecture Revolution. Wiley, 2013.
 Coplien, James and Gertrud Bjørnvig. Lean Architecture: for Agile Software Development. Wiley, 2010.
Last update: 20 October 2015