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

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

Scott Whitmire - Just What is Architecture Anyway

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Scott Whitmire - Just What is Architecture Anyway

Similaire à Scott Whitmire - Just What is Architecture Anyway (20)

Plus de iasaglobal

Plus de iasaglobal (20)

Dernier

Dernier (20)

Scott Whitmire - Just What is Architecture Anyway