Charlie Alfred’s Weblog

4 B’s of Systems, 8 C’s of Architecture

The goal of this article is to have a little fun, while highlighting the nature of the relationship between systems and architecture.

A system is a collection of parts (or elements) whose interrelationships yield emergent priorities, characteristics that the parts alone cannot create.  Architecture deals with the class of systems known as intentional.  These are systems whose parts and relationships are deliberately designed to yield emergent properties.

Alliteration on the Essence of Systems and Architecture

Let’s start with four words beginning with ‘B’ that aim to capture the essence of a system and eight words beginning with ‘C’ that seek to capture the essence of architecture:













The words highlighted in italics represent the most immediate qualities of systems and the architecture processes used to create them.  The following diagram illustrates this:


Front Burner and Back Burner Activities

Architecture is often defined as the set of critical decisions that combine to have the greatest impact on a system’s most important quality attributes.  It has been said that all systems have architecture, but only some of them are intentional.

The truth in this statement stems from the fact that all systems have important quality attributes and these quality attributes are a direct result of decisions.  It doesn’t matter if these decisions were made deliberately or accidentally, or using an agile or waterfall process.  Due to the fact that systems are collections of interrelated parts, these decisions automatically shape the system’s being, behavior, balance and becoming. Q.E.D.

Whether due to management emphasis, convenience, or choice, many project teams use an approach to architecture that resembles Figure 1    Priorities are biased toward the upcoming deliverable, and the requirements of the immediate deployment.  The primary architecture activities focus on the components and collaborations needed to deliver the system’s required capabilities and separation of concerns needed to realize the system’s key quality attributes.

But just as system’s have architectures whether they are intentional or not, architecture processes address contexts, challenges and confirmation, whether intentionally or not.  This is true because just like components, collaboration, coupling and cohesion, these characteristics are an essential part of the fabric of architecture.

The only question is whether they are on the front or back burner when the architecture is being conceived.  The following diagram illustrates the relationship between contexts, challenges, confirmation and the other aspects of architecture (rolled up into choices).


Contexts, Challenges and Confirmation Illustrated

As Figure 2 shows, a context provides the purpose and environment for a system.  Context encapsulates external forces as well as stakeholders, their expectations, and use cases. External forces (such as constraints, uncertainty, dependency, variation and change) collide with expectations and priorities.  These collisions reveal challenges, and make them contextual.

The choices made by an architecture address challenges, whether well or poorly, intentionally or accidentally.  Andrew Counts writes about failures of the $500M website:

“The site itself, which apparently underwent major code renovations over the weekend, still rejects user logins, fails to load drop-down menus and other crucial components for users that successfully gain entrance, and otherwise prevents uninsured Americans in the 36 states it serves from purchasing healthcare at competitive rates –’s primary purpose. The site is so busted that, as of a couple days ago, the number of people that successfully purchased healthcare through it was in the ‘single digits,’ according to the Washington Post[i].”

It scarcely matters which challenge you believe the’s web site fails to address: scalability or handling denial of service attacks by Tea Party Republicans, it’s hard to fathom what activities were used to confirm the architecture choices before the system was deployed.

Microsoft’s architecture choices with Windows 8 are more complex.  Android and iOS have already shown that it is feasible to serve two contexts with a common operating system: smart phones and tablets.  Windows 8 is trying to serve three: smart phones, tablets, and personal computers (laptops and desktops).

Clear similarities exist.  Smart phones, tablets and laptops are all personal computing devices.  All of them can be used to browse the web, access email, listen to music, watch videos, read books and store documents.  But there are important differences between these devices.  Laptops are larger and more powerful computers.  They have larger displays, more processing power, more memory and more storage.  They have faster network connections (Ethernet and 802.11 wireless) and use keyboard and mice for input.  Laptops are portable.  They can be moved from one place to another, but were designed to be used while stationary.

By contrast, smart phones and tablets are mobile devices.  They can be used in one place, but were designed to be used while being moved.   They support wireless networks, but were designed to use cellular modems.  They are smaller and lighter devices, with smaller displays, processors, memory and storage.

So what’s the big deal?  Let’s look at personal vehicles to get a different perspective.

Toyota makes the Celica, Camry and Tundra.  All three are vehicles driven by people to provide transportation.  All three have gas powered engines, brakes, steering wheels, four tires, seats, doors and windows.  It wouldn’t be inappropriate to suggest that the Celica, Camry and Toyota are as similar as vehicles as laptops, tablets and smart phones are as computing devices.

But it is also clear that within their respective groups, laptops are as different from mobile devices as pickup trucks are to passenger cars.  To illustrate, consider the following challenges that might be faced by a homeowner:


Might Choose

Far More Likely to Choose

Type a long email or document Smart phone or tablet Laptop PC
Stream a Netflix movie while a passenger in a car Laptop PC (with a USB cell modem) Smart phone or laptop
Drive 3 people and luggage from Boston to Chicago Pickup truck Passenger car
Transport 50 cubic yards of bark mulch from Home Depot Passenger car (with a trailer attached) Pickup truck

This example confirms a quote attributed to Gerry Weinberg that is pertinent to systems and contexts:

“Something can be well-adapted or very adaptable, but it is extremely difficult to be both at the same time.”

Apple (iOS) and Google (Android) elected to be well adapted to the mobile device market and both have been successful.  Microsoft has chosen to try to be adaptable for the mobile and portable device markets, and has struggled to be well adapted for either.

“According to the researchers at NPD, sales of Windows PCs dropped 13% year-over-year for the period between October and the first week December, a statistic first reported by the New York Times. Considering that’s the exact time Windows 8 devices arrived on the market, it’s pretty damning evidence the new operating system isn’t catching on[ii].”


Many architecture processes today use Concept, Capabilities, Concerns, Components/Classes and Capabilities as primary considerations.  Often, these considerations are immediate, meaning that the main focus is on the near-term deliverable.  In an effort to limit system scope and complexity, context and challenges are often limited to the high priority use cases needed by users in the initially intended deployment environment.

In the process, other contexts are ignored or are given secondary consideration.  This includes:

  • Different sets of expectations or priorities of users in other contexts
  • Different sets of conditions or situations present in other contexts

Later on, if and when these contexts emerge as a priority, it is likely that the architecture has already committed to certain decisions that make these contexts much harder to satisfy.  Another way of saying this is that the architecture committed to some early decisions to satisfy the immediate context.  These decisions hardened into constraints that created or magnified challenges in the emerging contexts.

It is possible these constraints arose from something unexpected that changed in the emerging contexts.  For example, a country that is a new market for a medical device may have enacted unanticipated legislation or regulations.  In this case, the problem was unavoidable.  However, often these challenges were “hidden in plain sight”, that is, knowable all along.  The problem is caused by the oversight or unwillingness to consider the secondary contexts and challenges.

The tag line from the legendary 1981 Fram Oil Filter commercial[iii] captured this tradeoff perfectly.  “You can pay me now, or you can pay me later.”  Focusing some additional effort during the early phases of system definition to better understand alternate contexts and the deferred challenges the pose is not free.  Neither is the process of verifying how your planned architecture would address these contexts and challenges.  But failing to do this is like going ocean sailing without monitoring the weather forecast.  A Perfect Storm could be brewing without your awareness.

[i] See, as posted by Grady Booch’s Twitter feed @Grady_Booch on 10/10/2013.

[iii] See for a video of this commercial.



  1. Excellent post, as always.

    Comment by Gene Hughson — October 14, 2013 @ 9:15 am | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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

Blog at

%d bloggers like this: