Given an established enterprise with its decades-old IT department, processes, and practices versus the accelerating marketplace — when missing out on modern IT practices and being too rigid to react to market trends, with even innovation on half-yearly cycles — then¹ we see the hiring of a talented Agile architect to bridge the gap and lead the recently established digital pillar of the company.²

Let’s explore the common challenges The Architect faces via the story of a day.

At the start of the day, The Architect’s mind is still full of the escalation emails that arrived last night. Most of them asked about viability and for accurate estimates of important future roadmap items. The rest ranged from a gentle reminder of the yearly roadmap planning cycle through blocker escalations to the postmortem details of a new technology that failed in production. The Architect is determined to prioritize the most pressing blockers first to enable as many teams as possible. A few quick decisions are made — hesitantly — under time pressure and not having enough information. They are guided mostly by gut feeling and instinct. A few responses to escalation emails get sent, asking for more business context in hopes of avoiding the invisible landmines of corporate politics.

Feeling more comfortable, The Architect joins in on early team discussions only to learn that there is no mutual understanding between the implementers and consumers of an API and that another team has no idea of the revenue impact of the long-awaited feature it committed to deliver. Without the right governance, this feels like herding cats, but an over-regulated process would slowly strangle the teams’ progress. So The Architect quickly advises the teams to talk, share knowledge, and remember to document it, trying to keep in mind that the architecture metamodel — the tool mandated by the corporate enterprise architecture group — needs to be updated, too. In The Architect’s rush to the governance board meeting, reports based on “accurate” figures are quickly put together and some draft slides are produced from memory, not having the real-time insight or tools to produce them on the fly.

At the architecture governance board meeting, there are fewer people than usual, and The Architect quickly scans those present to sense the changes in power around the table. The Architect knows that important decisions need to be made. But these decisions often reflect the typical uninformed conversation where everything has to be “just right” immediately and are often based on “the single objective truth” that people so blindly believe in. The Architect then quickly sinks into familiar thoughts: how the digital department of the company should design “good enough” flexible solutions instead of producing report after report; and how quality, context, and meaning can be so detached from the measures demanded. Becoming somewhat frustrated, The Architect focuses on the meeting again to quickly note a few important changes in direction, the roadblocks arising from corporate policy changes, and the awkward technology solution that a previously unheard of unit has just forced into production.

It’s now time for coffee with the team leads and fellow architects and to convey the most important relevant changes. This is also the appropriate time to gently shape the practice and understanding of the architecture. After a quick argument with the most knowledgeable old-timer — a strong analytical thinker who questions anything not accurate to the most minute detail and who has been reassigned from a monolith company to spread domain knowledge — it becomes apparent that a balance between design and engineering thinking is still far away. More hands-on architecture practice is needed, and a pragmatic evaluation of the next emerging technology stack might be a good candidate.

The Architect’s closing thought of the day is the need to catch up with the teams as early as possible the next day, as there is no time for activities such as capturing, rethinking, or redesigning the architecture or solutions. There is only enough time to quickly align the delivery teams in-flight to avoid wasted effort.³

Architects spend their days trying to synthesize the old and the new; the static and the dynamic; organic solutions and problems; and, ultimately, dealing with people, process, and architecture equally. Without the necessary contextual insight, usually from more than one context, striking the right balance is extremely difficult, leading to fragile tradeoffs.

It’s Not the Trees

“Architecture,” for the purposes of this article, is the interconnected structure of relevant people, roles, and visions within a certain context. Defined in this generic way, architecture always exists and is implicitly defined. Consequently, architecture expands through space and time (space being the context for the usual structural representations; time being the context for architecture dynamics). As such, our definition of architecture is far from static diagrams and docu­mentation; rather, it is the living fabric in the business technology ecosystem.

When approaching an architecture representation, a key point is its decomposition into elements, usually leading to a containment-based representation structure. We might then navigate the architecture along the “containing” relations,⁴ or using predefined viewpoints. “Navigating along the containing relations” is the ability and constraint that navigation is only possible along hierarchies in the usual drill-down order. By principle, this then constrains what can be seen and in what context.

My proposal is free navigation across layers, taxonomies, and granularity levels. Viewpoints by their very nature define a single context; thus, views might miss an indirect relationship completely. Viewing an organic system only via tree-based representations is akin to the “blind men and the elephant” parable. The multitude of different aspects without a holistic view can be misleading.

To fill the gap, the proposed model should represent transitive relationships and their projections to groups of elements. The model should be navigable in a spherical manner, not limiting the insight to specific taxonomies. Any subset of the architecture should be decoupled from the way it is projected onto views. Forcing the emerging relationships into predefined taxonomies should be avoided.⁵

To reach the ideal balance in governing architecture, the challenge is to harmonize the intentional and the emergent architectures. The former is driven top-down, along tree structures, while the latter relies on loosely structured, bottom-up information flows. Thus, to incorporate both, the core representation model needs to expand accordingly. Moreover, to represent architecturally relevant information, the model should center around structural properties and patterns tagged with additional information about relationships and elements. Cohesion and coupling, the most common structural properties describing component autonomy, need to be explicit. Information about specific elements is naturally reflected in the context defined by their relationships to their neighborhood. In summary, the simplest model is an unconstrained dependency network tagged with metadata on its elements and relationships — the Architecture Knowledge Graph.

Architecture + Agile: The Yin & Yang of Organizational Agility 

This issue of Cutter Business Technology Journal explores how architecture can be the gateway to a future of continuous adaptation, innovation, and success for your organization. Order now with Code AA20 to Save 20%!

Notes

¹ The “given-when-then” structure refers to Gherkin, the common description language of behavior-driven development (BDD); see “Introducing BDD.”

² This scenario was chosen over another common story: rushing an Agile startup without any established architectural baseline or feedback cycle. In practice, both scenarios reveal similar difficulties.

³ One might rightly think that time management is the real issue. However, from another perspective, software projects are rarely protected from change and even under careful time management, unforeseen circumstances emerge.

⁴ For example, whenever a link is labeled as “part of” or “implements,” it is a “containing relation” by nature.

⁵ More precisely, tree structures typically imply complete coverage of all elements; there can be no uncategorized ones (this requirement is often addressed by introducing a specific undefined taxonomy item). Our core model relaxes the equivalence class-based model.

[For more from the author on this topic, see “A Light-Touch Architecture Governance Approach.”]