Scott Whitmire - Just What is Architecture Anyway

Scott Whitmire

CITA-P, Iasa Fellow

Enterprise Architect, Nordstrom, Inc.

JUST WHAT IS “ARCHITECTURE,” ANYWAY?

COPYRIGHT © 2012 BY SCOTT A. WHITMIRE. 1

WHY ARE WE STILL ASKING THIS QUESTION?


• The Agile Manifesto (www.agilemanifesto.org) says this:

• The best architectures, requirements, and designs emerge

from self-organizing teams

• This implies that:

• An architecture is fluid, that it evolves over time

• The development team has considerable choice in the

matter

• Any up-front architectural work is bad and should be avoided

• None of this is true

http://www.agilemanifesto.org

WHAT IS ARCHITECTURE?


• Rosanski and Woods:

• The architecture of a system is the set of fundamental

concepts or properties of the system in its environment,

embodied in its elements, relationships, and the principles of

its design and evolution.

Rozanski, N., & Woods, E. (2011). Software Systems Architecture, 2ed. Upper Saddle River, NJ, USA: Addison-Wesley.



• Software Engineering Institute:

• The software architecture of a program or computing system

is the structure or structures of the system, which comprise

software elements, the externally visible properties of those

elements, and the relationships among them.

Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice, 2ed. Upper Saddle River, NJ, USA:

Addison-Wesley.



• IEEE/ISO (ISO/ICE 42010:2011):

• The fundamental organization of a system embodied in its

components, their relationships to each other, and to the

environment, and the principles guiding its design and

evolution

IEEE. (2000). IEEE Std 1471-2000. Piscataway, NJ, USA: IEEE.



• Roy Fielding:

• (Dynamic) A software architecture is an abstraction of the

run-time elements of a software system during some phase

of its operation. A system may be composed of many levels

of abstraction and many phases of operation, each with its

own software architecture.

• (Static) A software architecture is defined by a configuration

of architectural elements – components, connectors, and

data – constrained in their relationships in order to achieve a

desired set of architectural properties.

Fielding, R. (2000). Architectural Styles and the Design of Network-based Software Architectures (Dissertation).

University of California, Irvine, Information and Computer Science. Irvine: University of California, Irvine.

NOTICE THE PATTERN? WE DID


• Iasa Software Architecture:

• A software architecture describes the dominant structure

formed by the software components of a system and their

elements, their functional and non-functional properties, and

the connections between them.

IASA Board of Education. (2008). Software Architecture Course Curriculum. IASA Board of Education. Austin: IASA.

WHERE DOES ARCHITECTURE ORIGINATE?


• The short answer:

• The problem domain

• In most cases related to systems, the architecture is there to be

discovered, not created

• Architects face constrained choices, not a clean slate

• The practice of architecture is mostly about navigating

constraints

CONSIDER BRIDGE DESIGN


• Type of bridge is largely determined by

• Length of central span

• Condition of anchor points

• Condition of bottom

• Customer’s budget

• As central span gets longer, architecture options get more constrained

• For spans of 1000’ or more, there are only two options

• Anchor points determine which of these two you can use

WHAT DOES THAT MEAN FOR SOFTWARE?

• Wikipedia’s entry on non-functional requirements

includes this:

• The plan for implementing functional requirements is

detailed in the system design.

• The plan for implementing non-functional

requirements is detailed in the system architecture.

• Architecture is mainly about non-functional

requirements


SO, WHAT DOES THAT MEAN?


• Architecture of a software system is driven by context and non-

functional requirements

• The problem being solved has far more influence than the

architect

• You don’t need to know much about functional requirements to

define an architecture

• Architecture does not “evolve” in the sense that a design can

WHAT DO WE NEED TO KNOW?


• Context is the environment that surrounds the system

• The type of problem being solved

• Business application vs. functional vs. real-time process control

• User community size and distribution

• Data creation and consumption patterns

• Scale and scalability

• Availability

• Performance

• Security

• Variability and volatility

PROBLEM TYPE


• Data-strong – Typical business application

• Models data about things

• Example: Customer Relationship Management

• Function-strong – Typical mathematical or scientific application

• Models behavior of things

• Example: Weather model

• Control-strong – Typical real-time control system

• Interacts with real world to do real work

• Example: Brewery control system

USER COMMUNITY


• How many users are there?

• How many time zones do they cover?

• For a global application, including most web apps, it is always

first shift

• Large user communities require different approaches than small

communities

• Geographically dispersed user communities require different

approaches than co-located communities

DATA CREATION AND CONSUMPTION


• Data is always created locally

• How is it consumed?

• Shared globally – eg: Web-based eCommerce site

• Used locally – eg: Distributed warehouse management

• Local data usage lends itself to partitioned or distributed databases

• Global data requires central database (or the appearance of)

• Large user community + central database = big problem (one that we

still haven’t solved completely)

• Facebook and Twitter are hybrids

SCALE AND SCALABILITY


• Scale is the typical size

• 10k transactions per day vs. 100M transactions per day

• Scalability is the requirement for scale to change

• Adapt to changing loads – up or down

• Large scale requires different approaches than small scale

• Large changes in scale require interesting operations

techniques (but are easily solved)

AVAILABILITY


• Measured as up-time

• Classes of “nines”

• 3 nines (99.9%)

• 4 nines (99.99%)

• 5 nines (99.999%) => ~5 minutes of downtime per year

• Each additional 9 is about 10x in cost

• Going from 4 nines to 5 nines requires architectural changes

• Infrastructure – high-availability components and geographic redundancy

• Application – active-active instances and components – and databases

PERFORMANCE


• Four “real” performance classes

• Eye-blink – it happens immediately

• Delay – long enough to be annoying, too quick to do something else

• Wait – long enough to do something else and come back

• Overnight – anything longer than wait

• Are there hard limits imposed by the problem?

• Latency accumulates as you add layers and decoupling

• High-performance across layers requires architecture work

SECURITY


• Security is inherent in the architecture (or not)

• Threat model must be considered early

• An story: A medical monitoring application

VARIABILITY AND VOLATILITY


• What can change and how often?

• Isolate volatile components from others and from each other

• Loose coupling is the goal, there are many techniques

LET’S LOOK AT AN EXAMPLE


• Operating models are problem domain patterns

• Two (unified and coordinated) require customer and product

data to be shared across business units and processes

• Most companies are one of these two patterns

• It took the introduction of Master Data Management to finally(!)

consolidate our view of customer and product data

LOOK FAMILIAR?


IS THIS A DIFFERENT PATTERN?


STILL LOOK FAMILIAR?


HERE’S ANOTHER VIEW


THE PICTURES ARE ALL THE SAME


• The dominant structure is shared data

• We call it the Blackboard1 pattern

• Layers is a structural pattern to show separation of concerns

• N-Tier is a deployment pattern

• Maybe 90% of business applications are Blackboard – if you dig

deep enough

1Buschmann, F., Munier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Pattern-Oriented Software Architecture

Volume 1: A System of Patterns (Vol. 1). New York, NY, USA: John Wiley & Sons.

OTHER PATTERNS


• Pipes-and-Filters

• Video games

• Mathematical and scientific applications

• Microkernel

• Real-time control systems, including embedded systems

• There are others, but these are most common

PIPES-AND-FILTERS – IMAGE PROCESSING


Noise Filtering

Edge Detection

Movement Detection

MICROKERNEL – DEVICE CONTROL


Controller

Analog Sensor

Automatic Valve

Event Processing

Engine Machine(s)

Digital Sensor

WHY DOES IT MATTER?


• Most system failures are caused by a mismatch between the

dominate pattern in the problem domain and the dominant

pattern in the solution

• At the very least, use, operation, and maintenance is painful

• Some examples:

• Customer credit account

• Database keys

• Inventory balance

CONCLUSION


• Architecture (as a verb) is about matching the solution pattern to the pattern of your problem – the problem drives the solution

• Architecture (as a noun) is that pattern

• The art is recognizing the problem’s pattern in the first place

• The science is applying knowledge and experience to create a matching solution

• The problem’s pattern isn’t likely to evolve, and the team doesn’t get to decide

• We have lots of tools

• Past practice

• Patterns

• Abstraction

• Encapsulation


Thank you!

ARCHITECTURE ≠ DESIGN

Technology

Scott Whitmire - Just What is Architecture Anyway