Characterizing and Managing System Architectures

1

• Characterizing and Managing System Architectures
• Rick Steiner
• Raytheon Systems Company
• Naval and Maritime Systems
• San Diego, California
• fsteiner_at_west.raytheon.com

2
Confusion About the Term Architecture

• Dont bother distinguishing design from
  architecture its pointless!
• All concepts eventually need to be defined to the
  point where they can be implemented
• Why is System Architecture such a contentious
  term? Conflicting views and a spectrum of
  abstraction
• Highly precidented systems Architecture which
  version to use
• Software systems Architecture layers of
  support systems/services
• Network systems Architecture servers/routers,
  protocols, topology
• System integrator Architecture interface
  specifications/standards
• User Architecture user interface, scenarios,
  function, acceptance method
• Unprecidented systems Architecture development
  approach, guidelines, process contstraints,
  validation concept
• Complex systems Architecture strategy for
  segregation of subsystems
• Christopher Alexander Architecture a timeless
  way of building

3
What does an Architecture DO?

• Applies structure or framework to technical
  endeavor
• Aid technical decision management
• provide a mechanism for cohesion
• vehicle to focus the customer, user, and builder
  on what is important
• information hiding (dont sweat the small stuff)
• translation between operational, technical, and
  production domains
• Characterizing Architectures - orthogonal
  approaches
• Hierarchies
• level of Abstraction (indenture supersystem,
  system, subsystem)
• level of detail (confidence, design rationale)
• detail increases as design develops not a good
  way to characterize architecture
• View Form vs. Function, etc. (domain specific,
  can be generalized)
• Permanence Enduring vs. Transitory (temporal
  aspect of architecture deployment)

4
Approach to an Integrated Architecture Model
Ideally, this entire space should be filled by
the system architecture concept A Solid Cube!
We need a way to identify things that are
inconsistent or missing!
5
Abstraction Axis

• Continuum from Abstract to Concrete
• Abstract - design guidelines, integration
  principles, vision of product
• concept level, understandable by user or customer
• Concrete - implementable design
• buildable by domain specialist
• Abstraction across views
• layers of consistent form function
• Abstraction across permanence
• discrete points for identifying reuse

6
View Axis

• Two relevant aspects Structure (form) and
  Behavior (function).
• Many other views, most are sub-setsof these two
  (Wright ADL, Oliver)
• Behavior states, modes, functions, information
  models, input/output relationships, transfer
  functions, software performance models
• use cases and interaction diagrams are only
  partial descriptions of behavior
• integration of these threads yields system
  behavior, and engineering is required to do that
• Structure components, interfaces, pinouts,
  voltages, software modules, hardware software
  configuration items
• software is buildable, hence it is structure.
  It must be tested to behavioral requirements.
• Consistency of form function architectures at a
  given level of abstraction and/or detail

7
Abstraction - View Plane

• Traditional SE approach starts abstract and
  ends concrete, BUT
• Need to deal with multiple levels of abstraction
  simultaneously
• Need to control rigidity of design, which
  changes over time within each abstraction level
• B S balance at each progressive level of
  abstraction
• Completion and Consistency criteria at each
  technical milestone
• Clear statement of design objectives to
  engineering team leaders during each phase of
  development

8
Permanence Axis

• Continuum from Enduring to Transitory
• Used to explore lifecycle design, potential
  changes in stakeholder roles, technology
  insertion, COTS dependencies
• Used to establish Anchor points of system
  architecture
• human system interface, logistics, support chain,
  safety, reliability
• conscious identification of enduring aspects of
  architecture
• consistent with business strategy, core
  competence
• establish tech insertion, reuse goals
• minimize COTS risk on long-life programs
• proprietary data and interfaces
• unplanned upgrades
• identify aspects of architecture that are throw
  away
• Enduring aspects at multiple levels
• reuse of top level concepts (manage demands on
  subsystems)
• reuse of subsystems (design for flexibility)
• reuse of standards, protocols

9
Abstraction - Permanence Examples
Strategy for legacy system integration
Interface management principles
Pragmatic design/ integration details
Protocols, data exchange standards
10
View - Permanence Examples
legacy components
key interfaces
legacy protocols
partitioning of core processing
11
Management of Enduring Architectures Some
Thoughts

• Enduring architectures have strategic
  significance
• Focus core business competence on enduring
  architectures
• minimize internal on transitory aspects do just
  enough to meet immediate needs, or subcontract to
  someone else
• dont allow transient aspects to subsume your
  entire business!
• factor in how transitory aspects change
• set rollout dates, focus on transition plans
• be flexible when considering enduring aspects,
  but dont be driven by short term concerns
• Standards arent always enduring, but they have
  their place
• see beyond the immediate standard to the long
  term need
• dont rely solely on a standard to solve an
  evolvability or technology insertion problem!
• identify evolutionary technology needs, then look
  at standards
• COTS systems are transitory
• enduring COTS architectures belong to the vendor,
  not the integrator

12
What Next?

• Rules for consistency checking across the
  integrated architecture model how do we know
  when something is missing?
• Capture of real architectures using the
  integrated model concept
• how to deal with permanence axis in architecting
  tools?
• Have not adequately distinguished product system
  from producing system
• product - producing system relationships need
  special attention, especially along permanence
  axis

13
Backup
14
Who Needs an Enduring Architecture?
15
Examples of Classification of Architecture
Elements
16
Architecture Endurance Across Multiple Systems

• Maturation vs. Evolution (distinguished as in
  biology)
• long life, complex, integrated systems tend to
  mature over time (single system lifetime)
• weapon systems, traffic control systems, public
  infrastructure/utilities
• shorter life, self-contained systems tend to
  evolve (generation to generation)
• computer systems, consumer electronics,
  automotive
• Growth Architecture -gt system maturation
• P3I, tech insertion
• Evolutionary Architecture -gt system evolution
• core competencies, open interfaces, standards

17
Form, Function Evolutionary Architectures