The Importance and Evolving Role of Architecture Reviews in IT

Are architecture reviews relevant?

This question often arises among IT leaders, reflecting a perception that traditional architecture reviews may no longer serve their intended purpose effectively. Yet, as with the adage "measure twice, cut once," one might wonder why architecture design should be any different. Where, then, lies the disconnect?

One source of discontent with architecture reviews stems from outdated legacy processes that persist in many IT organizations. Business and IT leadership have two critical, distinct responsibilities in architecture development: governance and assurance. Unfortunately, these functions are often conflated, causing confusion and reducing effectiveness.

Understanding Architecture Governance vs. Assurance

Architecture development for strategic initiatives generally progresses through three levels of detail: conceptual, logical, and physical architecture. These correspond to enterprise, solution, and technical architecture, respectively. Each level requires dedicated governance and assurance functions to ensure that designs align with business goals, standards, and operational needs.

Architecture Governance involves senior business and IT leaders who establish oversight over architecture activities. Governance ensures that appropriate controls, principles, policies, and escalation paths are in place to support decision-making throughout strategic planning.

Architecture Assurance ensures that conceptual, logical, and physical architecture designs comply with reference architectures, organizational principles, and technology standards. Assurance activities are conducted at specific points during the solution delivery process, typically by teams with expertise in various technical domains relevant to each architecture level.

The skills required for governance and assurance differ significantly, as do their respective cadences within the solution delivery cycle. Governance committees generally include senior business and IT leadership accountable for architecture decisions at the conceptual level, while assurance teams consist of subject matter experts (SMEs) and architects who review solution and technical designs to validate alignment with organizational objectives.

Common Pitfalls in Architecture Review Processes

Unfortunately, many organizations blend governance and assurance, conducting both activities simultaneously with the same team. This one-size-fits-all approach, often managed by a single Architecture Review Board (ARB), compromises both governance and assurance functions. Originally, ARBs were formed to provide governance at the conceptual level—overseeing high-level decisions, not reviewing detailed blueprints. However, these boards morphed into catch-all committees, now attempting to review designs across all architecture levels. This setup results in ineffective oversight, as those making strategic architecture decisions often lack the specialized knowledge needed for detailed assurance activities.

This issue is exacerbated in Agile environments. Traditional ARB reviews, already problematic, conflict with Agile methodologies that prioritize flexibility, rapid delivery, and iterative feedback. The ARB reviews, perceived as mere formalities, divert resources from development teams, hinder progress, and offer limited value due to their timing late in the delivery process.

Rethinking Architecture Review for Agile Environments

To address these issues, organizations should establish distinct governance and assurance functions:

Separate Governance and Assurance Committees: Governance committees should focus on high-level decisions at the conceptual level, while assurance working groups review solution and technical architectures as needed. Specialized assurance reviews at each architecture level allow experts to examine solutions at the right stages, catching issues early when they’re less costly to fix.

Proactive, Continuous Assurance in Agile: In Agile environments, assurance should be integrated into the design and development processes, not as formal checkpoints but as ongoing collaboration. Architects should provide guidance early, embedding best practices, patterns, and standards into the development process to reduce the need for later-stage reviews.

Collaborative Working Sessions: Rather than traditional “show and tell” review sessions, architecture assurance can be conducted informally as part of ongoing design activities, directly involving architects and SMEs in working sessions to resolve issues proactively. This helps teams address potential issues before they become problems.

Lightweight, Accelerated Governance and Assurance: Organizations can accelerate governance and assurance by making reference materials—such as architecture patterns, baseline requirements, and standards—easily accessible from the outset of development. This approach reduces the need for elaborate reviews by ensuring that designs align with standards from the start.

Implementing Effective Architecture Review Structures

Organizations should conduct maturity assessments of their architecture practices, re-evaluating the operating model to ensure proper support for architecture governance and assurance functions at all levels. By separating governance from assurance and appointing appropriate stakeholders from business and IT, organizations can create a framework that supports timely, effective decision-making throughout strategy implementation.

While architecture reviews remain crucial, they must evolve to fit the needs of modern delivery methodologies. By decoupling governance and assurance, fostering collaboration, and embedding best practices, organizations can ensure that architecture reviews serve their intended purpose—supporting strategic goals and minimizing risks without impeding agility or progress.

Author: Sunil Rananavare, IT Strategy Planning and Architecture (CIO Advisory)

Follow me on LinkedIn to stay informed. Like and share if you found this article useful.

?

The views in the article are author’s own and not necessarily of his employer.