Reconciling Systems, Software, and
other Architectures
Mark W. Maier, Ph.D.
Distinguished Engineer
The Aerospace Corporation
THE AEROSPACE
C O R P O R AT I O N
© 2008 The Aerospace Corporation,
Page 1 6/27/2016
Topics To Consider

Reconciliation of what?
» Of “Architectures” (treated as decisions)?
» Of “Architecture Descriptions?”
» Of programs and processes?

A discussion of the need to “reconcile system and software
architectures” may be something of a cover for a variety of
problems
» A desire for common notations and tools (whether needed or not)
» Poor compatibility between basic architectural decisions about the
software with basic architectural decisions about the hardware within the
system being developed
» Poor compatibility between basic architectural decisions about the program
with basic architectural decisions about the system being developed
» Inefficient ordering of information developed in software-centric systems

We’ll consider the major cases in turn
THE AEROSPACE
C O R P O R AT I O N
Page 2 6/27/2016
Architecture and Program Sequence



Take softwarecentric or intensive
as meaning 70-80%
of development is
spent on software
development
Then, architecting of
software will/must
start early, before
systems engineering
is complete, and will
be very enduring
Needs at system
level induced by
software architecture
should have priority
THE AEROSPACE
C O R P O R AT I O N
Needs, Scoping
System Structuring
Sys. Architecture
and its Iteration
System Architecting
Requirements Development
System Engineering
Software Architecture Development
Page 3 6/27/2016
Top Down vs Bottom Up Architecting

Stakeholders
» Stakeholder Concerns
» System level use-cases and objectives
Objectives-driven
Function-centric
Value-based invariants
Many areas likely to gap
Typically poor attention to HW/SW drivers
Mismatched SE and SW-Architecture order

Software architecture
Design-needs-driven
Object-centric
Design-based invariants
» Identification of the logical structure of the software
» Concurrency and synchronization requirements, induced by software
boundary
THE AEROSPACE
C O R P O R AT I O N
Page 4 6/27/2016
Program and System


Systems engineering classically
looks in physically oriented
hierarchies
Software is now more typically
structured in layers
» At least in modern, complex
systems


THE AEROSPACE
C O R P O R AT I O N
What happens when the WBS is
written to follow the systems
hierarchy, not the software
layers?
Classic example of mismatch of
the structure of the program (via
the system) with the structure of
the software to be developed by
the program
Page 5 6/27/2016
Which are the Subsystems?
Home PC
Home PC
Home PC
Modem
Home PC
Modem
Modem
Modem
Superserver
Superserver
Web Client
Internet
Web Client
Web Server
Data
base
Internet
Web Server
Data
base
Data
base
Data
base
Store Workstation
Store Workstation
Platform
Unique
Shared
Interface Backbone
Functions Layer
THE AEROSPACE
C O R P O R AT I O N
Page 6 6/27/2016
The Four Way Tension
Organization
Who’s doing what?
One or several?
What are they good/bad at?
What is their “strategic identity?”
System
Problem
What are we building?
What are the key tech decisions?
What are the components?
How is it tested?
What are we doing?
What delivers value?
What is the environment?
What is success?
Program
How do we build/operate?
Separation of responsibilities
THE AEROSPACE
C O R P O R AT I O N
Page 7 6/27/2016
A Little Exercise Question

What aspects of the problem domain lead you to make a
decision in favor of incremental development?
» What aspects of the problem domain lead you to make a decision to avoid
any sort of incremental development?

Given that you want an incremental development
architecture for the program…
» How does it (should it) change the architecture of the system? What
system architectures are “consistent” with incremental development, and
which ones are not?
» How does it change design decisions in supporting areas (e.g. testing,
verification, validation)?
» How does it effect the organization that carries out development and the
supported missions?
THE AEROSPACE
C O R P O R AT I O N
Page 8 6/27/2016
Notations and Methods


Lack of attention to notations and methods may be the
problem
Or, too much attention to notations and methods may be the
problem
» Can’t fix bad decisions by changing the description framework




And…it can also be part of a solution
The “right” notation can directly incorporate the bottom-up
concerns of software developers
The right notation composition rules can support explicit
layering, and parallel subsystem decomposition
The right descriptions can highlight issues between the
system and program
THE AEROSPACE
C O R P O R AT I O N
Page 9 6/27/2016
Some Pieces to Use
Example of Proposed Interface
Logic Modifications
H/P Style AFD
Image
Image
Processor
Sensor A
Collect_
Command
Track_
File
Luminance
Scan_
Mode
Display
Track_
Screen
Processor
Sensor A
Collect_
Command
Track_
File
Luminance
Scan_
Mode
Display
Track_
Screen
Layer 4
Hard-coupled Push
Inter-layer
Interfaces
Layer 3
Hard-coupled Pull
Layer 2
Soft-coupled Push
Layer 1
Layer 1
Soft-coupled Pull
Blocking Push
Blocking Pull
THE AEROSPACE
C O R P O R AT I O N
Queued Transfer
Page 10 6/27/2016
Conclusions



Bringing architecture (and architecture description)
together among systems and software is important stuff
But…the systems/software divide is only part of the story
Consider from the position of fundamentals
» Things (software, systems, programs) have architectures. Those
architectures are formed from the basic structural decisions.
» Compatibility means (largely) consistent, coherent decisions between and
among those levels
– Between hardware and software
– Between problem and system-solution
– Between system, program, and organization
» Compatibility of “architecture descriptions,” (models and documents) also
is an issue
» Good choices in tools and methods can help with compatibility, but isn’t a
panacea
THE AEROSPACE
C O R P O R AT I O N
Page 11 6/27/2016