Charlie Alfred’s Weblog

Alignment in System Architecture

pbpk

The diagram above was tweeted by Philippe Krutchen (@pbpk) in October 2014 and recently retweeted by Ruth Malan (@ruthmalan)

For its intended scope, it is an accurate diagram.  It correctly highlights the need to align the architecture of the system with the structure of the development organization and the production infrastructure.

However, its intended scope is incomplete and risks aligning 3 tires while leaving the fourth badly out of alignment.

What is the 4th dimension, you ask?  It’s the set of problems being solved by the system – the mission of the architecture.  Surely, that’s the system requirements, you say.  Yes, but only after the fact.

According to Jack Greenfield (Software Factories co-author), a requirement is a statement made by a stakeholder about an outcome they consider to be mandatory.  For my purposes, user stories are requirements packaged in a six pack, rather than a 12 oz. bottle.  They provide much richer, contextual statements of essential outcomes.

Individual requirements or stories should be clear, concise and testable.  The problem is that the aggregate set of requirements need to be complete, feasible and consistent.  Given that requirements are provided by many stakeholders, what force of nature ensures complete, feasible, and consistent?

This is the missing fourth –ture.  It has been said that efficiency is doing things economically, without wasted effort.  Effectiveness is doing the right things efficiently. If this is so, then aligning system architecture, development organization and physical infrastructure are efficiency plays.  And aligning these three with the contexts and challenges of the system are effectiveness plays.

Let me try to justify this with a dozen short statements that act as core principles.

  1. Systems have many stakeholders. Value is in the eye of the beholder, meaning that it is subjective and shaped by stakeholder jobs, win opportunities and pain points.
  2. It is possible to group stakeholders into more manageable sets. A context is a set of likeminded stakeholders (similar goals and priorities) facing similar constraints and uncertainties.
  3. A value expectation is a property of a context. It captures a win opportunity or pain points and associates it with the constraints and uncertainties that must be overcome to realize it
  4. Each context has its own requirements. Simply cleaning up these statements and aggregating them into a system requirements document is fruitless:
    • Statements conflict with each other
    • There are missing or unstated requirements
    • Certain outcomes are infeasible, or at least, not known to be feasible
    • The solution set for certain outcomes precludes the achievement of others
  5. In short, we have a system problem. The set of stakeholder requirements is like having most of the jigsaw pieces from puzzle #1, plus a quarter of the pieces from puzzles #2 and #3.
  6. Architecture, in its simplest form, is a set of high-level decisions about a system that establishes its ability to realize the present and future goals of the system in an effective way.
  7. Paul Clements, Rick Kazman and Mark Klein (Architecture Tradeoff Analysis Method) observe that resolving risks and managing tradeoffs are fundamental tasks of architecture.
  8. This suggests that architecture decisions that have the most importance (highest priority) should be the ones addressed first.
  9. A challenge is a difficulty or complexity encountered by the system’s provider while trying to realize similar value expectations across one or more contexts.
  10. Architecture decisions should be traceable to challenges, not requirements. Challenges are the essence of the problem.  Requirements are a statement of the desired outcome.  Challenges include quality attributes and permit tradeoffs and risks to be managed more effectively than binary requirements.
  11. Challenges need to be prioritized, according to:
    • importance (of value expectation and context),
    • difficulty (including # of viable solutions) and
    • centrality (how many other challenges depend on this one)
  12. Each architecture decision reduces the degrees of freedom remaining to address the remaining challenges. Therefore, it stands to reason that the highest priority challenges should be addressed first.

The act of formalizing the problem according the above principles is an act of aligning the problem with the system architecture, development organization and physical infrastructure.  This alignment brings effectiveness to the efficiency of aligning the other three alone.

Advertisements

7 Comments »

  1. […] See https://charliealfred.wordpress.com/alignment-in-system-architecture/ for more discussion. […]

    Pingback by Efficiency and Effectiveness in System Architecture | Charlie Alfred's Weblog — March 18, 2015 @ 6:07 am | Reply

  2. I suspect Kruchten considered it obvious that the architecture of the solution should match the architecture of the problem. That’s a dicey assumption when the alignments he illustrated (which are necessary but not sufficient to insure effectiveness) are noteworthy. In other words, if the alignments in the illustration are missing, then it’s almost guaranteed that the design is flawed.

    Comment by Gene Hughson — March 18, 2015 @ 1:01 pm | Reply

    • Since all 3 of the alignments are solution-centric, I don’t assume it’s a given that they necessarily align with the problem. If if’s necesssary to state these 3 alignments, why is it appropriate to assume the other(s)? As the old saying goes, “when I assume, I make an ass out of u and me”.

      Comment by charliealfred — March 18, 2015 @ 3:13 pm | Reply

      • Well, I’m not exactly saying that it’s appropriate to assume, merely that it’s likely that the assumption took place. I think we’re in agreement that it’s dangerous to assume that the system architecture is always going to be in alignment with the problem space – just the opposite, people frequently deliver solutions to the wrong problem.

        As to the other alignments, I’m of the opinion that conforming to Conway’s law in both the system design and the delivery process design is part of aligning the solution to the problem. They’re not sufficient in and of themselves, but they seem to me to be a necessary condition.

        Comment by Gene Hughson — March 18, 2015 @ 3:39 pm

  3. Agree it is part. Stakeholder groups in Conway’s Law are certainly part of the value equation. Omit them at your peril and if you do, the tire will have punctures. Also agree it is not sufficient. If I could describe succinctly how much guesswork about client needs occurs, it certainly would disappoint you.

    What still perplexes me is the ratio of solution-centric conversation (e.g. microservices, cloud, Big Data, tecnology stacks, etc.) to problem centric conversation. Actually, perplexes might be the wrong word. At some level, we ignore the problem space because it tells us how much further we need to go.

    Comment by charliealfred — March 18, 2015 @ 3:49 pm | Reply

    • Lots of reasons for that ratio, IMHO:

      1) anti-design bias – people see high-level design as ‘waste’; worship at the temple of emergence; anything that’s not completely ad hoc (Yee Haw YAGNI!) is BDUF. Ironically, these are the ones most likely to be handed their rumps in a microservice scenario – if they think dozens of services implemented by independent teams are going to operate without _any_ coordination, well, have fun with that.

      2) cargo-cult mentality – people like to be told “do this, succeed”. It’s never true, but they buy into it over and over and over… I saw a discussion on LinkedIn the other day: “Please tell me the appropriate design patterns for an app in the insurance industry” – the level of hopelessness there is profound.

      3) lack of self-awareness – lots and lots of people who believe they do a fine job of designing and have no interest in discovering otherwise – “if it ain’t broke (at least as far as I know), why fix it?”

      4) technology addiction – there are a lot of people out there who see the technology of the day and start trying to find an excuse to shoehorn it into their situation – the idea of starting with a problem and then looking for answers is a foreign concept.

      Comment by Gene Hughson — March 18, 2015 @ 4:12 pm | Reply

      • Thanks, Gene. I feel a lot better now!

        Comment by charliealfred — March 18, 2015 @ 4:18 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: