Systems Engineering Enterprise Architecture for IOOSDMAC

1
Systems Engineering/ Enterprise Architecture
forIOOS/DMAC

• John Lever
• Director, Information Architecture Governance
• Naval Meteorology and Oceanography Command

2
Need

• Size
• Complexity
• Variety
• Coordination
• The Plan "the other sections of this document
  describe a wide variety of requirements that
  represent a diverse group of stakeholders. The
  resultant complexity would likely render
  ineffective any uncoordinated approach to
  satisfying these requirements. Accordingly, there
  is strong evidence that the Data Management and
  Communication subsystem of the Integrated Ocean
  Observing System can only be accomplished using a
  formalized System Engineering process."

3
Systems Engineering is

• The engineering discipline of defining the system
  elements that a system must include and the
  essential tasks that a system must perform

From Beginners Guide to Systems Engineering,
INCOSE, 2001
4

• Systems Engineering is a management technology
  that controls a total lifecycle process, which
  involves and which results in the definition,
  development, and deployment of a system that is
  of high quality, trustworthy, and cost effective
  in meeting user needs.

Sage, A.P., Systems Management for Information
Technology and Software Engineering, Wiley, New
York, 1995.
From Beginners Guide to Systems Engineering,
INCOSE, 2001
5
The Many Roles of a Systems Engineer

• System Concept Definition
• System Requirements Analysis
• System Design
• Subsystem Requirements Analysis
• Subsystem High/Low Level Design
• Subsystem Build
• Subsystem Integration
• Subsystem Test
• System Integration
• System Test
• System Deployment
• System Operation and Maintenance
• System Phase Out

• Each phase of the systems life cycle has defined
  inputs, activities, products, processes, and
  possibly tools to support the activities,
  products, and processes.
• The Systems Engineer may be responsible for
  providing inputs, conducting activities,
  producing products, overseeing processes, and
  using tools to produce the output of the
  lifecycle phase.
• Heres a list of generally accepted system
  lifecycle phases

From Beginners Guide to Systems Engineering,
INCOSE, 2001
6
Systems Engineers Perform a Balancing Act

• To determine fit
• Emphasize the whole, understand the pieces
• Systematic, structured approach through applying
  quantitative, measurable terms
• To achieve balance
• Cost/risk/schedule against function/performance
• Strive for reasonable expectations
• To select the best compromise
• Optimized system design is not necessarily
  technically superior
• Design complexity versus development simplicity

From Beginners Guide to Systems Engineering,
INCOSE, 2001
7
Enterprise Architecture

• An architecture description is a representation,
  as of a current or future point in time, of a
  defined domain in terms of its component parts,
  what those parts do, how the parts relate to each
  other, and the rules and constraints under which
  the parts function. - C4ISR Architectural
  Framework
• The Federal Enterprise Architecture (FEA) is a
  business-based framework for Government-wide
  improvement. - feapmo.gov
• An essential framework or blueprint for
  communication, interpretation and implementation
  of corporate objectives across an organization,
  to enable the evolution of a strongly aligned IT
  environment. - The Butler Group
• A comprehensive description of all of the key
  elements and relationships that make up an
  organization. Business Process Trends

8
Benefits

• Provides the central authority and control
  necessary to effectively migrate from a
  controlled centralized approach to a controlled
  but truly distributed approach to computing
• Control decentralized chaos
• Provide standardization so that differentiation
  can occur on the important things
• Promotes integration and coordination across
  enterprise
• Redundancy/replication
• Awareness of dependencies
• Facilitates coordination and deployment of IT
  resources in direct support of business
  functions.

Building Enterprise Information Architectures
Melissa A. Cook, 1996
9
Zachman Framework
10
Zachman Framework
11
Zachman Framework
12
Zachman Framework
13
Zachman Framework
14
Zachman Framework
15
Zachman Framework
16
DODAF Views
17
Mapping DODAF to Zachman
"Civilian Application of the DOD C4ISR
Architecture Framework A Treasury Department
Case Study", Rob Thomas II
18
Mitreteks Approach to IOOS Architecture

• Benefits of having a formal (enterprise)
  architecture
• Architecture is the arrangement of parts or
  components into a whole, and the organization and
  relations of those components, so as to achieve
  the goals of the enterprise or system.. . .
  how all parts of an enterprise work together to
  provide the capability of an enterprise to
  achieve its vision.
• Case in point cell phone systems
• Carriers must interoperate (standards,
  implementations).
• Carrier organizations must cooperate in specific
  ways (e.g., billing, routing, recognizing and
  assigning phone numbers).
• BUT Europe vs US GSM vs CDMA phones no
  interop.

19
Mitreteks Approach to IOOS Architecture
Benefits (continued)

• Enterprise level
• Roadmap for transition to desired system.
• Communication tool.
• Reduce duplication, increase interoperability.
• Help develop suitable organizations and
  governance.
• Reduce needed IT, development resources.
• System level
• Understand scale of connectivity, range of
  existing systems.
• Guide integration of existing systems.
• Communication tool.
• Improve quality of requirements and
  specifications.
• Budgetary level
• OMB requires participating (federal) entities to
  comply with FEA to justify funding.

20
Mitreteks Approach to IOOS Architecture
(continued)

• Architecture frameworks
• Basis for organizing architecture.
• Several extant
• E.g., FEA, DoDAF
• Mitretek tailoring of framework for IOOS
• Subset of framework as applicable.
• Merge FEA, DoDAF subsets
• Some overlap.
• Extend using Mitretek frameworks as appropriate.
• Catalog existing Ocean Obseving organizations and
  their relationships.
• Catalog suitable existing protocols and meta data
  standards (if any), otherwise create placeholders
  for future agreed-on protocols and standards.

21
Mitreteks Approach to IOOS Architecture
(continued)

• Examine existing partially-integrated Ocean
  Observing systems, Boeing and Northrup IOOS demos
  for useful architectural approaches and lessons.
• Describe current non-integrated (non)system.
• Organizations, systems, technical standards,
  networks, capacities.
• Describe desired future integrated system
• Missions, goals, organizations, systems,
  technical standards, networks, capacities,
  archiving policies, etc.
• FEA models, primarily for business-related
  aspects.
• DoDAF and similar tailored views for remainder.

22
Mitreteks Approach to IOOS Architecture
(concluded)

• Create high-level, preliminary architecture first
• Back-fill, add detail later as tasked.
• Emphasize simplicity and usefulness of
  architectural products.

23
Roles and Responsibilities