The Architecture Risk Principle and the Value of the Design Architect

February 28, 2018

If you are a digital product owner or manage a UX organization it’s important for you to consider what I call the architecture risk principle (ARP). ARP correlates to a widely known statistical probability, called the Pareto principle. The Pareto principle, commonly referred to as the 80–20 rule, states that, for many events, roughly 80% of the effects come from 20% of the causes. Likewise, the architecture risk principle asserts that architecture activities for any given project represent 20% of the effort, but effects roughly 80% of the subsequent collaborative efforts for design execution.

This means that sound digital architecture activities can mitigate up to 80% of a project’s risk—leaving design resources responsible for the remaining 20%.

architectural-risk-principle-graphic

 

Why Complex Projects Struggle at Execution

Design activities must naturally confront certain risks that architecture activities are unable to mitigate. Hence, architecture oversight must give way to design managers who coordinate domain-specific processes and their respective practitioners as they bear the remaining 20% of a project’s total risk.

However, when teams forego formal architecture activities and lead with iterative design execution, the responsibility of risk that’s placed on design managers and their staff (including software developers) increase by 400%; the crushing weight of this assumed responsibility is why projects fail.

This is a drastic and unrealistic transfer of responsibility that usually goes unacknowledged. The “canary in the coal mine” for projects often manifests as a tense exchange between team members to gain clarity and direction while simultaneously attempting to articulate a solution under fixed time constraints. Consequently, a significant portion of team resources is redirected to activities and documentation that fall into the realm of architecture.

“…the responsibility of risk that’s placed on managers, designers, and developers actually increases by 400%; the crushing weight of this assumed responsibility is why projects fail.”

When formal architecture activities take a back seat to design and engineering activities, talented managers, designers, and software engineers will instinctively close essential architectural gaps while others go unresolved. As a result, the architectural gaps that are addressed during the design process create a patchwork-like architecture that likely falls short of being a reliable foundation for future complexity and scale.

Common Warning Signs of Architectural Gaps

  • An architecture lead (role) is not assigned
  • No one has been assigned the responsibility to model the UI structure (information architecture)
  • Team members find it difficult to identify firm objectives
  • Ambiguous scope creates more questions than answers for designers and developers
  • Lack of UI- and UX-specific key performance measures
  • The absence of a shared vocabulary for discussing key project activities and deliverables

Architecture Promotes Clarity

Architecture is an act of establishing a frame of reference for which owners, designers, and technology teams collaborate to render an optimum solution. Translating owner intent and documenting a synthesized rationale across a wide range of factors are essential skills of a design architect.

Architects maintain the systemic view to effectively guide design teams and keep them on task and are the most senior advocate of design and planning.

While hiring a design architect is not required for every project, organizations must do a better job of determining when to employ them. When senior UX designers assume an architecture role—which will happen more often than not— it’s important to communicate the extended responsibility to the owner and team. When the team is faced with a future scope that warrants an exclusive architecture resource, the team and owner will be familiar with the value of the role.

What is a Design Architect?

If the “design architect” phrase sounds unfamiliar to you, it’s because I’m formally proposing it here. I originally introduced the idea of a design architecture in a 2015 article called, “A New Architecture for Information Systems.

“A design architect[1] is a seasoned facilitator of user experience planning, UX design, and is the operational lead in the creation of application user interfaces. They are relied upon to help rationalize the phases of user engagement and expertly promote scope alignment and design approach in preparation for the architecture, design, and engineering activities of application user interfaces.”

Overall, “the design architect is not the champion for the users; they are the champion of the business (owner) and the user. Striking a sustainable (via process and governance) and equitable balance between the two is the strategic responsibility of the design architect.”

A design architect[1] is a seasoned facilitator of user experience planning, UX design, and is the operational lead in the creation of application user interfaces.

In Summary

The cost of poor architecture is real: 1) Teams lose valuable time iterating over ambiguity, 2) design and engineering contributors become overextended, and 3) products meet their untimely demise due to major gaps in systemic thinking.

Consider adding a design architect role to your next project. When architectural discipline is incorporated into the process of designing application user interfaces, digital teams will improve time-to-market cycles, bring greater focus to team contributors, and see their systems of human-digital experience deliver sustainable user and business value.