The Value of a Reference Architecture GSAW 99 Workshop

(1)

The Value of a Reference

Architecture

GSAW 99 Workshop

Janis Putman

Mike Hooper

Andy Reho

(2)

So…Why a Reference Architecture?

● _{MOTIVATION: Need an overarching architecture strategy to accommodate}

cross-organization incremental system level solutions for a shared environment: frame incremental solution choices to ensure consistent concepts and rules of structure are incorporated into all intermediate solutions.

● _{PURPOSE: Provide the basis for making incremental specific design decisions and}

product choices later on in the system building process.

● _{DEFINITION: A high-level parameterized system framework} _{for a ’system’ that defines}

its overall target structure (components and relationships among them) in a systematic consistent manner Reference Architecture Technical drivers Business drivers Previous Solution Systems Influences

Cost, Risk, Schedule System

Constraints System Performance System QoS System Components System Interactions System Conformance Test Architecture Rules System Behavior Architecture Concepts

(3)

Objectives

● System-wide Properties (example)

-

Quality of Service

-

Policies (permissions, prohibitions,

obligations)

-

Autonomy

-

Cooperation - Execute tasks jointly,

-

Shared environment - Interoperate,

Information Sharing Business Activity A Business Activity B Relationships Business Activity C Cross-Organization Separate Systems No Central Control

Cooperative Corporate Systems

-

Scalability - Addition of

resources (users, system)

-

Interoperability - Mutual

understanding of exchanged messages

-

Connectivity - Ability of systems

(4)

Current Challenges

●

Cross-Enterprise Endeavor

with:

-

Incomplete Requirements

-

Heterogeneous Legacy Systems

-

Lack of Interaction Specification

-

Severe Constraints: ● Politics, Resource Constraints, Independent Organization Mandates

● COTS Middleware Complexity

● _{Architecture ‘tools’ Complexity,}

Inconsistency, Incompleteness

●

Inadequate and Complex Software

Architecture

-

ADLs, without commercial maturity

and support

-

Styles and connectors: how do they

relate to: each other, APIs, interaction, QoS parameters, networks, actions, etc. ?

-

Few (Integrated) Tools aimed at the

architect’s problem

-

UML incomplete: semantics of

interaction lacking +graphic tools do

not capture all of UML (e.g., ROSE ©₎

-

Multiple languages, models, and

frameworks for “required use”, with insufficient consistency

(5)

Functional Reqts System Reqts Mandates Performance Business Technical Dri ve rs Resource Management Program Coordination IT Planning Current Solution Target Solution Architecture n

Cross-Organizations

Reference Architecture Concepts

Transitional Processes Cap abi lity n Cap abi lity 3 Cap abi lity 2 Architecture 2 Architecture 1

Policies, Standards, Business Rules, etc.

Cost, Risk, Schedule, Assessments, Conformance

Incremental Solutions Reference Architecture Information Enterprise Application Engineering Technology Ca pab ilit y 1

(6)

Phase 1 Phase 2 Phase N Baseline Capability Engineer Assess Propose Test/Demo Engineer Assess Propose Test/Demo Engineer Assess Propose Test/Demo Architect Architect Architect

Incremental Developed Shared System of Systems

Guided By A Reference Architecture

Initial Capability Additional Capability Demonstrations User Acceptance Additional Capability Reference Architecture Phase 1 Phase 2 Phase N Baseline Capability Engineer Assess Propose Test/Demo Engineer Assess Propose Test/Demo EngineerAssess Propose Test/Demo Architect Architect Architect Phase 1 Phase 2 Phase N Baseline Capability Engineer Assess Propose Test/Demo Engineer Assess Propose Test/Demo EngineerAssess Propose Test/Demo Architect Architect Architect Phase 1 Phase 2 Phase N Baseline Capability Engineer Assess Propose Test/Demo Engineer Assess Propose Test/Demo EngineerAssess Propose Test/Demo Architect Architect Architect •Different Increments •Different Organizations •Different Phases

(7)

Increment Examples

Public Key Infrastructure Mediators Pharmaceutical Management Med Equip Management STEP Workflow Medical Data Semantics Purpose, Business Semantics Functionality Services, Distribution Products Enterprise Information Application Technology Engineering Patient Mgmt

(8)

Use of Reference Architecture

●

Viewpoints

-

provide abstraction

-

separation of

concerns

-

can be incremental

●

Viewpoint Consistency

-

architecture

evaluation

-

common

understanding

-

increased

completeness and

consistency

Example: C2--Actions Commander--Role

Joint Chiefs--Role

Supply--Resources

Map--Resources

Authority--Permission

Responsibility--Obligation

Tasking Order--Contract

Response Delay--QoS

The Aggregation of the Generic RM-ODP Framework and Specific Customer Requirements

Enterprise Information Application Engineering Technology Increment n Solution Conformance test Govt Govt Govt + contractor Contractor A Contractor B Contractors

-

geographically distant

multi-organization can

specify and implement

separately

(9)

Objects Cluster Node Capsule Transparency Managers Functions Local Binding Signature Control Engineering Interface Channel Distributed Binding Engineering Components Interaction Binding Signature Binding Object QoS Contract Interface client/server Interface signal Interface stream Relation sh ip r u le s Computational Technology Electr onic Bondi ng CORBA ORB TCP/IP Java HTML XML Solaris Server Oracle 7.2 SoftDock COM+

Relationships Across Viewpoints (

Sample RM-ODP

)

Enterprise object Role Actions QoS Interactions Policy: Obligation Permission Prohibition Relationship Contract Enterprise Dynamic Schema Static Schema Invariant Schema Information

The Value of a Reference Architecture GSAW 99 Workshop