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 Abstract

In systems of enterprise scale, poor strategic technical visibility can cause excessive systems redesign, resulting in poor economics. Enterprise systems are well served by having some amount of intentional architectural runway built into their systems to support current and near-term feature needs. In addition, some architectural governance to drive common usability and system behavioral constructs across the enterprise’s products and services is beneficial. At the Program Level, we highlight the role of the System Architect in providing much of this guidance.

At the Portfolio Level, business activities such as 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. In the Framework, we’ve illustrated an Enterprise Architect (or CTO, or architecture team, or……) as a responsible authority with the requisite knowledge to work across programs and help provide strategic direction that can optimize enterprise outcomes. Aspects of this strategy can include recommendations for development and delivery technology stacks, inter-program system collaboration and APIs, and hosting strategies. These strategies are most effective when enterprise architects foster incremental implementation, while maintaining a solid connection to the team’s reality.

Details

Summary Role Description

The Enterprise Architect works with business stakeholders and System Architects to drive holistic technology implementation across programs. 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.

Responsibilities

Within the context of the Framework, the enterprise architect is focused primarily on the following responsibilities:

Maintain a high-level, holistic vision of enterprise solutions and development initiatives
Helps define key initiatives that support Investment Themes via Architectural Epics
Participates in the strategy for building and maintaining the enterprise Architectural Runway
Communicates key business drivers for architecture to system architects and communicates technical decisions to non-technical stakeholders
Drives the Architectural Epic Kanban and participates in epic analysis where applicable
Influences common Modeling, design and coding practices
Collects, generates and analyzes innovative ideas and technologies that are applicable across the enterprise
Facilitates the re-use of ideas, components, and proven patterns
Synchronizes the following across solutionswhenever applicable:
- System and data security and quality
- Production infrastructure
- System to System UX governance
- Scalability, performance and other NFRs

(Note: The Enterprise architect may also significant responsibility in supporting selection, deployment and evolution of internal IT systems, but those responsibilities lie outside the scope of the Framework.)

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 elements of such a strategy.

Figure 1. Five elements of enterprise architecture strategy

Choice of Technology and Usage. The choice of technologies that will best support current investment themes is one key strategy element. Supporting activities include research and prototyping, understanding applicability and scope and assessing maturity of innovative new technologies.

System Architecture Strategy. The enterprise architect works closely with system architects to assure 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 contra-indicator 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, and one that overlaps with the system architect responsibilities. Some of these aspects include the re-use of configuration patterns, common physical infrastructure, knowledge sharing between Release Trains (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.

Inter-program 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 programs have sufficient degrees of freedom; otherwise, there will be little innovation. Thus, both common and variable architectural aspects should be actively shared between 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 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 agile teams and programs abilities to refactor as necessary and to preserve multiple possible design options wherever practical. This is achieved, in part, through the usage of abstraction and generalization, which helps avoid too early binding specificity, 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 where everyone operates on facts, not assumptions. This is particularly important for enterprise architects, who operate “one (or two!) steps removed” from the day to day development activities. Thus, the enterprise architect is well served by: maintaining personal connections to each Agile Release Train and its System Architect; receiving feedback on current enterprise-wide initiatives; participating in 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.

Learn More

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

Larman, Craig & Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010. Chapter 8.