MFESA – The Method-Framework for Engineering System Architectures MFESA-Compliant Architecture Engineering Method
MFESA Method Components
MFESA Metamethod
Donald Firesmith ½ Day Tutorial at the IEEE International System Conference In Montreal, Quebec, Canada 4 April 2011
MFESA Repository
MFESA Metamodel
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
1
Tutorial Objectives Introduce you to the Method Framework for Engineering System Architectures (MFESA): • MFESA Ontology of reusable concepts and terminology
• MFESA Metamodel of reusable method components • MFESA Repository of reusable method components: —
MFESA Architectural Work Units and Work Products
—
MFESA Architectural Workers
• MFESA Metamethod for generating appropriate project-specific
system architecture engineering methods
Help you determine whether Situational Method Engineering (SME) and MFESA are right for you. The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
2
MFESA Project Started January 2007 Collaborators: • SEI Acquisition Support Program (ASP) –
Don Firesmith (Team Lead), Peter Capell, Bud Hammons, and Tom Merendino • MITRE – Dietrich Falkenthal (Bedford MA) • USAF – DeWitt Latimer (USC)
Current work products: • Reference Book (November 2008) • Tutorials and Training Materials • Articles
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
3
Intended Tutorial Attendees System and Subsystem Architects Process Engineers Requirements Engineers
Technical and Administrative Managers Acquirers Developers Testers Trainers and Educators Standards Developers Academic Researchers
Any other Stakeholders The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
4
Topics Motivation MFESA Overview MFESA Ontology of Concepts and Terminology MFESA Metamodel of Reusable Method Components MFESA Repository of Reusable Method Components • Architectural Work Units and Work Products
• Architectural Workers
MFESA Metamethod Conclusion
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
5
System Architecture – Traditional Definition System Architecture the organization of a system including its major components, the relationships between them, how they collaborate to meet system requirements, and principles guiding their design and evolution
Note that this definition is primarily oriented about the system‟s structure. Yet systems have many static and dynamic logical and physical structures. The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
6
System Architecture – MFESA Definition System Architecture all of the most important, pervasive, top-level, strategic decisions, inventions, engineering tradeoffs, assumptions, and their associated rationales concerning how the system will meet its derived and allocated requirements Includes: •
All major logical and physical and static and dynamic structures
•
Other architectural decisions, inventions, tradeoffs, assumptions, and rationales: —
Approach to meet quality requirements
—
Approach to meet data and interface requirements
—
Architectural styles, patterns, mechanisms
—
Approach to reuse (build/buy decisions)
•
Strategic and pervasive design-level decisions
•
Strategic and pervasive implementation-level decisions
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
7
Architecture vs. Design
Architecture
Design
Pervasive (Multiple Components) Strategic Decisions and Inventions Higher-Levels of System Huge Impact on Quality, Cost, & Schedule Drives Design and Integration Testing Driven by Requirements and Higher-Level Architecture Mirrors Top-Level Development Team Organization (Conway‟s Law)
Local (Single Components) Tactical Decisions and Inventions Lower-Levels of System Small Impact on Quality, Cost, & Schedule Drives Implementation and Unit Testing Driven by Requirements, Architecture, and Higher-Level Design No Impact on Top-Level Development Team Organization
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
8
System Architecture Engineering System Architecture Engineering the subdiscipline of systems engineering consisting of all architectural work units performed by architectural workers (architects, architecture teams, and their tools) to develop and maintain architectural work products (including system or subsystem architectures and their representations)
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
9
System Architecture is Critical Supports achievement of critical architecturally significant requirements Enables engineering of system quality characteristics and attributes
Drives all logically-downstream activities (design, implementation, integration, deployment, …) Greatly affects cost, schedule, and risk
Greatly affects system acceptability and success
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
10
System Architecture Engineering is critical to Project Success
Joe Elm, Dennis R. Goldenson, Khaled El Emam, Nicole Donatelli, and Angelica Neisa, A Survey of Systems Engineering Effectiveness – Initial Results, CMU/SEI-2007-SR-014, Software Engineering Institute, November 2007, p. 222. The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
11
Limitations of Current Methods and Standards Do not adequately address: • The increasing size and complexity of many current systems • All types of architectural components (especially software)
• All types of interfaces (interoperability and intraoperability) • All potentially important system structures, views, models, and
other architectural representations • All life cycle phases (production, evolution, and maintenance
of architectural integrity) • System quality characteristics, attributes, and requirements • Reuse and Component-Based Development (CBD)
• Specialty engineering areas (such as safety and security) The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
12
More Limitations of Current Methods and Standards2 Current methods: • Overemphasize two structures: — Static logical functional decomposition view — Static physical aggregation decomposition view • Are weak on structure, view, and model consistency. • Confuse requirements engineering with architecture engineering. • Tend to assume that One Size Fits All. • Produce only a single architectural vision. • Excessively emphasize architectural models over other architectural representations. The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
13
Architecture Engineering Challenges1 Poor architecturally significant requirements: missing, incompatible, and poorly engineered (analyzed, specified, managed). How good is „Good enough‟? We lack sufficient adequately trained and experienced architects. • Many young architects must perform tasks for which they are under
qualified. • Field promotions
Architects may use multiple inconsistent architecture engineering methods. Architecture engineering methods are often incomplete or incompletely documented: different backgrounds, organizations, and training. Architects can rely too much on architectural engineering tools. The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
14
Architecture Engineering Challenges2 Different stakeholders have different and possibly conflicting needs for different architectural representations at different levels of abstractions: • Requirements Engineers – Ensure architecturally significant (e.g., quality)
requirements are properly engineered • Architects – Capture and convey their architecture to themselves, other
architects, and other stakeholders • Designer and Implementers – Constrain designs and implementations
• Specialty Engineers – ensure architecture supports specialty engineering
requirements and incorporates related patterns/mechanisms. • Testers – Integration tests and whitebox system and component testing • Manufacturers – Producibility of the system given its architecture • Acquirers and Funders – Understand what is being acquired and paid for
• Managers – Manage development and Conway‟s Law • Certifiers, Accreditors, and Regulators – Ensure system will be able to be
safely and securely operated The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
15
Why Method Engineering? – Systems Vary Greatly Autonomy of subsystems: • Individually useful, self-contained, relatively independent • Synergistic symbiosis among collaborating interdependent subsystems
Complexity: • Simple through ultra-complex • Organized simplicity, organized complexity, unorganized complexity
Criticality: • Business, mission, safety, and security • System vs. individual subsystems
Domains (such as energy, finance, telecommunications, transportation, weapons)
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
16
Why Method Engineering? – Systems Vary Greatly2 Driven by: • Requirements (top-down) • Subsystem availability (bottom-up reuse)
Emergent behavior and characteristics: • Required, beneficial, and detrimental • Foreseeable vs. unexpected
Flexibility: • Configurability • Internationalization • Personalization
Geographical distribution of subsystems Homogeneity/heterogeneity of subsystems The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
17
Why Method Engineering? – Systems Vary Greatly3 Intelligence Operational dependence on other systems Reconfigurability (adding, replacing, or removing subsystems)
Relative amounts of data, hardware, software, people, facilities, manual procedures, … Requirements: • Existence, volatility • Functional, data, interface, quality characteristics and attributes, constraints
Self-regulation (proactive vs. reactive, homeostasis) Size (trivially small through ultra-large-scale)
Technologies used (including diversity, maturity, and volatility) The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
18
Why Method Engineering? – Organizations Vary Greatly
Number of organizations Degree of centralized/distributed governance: • Authority, policy, funding, scheduling • Directed, Acknowledged, Collaborative, or Virtual
Types of organizations: • Owner, Acquirer, Developer, Operator, User, Maintainer • Prime contractor / system integrator, subcontractors, vendors, open
source
Size of organizations Management and engineering culture Geographical distribution Staff expertise and experience The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
19
Why Method Engineering? – Endeavors Vary Greatly
Type (project, program of related projects, enterprise) Contracting: • Formality (informal in-house agreement vs. formal contract)
• Type (e.g., fixed-price or cost plus fixed fee)
New (greenfield) development vs. legacy enhancement Lifecycle scope (development, manufacturing, operations, and sustainment) System scope (subsystem, system, “system of systems”) Duration (weeks, months, years, or decades) Schedule (adequacy, criticality, coordination) Funding (adequacy, dependability, duration, and distribution) The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
20
Why Method Engineering? – Stakeholders Vary Greatly Number of stakeholders Diversity of stakeholders: • Acquirer, developer, maintainer, member of the public,
operator, regulator, safety/security accreditor/certifier, subject matter expert, user, … Authority (requirements, funding, policy, … )
Accessibility of the stakeholders to the architecture teams Volatility of stakeholder turnover (especially acquirers) Motivation and needs
Degree of trust The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
21
Why Method Engineering? – Profiling Systems (Programmatic Meters)
Endeavor Characteristics
Stakeholder Characteristics
Organizational Characteristics
Low Risk Systems Number of Organizations Size of Organizations Mgmt / Eng. Culture Geographic Distribution Expertise Experience Number of Stakeholders Stakeholder Accessibility Stakeholder Authority Degree of Trust Stakeholder Volatility Endeavor Cycle Endeavor Scope
High Risk Systems
One
Very High
Tiny
Huge
Late Adopters
Local
Early Adopters
Global
High
Low
Low
High
High
Low
High
Low
High
Low
Low
High
Single Phase
Individual Subsystem
Total Lifecycle
System of Systems
Duration Weeks
Decades
Funding Inadequate
Generous
Inadequate
Generous
Schedule
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
22
Why Method Engineering? – Profiling Systems (Quality Meters) Poor Quality Systems
High Quality Systems
Availability Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
Low
High
External Quality Characteristics
Capacity Interoperability Performance Reliability Robustness Safety Security Usability
Internal Quality Characteristics
Variability
Extensibility Financial Feasibility Maintainability Portability Testability
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
23
Why Method Engineering? – Profiling Systems (SoS Meters) Ultra-Large Scale Systems (“System of Systems”)
Trivial Systems Complexity
System Characteristics
Trivially Simple
Ultra -Complex
Evolution Negative Emergence
Highly Static
Constantly Evolving
Positive Emergence
Negative Emergence
Size Trivially Small
Ultra -Large-Scale
Variability Single Variant or Configuration
Ultra -large Amounts of Variability
Subsystem Characteristics
Autonomy Operationally Interdependent
Operationally Independent
Governance Centrally Governed
Independently Governed
Heterogeneity Completely Homogeneous
Physical Distribution
Contiguous Systems
Completely Heterogeneous
Extremely Distributed Systems
Reuse 100% New
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
100% Reuse
© 2011 Donald Firesmith
24
Why Method Engineering? – Bottom Line No single system architecture engineering method is sufficiently general and tailorable to meet the needs of all endeavors.
Method engineering enables the creation of appropriate, system/organization/endeavor/stakeholder-specific architecture engineering methods.
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
25
Topics Motivation
MFESA Overview MFESA Ontology of Concepts and Terminology MFESA Metamodel of Reusable Method Components MFESA Repository of Reusable Method Components •
Architectural Work Units and Work Products
•
Architectural Workers
MFESA Metamethod Conclusion
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
26
Definition Method-Framework for Engineering System Architectures (MFESA) a method framework for engineering appropriate situation-specific system architecture engineering (SAE) methods
MFESA is not a single system architecture engineering method.
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
27
As-Performed Processes
Process-Level Actual As Performed Project-Specific Process Components (and Processes)
Architecture Team 1
Architect Architect John Mary
Architecture Task 1 Execution
Architecture Plan
Architecture Task 2 Execution
Architecture
Architecture Model
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
Architecture Document
© 2011 Donald Firesmith
28
As-Intended Methods
Method Level As Intended Methods and Standards (Method Components) SEI CMMI
SEI ADD
SEI EPIC
Process Level Actual As Performed Project-Specific Process Components (and Processes)
Prime Contractor Method RUP
Subcontractor Method
INCOSE Guidebook
Architecture Architect Architect Team 1 John Mary
SubsystemSpecific Method
System-Specific Method
Architecture Task 1 Execution
Aviation-Appropriate Method
DODAF
AutomotiveAppropriate Method
Architecture Plan
Architecture
Architecture Task 2 Execution
Architecture Model
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
Architecture Document
© 2011 Donald Firesmith
29
Method Frameworks Metamethod Level Method Framework
MFESA
Method Level As Intended Methods and Standards (Method Components)
SEI CMMI
SEI ADD
SEI EPIC
Process Level Actual As Performed Project-Specific Process Components (and Processes)
Prime Contractor Method
RUP
Architecture Team 1
Subcontractor Method
INCOSE Guidebook
Architect Architect John Mary
SubsystemSpecific Method
System-Specific Method
Architecture Task 1 Execution
Aviation-Appropriate Method
DODAF
AutomotiveAppropriate Method
Architecture Plan
Architecture
Architecture Task 2 Execution
Architecture Model
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
Architecture Document
© 2011 Donald Firesmith
30
Primary Inputs to MFESA Situational Method Engineering
ANSI/EIA 632-2003 ANSI/IEEE 1471-2000
System Architecture Engineering Methods
Department of Defense Architecture Framework (DODAF)
Software Architecture Engineering Methods
INCOSE SE Handbook ISO/IEC 15288-2002
System Engineering
Naval Systems Engineering Guide
Software Engineering
MFESA
SEI Attribute-Driven Design (ADD)
Component-Based Development / Reuse
SEI Capability Maturity Model Integrated (CMMI)
Systems of Systems Engineering
SEI Evolutionary Process for Integrating COTS-based Systems (EPIC)
Human-Centered Architecture Engineering
System Architecture Engineering Experience
Specialty Engineering (e.g., Performance, Reliability, Safety, and Security)
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
31
MFESA Components (Top View)
MFESA
MFESA Ontology
MFESA Metamodel
Method Engineering Framework
MFESA Repository
MFESA Metamethod
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
32
MFESA Components (Detailed View) Method Engineering Framework
MFESA
MFESA Ontology defines the concepts and terms used in the
MFESA Metamodel
MFESA Repository
MFESA Metamethod
stores the
describes how to engineer project-specific
Foundational MFESA Method Components tailored
Reusable MFESA Method Components
MFESA Architecture Engineering Method
Reusable MFESA Architecture Engineering Methods
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
33
MFESA Components (Usage) Method Engineering Framework
MFESA
MFESA Ontology defines the concepts and terms used in the
MFESA Metamodel
MFESA Repository
MFESA Metamethod
stores the
describes how to engineer project-specific
Foundational MFESA Method Components tailored
Reusable MFESA Method Components
MFESA Architecture Engineering Method
performs the
Architect performs the
may play the role of the
Reusable MFESA Architecture Engineering Methods
Process Engineer
selects and tailors the
selects, tailors, and integrates the
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
34
MFESA Addresses Size and Complexity
Third Generation Approaches Needed Maximum Size and Complexity of the System and its Architecture
Second Generation Method Frameworks and Project-Specific Methods First Generation General Purpose Individual Standards and Methods Date in Years
Today
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
35
Topics Motivation MFESA Overview
MFESA Ontology of Concepts and Terminology MFESA Metamodel of Reusable Method Components MFESA Repository of Reusable Method Components • Architectural Work Units and Work Products
• Architectural Workers
MFESA Metamethod Conclusion
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
36
MFESA Ontology More than merely an architectural glossary Information model of system architecture engineering Defines foundational architectural concepts and terminology Defines relationships between concepts
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
37
MFESA Ontology of Concepts and Terminology System System Architecture Architectural Structures
Architectural Styles, Patterns, and Mechanisms Architectural Drivers and Concerns Quality Model, Quality Requirements,
Architectural Representations Architectural Models, Structures, Views, and Focus Areas Architectural Quality Cases Architectural Visions The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
38
System - Definition System a cohesive integrated set of system components (i.e., an aggregation structure) that collaborate to provide the behavior and characteristics needed to meet valid stakeholder needs and desires
Important Ideas: • Modeled as hierarchical aggregate structure • Integrated system components • Components collaborate • Emergent behavior and properties
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
39
System Component Types Subsystems • Consumable materials (e.g., ammunition, fuel, lubricants, reagents, and
• • • •
• • • • • • • •
solvents) Data Documentation (both separate physical and built-in electronic documentation) Equipment (e.g., maintenance, support, and training equipment) Facilities (e.g., maintenance, manufacturing, operations, support, training, and disposal facilities including their component property, buildings, and their furnishings) Hardware Manual procedures Networks (for the flow of data, power, and material) Organizations Personnel Physical interfaces Software Tools
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
40
System – A Partial Example Aircraft System of Systems
Aircraft System
Airframe Segment
Ground Support System
Avionics Segment
Empennage Horizontal Stabilizers Vertical Stabilizer Tail Cone
Skin
Propulsion Segment
Vehicle Segment
Crew Compartment
Engines
Auxiliary Power
Communications
Passenger Compartments
Fuel
Electrical Power
Nacelles
Fire Protection
Pylons
Flight Control Surfaces
Crew Interface Entertainment Information Processing Navigation
Windows
Interiors Segment
Training System
Auto Flight
Fuselage
Doors
Maintenance System
Prognostics and Health Management Sensors
Cargo Compartments Galleys Lavatories
Ailerons
Emergency Provisions
Elevators
Water & Waste
Flaps
Environment
Rudder Hydraulic Power
Structure Wings
Air Conditioning
Pneumatic Power
Air Pressure Landing Gears Oxygen
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
Shipside Lighting
© 2011 Donald Firesmith
41
Some System Characteristics Multiple Components Multiple Interactions between Components Multiple Structures (Logical and Physical, Static and Dynamic) Multiple: • Views and Viewpoints • Models • Focus Areas
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
42
What about Systems of Systems? System of Systems (SOS) a system composed of systems
Almost all systems are composed of systems (i.e., subsystems) When most people say systems of systems, what they really mean is something like this: an ultra-large and complex, highly flexible, dynamically evolving, technologically ambitious, and geographically-distributed system of pre-existing, heterogeneous, autonomous, self-contained, and independently governed (e.g., acquired, developed, operated, scheduled, and funded} systems, whereby the system of systems exhibits significant amounts of unexpected emergent behavior and characteristics
Engineering the architecture of such systems of systems calls for a different architecture engineering method than simpler systems. The Method Framework for Engineering System Architectures (MFESA) . Donald G. Firesmith
© 2011 Donald Firesmith
43
System and System Architecture - Ontology Architect(s)
Subsystem
System of Systems
Architectural Decisions
engineer the System 1
abstracts the 1
System Architecture
Architectural Inventions Architectural Tradeoffs
drive
Architectural Assumptions Associated Rationales
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
44
Architectural Structure, Element, and Component – Definitions Architectural Structure a cohesive set of architectural elements connected by associated relationships that captures a set of related architectural decisions, inventions, tradeoffs, assumptions, and rationales
Architectural Element a part of an architectural structure
Architectural Component a physical architectural element of a static physical aggregation structure
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
45
Architectural Structure – Ontology
System
1
abstracts the 1
Architectural Decisions System Architecture
1
1
are abstractions (models) of the Static Structures Dynamic Structures Logical Structures Physical Structures
Architectural Inventions Architectural Tradeoffs
consists primarily of
Architectural Assumptions
drive and constrain 1..*
1..* 0..* may have known 0..* Architectural Risks
Associated Rationales
1..*
Architectural Structures
incorporate most
1..* Architectural Elements
drive
1..* connect
Relationships Between Architectural Elements
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
46
Architectural Styles, Patterns, and Mechanisms – Definitions Architectural Pattern a well-documented reusable solution to a commonly occurring architectural problem within the context of a given set of existing architectural concerns, decisions, inventions, engineering trade-offs, and assumptions
Architectural Style a top-level architectural pattern that provides an overall context in which lower-level architectural patterns exist
Architectural Mechanism a major architectural decision or invention, often an element of an architectural pattern
The Method Framework for Engineering System Architectures (MFESA) Donald G. Firesmith
© 2011 Donald Firesmith
47
Architectural Styles, Patterns, and Mechanisms - Ontology Architectural Styles <
