All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.

—Sun Tzu

 

Enterprise Architect

The Enterprise Architect fosters adaptive design and engineering practices, and drives strategic architectural initiatives for a SAFe Portfolio. Enterprise Architects also facilitate the reuse of ideas, components, services, and proven patterns across various Solutions in a portfolio.

In enterprise-scale systems, poor strategic technical planning, communication, and visibility can cause poor systems performance, prompting significant, and delaying, redesign. To prevent this, and to support current and near-term business needs, these systems benefit by having some Architectural Runway. Some architectural governance is also helpful (for example, to drive common usability and behavioral constructs across the enterprise’s solution). To address parts of this problem, SAFe highlights the roles of System and Solution Architects, who provide much of this guidance at the Program and Large Solution levels.

At the Portfolio Level, the challenge is even larger. Mergers and acquisitions, changes in underlying technologies and competition, emerging standards, and other factors often push businesses in directions beyond the purview of Agile teams. To counter that, the SAFe Enterprise Architect has the authority and knowledge to work across Solution and Agile Release Trains (ARTs). They can provide the strategic technical direction that can improve results. Aspects of this strategy may include recommendations for development and delivery of technology stacks, Solution interoperability, APIs, and hosting strategies. These approaches produce results because enterprise architects foster incremental implementation while staying connected with the team’s work.

Details

Summary Role Description

The Enterprise Architect works with business stakeholders and Solution and System Architects to implement holistic technology across Value Streams. They rely on continuous feedback, foster adaptive design and engineering practices, and drive programs and teams around to rally a common technical vision.

Responsibilities

The enterprise architect is focused primarily on the following responsibilities:

  • Collaborating with Lean Portfolio Management to provide a high-level, all-inclusive vision of enterprise solutions and development initiatives
  • Defining key technical initiatives that support Lean Budgets via Enabler Epics
  • Participating in the strategy for building and maintaining the Architectural Runway
  • Understanding and communicating Strategic Themes, and other key business drivers for architecture, to system architects and non-technical stakeholders
  • Driving architectural initiatives in the Portfolio Kanban system, and participating in Epic analysis where applicable
  • Influencing common modeling, design, and coding practices
  • Promoting Continuous Delivery Pipeline and DevOps capabilitties
  • Collecting generating, and analyzing innovative ideas and technologies to use across the business
  • Facilitating the reuse of ideas, components, and proven patterns
  • Synchronizing the following disciplines 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 vital element. Figure 1 illustrates five key aspects of such a strategy.

Figure 1. Five elements of enterprise architecture strategy

Choice of technology. Choosing appropriate technologies is a key element of the strategy. Supporting activities include research and prototyping, understanding applicability and scope, and assessing the 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 business and technical objectives. Emerging solutions to local problems should be consistent with the overall enterprise strategy. When that’s not the case, decisions should be made explicit, as the inconsistent option may well influence future enterprise strategy.

Development and Deployment Infrastructure Strategy. When it fulfills its function properly, development and deployment infrastructure goes unnoticed. However, the strategy for building and maintaining the infrastructure is a key challenge, overlapping 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 intersect with internal IT systems. The enterprise architect can provide direction there as well.

Inter-Program Collaboration. Various aspects of architecture work occur in different teams and programs. Which is why it’s helpful to ensure that common technology, design practices, and infrastructure are used when applicable. However, it’s also important that value streams and programs have sufficient degrees of freedom. Otherwise, innovation decreases. Thus, both common and variable architectural aspects should be actively shared among the ARTs via joint design workshops, Design Communities of Practice (CoPs), etc.

Implementation Strategy. The importance of an effective, incremental Agile implementation strategy can hardly be overstated. Building the technical foundation for business epics into the architectural runway must be an incremental process. Continuous technical learning and fast feedback allow architecture and business functionality to grow synchronously over time. The ability of Agile Teams and programs to refactor as necessary and preserve multiple possible design options wherever practical supports this. Abstraction and generalization help avoid binding specificity too early, which 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. This is why the enterprise architect is wise to maintain personal connections to each Solution Train, ART, and architect through the following activities:

  • Receiving feedback on current enterprise-wide initiatives
  • Participating in value stream or program-level design CoPs
  • Attending demos whenever critical redesign or foundation work is in process.

Developers and testers will better trust strategy driven by the person who knows their current challenges and context. Likewise, the enterprise architect will better trust teams that provide full visibility of their current context.


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 20.

[2] Bloomberg, Jason. The Agile Architecture Revolution. Wiley, 2013.

[3] Coplien, James and Gertrud Bjørnvig. Lean Architecture: for Agile Software Development. Wiley, 2010.

Last update: 1 June, 2017