Charlie Alfred’s Weblog

Architecture in a Nutshell


Object-oriented programming is difficult.  Ask anyone who does it for a living.  But the core concepts that form the foundation for object-oriented programming are straightforward: abstraction, encapsulation, inheritence, polymorphism, and interface contracts each can be described clearly in a sentence or two.  Yet these concepts are the cornerstones of any good object-oriented program.  Omit them and the foundation crumbles, and the program devolves into a brittle tangle of programming statements that are difficult to understand and harder to maintain.

Software architecture is difficult, too (although more people fancy themselves to be architects than fancy themselves as crackerjack programmers).  Architecture has its own list of core concepts.  Any good architecture incorporates all of them.  Omit them, and while your code may build, your system will perform poorly, fail to scale, have security issues, be hard to configure, and costly to maintain.  Just as no amount of good carpentry can rescue a poor house architecture, no amount of good programming can rescue a poor software architecture.

In this article, I will mention each core architecture concept, and describe it in a short paragraph.  Following each concept is a link to 2 or 3 articles that explore some facet of this concept in greater detail.

Eight Essential Concepts

Context is the setting in which solutions are experienced and value is perceived.   Changes in location, situation, surrounding systems, and subjective perceptions of users can alter the context, forcing the system to adapt.  In a semiconductor cleanroom, dust is a key part of the context.  For automobiles, weather and pollution standards are big parts of the context.   One of the most challenging aspects of context is finding an effective way to straddle them.


Value is the perceived worth of a solution as experienced by some like-minded group of stakeholders within a similar context.  Value tends to be higher when an opportunity is opened or a pain point is addressed.  Value could be absolute, or be relative.  In the latter case, it could be relative  to another alternative, or to the stakeholder’s (unrealistic?) expectations.  Value is different from benefit.  Benefit is objective and quantifiable; value is how benefits are experienced.



Picture credit:

Challenges are major risks and obstacles with the most impact on value.  The key concepts here are difficult, valuable, and dependency.  Difficult, because easy risks and obstacles tend have lots of good alternatives (i.e. degrees of freedom).  Valuable, because the solution should just avoid or mitigate big risks and obstacles that don’t have a big effect on value.   Dependency, because decisions on which many other decisions depend can be the most difficult to undo.

Priorities apply to Challenges and are the principal guidelines used for determining the sequence in which architecture decisions should be made.  The specific criteria used to prioritize challenges may vary, but should always include value, complexity, dependency, and the availability of good alternative approaches.  The first three criteria were discussed briefly under Challenges.  The fourth criteria ensures that the architect avoids painting him/herself into a corner by treating “the last good alternative” as an alert.

Requirements are verifiable assertions, each of must be satisfied for a solution to be acceptable.  A specification containing hundreds or thousands of extremely detailed requirements is a straightjacket for mitigating risk, making tradeoffs, or overcoming challenges.  Good requirements specify minimum performance levels for the system’s highest priority challenges.  Motor vehicle inspection is a good illustration.  Certain things like headlights, breaklights, steering, breaks and emissions must work properly.  But passing inspection, does not necessarily guarantee that the car is efficient to operate and a pleasure to drive.

Goals are statements of outcome which map challenges to value perceived by stakeholders.  In many cases, a challenge will have both a Requirement and a Goal.  Clearly specified goals (and clearly differentiated from requirements) are the basis for assessing sensitivity of value to a decision, and for making good tradeoff decisions.  For example, consider a requirement for a laptop to weigh under 10 lbs, with a goal to reach 7 lbs.  However, delivering more memory and disk space might be a better tradeoff than achieving the goal weight.


Architecture is formulating solutions which create significant value for stakeholders in the target contexts.  Since the solution usually takes the form of a complex system, architects must also participate in or lead the process of identifying and prioritizing challenges, which yield requirements and goals.  During the formulation of the solution, the architect(s) must identify approaches, assess impact, consider dependencies and tradeoffs, manage risk, and understand sensitivity (how value varies with changes in approach).


Principles are rules, best practices, patterns, and styles which capture wisdom from similar types of problems.  Many of the principles can be identified when constructing the prioritized list of challenges (e.g. server clusters are useful for load balancing and high availability).  Some principles surface when approaches are being defined (e.g. replication of database transactions to a read-only mirror is a good way to offload query traffic).  Others might reveal themselves after the challenges have been addressed.  In any case, principles are an important source of conceptual integrity, and make it possible for more participants to have a clear comprehsion of the architect’s intent.



Value is perceived by stakeholders and varies as context changes.  Challenges are barriers to delivering value.  Priorities for a set of challeges are based on value, complexity, and dependency.  Having challenges with clearly defined priorities is essential for making effective tradeoffs.   Challenges identify, and are linked to, requirements and goals.  Requirements are minimal acceptable outcomes (binary).  Goals express how well solutions to challenges yield value.  Architecture must identify approaches (sets of related decisions) to address the prioritized challenges.  Principles are great ways to make the architectural intent more understandable by expressing rules and/or patterns in decisions.

In too many projects that I’ve seen, product management and development teams race ahead into defining functionality, laying out user interface screens and specifying requirements.  Precious little thought is given to which contexts exist, why they are different, and how this affects what stakeholders need and want.  Even less thought seems to be given to recognizing and prioritizing challenges.  The act of defining requirements in the absense of comprehending challenges and their priorities is naive in the best case, irresponsible in the worst.  And finally, creation of a technical solution without clearly articulating the principles that form the backbone for this solution is simply a guarantee that nobody else will understand the approach, and will just do what makes sense to them.  If there is a stronger prescription for misalignment, I don’t know what it is.

As in programming, the easy part is knowing what you are supposed to be thinking about.  The hard part is understanding the nasty problems, and learning about the strengths and weaknesses of the solution alternatives.  This part makes your brain hurt.  The harder part is dealing with all the constraints, uncertainties, and interdependencies.  This part makes your stomach hurt and keeps you awake at night.  But the hardest part is dealing with the stakeholders who see only their perspective, and trying to explain the other considerations to them.  This part can cause you to give up hope, but it also can be your source of greatest joy.  Because in the end, helping to a disparate group of people align on the same approach and work for it is something that many people never get a chance to experience.  But in order to do this, you must know how to make the core concepts work for you.




  1. Woww !!!!

    This write up is just wonderful. So much packed in so little space.


    Comment by Deepak — May 1, 2009 @ 2:13 am

    • Thanks, Deepak. I appreciate the comments, very much. The journey to get to the insights in that article was difficult, but personally very rewarding. I was fortunate to have had the experiences I did.

      Comment by charliealfred — May 1, 2009 @ 2:23 am

  2. Too good, I was looking for something compact, different and useful; finally I got it here…

    Thanks Charlie!

    Comment by Amby — May 25, 2009 @ 1:30 pm

  3. Thanks! Now the next task is to get organizations to actually do it this way! 🙂

    Comment by Charlie — May 25, 2009 @ 3:51 pm

  4. Great site, how do I subscribe?

    Comment by Kelli Garner — October 3, 2009 @ 2:31 am

    • Navigate to the WordPress URL. In your browser, you should see an RSS button. In IE7 it is on the right, in the top menu bar near the Home button. Click it and it should show a page with a link that lets you establish an RSS feed.


      Comment by charliealfred — October 4, 2009 @ 8:32 am

  5. i am amazed with the photo of the climber on your website and was wondering if i could have your permission to use it for a scholarship poster i am making. The photo would enhance my poster to a great extent to help create the poster i imagining. Thank you

    Comment by Rebekah — March 11, 2010 @ 2:57 pm

RSS feed for comments on this post. TrackBack URI

Blog at

%d bloggers like this: