Make Architecture More Valuable: Take on At-Risk & High-Risk Initiatives

Author: Frank Guerino

The Visibility Problem in Architecture

Architecture organizations do important work that is largely invisible when things go well. They define standards, evaluate technology choices, review designs, and govern the consistency of the enterprise’s technical landscape. When an architecture team is functioning properly, projects run more smoothly, technical debt accumulates more slowly, and integration decisions are made with the full picture in view. None of that shows up on an executive dashboard.

The consequence is a persistent perception problem. In many enterprises, architecture is seen as overhead—a compliance function, a review gate, a team that slows delivery without contributing to it. CIOs who have inherited underperforming architecture teams often question whether the function earns its investment. Chief executives rarely mention architecture when they describe what is making their technology organization competitive. The work is real; the credit is not.

Part of the problem is the nature of architecture’s primary outputs. Policies, standards, assessment reports, reference diagrams, governance frameworks—these are the documents that architecture teams spend the majority of their time producing. They are genuine contributions to enterprise health, but they are not perceived as critical by the executives who control budgets and headcount. Delivery teams keep systems running and ship products. Operations teams maintain uptime and respond to incidents. Architecture teams write documents. In the calculus of organizational value, documentation rarely wins.

This perception gap becomes dangerous when financial pressure arrives. When budgets tighten and cost reduction becomes the mandate, C-level leaders make a straightforward calculation: who is getting their hands dirty, and who is not? Functions that are embedded in delivery, that own operational outcomes, and that would leave a visible gap if removed are protected. Functions that produce documents, sit in review committees, and operate at a comfortable distance from the work that actually moves the business are the first candidates for reduction. Architecture organizations that have not built delivery accountability into their operating model are structurally exposed every time the enterprise faces financial stress.

The root cause is structural: architecture organizations are designed to be advisory. They stand to the side of delivery, offering guidance without accountability. When a project succeeds, the delivery team gets the credit. When a project fails, architecture was not responsible for the outcome—it only reviewed it. Low visibility translates directly into the executive perception that nothing important is happening—not because the work lacks value, but because the work lacks presence at the moments that matter. Advisory functions do not build executive relevance. Accountable functions do.

It is useful to think of architecture organizations as operating somewhere on a spectrum. At one end sits the documentation-heavy model—the architecture function that defines TOGAF-compliant frameworks, produces voluminous reference architectures, authors policy libraries, and generates assessment reports that consume significant effort and land with limited organizational impact. This end of the spectrum has its place: standards matter, and a well-governed technical landscape does not happen by accident. But an architecture organization that lives exclusively at this end of the spectrum is perpetually at risk of being perceived—and eventually treated—as an overhead function. At the other end of the spectrum sits the delivery ownership model: architects who are inside programs, accountable for outcomes, making decisions, and measured by whether the work they touch succeeds. The At-Risk Architecture Practice is a deliberate mechanism for moving architecture toward the delivery ownership end of that spectrum—not by abandoning standards and governance, but by adding an accountability dimension that the documentation model alone cannot provide.

Why At-Risk and High-Risk Initiatives Are the Answer

At-risk and high-risk initiatives are the moments in the enterprise calendar when leadership is paying full attention. These are the programs where the CIO is in weekly status meetings, where the CEO is asking for updates, where the board has visibility into delivery timelines. They are the initiatives where careers are made or ended, where significant capital is deployed, and where the organization’s ability to execute is most directly on display.

They are also the moments when the absence of sound architecture is most acutely felt. At-risk programs are frequently at risk precisely because of unresolved architectural dependencies, poorly understood integration complexity, technology choices made without enterprise context, or governance failures that accumulated quietly until the deadline became real. The problems are architectural. The pain is executive. The connection between the two is rarely made explicit—because architecture was advisory, not accountable.

Architecture that inserts itself into these moments—that takes on accountability for resolving the architectural dimensions of at-risk work—accomplishes something that no governance charter or organizational mandate can provide. It demonstrates value at the exact moment when value is most visible, to the exact audience that controls the architecture organization’s budget, scope, and influence.

Defining At-Risk and High-Risk

The terms at-risk and high-risk are often used interchangeably, but they describe meaningfully different situations—and the distinction matters for how the practice engages with each. Understanding the difference shapes the practice’s posture, its timing, and the nature of the work it does.

A high-risk initiative is one that carries significant potential for failure before it begins. The risk is inherent in the nature of the program itself: its strategic stakes, its technical complexity, its scale, its dependency profile, its novelty, or the organizational dynamics surrounding it. A greenfield platform migration across a global enterprise, a first-time cloud-native deployment in a regulated industry, a system integration touching twenty upstream sources and thirty downstream consumers—these are high-risk by construction. No mistakes have yet been made. No deadlines have been missed. But the conditions for failure are present from the outset, and the consequences of failure are significant enough to warrant architectural attention before the program reaches a point of crisis. For high-risk initiatives, the practice’s posture is preventive: embed early, establish architectural guardrails, surface and sequence dependencies, and provide the decision authority that keeps the program on a sound structural footing from the start.

An at-risk initiative is one that has become endangered in flight. Something has gone wrong—or conditions have changed—and the program is now in danger of failing to deliver on its commitments. Timelines have slipped. Integration assumptions have proved incorrect. A key vendor has underperformed. A system dependency was not visible when the program was scoped. The program has been formally flagged red or yellow by delivery governance, or it is heading in that direction. For at-risk initiatives, the practice’s posture is interventional: triage the architectural state, identify root causes, produce a credible remediation plan, and take accountability for the architectural track of the recovery. The goal is not to assign blame but to stabilize the program and restore its ability to deliver.

In practice, the practice will encounter both types. The intake criteria should be designed to catch high-risk programs early—before they become at-risk—and to engage at-risk programs before their situation becomes unrecoverable. The sooner the practice is involved, the more options it has and the less costly the intervention.

The structural solution is a dedicated practice within the architecture organization—a specialized team whose primary mission is to identify, engage, and take ownership of at-risk and high-risk initiatives across the enterprise. This is not a consulting helpdesk. It is not a review committee. It is not a tiger team that parachutes in, makes recommendations, and leaves. It is a delivery-accountable unit that embeds in struggling programs, owns the architectural track of their remediation, and is measured by delivery outcomes.

The practice should be staffed with senior architects who have direct delivery credibility—individuals who have built systems, managed technical programs, and navigated organizational complexity at the program level. Advisory skills matter in this role, but they are not sufficient. The practice needs architects who can make hard decisions quickly, communicate risk clearly to executive sponsors, and hold a line under pressure. These are not generalist reviewers. They are experienced practitioners who happen to operate within an architecture function.

The practice should operate under a formal intake process that establishes clear criteria for what constitutes an at-risk or high-risk initiative. It should maintain a standing view of initiative health across the enterprise, updated regularly and shared with senior leadership. And it should measure its own performance not by the quality of the architecture documents it produces, but by the delivery outcomes of the programs it engages.

What Qualifies as At-Risk or High-Risk

Not every troubled project merits engagement from the At-Risk Architecture Practice. The intake criteria should be deliberately calibrated to initiatives where architectural factors are materially contributing to risk and where architectural intervention can materially improve outcomes. The following categories represent the core of the qualifying population:

• Strategic programs with aggressive timelines where architectural dependencies have not been fully resolved or sequenced

• Modernization and migration initiatives crossing multiple system domains, where integration complexity is underestimated or unmanaged

• Initiatives that have already been formally flagged as red or yellow by delivery governance, particularly where the stated risks have architectural root causes

• New technology adoption programs—cloud migrations, platform consolidations, AI deployments—where the organization lacks architectural precedent and the risk of misalignment is high

• Programs with unresolved dependencies on systems that are simultaneously being changed by other initiatives

• Initiatives where vendor commitments have been made ahead of architectural validation, creating delivery obligations the architecture has not been designed to support

What the Branch Practice Does

Once engaged with an at-risk initiative, the practice operates as an embedded delivery partner rather than an external reviewer. The mode of engagement is active and accountable, not passive and advisory. In practice this means:

• Conducting rapid architectural triage: a structured assessment of the initiative’s architectural state, identifying what is sound, what is at risk, and what is broken

• Producing a remediation roadmap with explicit owners, timelines, and acceptance criteria—not a list of recommendations, but an actionable plan with committed outcomes

• Embedding an architect directly in the program team for the duration of the engagement, with a seat at the delivery leadership table and direct access to the executive sponsor

• Owning architectural decisions rather than advising on them—the practice architect has decision authority within the scope of the engagement, not merely influence

• Maintaining a current architectural risk register for the initiative, updated at the cadence of delivery governance, and reported directly to the CIO or program executive

• Coordinating across other architecture domains—infrastructure, data, security, application—to ensure that remediation is coherent rather than piecemeal

• Handing off ownership upon successful delivery: when an engagement concludes and the program has been stabilized or delivered, the practice formally transfers architectural ownership of what was built to the appropriate domain leaders and program teams. The practice does not become the permanent steward of the systems it rescues or the programs it guides to completion. Its role ends at the point of successful delivery, and the next engagement in the queue begins.

This handoff discipline is not incidental—it is essential to the practice’s sustained effectiveness. The at-risk and high-risk initiative queue is never empty. There are always more programs that need architectural intervention than the practice has capacity to address simultaneously. A practice that retains ownership of delivered programs quickly becomes a maintenance function rather than an intervention capability. By design, every successful delivery creates capacity for the next engagement. The practice’s value is not in what it holds. It is in what it fixes, stabilizes, and then releases—so it can move on to the next fire.

How This Raises Architecture’s C-Level Profile

The mechanism is straightforward but powerful: when architecture is visibly present at the point of crisis, and when the crisis resolves, the connection between architectural quality and delivery success becomes undeniable to the people who were watching. C-level leaders remember who was in the room when things were hard and who helped turn them around. They do not remember the architecture review that happened eighteen months before the program launched.

Over time the effect compounds. As the practice accumulates a track record of engagements—programs rescued, risks resolved, timelines recovered—it builds a portfolio of evidence that architecture is not overhead but leverage. That portfolio becomes the foundation for a different kind of conversation at the executive level: not a defense of the architecture organization’s budget, but a discussion of where it should be deployed next to protect the most critical investments in the enterprise’s portfolio. Critically, this track record also provides the most durable protection against budget cuts. When finance asks the CIO which teams are essential, the answer is shaped by who was present and accountable when the hardest problems were being solved—not by who produced the most thorough governance documentation.

There is also an internal effect that should not be underestimated. Architecture teams that operate only in advisory mode often struggle with engagement, purpose, and retention. Senior architects are attracted to consequential work. A practice that takes on the hardest delivery problems in the enterprise gives those architects exactly that—meaningful accountability, direct executive visibility, and the professional satisfaction of materially changing outcomes. It makes the architecture organization a more compelling place to work and a more credible institution from which to recruit.

A Real-World Example: Two Industries, One Result

The At-Risk Architecture Practice is not a theoretical construct, and it is not an anomaly produced by a single organization’s unique circumstances. The same model—solutions architects with delivery credibility, domain-aligned, embedded in at-risk and high-risk programs with accountability for outcomes—was implemented independently in two very different industries and produced the same result in both. The convergence is instructive.

Merrill Lynch’s Asset Management Business. Within Merrill Lynch’s asset management organization, the solutions architecture branch of the enterprise architecture function was repositioned from a traditional review and advisory role into a team explicitly accountable for at-risk and high-risk technology delivery. The asset management business operated a complex and deeply interconnected technology landscape: front-office portfolio management systems, trading and order management platforms, middle and back-office settlement and reconciliation infrastructure, regulatory reporting systems operating under SEC and FINRA requirements, and client reporting platforms serving institutional and high-net-worth clients with zero tolerance for error or delay. These systems were heavily interdependent, continuously evolving under regulatory pressure, and regularly the subject of large-scale transformation programs that carried significant execution risk.

Solutions architects were assigned to specific business domains—portfolio management technology, trading infrastructure, client platforms, and regulatory systems—aligned with their prior delivery experience and their existing relationships with business and technology leaders in those areas. When a program encountered difficulty, the assigned solutions architect did not arrive as a stranger with a governance checklist. They arrived as a known and trusted practitioner with deep familiarity with the domain’s constraints and the credibility to take on architectural accountability immediately. Programs that had been stalled by unresolved integration dependencies, by architectural decisions made without full enterprise context, or by the compounding complexity of simultaneous changes across interdependent systems were stabilized. Recovery timelines were established and met. In several cases, regulatory compliance deadlines that had been at risk of being missed were delivered on schedule. The Chief Information Officer and the heads of the business lines took notice—not because the architecture team presented a report about what it had done, but because the evidence was in the delivery outcomes they had personally been tracking.

A Leading Life Sciences and Pharmaceutical Company. A global life sciences and pharmaceutical company implemented the same model by transforming the solutions architecture branch of its enterprise architecture organization into the designated responder for at-risk and high-risk delivery initiatives across IT and the business. The practice was placed directly in the path of the company’s most troubled and highest-stakes programs: regulatory compliance systems under FDA and EMA submission deadlines, global clinical trial data platforms with cross-regional integration failures, ERP migrations spanning manufacturing, supply chain, and commercial operations, and commercial launch technology programs where delays carried revenue consequences measured in hundreds of millions of dollars.

As at Merrill Lynch, solutions architects were assigned to specific domain areas—R&D and clinical, manufacturing and supply chain, and commercial—aligned with their prior experience and professional networks. A solutions architect with deep regulatory and clinical systems experience was the credible partner for a VP of Clinical Operations navigating a submission deadline at risk. One with manufacturing and supply chain systems experience was the right person in the room when an ERP migration dependency chain threatened to cascade across three production domains. The assignments were stable and deliberate, allowing each architect to deepen both their domain knowledge and their working relationships over time. The results followed the same pattern: programs recovered, deadlines met, architectural root causes surfaced and resolved before they became submission failures or production outages.

The effect on architecture’s standing within the organization was rapid and durable. Within the first year, the solutions architecture branch had become the team the CIO called when a program was in serious trouble, and the team that business unit presidents referenced when explaining to their own leadership how a critical system had been stabilized. The Chief Digital Officer began including the practice in strategic planning conversations. Budget discussions shifted from justifying architecture’s existence to asking whether the practice had sufficient capacity to cover the full portfolio of at-risk programs.

The convergence across these two organizations—one a major financial services asset manager, the other a global pharmaceutical company, operating in different industries with different regulatory environments, different technology landscapes, and different organizational cultures—demonstrates that the model is not industry-specific. The conditions that make it work are consistent: delivery-credible architects, domain-aligned assignments, real accountability for outcomes, and the organizational willingness to put architecture in the path of the work that matters most. Where those conditions exist, the results follow.

Staffing the Practice: Who You Need

The At-Risk Architecture Practice is only as effective as the people in it. Staffing decisions are the single most consequential factor in whether the practice succeeds or becomes yet another advisory function with a different name. The profile required is specific, and it is not the same as the profile of a strong enterprise architect working in a traditional governance or standards role.

A proven track record of delivery, not just design. The architects in this practice must have personally owned delivery outcomes—not reviewed them, not advised on them, but owned them. They should be able to point to systems they built, programs they led through to completion, and technical decisions they made and stood behind when things got hard. The absence of that track record is disqualifying. Programs in crisis do not have time or tolerance for architects who have only ever operated at a theoretical distance from delivery. The credibility to walk into a struggling program and take on accountability for its architectural recovery comes from having done the equivalent work before, and from having the scars to prove it.

Domain knowledge and existing relationships. Each architect in the practice should be assigned to the business domains where they have genuine depth—not just familiarity with the technology, but understanding of the business processes, the regulatory environment, the organizational dynamics, and the operational constraints that shape what success looks like in that domain. Ideally, they bring existing professional relationships with delivery leaders, technical managers, and business stakeholders in those domains. When an architect already knows the Vice President of Manufacturing IT or the Director of Clinical Data Management as a colleague rather than a stranger, the first conversation in a crisis engagement begins at a completely different level of trust and directness. Where existing relationships do not exist, the architect must have the domain credibility and professional maturity to build them quickly. Either way, domain assignment should be deliberate and stable—not rotated arbitrarily, but maintained so that the architect deepens their domain expertise and their network over time.

The ability to make and hold decisions under pressure. Advisory architects are trained to present options and defer to others for decisions. The architects in this practice must be capable of the opposite: analyzing a situation, forming a clear point of view, making a decision, and holding that decision when it is challenged by program teams, vendors, or organizational politics. At-risk programs are environments of high stress, competing interests, and strong personalities. An architect who hedges, defers, or softens difficult findings will not move the needle. The practice needs people who can deliver hard truths directly, defend their positions with evidence and reasoning, and remain steady under the pressure that crisis programs routinely generate.

Executive communication and presence. Branch architects will regularly brief CIOs, Chief Digital Officers, business unit presidents, and program executive sponsors on architectural risk, remediation progress, and decision recommendations. They must be able to communicate complex technical situations clearly and concisely to senior leaders who have limited time and no patience for architectural jargon. This means translating technical risk into business language, framing options in terms of outcomes and trade-offs rather than technical specifications, and delivering assessments with the confidence and clarity that executive audiences expect from trusted advisors.

A learning orientation for unfamiliar domains. No architect will have deep expertise in every domain the practice may be asked to engage. The practice should prioritize architects who have demonstrated the ability to learn new domains quickly—to absorb the language, understand the constraints, and build credibility with domain stakeholders in compressed timeframes. This is a distinct skill from domain knowledge itself. Architects who are intellectually curious, who ask good questions, who earn respect through the quality of their thinking rather than the volume of their credentials, and who can adapt their framing and communication style to the norms of a new domain will extend the practice’s reach far beyond the domains where they have prior experience.

Small, senior, and selective. The practice should be deliberately small and deliberately senior. A team of two to five experienced architects operating at the principal or distinguished level will consistently outperform a larger team of mid-level architects operating under close supervision. The work requires judgment, experience, and autonomous decision-making that cannot be delegated down or supplemented with volume. Resist the temptation to build headcount. Build capability.

Standing the Practice Up

The practice does not require a large team or a lengthy organizational redesign. It requires three things: the right people, a clear mandate, and a visible first engagement. A founding cohort of two to three senior architects with delivery credibility is sufficient to begin. The intake process can be as simple as a standing conversation between the architecture leader and the PMO or delivery governance function, with a shared understanding of what qualifies for engagement.

The first engagement is the most important. It should be chosen carefully: a program that is genuinely at risk, where architectural factors are clearly contributing, and where the executive sponsor is willing to allow the practice to operate with real accountability rather than advisory status. A successful first engagement creates the proof of concept internally, establishes the practice’s credibility with delivery leadership, and gives the CIO something concrete to point to when describing what the architecture organization is doing to protect critical investments.

As the practice matures, the intake criteria can be formalized, the reporting cadence standardized, and the engagement model refined based on what has worked. Over time it should develop a repeatable methodology for architectural triage and remediation that can be deployed consistently across different program types and technology domains. That methodology becomes an organizational asset—not just a delivery capability, but a body of knowledge about how architectural risk manifests and how it can be resolved at speed.

A Caveat Worth Smiling At: Everyone Will Want Your People

There is a downside to building a team of delivery-credible, domain-savvy, pressure-tested architects who repeatedly walk into organizational crises and walk out with programs stabilized and executives impressed. Everyone will want to hire them away from you.

This is not a hypothetical. It is an operational reality that architecture leaders who run this model encounter with remarkable consistency. The same qualities that make a practice architect effective—genuine delivery experience, domain relationships, the ability to make hard calls under pressure, executive communication skills—are precisely the qualities that program managers, delivery leaders, and business unit CIOs spend their careers trying to find and keep. Once your architects have demonstrated those qualities in a high-stakes engagement, those leaders will notice. And then they will call.

Expect informal conversations in hallways. Expect your architects to be referenced by name in succession planning discussions they were never told about. Expect a VP of Clinical Operations or a Head of Trading Technology to approach your CIO with a quiet suggestion that one of your architects would make an excellent permanent addition to their organization. In some cases, the compliment will arrive disguised as a reorganization proposal. This is, in its way, the highest possible validation that the model is working—your people have become so demonstrably valuable that the rest of the enterprise wants to absorb them.

The architecture leader’s job is to take the compliment graciously, hold the line firmly, and make the practice a place that senior architects actively choose to stay. That means meaningful work, executive visibility, professional development, and the organizational backing to operate with real authority. It also means having an honest conversation with the CIO early: the practice’s value depends on retaining the people who built its reputation, and protecting that talent is a leadership responsibility, not just an HR matter. Build the retention plan before you need it. You will need it sooner than you expect.

Closing Thought

The most durable path to making architecture indispensable is the same path available to any function that wants to earn lasting executive relevance: be accountable for outcomes that matter to the people who fund the organization, and deliver on that accountability where the stakes are highest.

At-risk and high-risk initiatives are where those outcomes are decided. They are the moments when the enterprise is most exposed, when leadership is most attentive, and when the difference between sound and unsound architecture is most directly felt. Architecture that is present, embedded, and accountable at those moments does not need to explain its value. Its value is visible to every executive who was watching.

The At-Risk Architecture Practice is not a theoretical construct. It is a practical organizational design for architecture teams that are ready to move from advisory to accountable—and to claim the relevance that accountability earns.

Read more about the IF4IT Enterprise Architecture Value Model.