The practice of enterprise architecture (EA) continues to evolve as architects get recognized for enabling business strategies in their organizations. To ensure that their artifacts deliver specific outcomes, enterprise architects need to be engaged with business stakeholders and their funded initiatives. Such engagement needs to be governed by the organization’s processes that include technology and architecture governance. This article examines the right sizing of an Architecture Review Board (ARB) in the context of effective architecture governance that starts with the ‘What,” “Why,” and “How” questions:
- What
- What is the purpose or charter of architecture governance?
- What decisions must be made to ensure: a) usage, b) consistency, and c) effective introduction and implementation of architectures and architecture assets?
- Why
- Why does the organization need architecture governance now?
- What is the trigger? Understand the trigger for designing architecture governance. For example, TOGAF (section 47.3) highlights several triggers including a new CIO, merger or acquisition, and significant business change, among others.
- How
- How and when should people engage an enterprise architect?
- How will architecture decisions be made and monitored? (In other words, how do we ensure realization of enterprise architecture?)
The benefits of architecture governance—the “What” and “Why”—are well documented in the context of IT governance, but the setup and sustenance— the “How”—continues to be reviewed in articles, blogs, and forums.
CASE IN POINT: REDESIGNING ARCHITECTURE GOVERNANCE
Among my first tasks after joining the EA team at a multinational agri-business company was to redefine the ARB, an assignment triggered by a review of our enterprise architecture program.
Some of the key learnings from this experience have also been captured in the framework (figure 1) driving the discussions in this article. The simple and transparent design of the ARB led to a buy-in from global teams with minimal resistance. Focusing ARB reviews on significant initiatives led to optimization of time spent on reviews.
The result: A cadence enabled by a pre-published schedule for architecture review and approvals replaced the ad hoc design review meetings. The use of a common calendar fostered a sense of community among the geographically distributed team working across time zones. We also adopted a few simple techniques like the use of common review templates to minimize overhead. A tiered review model focused on review of complex programs, especially those introducing new technology and services, ensured delegation of smaller projects to a “self-governed” model.
The key enablers that lead to predictable processes of architecture governance include an understanding of the Enterprise Context, Stakeholder Alignment, and Right Sized Design (figure 1).
ARCHITECTURE GOVERNANCE IN CONTEXT
The architecture review process should coexist with corporate governance and control processes. Enterprise architects engage with business and technology stakeholders to influence business strategies and translate actionable insights into functional and technical road maps. These road maps are used to guide business-funded projects and programs.
Architecture governance coexists with other processes in the organization. Identifying and aligning with stakeholders is critical to the successful rollout of an ARB and should address the key question: “How can the ARB and Enterprise Architects help me?”
The size of the organization, geographies of operation, and number of branches and offices will also influence the governance requirements. An ARB may be just one of the many compliance processes in an enterprise, and minimizing the overhead of end-to-end processes by designing the ARB to coexist with other processes will ensure buy-in and continued sustenance. A few key benefits of having an ARB embedded with organizational governance include:
- Provides transparency of decision making: ARB designed as a forum to facilitate architectural review, discussions, and agreements.
- Highlights architecture risk by enforcing the architecture principles and best practices during reviews.
- Ensures project alignment with predefined road maps to enable long term strategies.
- Aligns budget and spending across projects. This may include alignment of projects rolling out similar processes or technologies across business divisions.
- Promotes better understanding of the end-to-end portfolio.
ESTABLISHING AN ARB
Here are some practical tips, based on my experience in review and redesign of ARB:
- Define the scope of the ARB clearly. Large organizations may have more than one architecture and design process that supports regional and functional business units. One should clarify the scope and span of influence of the ARB, especially in the context of:
- Geographic span of operations—regional/business unit vs. global operations
- Area of focus for reviews—technical- or process-centric focus
- Identify ARB attendees.
- Distinguish between core attendees (those who will attend all meetings) and invitees (people who can contribute to review of a specific topic)
- Identify a meeting chair (facilitator) who will manage the ARB process including agenda, conduct the call and steer discussion, and adhere to time allotted. The chairperson should be knowledgeable on architecture processes
- Communicate on recurring meetings and cadence.
- Pre-publish calendars with recurring meetings for architecture reviews. This will ensure quorum of attendees.
- Publish an agenda with the review schedule. It may be practical to update the agenda closer to the meetings. This ensures the most relevant programs and proposals are reviewed.
- Recognize global time zones. Large organizations may be geographically distributed across time zones, and teams may have to agree on a common time.
- Create predefined rules of engagement.
- Agree and publish the simple rules of engaging ARB (e.g., do all projects require an ARB review or only projects that meet a set of criteria?).
- Determine voting procedures. Do core team members have a “vote” during review of a solution or design? If so, agree if they also have a “veto.”
- Clarify in the rules of engagement what happens if an exception to architecture guidelines or principles is noted during review.
- Publish minutes and actions after meetings. The minutes and actions are also a written record for reference and may serve as inputs to other governance processes (e.g., has architecture approved this project?).
CONCLUSION
An architecture review board is a consultative forum that should be designed to bring together subject matter expertise to guide and consult with projects and programs. The design of an ARB should be based on an understanding of the enterprise context and stakeholder requirements and should ensure that the artifacts and results produced by enterprise architects enable stakeholders to deliver specific business outcomes. The ARB should also be a forum to review proposals and highlight architecture risks. As with most other processes in an organization, the review and refresh of an ARB should be a continuous process that accommodates periodic changes in the organization and its operating environment.
