analysis, either on the spot or from a short analysis after the fact.

The design won’t be

elaborate because the exercise is timeboxed. Team members ideally get feedback from
the experienced architecture about missed trade-offs and alternative designs.

Case Study: Silicon Sandwiches

To illustrate several concepts, we use an architecture kata (see “The Origin of Archi‐
tecture Katas” on page 68 for the origin of the concept). To show how architects
derive architecture characteristics from requirements, we introduce the Silicon Sand‐
wiches kata.
Description
A national sandwich shop wants to enable online ordering (in addition to its cur‐
rent call-in service).
Users
Thousands, perhaps one day millions
Requirements
• Users will place their order, then be given a time to pick up their sandwich and
directions to the shop (which must integrate with several external mapping serv‐
ices that include traffic information)
• If the shop offers a delivery service, dispatch the driver with the sandwich to the
user
• Mobile-device accessibility
• Offer national daily promotions/specials
• Offer local daily promotions/specials
• Accept payment online, in person, or upon delivery
Additional context
• Sandwich shops are franchised, each with a different owner
• Parent company has near-future plans to expand overseas
• Corporate goal is to hire inexpensive labor to maximize profit
Given this scenario, how would an architect derive architecture characteristics? Each
part of the requirement might contribute to one or more aspects of architecture (and
many will not). The architect doesn’t design the entire system here—considerable
effort must still go into crafting code to solve the domain statement. Instead, the
architect looks for things that influence or impact the design, particularly structural.
First, separate the candidate architecture characteristics into explicit and implicit
characteristics.

Case Study: Silicon Sandwiches | 69

Explicit Characteristics
Explicit architecture characteristics appear in a requirements specification as part of
the necessary design. For example, a shopping website may aspire to support a partic‐
ular number of concurrent users, which domain analysts specify in the requirements.
An architect should consider each part of the requirements to see if it contributes to
an architecture characteristic. But first, an architect should consider domain-level
predictions about expected metrics, as represented in the Users section of the kata.
One of the first details that should catch an architect’s eye is the number of users: cur‐
rently thousands, perhaps one day millions (this is a very ambitious sandwich shop!).
Thus, scalability—the ability to handle a large number of concurrent users without
serious performance degradation—is one of the top architecture characteristics.
Notice that the problem statement didn’t explicitly ask for scalability, but rather
expressed that requirement as an expected number of users. Architects must often
decode domain language into engineering equivalents.
However, we also probably need elasticity—the ability to handle bursts of requests.
These two characteristics often appear lumped together, but they have different con‐
straints. Scalability looks like the graph shown in Figure 5-1.

Figure 5-1. Scalability measures the performance of concurrent users

Elasticity, on the other hand, measures bursts of traffic, as shown in Figure 5-2.

70 | Chapter 5: Identifying Architectural Characteristics

Figure 5-2. Elastic systems must withstand bursts of users

Some systems are scalable but not elastic. For example, consider a hotel reservation
system. Absent special sales or events, the number of users is probably consistent. In
contrast, consider a concert ticket booking system. As new tickets go on sale, fervent
fans will flood the site, requiring high degrees of elasticity. Often, elastic systems also
need scalability: the ability to handle bursts and high numbers of concurrent users.
The requirement for elasticity did not appear in the Silicon Sandwiches requirements,
yet the architect should identify this as an important consideration. Requirements
sometimes state architecture characteristics outright, but some lurk inside the prob‐
lem domain. Consider a sandwich shop. Is its traffic consistent throughout the day?
Or does it endure bursts of traffic around mealtimes? Almost certainly the latter.
Thus, a good architect should identify this potential architecture characteristic.
An architect should consider each of these business requirements in turn to see if
architecture characteristics exist:

1. Users will place their order, then be given a time to pick up their sandwich and
directions to the shop (which must provide the option to integrate with external
mapping services that include traffic information).
External mapping services imply integration points, which may impact aspects
such as reliability. For example, if a developer builds a system that relies on a
third-party system, yet calling it fails, it impacts the reliability of the calling
system. However, architects must also be wary of over-specifying architecture
characteristics. What if the external traffic service is down? Should the Silicon

Case Study: Silicon Sandwiches | 71

 Sandwiches site fail, or should it just offer slightly less efficiency without traffic
information? Architects should always guard against building unnecessary brit‐
tleness or fragility into designs.
2. If the shop offers a delivery service, dispatch the driver with the sandwich to the
user.
No special architecture characteristics seem necessary to support this
requirement.
3. Mobile-device accessibility.
This requirement will primarily affect the design of the application, pointing
toward building either a portable web application or several native web applica‐
tions. Given the budget constraints and simplicity of the application, an architect
would likely deem it overkill to build multiple applications, so the design points
toward a mobile-optimized web application. Thus, the architect may want to
define some specific performance architecture characteristics for page load time
and other mobile-sensitive characteristics. Notice that the architect shouldn’t act
alone in situations like this, but should instead collaborate with user experience
designers, domain stakeholders, and other interested parties to vet decisions like
this.
4. Offer national daily promotions/specials.
5. Offer local daily promotions/specials.
Both of these requirements specify customizability across both promotions and
specials. Notice that requirement 1 also implies customized traffic information
based on address. Based on all three of these requirements, the architect may
consider customizability as an architecture characteristic. For example, an archi‐
tecture style such as microkernel architecture supports customized behavior
extremely well by defining a plug-in architecture. In this case, the default behav‐
ior appears in the core, and developers write the optional customized parts, based
on location, via plug-ins. However, a traditional design can also accommodate
this requirement via design patterns (such as Template Method). This conun‐
drum is common in architecture and requires architects to constantly weight
trade-offs between competing options. We discuss particular trade-off in more
detail in “Design Versus Architecture and Trade-Offs” on page 74.
6. Accept payment online, in person, or upon delivery.
Online payments imply security, but nothing in this requirement suggests a par‐
ticularly heightened level of security beyond what’s implicit.
7. Sandwich shops are franchised, each with a different owner.
This requirement may impose cost restrictions on the architecture—the architect
should check the feasibility (applying constraints like cost, time, and staff skill
set) to see if a simple or sacrificial architecture is warranted.

72 | Chapter 5: Identifying Architectural Characteristics

 8. Parent company has near-future plans to expand overseas.
This requirement implies internationalization, or i18n. Many design techniques
exist to handle this requirement, which shouldn’t require special structure to
accommodate. This will, however, certainly drive design decisions.
9. Corporate goal is to hire inexpensive labor to maximize profit.
This requirement suggests that usability will be important, but again is more con‐
cerned with design than architecture characteristics.

The third architecture characteristic we derive from the preceding requirements is

performance: no one wants to buy from a sandwich shop that has poor performance,
especially at peak times. However, performance is a nuanced concept—what kind of
performance should the architect design for? We cover the various nuances of perfor‐
mance in Chapter 6.
We also want to define performance numbers in conjunction with scalability num‐
bers. In other words, we must establish a baseline of performance without particular
scale, as well as determine what an acceptable level of performance is given a certain
number of users. Quite often, architecture characteristics interact with one another,
forcing architects to define them in relation to one another.

Implicit Characteristics
Many architecture characteristics aren’t specified in requirements documents, yet
they make up an important aspect of the design. One implicit architecture character‐
istic the system might want to support is availability: making sure users can access the
sandwich site. Closely related to availability is reliability: making sure the site stays up
during interactions—no one wants to purchase from a site that continues dropping
connections, forcing them to log in again.
Security appears as an implicit characteristic in every system: no one wants to create
insecure software. However, it may be prioritized depending on criticality, which
illustrates the interlocking nature of our definition. An architect considers security an
architecture characteristic if it influences some structural aspect of the design and is
critical or important to the application.
For Silicon Sandwiches, an architect might assume that payments should be handled
by a third party. Thus, as long as developers follow general security hygiene (not pass‐
ing credit card numbers as plain text, not storing too much information, and so on),
the architect shouldn’t need any special structural design to accommodate security;
good design in the application will suffice. Each architecture characteristic interacts
with the others, leading to the common pitfall of architects of over-specifying archi‐
tecture characteristics, which is just as damaging as under-specifying them because it
overcomplicates the system design.

Case Study: Silicon Sandwiches | 73

The last major architecture characteristic that Silicon Sandwiches needs to support
encompasses several details from the requirements: customizability. Notice that sev‐
eral parts of the problem domain offer custom behavior: recipes, local sales, and
directions that may be locally overridden. Thus, the architecture should support the
ability to facilitate custom behavior. Normally, this would fall into the design of the
application. However, as our definition specifies, a part of the problem domain that
relies on custom structure to support it moves into the realm of an architecture char‐
acteristic. This design element isn’t critical to the success of the application though. It
is important to note that there are no correct answers in choosing architecture char‐
acteristics, only incorrect ones (or, as Mark notes in one of his well-known quotes):
There are no wrong answers in architecture, only expensive ones.

Design Versus Architecture and Trade-O s

In the Silicon Sandwiches kata, an architect would likely identify customizability as a
part of the system, but the question then becomes: architecture or design? The archi‐
tecture implies some structural component, whereas design resides within the archi‐
tecture. In the customizability case of Silicon Sandwiches, the architect could choose
an architecture style like microkernel and build structural support for customization.
However, if the architect chose another style because of competing concerns, develop‐
ers could implement the customization using the Template Method design pattern,
which allows parent classes to define workflow that can be overridden in child classes.
Which design is better?
Like in all architecture, it depends on a number of factors. First, are there good rea‐
sons, such as performance and coupling, not to implement a microkernel architec‐
ture? Second, are other desirable architecture characteristics more difficult in one
design versus the other? Third, how much would it cost to support all the architecture
characteristics in each design versus pattern? This type of architectural trade-off anal‐
ysis makes up an important part of an architect’s role.
Above all, it is critical for the architect to collaborate with the developers, project
manager, operations team, and other co-constructors of the software system. No
architecture decision should be made isolated from the implementation team (which
leads to the dreaded Ivory Tower Architect anti-pattern). In the case of Silicon Sand‐
wiches, the architect, tech lead, developers, and domain analysts should collaborate to
decide how best to implement customizability.

An architect could design an architecture that doesn’t accommodate customizability

structurally, requiring the design of the application itself to support that behavior (see
“Design Versus Architecture and Trade-Offs” on page 74). Architects shouldn’t stress
too much about discovering the exactly correct set of architecture characteristics—
developers can implement functionality in a variety of ways. However, correctly iden‐

74 | Chapter 5: Identifying Architectural Characteristics

tifying important structural elements may facilitate a simpler or more elegant design.
Architects must remember: there is no best design in architecture, only a least worst
collection of trade-offs.
Architects must also prioritize these architecture characteristics toward trying to find
the simplest required sets. A useful exercise once the team has made a first pass at
identifying the architecture characteristics is to try to determine the least important
one—if you must eliminate one, which would it be? Generally, architects are more
likely to cull the explicit architecture characteristics, as many of the implicit ones sup‐
port general success. The way we define what’s critical or important to success assists
architects in determining if the application truly requires each architecture character‐
istic. By attempting to determine the least applicable one, architects can help deter‐
mine critical necessity. In the case of Silicon Sandwiches, which architecture
characteristic that we have identified is least important? Again, no absolute correct
answer exists. However, in this case, the solution could lose either customizability or
performance. We could eliminate customizability as an architecture characteristic
and plan to implement that behavior as part of application design. Of the operational
architecture characteristics, performance is likely the least critical for success. Of
course, the developers don’t mean to build an application that has terrible perfor‐
mance, but rather one that doesn’t prioritize performance over other characteristics,
such as scalability or availability.

Case Study: Silicon Sandwiches | 75