Emerging vs Intentional Architecture

Part 2 of the Agile Architecture Series

If you’ve seen Part 1 of the series, you may be able to recognise One-way or Two-way decisions when it comes to Architecture (or life in general). How do we go about architecting solutions now that we know how vital or “permanent” the decision is?

Let’s start with the two extremes of architecting; Emerging and Intentional.

Emerging Architecture

Photo by Martijn Baudoin on Unsplash

Architecture is quite informal and is usually determined after the solution is built (or as part of building the solution).

Typical steps involved

1. BUILD
2. Document Architecture (optional)

Intentional Architecture

Photo by Kelly Sikkema on Unsplash

Architecture is planned, documented, debated, approved, and then the solution is built.

Typical Steps involved

1. Discuss / Debate Architecture
2. Document Architecture
3. Approve Architecture
4. Build
5. Document actual Architecture (optional)

spoiler alert: I don’t think Emerging Architecture or Intentional Architecture is Agile Architecture.

A quick summary of One-way and Two-way decisions. One-way decisions are difficult to change and should be more considered, whereas Two-way decisions can be changed (without a lot of impact) and should have a lighter governance touch.

• Intentional Architecture is still needed when looking at One-Way decisions. You need to get a consensus that you are making the right choices and that all the stakeholders have bought into the future state architecture.
• We can’t always afford the effort of Intentional architecture for our Two-Way decisions. We also don’t want our architecture to just emerge based on a conversation in a one-hour sprint planning session.

Trade-offs

Emerging vs Intentional Architecture appears to be about trade-offs that you need to make when you are designing a system.

Sometimes Agile = Emerging Architecture or “Architecture Free”

When I think about Agile, it is usually about choosing

1. Immediate Value (aka the MVP)
2. Ensuring Teams have the Autonomy to run as fast as they can
3. Being Agile and Responsive to Customer Needs.

Interestingly enough, these Agile goals are usually the bane of the Architect, where teams use the Agile mantra to load up on Technical Debt and never quite tackle the big problems, or drive the big solutions that will help organisations with their long-term strategic goals.

On the other hand, when (formally) architecting a solution we look to

1. Maximum Value at the expense of immediate value.
2. Seek Opportunities for Reuse and synergy across Teams instead of seeking Autonomy.
3. Be Forward-thinking (i.e. Slow) instead of Agile and Responsive.

So what we appear to have is a fundamental dichotomy of goals that are equally important but seem to have trouble living together.

Immediate Value vs Maximum Value

So where do we set this dial?

• Do I want 50% of the possible value of an opportunity within 1 month or wait for 90% of the possible value in 10 months?

And the answer is → It depends. What a great discussion to have with your stakeholders!

Autonomy vs Reuse

So what is more important?

• What you know? OR
• Who you know?

So a totally unsubstantiated hypothesis is that -

H1. Engineers like being autonomous and keeping to themselves because as a group they are mostly Introverts.

H2. Engineers are a very clever group of people and what they need to do can be done quicker if they don’t need to talk to anyone.

H3. Reuse won’t happen, unless Engineers are forced or have an incentive to look within the organisation for possible reuse.

Some ideas for unlocking reuse .. coming up

Agile and Responsive vs Forward Thinking

It is very rare, when looking at a plan for a new feature or some uplift of functionality that I see time carved out to understand and get the architecture right.

Usually, there is an expectation that “build” will start the week following the kick-off / sprint-planning / discovery workshop, etc. As architects, we don’t then have a lot of time to draw rectangles on whiteboards and stare out the window looking for inspiration.

So the challenge for the “Agile” Architect is how can we -

• Provide enough guidance to the Engineers to start build, without making them wait until we finalise the architecture.
• Minimise any waste; yes a lot of incremental work are two-way decisions that can be reversed, but let’s not waste a sprint if we don’t need to.

The usual approach to solve this is to complain that Product / Service Design etc have had months doing research and study and there is just not enough time to do a proper architecture. A different approach coming up.

Problem 1 — Equating Agile Architecture with No Architecture

Favouring the No Architecture Approach

Technical Debt gets accumulated

Actually, there is Bad technical debt and Not-So-Bad technical debt.

• Bad technical debt is technical debt that we accumulate .. and we don’t know that we are creating it — until later.
• Not-So-Bad technical debt are short-cuts that we know about upfront and are still willing to pay the price because the “Value” is worth it.

So the risk here is that we are creating Bad technical debt, and we don’t know it yet. Was the effort plus the new debt accumulated worth the Value we unlocked with this initiative?

Can’t see the forest for the trees

The Emerging Architecture / No Architecture approach lacks connection with a greater purpose. It can be difficult to see if this is moving us closer or further away from our medium and long-term goals for the system/portfolio/organisation.

Reuse is not identified

Refer to the Hypothesis above.

• H3: Engineers will not look to reuse assets if it is too hard or they are not told to.

Problem 2 — Thinking that Agile Architecture is just the same as what we used to do

All Architecture is Intentional and sometimes Ivory Tower architecture

Value opportunities are missed or diluted

Every week we spend architecting the perfect solution, means a week longer to start realising value. The time we consume should be sympathetic to the value that is being unlocked and any expiry date on that potential value.

As an IT capability, we sometimes gather around and discuss how product can’t make up their minds and keep pivoting on direction. Actually what might be happening is that solutioning is taking too long and that the potential value has expired.

Capacity is drained with reviews and decisioning

… where no decision is needed

It’s not uncommon to have multiple layers of approval for a relatively minor architecture solution. Even if that solution is implementing a pattern that has been implemented many times before.

Time can be wasted in formal reviews and preparing for reviews, where we could perhaps put more trust in our senior engineers and a peer review process.

Agile Architecture

So bouncing from one sprint to the next and doing just enough design to keep the Engineers busy is not Agile Architecture and the old ways of pondering about a solution for months to produce all the “correct” architecture artefacts is not Agile Architecture. What can we say is Agile Architecture? What are the Steps?

Step 1: The Architect Title and the Architect Role

I’m An Architect so I do all the Architecture. Or this solution needs architecting.

Hi I’m from Architecture, I’m here to help

At the risk of putting some architects out of business. Not all architecture needs to be done by someone with the title of “Architect”. In fact, an Engineer in the Pod or Tribe may be much closer to the problem to be solved and the value that is being unlocked.

When creating a design for a new feature or enhancement, the person doing the architecture needs to consider -

• How do we usually solve these types of problems? Is there a Pattern or Guideline for this already? See Step 2
• Do I need help? Find an Architect or another Engineer to run your idea by.
• Just like code reviews, get your solution peer-reviewed. See Step 3

Step 2: Architecture Patterns & Guidelines

The Guardrails and Cheatsheets

Photo by Bournes senruoB on Unsplash

Extract from the TOGAF 9 Standard —

Patterns offer the promise of helping the architect to identify combinations of Architecture and/or Solution Building Blocks (ABBs/SBBs) that have been proven to deliver effective solutions in the past, and may provide the basis for effective solutions in the future.

Architecture patterns provide a systematic approach to solving common challenges. They not only expedite the solutioning process but also ensure that solutions adhere to best practices, promoting consistency and reliability across diverse projects.

Well-documented patterns solves the first challenge of reuse — How do we get Engineers (and other people doing architecture) to leverage the organisation’s knowledge.

Actually, can a lot of the detailed solutioning be distilled down to just a set of tick-a-boxes? For example -

☐ Does the solution use our documented OAuth pattern for Authentication

☐ Does the solution use the standard logging pattern

☐ Does the solution’s APIs conform to the API standard and are they published in the developer portal.

… you get the idea.

How to Create Architecture Patterns

1. The best practice is extracting the architecture patterns out of the strategic projects within the organisation which leverages the depth and breadth of experiences gained during these significant initiatives. Many of the strategic projects include One-way decisions. We should be building patterns that consolidate our investment in these decisions.
2. Industry patterns are a great source of inspiration. The problem though is that there is more than one way (pattern) to do something. A process is needed to agree on the suitable patterns to use.
3. The most challenging way to produce patterns is a forensic analysis of what already exists in the organisation. This typically means multiple patterns have been used to solve the same type of problem. Work is needed to review the existing patterns and pick a winner for moving forward.

Step 3: Peer Reviews

The Light Governance Approach

Photo by Paulina Milde-Jachowska on Unsplash

In the words of one of America’s greatest Politicians and B-grade actors Ronald Reagan “Trust but verify” (Actually he borrowed it from a Russian proverb).

We want to trust people doing architecture to get on and do architecture, with a minimum of red tape. Especially for those two-way / noncritical solutions that are providing incremental value for their teams.

• Our Engineers are clever people who should not be slowed down by too much bureaucracy.

The Solution for ensuring conformance to architecture is -

1. Train Engineers / Architects to recognise Architectural significant solutions. Solutions that are systemically important need to have some more oversight and review.
2. Use the helpline / phone a friend to get to the right solution. This is especially important if you are colouring outside the lines or traveling too close to the guardrails.
3. Reviews should be open; foster debate and take us to a better place. They should not be so scary that they are avoided at all costs.

Summary

Large programs of work and One-Way Decisions

When putting together an architecture for a significant piece of work or a One-Way decision, it is important to be intentional. Architecture should be well defined and endorsed, after all, it will be around for some time.

To get the most out of these types of investments, we should aim to produce Architecture Patterns. Architecture Patterns will help to ensure that enhancements and features that build on top of the work delivered are consistent and maximise value.

Agile Architecture for Everything Else

So now that we have sorted out the large significant projects and architectures …

1. Good architecture is not just done by Architects. Given the right tools and support, we can have good repeatable architecture solutions from within the Pods / Tribes without bringing in external consultants (ie architects)
2. Invest “architecture time” in Patterns rather than Solution Architectures. We don’t need to lock up capacity building, documenting, and approving solutions for something that we already know the answer to. An architecture pattern documented once can serve many project initiatives.
3. Trust but verify. Architecture solutions can be peer-reviewed as well. Engineers and architects should not be afraid to raise an architectural concern.

Next — Agile Enterprise Architecture?

Did not get a chance to discuss how Agile architecture can / needs to align with the organisation strategy. Topic for next part in the series.