Why Great Architectures Fail and Adequate

Architectures Succeed
Dr. Paul Montgomery
Associate Professor of Systems Engineering
Naval Postgraduate School

Presented to INCOSE (WMA)

13 April 2010
© Paul Montgomery 1
 Developing and Transitioning Architectures
Outline of our discussion tonight

•  What is an ‘architecture’ to an SE?

•  How do SE’s develop architectures?
•  Are they built?
•  Do they evolve?
•  How to they guide engineering efforts?
•  If there are proven SE processes to develop
architectures, why do so many fail?
•  What makes architectures “succeed”?

2
 A Case Study in Success
Outline of our discussion tonight

•  What makes architectures “succeed”?

•  Great design?
•  What are the “other” factors of architecture
development success and failure?
•  Pushers
•  Pullers
•  Enablers
•  Inhibitors
•  This is “a” story, not a universal prescription
•  Derived from a 12 year journey in large DoD
systems acquisition organization
3
Definitions and Context

4
 Definitions
INCOSE

•  Architecture = system elements, their

characteristics, and their arrangement that meet the
following criteria:
•  Satisfies the requirements (including external
interfaces)
•  Implements the required functions
•  Is acceptably close to the true optimum within
the constraints of time, budget, available
knowledge and skills, and other resources
•  Is consistent with the technical maturity and
acceptable risks of available elements

5
What is an “Enterprise” Architecture?
Mission and Organizational Focus

6
Are All Architectures the Same?
DODAF Perspectives

7
Needs + Art + Process + Reality

8
 Architectures are a Framework for Common
Understanding and Communications
•  An Architecture guides…it does not get built

•  Architecture failure = the architecture does not guide

the development of systems, improve the mission, nor
impact the organization

9
Developing Solution Architectures
Dennis Buede

10
Architecture Process Flow
INCOSE

11
Understand the Customers’ Problems and Needs

12
 A Case Study
Background

•  Where was the customer in mid-1990s?

•  “Stovepipe” systems were not readily adapting to
rapidly changing mission
•  Developments were overlapping and uncoordinated
•  Technology was moving far faster than the mission
system could ingest and exploit
•  Even more $$ could not move the enterprise fast
enough

13
 Natural Flow of Systems Development
Customer/Mission Needs Are Drivers

Capabilities Architecture Alignments Organization

Need 1

Customer
Business
Unit 1

A
BU 1 BU 2 BU 3
Need 2

Customer
Business Mission
Need 3 Mission C

Customer B
Unit 2 A
Mission
Business B

C
Need 4 Unit 3

Diverse customer needs often

lead to “balkanization’ of
architectures, technology, and
organizations • Technologies
• Capabilities
• Missions 14
• Customers
Desired Architecture Transition
Architecture Evolution
Stovepipes
Balkans
Isolation
Stagnation
Non-Agile

?
Organization

Business/Mission Focused Architecture Alignments

Customer A Product Product Product

Line A Line B Line n

Customer B

Customer C

Technologies & 15
Capabilities
The Transition to Enterprise Architectures
Not an uncommon problem

Where the customer was……………….Where they needed to be

16
The Goal Reference Architecture for most of IT
Most DoD mission systems are IT systems
•  Define a common data model and information standard
•  Component-to-network interfaces, not component-to-component
•  Component interfaces are coordinated and authenticated
•  Expose information and post for any authorized subscriber to access
•  Producers of information don’t have to be aware of consumers

Component Component Component Component

Attributes Attributes Attributes Attributes

Services Services Services Services

Data-Oriented API (Publish/Subscribe Model)

Information Architecture

Transport Services
17
Did This Great Architecture Succeed?
Not when first proposed
•  Too many new concepts
•  “Plug-n-Play”
•  Publish – Subscribe
•  Service - oriented
•  Network-enabled (LAN, WAN, SAN, etc)
•  Data/Information-centric
•  Hardware-agnostic

•  Too many technologies appeared too high risk

•  Processing power/size
•  Storage cost
•  Communications bandwidth
•  User interface designs/graphics

•  Too many disruptions to the organizations

•  Development organizations saw too much risk 18
•  Operational organizations saw too much “hype”
Realities of Change
Evolution is key

Engineering
•  Engineers incline to
elegance and often “go for
the long ball” in their
designs
•  Enterprise architectures
are strategically aligned to
mission / business
objectives and operations
Organization
•  Organizations resist
change
•  Organization structures
are often tactically
aligned to customers and
technology

Systems architects must include customers and total

organization buy-in to establish architectural change. Big
change wont work…elegance is often a non-starter…
understandable, incremental, and achievable change is
more likely the key to success…
…So what was our journey to develop a great architecture? 19
Technology and Community Risk Taking
Phase I

20
 Technology as an Enabler
Govt – Contractor Risk Taking

•  Breaking down system ‘silos’ depended upon:

•  Software-based mission processing vice hardware
•  Commoditizing hardware
•  Organization became the LSI
•  Software standard development environment was
mandated
•  Hardware standards established

•  Risks – Govt leadership required very strong personalities

with exceptional experience in all areas
•  Although many other changes were tried, two changes
(HW/SW) were all the community could accept at one time
21
Hardware / Software Standards
Architecture starts breaking down silos

• Capabilities developed in same SW environment

• Common hardware infrastructure emerges
• Mission capabilities start to become shared applications

• Puller – Mission and ops customers

• Pusher – Dynamic Govt leaders
• Enablers – High performance commodity hardware
• Inhibitors - Infrastructure
22
Community Buy-In
Phase II

23
 Business Model as an Enabler
“Open” architecture emerges

•  New business model required to support standards in

software and hardware (first stage of “open”
architecture)
•  Govt in “prime contractor” role
•  Contractors buy in to open and shared capabilities
model (i.e., non-proprietary / community)
•  Collaboration tools and environment needed
•  Mission customers provided more rapid development
and deployment of capabilities
•  Risks
•  Development model deploys less mature
capabilities very rapidly
•  Over-promising capability 24
Shared Software Applications
Mission architecture aligning to system architecture

• Common SW environment and application ‘pool’

• Mission applications starting to share key capabilities
• Architecture starting to “open” (i.e., “plug & play”)
• Customers starting to accept rapid deployment model
• Puller – Mission and ops customers
• Pusher – Contractor community
• Enablers – Rapidly growing SW application base / collaboration tools
• Inhibitors – Contractor community 25
The First “Enterprise”
Phase III

26
 Enterprise-Level Architecture Increases Co-
Operations
•  Adoption of industry practices (service-orientation
emerges)
•  Companion services (common to multiple missions)
become interoperable
•  Other organizations invited into the architecture
•  Common operating systems and environments

27
Enterprise Architecture
“Modern” IT Architecture is Achieved

• Puller – Fiscal pressures

• Pusher – Interest from other organizations
• Enablers – Enterprise-level OS, server-class technologies
• Inhibitors – Organizational independence, SE interactions 28
Enabling Re-Missioning
Phase IV

29
 Enterprise Architecture Achieving Collaboration
Minimizing Impacts of Change

•  Common mission practices

•  Higher degrees of interaction and collaboration
•  User experience consistency
•  Mission application differences now isolated to a few
SW applications and practices (vice HW/SW/
infrastructure/practices)

30
Enterprise Architecture Stabilized Mission
Performance

31
Organization Adaptation to the Enterprise
Architecture
Phase V – The “Final Frontier”

32
 Organization Decouples from Architecture

•  Organization free to decouple itself from

architecture technologies
•  Enterprise architecture serves the organization
(not vice-versa)
•  Diversely-focused organizational constructs possible
•  Inter-organization/agency risks are decoupled and
easily identified

33
Organization Adaptation
Many Organizations Possible with “Service” Architecture
Engineering
Organization

Mission
Organizations

• Puller – Ops environment

• Pusher – $$ environment
• Enablers – Director-level leadership
• Inhibitors – Training and cross-learning 34
Summary
Transitioning a Complex Systems Architecture

35
 Great Architectures Need More than Great
Design to Succeed
•  SEs must remain aware of non-engineering factors in
architecture design development
•  Pullers – Customers, mission objectives, operations
•  Pushers – Leadership
•  Enablers – Technology, business practices
•  Inhibitors – Resistance to change, business objectives,

SE Design Processes Pushers Enterprise Architecture

Pullers

Σ
Enablers
Inhibitors 36
Architecture Development is Multi-Step Process
SE Architecture Design Process Alone is not Enough
As - Is Transformation To - Be

BU 1 BU 2 BU 3

37
“ Successful architecture development is as
much about the roadmap as it is about the
design.”
Dr. Paul Montgomery

38
 References

•  Buede, Dennis; The Engineering Design of Systems –

Models and Methods, Wiley, 2000

•  Systems Engineering Handbook - A Guide For System Life

Cycle Processes And Activities, Version 3.2, INCOSE, Jan
2010

39