Charlie Alfred’s Weblog

The Architecture of the Problem

The Architecture of the Problem

This page is a series of FAQ-like questions and answers that describe what is meant by the term “Architecture of the Problem.”

What does the term “Architecture of the Problem” mean?

Systems, Software and Enterprise Architecture have historically defined solutions to problems.  Yet the problems to be solved contain as much richness and complexity as their solutions.  Unfortunately, the mechanisms for describing problems have lagged behind those for describing solutions.  The Architecture of the Problem is an attempt at bringing more rigor to the problem side.

For the purposes of this document, what is a System?

A System is a set of related components that exhibit emergent behavior.  For example, a car is a set of related components that exhibits motorized transportation as an emergent behavior.  All of the parts of a car, strewn on the floor of a mechanics shop does not possess this emergent behavior.  Solutions and Problems are each systems, although of slightly different types, as we will explore.

What is the Architecture of the Solution?

It is important to understand Solution Architecture in order to compare and contrast it with the Architecture of the Problem.  The solution architecture is typically specified as a set of views that combine to act as an “operators’ manual” for the solution.  Table 1 describes some of the key views.

View What does the View Describe?
Organizational What are the key components?What role(s) does each play?How are they structured (hierarchies? services?)
Informational What are the essential pieces of information?How are they related?  How are the relationships constrained?Is this information transient (messages) or persistent (storage)?
Process What are the processes that make up this system?What compute devices (computers, threads) do they run on?What are the main workflows for the system?

What are the inputs, outputs, steps, and conditions in each workflow?

Which workflows can run in parallel?  Which must run alone?

Deployment How is the system deployed?  What changes must be managed?What state does the system need to be in to be updated?How can the system be configured for different uses?
Use Case What are the goals of the system?What types of users or external systems interact with it?What are the set of use cases that describe these interactions

These views do a thorough job of describing the important pieces and relationships in the solution.  However, they do a limited job of explaining what problems the system solves.  For example, use cases describe capabilities, not intent or situation.  I may know that my smart phone can take pictures and its GPS knows my location.  But if I am involved in a minor car accident, I need to take photos of the other vehicle, its license plate, and find the nearest auto body shop.  These things typically don’t appear in the architecture of the solution.

How has the Problem typically been defined?

Historically, there have been two ways to describe the problem: Requirements and User Stories.  Each of these will be discussed briefly, along with their limitations.

How do Requirements define the Problem?

A system stakeholder is someone (or some group) who have a stake in the outcome of a system.  There are several types of stakeholders: buyers, end users, owners, development sponsors, developers, manufacturing, customer service, etc.

A requirement is a statement made by a stakeholder about an outcome that is mandatory.  A well-written requirement is atomic, clear, concise and testable.

A set of requirements defines the system at a specific level.  For example:

  • Business requirements describe the solution at the level of competitive products, gross features, time to market, up-front investment, etc.
  • Product requirements describe the solution at the level of specific product features and certain non-functional qualities like security, safety, precision, or availability.
  • System requirements decompose the system into functional subsystems, each of which addresses an engineering specialty such as mechanical, electrical, chemical, and software.
  • Subsystem requirements supply detailed requirements for a particular subsystem.

It is clear from this list that there is a hierarchical structure to the requirements.  The first three levels each describe the system from a different perspective.  The last two levels have a whole-part relationship.

A suitable set of requirements must have well-written individual requirements, and must be complete and consistent.  Tracing is a term used to describe the relationship of a requirement in one set with a requirement in another.  For example, a System requirement needs to trace to a Product requirement.  In theory, the set of traces identifies incomplete coverage and inconsistency.  However, in theory, theory and practice are the same.  In practice they are not.

In practice, what is the primary strength of requirements?

A well-written set of requirements is ideally suited to support verification.  Each requirement in a set is a statement of an outcome that must be met.  A well-written requirement is testable, and therefore can be independently verified.  Likewise, a set of requirements can be verified as a test case, and completeness can be verified.  Verifying consistency of requirements is a combinatorial problem and is more difficult to verify systematically.

In practice, what are some of the weaknesses of requirements?

Several practical weaknesses of requirements are listed below.  This is intended as an illustrative list, rather than an exhaustive one.  These weaknesses reflect normal practice.  Specific individuals and organizations may have workarounds for these weaknesses; however, in my experience, these have not yet been systematized into effective, routine practice.

  • Requirements are a definition of the intended solution, not the problem(s) for which the solution applies.
  • Traceability is much more difficult with vaguer, higher level requirements (e.g. business, problem and system). It is one thing to assert that a more detailed requirement supports a higher level requirement.  It is another to assert that a collection of lower level requirements fulfill a higher-level requirement.
  • Requirements don’t deal well with conditions. While it is possible to write conditional requirements (e.g. the operating limits of a component), it is very difficult to normalize conditions across a set of requirements.
  • Requirements don’t support risks and tradeoffs. Requirements state outcomes, where the risks and tradeoffs have already been analyzed.  Analysis of risks and tradeoffs are typically the province of architecture activities, where conditional outcomes[1] are incorporated.  This leaves us with the problem that business and product requirements are riddled with unresolved risks and tradeoffs.

How well do Requirements support the Architecture of the Problem?

The answer is it depends.  Problems are different.  Some organizations need to re-solve problems that they have solved successfully before.  Perhaps they are developing a next generation product where the market needs and technology capabilities are mostly the same.  In this case, the decisions from the prior product generations are mostly reusable, and their requirements form a suitable knowledge base.

The problem here is that changes in market needs, competition or technology can easily upend a previous set of requirements.  Given the nature of a system, interdependencies between these factors can introduce new risks or tradeoffs, neither of which requirements are well-suited to address.

The problem worsens when innovation is the goal.  In this case, risks and tradeoffs are high, and requirements aren’t very helpful until an organization has run experiments or built prototypes to resolve them.

What are Agile Methods?

This will be a short answer to a much longer story.  Many articles about agile theory and methods can be found via Google searches of the internet.  This description will focus on Scrum, one of the more popular of the agile methods.  Another method, not discussed here, is Kanban,

As a group, agile methods seek to manage risks and tradeoffs at the development level by:

  • Continuously developing a working system
  • Maintaining a backlog of work to be done
  • Working in short time iterations, on a limited subset of tasks
  • Testing continuously and getting stakeholder feedback after each iteration

Some agile teams also make it a point to refactor their system, after a set of changes compromise the structure.  Others don’t and frequently find themselves with a hefty portion of technical debt[2].

How does Scrum define the problem?

Different agile methods define the problem in different ways.  We’ll focus on Scrum here.  The unit of work in Scrum is called a story; the set of stories yet to be completed is called the backlog.  A story specifies one or more actors (or participants), pre-conditions, a stimulus to begin the story, a set of interactions and an expected outcome.  It may also contain error conditions and handling instructions or variations on the story.  Typically stories may describe:

  • interactions between end users and the system
  • interactions between external systems and the system
  • infrastructure behavior within the system

In practice, what is the primary strength of stories?

The biggest potential strength of well-written Scrum stories is that they can contain a lot of context, that is, useful information about the story that provides important background about conditions, situations, goals, priorities, and motivations.

Stories also have a flexible structure which permits “want goals” to be defined.  For their Decision Analysis method, Ben Kepner and Charles Tregoe[3] defined two kinds of goals:

  • Must goals specify required outcomes using a binary pass/fail statement
  • Want goals specify how well the outcome can be satisfied using conditional levels.

For example, using want goals, traditional school grades of A, B, C, D and F can be associated with different outcome levels, such as miles per gallon.  Each grade maps to how useful that outcome is perceived to be.  The outcome level slope between adjacent grades informs tradeoffs between this goal and other goals, or this goal and constraints which affect its result.

In the absence of want goals (such as with Requirements), one common result is the “over-constrained requirement.”  This occurs when a stakeholder fears that a requirement may not be satisfied, and specifies a stricter requirement, which harder to reach and leads to more tradeoffs.

What are the primary weaknesses of stories?

As the prior section observed, the template-based, free-text format of stories was their greatest strength.  When viewed from a different angle, it also is their greatest weakness.  Specifically, it is very difficult to ensure consistency, non-overlap and completeness with a set of free-text stories.

Another weakness is that there is no mandate to document conditions, situations and utility curves in a story.  Or, if these are documented, that they are documented consistently and completely.

Finally, the free-text nature of stories can lead to non-rigorous descriptions, which don’t function well as specifications when security, safety, or precision qualities are necessary.

How do Requirements and Stories support Solution Architecture?

Currently, Requirements and Stories are the two pervasive forms of problem specification that are used to support solution architecture and development.  The answer to how well they support it is best expressed by Goldilocks:  “This bed is too hard.  This bed is too soft…”

Requirements are mandatory statements in a fixed structure.  They are suitable for rigorously specifying a solution that is well-understood, establishing traceability and defining test criteria.  This makes them the technique of choice for specifying the boundary between architecture and development/verification.  However, they are awkward in the front and middle areas of a problem, where risks and tradeoffs live.

Stories are template statements in a mostly free-form structure.  They require pre-conditions, inputs, and outcomes, and describe interactions with external participants.  Stories are well-suited for describing collaborations between participants and the system.  These descriptions can and should identify most of the “why” statements, but often fall short of this goal.  While Requirements are well suited for the back end of the problem statement, Stories are most useful in the front end.

The problem is that neither Requirements nor Stories are innately good at the middle-end of Problem definition – the place where tradeoffs and risks must be resolved to generate a good and feasible solution.

What is the alternative for describing the Architecture of the Problem?

I refer to this as VDA[4] (or Value Driven Analysis).  It consists of a few components which will be mentioned here and discussed below:

  • Contexts
  • Challenges
  • Architecture Decisions

Why are Contexts important for the Architecture of the Problem?

In VDA, a context is a group of like-minded stakeholders with similar jobs to perform that is exposed to similar external forces.  Like-minded stakeholders typically have similar goals, priorities of goals, and utility curves (i.e. preferences for want goal outcome levels, as described above). External forces are typically captured as:

  • Conditions: An environmental state that is in effect when something interesting is occurring.  For instance: temperature, precipitation type, precipitation amount, wind speed and wind direction are important conditions for de-icing.
  • Situations: represent factors that change the degree of difficulty to achieve must goals or how well want goals are satisfied.  Conditions might create a problem (icy roads) or an opportunity (light traffic).

Strategyzer.com[5] uses Customer Segments as a key concept in defining Value Propositions.  They define a Customer Segment in terms of:

  • Job what the customers in a segment do, what value they provide
  • Pain Point situation where external forces impose constraints or risks
  • Gain Opportunity situation where  external forces reduce constraints or risks

VDA and Strategyzer formulation were defined independently but have important similarities which tend to validate each other.  VDA makes more explicit reference to external forces, both in the definition of a context and in the construction of pain points and goal opportunities.  This will be important below, in the definition of Challenges.

Why are Contexts important for the Architecture of the Problem?

The most important reason is that each Context represents a container for equivalent user experience.  After properly defining a Context, it is possible to:

  • Reason about its members collectively
  • Identify Conditions and Situations that affect goal achievement
  • Assess risks using outcome levels of want goals and probabilities of Situations
  • Assess tradeoffs using outcome levels and priorities of want goals

The second reason is that it is possible to consider Contexts as a group and compare goals, priorities, conditions, and situations.  For example, each Context might represent a different Customer Segment with different tradeoffs and exposure to risk.

The third reason is that Provider Contexts want to understand what their Challenges are to satisfy a group of Consumer Contexts.  Understanding the commonality and variability of Pain Points and Gain Opportunities is an important technique for achieving this.

Why are Challenges important for the Architecture of the Problem?

The simplest way to understand a Challenge is to think of it as a Pain Point in a Provider Context.  In other words, a Provider Context is a collection of like-minded stakeholders with a similar job whose primary goal it is to satisfy the needs of a set of Consumer Contexts.

For example, in a development organization of a product company, Provider Contexts might include:

  • Product Marketing
  • Systems Engineering
  • Mechanical Engineering
  • Electrical Engineering
  • Software Engineering
  • Quality Assurance
  • Manufacturing
  • Field Service

All work for the same company, but each has a different, but related job to do.  And each context will have its own set of challenges to overcome.  For example, Mechanical Engineering is more concerned about size, weight and durability, while Software Engineering might be concerned about realtime control and data collection.

Within a Provider Context[6], a Challenge crosses one or more Consumer Context.  It is the impact of one or more external factors on the ability to satisfy one or more goals.  For example:

  • Two or more Consumer Contexts might have similar goals and priorities, permitting one solution to satisfy all with minimal tradeoffs or risks.
  • Two or more Consumer Contexts might have conflicting goals or priorities, such that both cannot be satisfied well at the same time (e.g. a smart phone with a large screen that can be carried easily, used by men (pants pocket) and women (purse)).
  • Two or more Consumer Contexts might have varying goals that are independent (or largely independent). In this case, it might make sense to produce two products or produce a configurable product.

How are Challenges used in the Architecture of the Problem?

Unlike Requirements, Challenges are purely statements of the Problem:

  • Each Context has goals, utility curves, goal priorities and external factors
    • Conditions package up a common set of external forces
    • Situations package goals, conditions and external forces to alter the value equation
  • Pain Points and Goal Opportunities
    • Are specific to Consumer Contexts
    • Link goals, utility curves, goal priorities, and external forces
  • Each Challenge is owned by a particular Provider Context
  • Challenges are linked to Pain Points and Goal Opportunities in Consumer Contexts

Challenges describe what the problem is, in a way that is more complete and rigorous than either Requirements or Stories.  They strive to not describe how to solve the problem.  But most importantly, Challenges describe why the problem is a problem.

How are Challenges Prioritized?

One of the most important activities for a Challenge is prioritizing it relative to other Challenges.  The reason for this is:

  • An Architecture, in its rawest form, is a sequence of decisions for a system.
  • Each decision made in sequence, constrains the degrees of freedom for remaining decisions
  • As degrees of freedom are consumed, the viable alternatives for a Challenge shrink
  • This motivates making the most important decisions first

There are three main considerations that are combined to prioritize Challenges

  • Importance
    • Priority of goal affected within a Context times the Priority of the Context
    • Sum of Importance for goals that cross Context
  • Difficulty
    • How difficult is it to achieve this goal?
    • How many viable alternatives remain?
  • Centrality
    • How many other Challenges depend on this Challenge?

The Importance, Difficulty and Centrality factors typically exist in all problems.  How they are weighted is up to the Systems Engineer and Business Executives to determine.

How are Architecture Decisions related to Challenges?

An Architecture Alternative is a way to address a Challenge.  An Architecture Decision is preferred Architecture Alternative that is chosen for how well it addresses a Challenge, and its conformity with earlier Architecture Decisions.

The approach to decide among several Architecture Alternatives is left as an exercise for the reader.

In many cases, there will be a one-one relationship between an Architecture Decision and a Challenge.  In some cases it will be one-many (e.g. a spare in bowling).  In other cases it will be many-one (a difficult problem requiring several related decisions) or many-many.

 

 

 

[1] Examples of conditional outcomes are the MPG and cargo space of a minivan or crossover vehicle.  There is an inherent tradeoff between cargo space, vehicle size and fuel economy.  In order to analyze the tradeoff, it is necessary to have a “currency conversion table” that describes how much fuel economy I am willing to gain or sacrifice based on changes in cargo space (and vice versa).

[2] Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.  http://www.technopedia.com/definition/27913/technical-debt

[3] Kepner, B. and Tregoe, C., The New Rational Manager

[4] Alfred, C.  “Value-Driven Architecture: Linking Product Strategy with Architecture”, Microsoft Architecture Journal, July 2005.  Value-Driven Architecture was renamed to Value-Driven Analysis after publication.

[5] Osterwalder, A, Pigneur, Y, Bernada, G, and Smith, A, Value Proposition Design: How to Create Products and Services Customers Want (1st edition).  Wiley, 2014

[6] A Participant is an entity in the Problem Space.  Provider and Consumer Contexts are Roles played by a Participant.  For example, a Field Service organization (Participant) can play both Provider and Consumer Contexts.  As a Provider, it supplies product support to customers.  As a Consumer, it may get tools from Engineering.

6 Comments »

  1. […] outline that was in this post has been subsumed by: Architecture of the Problem which discussess this […]

    Pingback by Architecture of the Problem 2 | Charlie Alfred's Weblog — March 25, 2015 @ 11:05 am | Reply

  2. I like this! one person’s problem often has another person’s solution..and sometimes that solution forms another person’s problem!

    I like what you’ve said about how SCRUM sees requirements…it of course if quite behavioral in nature (as it should be).

    I also like your notion of context and challenges…might i also suggest you consider constraints? (you’ve got the 3 Cs in effect) wherein a constrain is something immutable.

    Comment by Grady Booch — March 31, 2015 @ 9:23 pm | Reply

  3. HI Grady, thanks for the comment. Regarding your last point, constraints an uncertainties are the foundations for challenges. Conditions are used here as a base class for constraints (known immutable factors) and uncertainties (variable/volatile forces).

    Challenges are the impact on value of one or more constraints and/or uncertainties. Example, friction is a constraint for cars – fuel economy, braking, etc. Uncertainty might show up in the form of road condiitions, traffic, weather, etc. The time to detect a hazard and begin braking is a challenge (i.e. the time needed to physically stop + time needed to respond = time available).

    Comment by charliealfred — April 1, 2015 @ 7:27 am | Reply

  4. Thanks. Totally agree. I find it depressing, however, that it (still) needs to be said. If you don’t understand the architecture of the problem, how can your solution architecture make sense (other than by accident or superior intuition)? The architecture of the problem, as you say, consists of multiple elements of which I suggest the requirements, as typically expressed, are the least useful. They may give me an idea how the customer wants the problem solved but not what the problem actually is.

    Comment by Stuart Boardman (@ArtBourbon) — June 5, 2015 @ 10:39 am | Reply

  5. Thanks for the comment Stuart. I think that people can be grouped in 4 quadrants. Columns are :”inclined to serve others” vs. “inclined to pursue self interest”. Rows are “thinks and acts independently” vs. “follows the direction of leaders”. The depressing part is that most corporate boards and executives are about maximizing corporate profits and their own incentives align them with these goals, while the inclination to serve others takes a back seat. I don’t think there are enough “serve others” and “thinks independently” types in the ranks to stem the tide. Until this balance changes, the architecture of the problem will be the vision of the few.

    Comment by charliealfred — June 5, 2015 @ 11:13 am | Reply

  6. […] it should be a taken as a given that this architecture of the solution must also align with the architecture of the problem as a minimum condition to be considered fit for […]

    Pingback by Can you afford microservices? | Form Follows Function — November 30, 2015 @ 12:22 pm | 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:

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

Blog at WordPress.com.

%d bloggers like this: