Part 5 – Decisions, trade-offs and architectural requirements


In previous posts Hillary has discussed Steps 1-5 of the “six step process” and we have now come to the end of the staircase. It has been so interesting to read how the architecture evolve and let’s not waste any more time introducing this chapter. Here is the final chapter from Hillary Sillito on the subject of; “What has system architecture got to do with requirements?”

A shared mental model

I have discussed the different steps in the “six step process” and have described the steps sequentially, but really there’s a lot of iteration and going back and forth. It’s a learning process – we work on each step in turn to increase our understanding of the whole. The first time through, we go as quickly as possible to build a coherent skeleton. Then we’ll flesh it out as needed to support decisions and give everyone a good understanding of the whole system and how their bit fits in.

A very important aspect of architecture is to give the team a “shared mental model”, so that “everyone is making the same system”.


Equally important, the six steps of system architecture show us how the different perspective are linked, and let us do trade-offs across all the perspectives to make the system cheaper, simpler and more effective.

The physical parts need to be chosen so that they fit together and work together. The individual physical parts that best fit together might not work together so well in “rainy day” scenarios. The parts that work together best for the “rainy day” scenarios might be too big, or take too much power. This is where we get the payback for all that work we did on enterprise and operational perspectives. Maybe we can make the system better, or cheaper, or more reliable, or easier to use, or all of these, if we go back up to Step 2 and change the way the system will be used.

The six step architecting process opens up the range of possible choices and lets us trade not just within the technical solution, but between the technical solution and the operational concept. It might be cheaper to change the way people work than to add complexity to the new product – or maybe we don’t even need the new product at all! Requirements can be renegotiated if we can show, through the architecture, how they make the solution expensive and risky.Hillary_part5

But hold on. I said six steps, and we’ve only talked about five. What is step six? That’s the decision perspective. Each of the other five perspectives involves a set of decisions; but since the perspectives are all inter-linked, we need a holistic view of how decisions interact and have consequences across all the perspectives.

The Decision perspective

Decision structures can be complex. One decision drives another, which drives another, which drives others, which drive the first. Or we have a long decision tree with many branches. So that the work can be planned in a good sequence, we need to build a decision map, which shows us how the key decisions relating to the architecture are inter-related, what order they should be taken in, and what supporting analysis and experimentation is needed to inform each decision.

This brings us to architectural requirements. When we architect a system, we combine knowledge from the problem space of what the customer wants, with knowledge from the solution space of how the system needs to be constructed to work, to keep working, and to be no more costly than absolutely necessary. One of the key architecting roles is to make the system-wide design decisions that impose coherence, consistency and efficiency across the system. These might be design principles for safety and security, common interface and data definition standards, overall power and thermal management, consistent layering schema, consistent start-up and recovery strategies, common MMI look and feel, standardised personnel and training policies, whatever is important for the system of interest.

All these decisions are to meet the implicit customer need for an effective system that is fit for purpose; but most won’t be traceable to explicit requirements in any straightforward way. The requirements management process needs to capture the rationale for the system wide design decisions and ensure they are reflected as requirements on the subsystems.

Previous post in this series on Architecture

This post is part of a series on architecture and requirements by Hillary Sillitto. You can read the previous posts or his personal bio here:

Part 1: what-has-system-architecture-to-do-with-requirements?

Part 2: System requirements don’t appear by magic

Part 3: Part 3 – Using System architecture to Decide if the requirements are coherent and sufficiently complete

Part 4: Part 4 – System Architecture Provides the framework and rationale for allocating requirements to parts

About the author

If any of you have the urge to get into contact with Hillary Sillitto he can be reached through his web page: www.sillittoenterprises.com

Next Blog

This was (sorry to say) the last post made by Hillary on this topic. I wish him to come back and write more! Next time I have another great mind who is going to elaborate about the errors and problems with User-Stories…

See you next time!



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 )

Connecting to %s