Software Reference Architecture Project - Paper due November 25, up to 11 pages or less.

profileHelloWorld123
Ref_Archi_Description_Final_v1_18Jun10.pdf

DoD Reference Architecture Description

Office of the Assistant Secretary of Defense 

Networks and Information Integration (OASD/NII) 

Reference Architecture  Description 

     

       

 

 

Prepared by the Office of the DoD CIO

JUNE 2010

DoD Reference Architecture Description

Table of Contents    1   Introduction ....................................................................................................................... 1

    1.1 Purpose ....................................................................................................................................................... 1

   

    1.2 Background ................................................................................................................................................ 1 1.3 Approach .................................................................................................................................................... 1 1.4  Document Structure ............................................................................................................................... 2 

2  Reference Architecture Definition ............................................................................. 3  3   DoD­wide Reference Architecture Description ..................................................... 5

    3.1 Strategic Purpose .................................................................................................................................... 6

   

    3.2 Principles .................................................................................................................................................... 6

    3.3 Technical Positions ................................................................................................................................. 7 3.4 Patterns ....................................................................................................................................................... 7 3.5  Vocabulary ................................................................................................................................................. 8 

4  DoDAF Models Utilized in RA ....................................................................................... 9  5  Summary ........................................................................................................................... 11  Ap  pendix A: Reference Architecture Sample Outline ............................................ A­1

  Ap  pendix B: Examples of Reference Architectures ................................................ B­1

  B1.  OASIS SOA Reference Architecture ............................................................................................. B‐1

  B2.  The Open Group SOA Reference Architecture ....................................................................... B‐2

  B3.  Global Justice Reference Architecture (JRA) ........................................................................... B‐3

  B4.  DoD Information Enterprise Architecture ............................................................................... B‐3 B5.  Service Oriented Architecture Foundation – Army,  SOAF‐A ........................................... B‐4 B6.  IBM Insurance Application Architecture .................................................................................. B‐5 

Appendix C:  References ................................................................................................... C­1 

List of Figures  Figure 1 ‐ Reference Architecture Purpose .................................................................................................. 3  Figure 2 ‐ Reference Architecture Relationships ....................................................................................... 4  Figure 3 ‐ DoD Enterprise Architecture ......................................................................................................... 5  Figure B‐1 ‐ Overview of the OASIS SOA RA and RM ............................................................................ B1  Figure B‐2 ‐ Layers of the Open Group SOA Reference Architecture ............................................. B2  Figure B‐3 ‐ IBM Insurance Application Architecture .......................................................................... B5 

 

 

Table  Table 1 ‐ Mapping of DoD‐wide Reference Architecture Elements to DoDAF Models ............ 10 

i

DoD Reference Architecture Description

1

1 Introduction  The term “Reference Architecture”, within the Information Technology community, has various  meanings, multiple purposes and uses, varying levels of detail and abstraction, and very little  common  guidance.  The  Deputy  Assistant  Secretary  of  Defense  (DASD)  for  Information  Management, Integration and Technology (IMI&T)/DoD Deputy CIO requested a position on  and  strategy  for  Reference  Architecture  in  the  Department.  The  Reference  Architecture  Description document is in response to this request. The objective is to provide useful guidance  and direction on the development and use of Reference Architecture as a tool to guide and  constrain architecture and solution development.  

1.1 Purpose  This document provides guidance for the development and use of Reference Architecture in  the  form  of  a  DoD  definition  for  Reference  Architecture  and  a  description  for  DoD‐wide  Reference Architecture. The definition is applicable to all DoD Reference Architectures, while  the description focuses on a unique set of DoD Reference Architectures that provide guidance  to  the  entire  Department,  hereafter  referred  to  as  DoD‐wide  Reference  Architectures.  This  description  establishes  standard  criteria  for  DoD‐wide  Reference  Architectures.  Reference  Architectures  developed  by  Components  for  their  specific  purposes  and  uses  are  not  constrained by the description of DoD‐wide Reference Architecture in this document.  

1.2 Background  Reference  Architectures  have  been  used  in  DoD,  other  Federal  Agencies,  and  Industry  to  provide  information,  guidance,  and  direction  for  focused  subject  areas.  These  Reference  Architectures have wide‐ranging purposes, uses, levels of detail, and levels of abstraction. The  term itself has multiple definitions and meanings and seems to be relative to the context of the  environment in which it is used. A Google search for Reference Architecture returned more than  705,000 results. 

Reference Architecture literature can be found throughout DoD, other Federal Agencies, and  Industry  addressing  various  subject  areas.  Due  to  current  interests  in  Service  Oriented  Architecture (SOA), a good amount of existing Reference Architecture literature is focused on  this area. Most notable are the efforts by the Organization for the Advancement of Structured  Information Standards (OASIS), The Open Group Architecture Forum (TOGAF), and the Object  Management Group (OMG).  

As information, services, and infrastructure requirements and solutions continue to evolve, the  need  for  Reference  Architecture  increases.  Reference  Architecture  serves  as  a  tool  for  providing common information, guidance, and direction to guide and constrain architecture  and solutions. A DoD definition is needed to establish this broader perspective of Reference  Architecture as the common position across the Department. While Reference Architectures  with varying purposes, uses, and content exist at many levels throughout the Department, and  will  continue  to  do  so,  a  standard  set  of  criteria  needs  to  be  established  for  DoD‐wide  Reference Architecture. A standard set of criteria for DoD‐wide Reference Architecture enables  consistent  development,  use  and  assessment  of  these  architectures.  It  also  establishes  a  common DoD expectation of the content provided by a DoD‐wide Reference Architecture. This  document focuses on describing the standard criteria.  

1.3 Approach  The approach for developing this document involved three steps: 

DoD Reference Architecture Description

a. The  first  step  was  to  research  and  gather  existing  Reference  Architecture  documents and information from commercial, Federal, and DoD sectors. The intent  was to pull together the broadest, representative sample of Reference Architecture  materiel as possible. 

b. The second step was to examine and analyze the Reference Architecture materiel to  better understand existing concepts of Reference Architecture, what it is used for,  its goals, objectives, characteristics, and key elements. The intent was to discover  common threads for defining best practices for developing Reference Architectures.  An additional benefit of this step was discovering that we already have information  sources serving as Reference Architectures that are not specifically called out as  Reference Architectures. 

c. The third step was to develop a DoD definition for Reference Architecture and a  description  for  DoD‐wide  Reference  Architecture  based  on  the  analysis  of  Reference Architecture material and the intent of the Deputy CIO. 

1.4 Document Structure  This document is structured to provide a logical progression of information about Reference  Archite r c   octu e in DoD. It  onsists of five sections and a set  f appendices. 

a. Section  1:  Provides  an  introduction  that  describes  the  purpose,  background,  approach, and structure for this document. 

b. Section 2:  P rovides the DoD definition for Reference Architecture. 

c. Section 3: Provides a description  for  the DoD‐wide Reference Architecture. This  section  describes  and  discusses  the  five  elements  of  a  DoD‐wide  Reference  Architecture. 

d. Section 4: Provides a sample of DoDAF v2.0 views and models that could be used in  describing the five Reference Architecture elements. 

e. Section 5: Provides a summary of the key points and positions described in this  document. 

f. Appendices  A‐C:  Appendix  A  provides  a  sample  Reference  Architecture  outline;  Appendix B provides examples of existing Reference Architectures; and Appendix C  rovides a list of References in this document. p

 

2

DoD Reference Architecture Description

2 Reference  rchitecture Definition  An examination and analysis of numerous existing Reference Architecture definitions within  DoD, other Federal Agencies, and Industry revealed common points among them. A common  theme among  the definitions  is  that  the primary purpose of  a Reference  Architecture  is  to  guide and constrain the instantiations of solution architectures as depicted in Figure 1. Based  on this, sset in [A&C, 2007]: 

A

 a Reference Architecture is considered an organizational a

• Providing common  language for the various stakeholders 

• Providing consistency of implementation of technology to solve problems 

• es Supporting the validation of solutions against proven Reference Architectur

• Encouraging adherence to common standards, specifications, and patterns 

   

 

Other relevant terms used in the definitions include “patterns” and “solution architectures”.  Patterns are models of architecture representations at a level of generality that provides some  degree of reuse. The DoD Architecture Framework (DoDAF)1 defines Solution Architecture as a  framework or structure that portrays the relationships among all the elements of something  that answers a problem. It describes the fundamental organization of a system, embodied in  its  components,  their  relationships  with  each  other  and  the  environment,  and  the  principles governing its design and evolution. Solution architecture instantiations are guided  and constrained by all or part of a Reference Architecture where the generalized and logical  abstract elements of the Reference Architecture are replaced by real world, physical elements 

Figure 1 ­ Reference Architecture Purpose 

according to the specified rules, principles, standards and specifications.  

From all of this, the derived DoD definition for Reference Architecture is: 

Reference Architecture  is an authoritative source of  information about a  specific  subject  area  that  guides  and  constrains  the  instantiations  of  multiple architectures and  lutions.  so

Reference Architecture serves as a reference foundation for architectures and solutions and  may also be used for comparison and alignment purposes.  There may be multiple Reference 

1 Department of Defense Architecture Framework (DoDAF) Version 2.0, Volume 1, 28 May 2009, Pg. 6.

3

DoD Reference Architecture Description

Architectures within a subject area where each represents a different emphasis or viewpoint of  that area as depicted in Figure 2. For each Reference Architecture, there may be any number of  architectures and solutions corresponding to different aspects of the subject area viewpoint.  

  Figure 2 ­ Reference Architecture Relationships 

 

Reference Architectures may be defined at many levels of detail and abstraction (from specific  to  generalized)  and  for  many  different  purposes.  In  fact,  a  Reference  Architecture  for  one  subject  area  can  be  a  specialization  of  a  more  general  Reference  Architecture  in  another  subject area. The level of abstraction provided in a Reference Architecture is a function of its  intended  usage.  Where  solution  architectures  are  to  be  developed  based  on  a  specific  Reference Architecture, the level of detail provided as a reference may have to be greater than 

nif a Reference Architecture is i tended to be used for alignment purposes only. 

Reference  architectures  may  also  be  complimentary  in  guiding  architectures  and  solutions.  Figure 2 also shows that Reference Architecture may guide and constrain various types and  instantiations  of  architecture  depending  on  the  purpose  and  scope.  DoD‐wide  Reference  Architecture,  due  to  its  broader  purpose  and  scope,  may  guide  and  constrain  Enterprise,  Segment, Capability, and Solution Architectures. 

4

DoD Reference Architecture Description

3 DoD­wide Reference Architecture Description  DoD‐wide Reference Architecture is part of the DoD Enterprise Architecture (EA). Figure 3,  DoD Enterprise Architecture (EA), shows the construct of the DoD EA depicting its components  and their general relationships.    

  Figure 3 ­ DoD Enterprise Architecture 

DoD‐wide  Reference  Architecture  is  part  of  the  “Architecture  Guidance”  block  under  the  “References” label in the upper portion of the diagram. In this position, it guides and constrains  all architectures in the DoD EA. 

The DoD‐wide Reference Architecture provides  information, guidance, and direction  that  is  applicable across DoD. This information, guidance, and direction are provided in the five (5)  elem nts that comprise a De oD‐wide Reference Architecture.  

a. Strategic Purpose – Identifies goals and objectives of the Reference Architecture  and describes the specific purpose of and the problem(s) to be addressed by the  Reference Architecture. 

b. Principles  –  Sufficient  high  level  foundational  statements  of  rules,  culture,  and  values that drive technical positions and patterns. 

c. Technical  Positions–  Technical  guidance  and  standards,  based  on  specified  principles that need to be followed and implemented as part of the solution. 

5

DoD Reference Architecture Description

d. Patterns  (Templates)2  –  Generalized  architecture  representations  (viewpoints,  graphical/textual models, diagrams, etc.) that show relationships between elements  and artifacts specified by the technical positions. 

e. Vocabulary  –  Acronyms,  terms,  and  definitions  that  are  used  in  the  Reference  Architecture  and  relevant  to  architectures  and  solutions  that  are  guided  and  constrained by the Reference Architecture.

3.1 Strategic Purpose  The Strategic Purpose describes the context for the Reference Architecture and provides the  basis  for  the  principles,  technical  positions,  patterns,  and  vocabulary  in  the  Reference  Architecture.  The  context  includes  descriptions  of  the  scope,  goals,  and  purpose  of  the  Reference  Architecture,  why  it  is  needed,  and  when  and  how  it  should  be  used.    The  key  authoritative sources used in the development of the RA, as well as the intended audience (to  whom  the  architecture  is  directed),  should  also  be  included  in  this  section.  The  strategic  purpose should explicitly identify the primary producing stakeholder (owner) organizations  that will develop and implement related architectures and solutions. It should also explicitly  describe  the  issue(s)  and  stakeholder  concern(s)  that  will  be  addressed  by  the  Reference  Architecture.  Understanding  and  consensus  on  the  strategic  purpose  of  the  Reference  Architecture  will  enable  end‐to‐end  traceability  between  organizational  context  and  an  eventual solution implementation. 

3.2 Principles  Principles  are  high‐level  statements  that  apply  to  the  subject  area  and  tie  back  to  business/warfighting requirements. They incorporate values and organizational culture, and  drive technical positions and patterns in defining how an organization fulfills its mission.  The  identification of assumptions and constraints can assist  in gaining an understanding of  the  context of the RA, which can provide a helpful perspective on the guiding principles.   

Principles are general rules and guidelines that should be understandable, robust, complete,  independent, and are not intended to state the obvious. They inform and support the way in  which an organization sets about fulfilling its mission and are intended to be enduring and  seldom  amended.  In  DoD‐wide  Reference  Architectures,  principles  without  any  additional  information  should  be  sufficient  to  clearly  convey  the  general  intent  of  the  Reference  Architecture. In some cases, principles may be extracted from relevant subject area policy. In  other cases, they may be created as a result of the development and analysis of the Reference  Arc tehi cture. The following are examples of principles from existing Reference Architectures: 

a. Authoritative data assets, services, and applications shall be accessible to all authorized  users in the Department of Defense, and accessible except where limited by law, policy,  security classification, or operational necessity (DoD IEA v1.2). 

b. All authorized entities have one identity and universal credentials are recognized by all  producers of information and service (GIG 2.0 Operational RA). 

c. All users must have a portable identity credential for authentication (Enterprise‐wide  Access to Network and Collaboration Services RA [EANCS RA]). 

2 Patterns is the most commonly used term to describe these kinds of abstract models and diagrams and will be used in place of Templates in this document.

6

DoD Reference Architecture Description

d. Each Military Department will determine its own appropriate number of AD forests  based on the risks and benefits of different size forests and the specific resources  managed within each (Active Directory Optimization RA [ADORA]) 

3.3 Technical Positions  Technical positions describe  the  technical guidance and standards established  for a subject  area. Due to rapidly evolving technology, technical positions are likely to change often to keep  up with  industry. Required services, standards, agreements, security model, communication  protocols, web services, XML namespaces, data quality, etc. are all technical positions that must  be described and addressed in a DoD‐wide Reference Architecture.  

Defining technical positions forces an organization to identify relevant technical guidance and  standards and justify their choices and tradeoffs. For example, a SOA Reference Architecture  would include descriptions of the services and standards to assist architects in understanding  and  incorporating  them  in  solution  architectures  for  the  subject  area.  The  Army  Reference  Architecture  for Security  for Web Services  [CERDEC, SWS, 2007] has definitions  for security  capabilities that  include authentication, authorization, etc. requiring such standards as WS‐I 

tBasic Security Profile, Security Assertion Markup Language (SAML) and o hers. 

An  effective  way  for  conveying  technical  positions  is  via  a  table  that  contains  information  relevant to a StdV‐1, but technical positions may be described in various ways. The following  are examples of technical positions from existing Reference Architectures: 

a. Available Mandatory Core Designated DoD Enterprise Services, as listed in Appendix G,  are  mandatory  for  use  regardless  of  capability  delivered  [Appendix  G  lists  Collaboration Service, Content Discovery Services, and Content Delivery Services] (DoD  IEA v1.2). 

b. DoD  CAC  Middleware  Requirements  Release  3.0  ‐  The  Middleware  Requirements  defines the standard set of services, interfaces, and configuration options that must be  implemented by all middleware for use on supported Microsoft‐Intel (WINTEL) server  and desktop operating systems platforms within the DoD (EANCS RA). 

c. DoD Active Directory User Object Attribute Specification ‐ Document developed to  provide common naming and attribute guidance to DOD Components that deploy AD.  This standard is applicable to the Contact Sharing capability being implemented  (ADORA). 

3.4 Patterns  Patterns show how artifacts may be organized and related for repeated use. They are typically  low to mid level tabular, structural, behavioral, or graphical model abstractions that focus on  interaction of the artifacts. Patterns undergo change most often as new pattern concepts are  discovered and emerge from solution architectures.  

Patterns may be conveyed through various means such as Activity Models, Process Models, and  Behavioral Models. It is important to identify the pattern and describe it with enough detail for  it to be clearly understood and used appropriately. 

Three potential benefits of architecture patterns are: 1) they enable improved communication  between  stakeholders;  2)  they  facilitate  application  of  sound  architectural  concepts  and  implementations;  and  3)  they  can  become  standardized  through  multiple  implementations  [Cloutier,  May  2006].    An  effective  way  to  develop  a  foundation  to  provide  patterns  of  operational behavior is to leverage the activities of OV‐5a (Activity Node Tree) with the OV‐6c 

7

DoD Reference Architecture Description

(Activity Event sequence diagram.   This combination of viewpoints exploits the relationship  between  the  process  model  and  the  operational  activities,  while  supporting  the  concept  of  integrated architectural viewpoints. 

3.5 Vocabulary   The  vocabulary  provides  the  acronyms,  terms,  and  definitions  that  are  pertinent  to  the  Reference  Architecture.  It  enables  a  common  understanding  of  terms  and  consistency  of  definitions across the subject area. This highlights the importance of a common vocabulary of  terms  as  key  content  of  a  Reference  Architecture.    As  well,  the  authoritative  nature  of  a  Reference Architecture can be reinforced through the practice of documenting the sources of  all activities, process steps and performers within the vocabulary (Integrated Dictionary). 

 

8

DoD Reference Architecture Description

4 DoDAF Models Util zed in RA   Architecture can be considered a Reference Architecture as long as it follows the guidelines  specified in this paper as being general in nature and targeted towards solving specific issues  within a single focused environment. A DoD‐wide Reference Architecture must also provide  the necessary elements – purpose, principles,  technical positions and policies, patterns, and 

i

vocabulary – in some form or another within the architecture.  

The latest version of the DoD Architecture Framework, DoDAF v2.0 [DoDAF, 2008], provides  an  extensive  number  of  compliant  views/models  and  allows  the  use  of  “Fit‐for‐Purpose”  artifacts as needed to sufficiently document the five elements. The DoDAF v2.0 Operational,  Service, and System viewpoints and  their models may all be used  to  formulate patterns of  operational activities and their resources, service level functionality and service resources, and  system level functionality and system resources.  

Table 1 provides a sample  listing of DoDAF v2.0 views and models utilized  in a DoD‐wide  Reference Architecture. This listing is neither exhaustive nor prescriptive.  

Table 2 ­ DoDAF Models Utilized in RA 

Content  DoDAF 2.0 Views/Models 

Purpose: Introduction,  overview, context, scope,  goals, purpose, why needed,  and when and how used 

• AV‐1 Overview & Summary Information  • CV‐1: Vision – overall strategic concept and high level scope  • OV‐1 High Level Operational Concept Graphic – executive 

operational summary level of what solution architectures are  intended to do and how they are supposed to do it 

Principles: foundational  organizational rules, culture,  and values that drive technical  positions and patterns 

• OV‐6a Operational Rules Model  • OV‐6b Operational State Description  • SvcV‐10a Services Rules Model  • SV‐10a Systems Rules Model  • OV‐4 Organizational Relationships Chart – architectural 

stakeholders  Technical Positions & Policies   • StdV‐1 Standards Profile – standards, specifications, guidance, 

policy applying to elements of the solution architectures  Architectural Patterns:  generalized patterns of  activities, service functionality  and system functionality and  their resources, providers  and  information/ data resource  flows              Generalized scenario patterns  of sequenced (sequential/ 

Operational Patterns • OV‐2 (multiple) Operational  Resource Flows 

• OV‐5 {a, b} Activity diagrams  • OV‐6c Event‐Trace Description    Service Patterns  • SvcV‐1 (multiple) Service  Interfaces 

• SvcV‐2 Service Resource Flows  • SvcV‐4 Service Functionality  • SvcV‐10b Service State  Transitions 

• SvcV‐10c Services Event‐Trace 

System Patterns  • SV‐1 (multiple) System 

Interfaces  • SV‐2 System Resource Flows  • SV‐4 System Functionality  • SV‐10b System State  Transitions 

• SV‐10c Systems Event‐Trace  Description 

9

DoD Reference Architecture Description

concurrent) responses by  activities, services and system  functions (together with their  resources) to synchronous/  asynchronous timed events 

Description

Event‐Based Scenario Patterns of Dynamic Behavior  • OV‐6c Event‐Trace Description  • SvcV‐10c Services Event‐Trace Description  • SV‐10c Systems Event‐Trace Description

Vocabulary   • AV‐2 Integrated Dictionary‐ definitions of terms used throughout  solution architectures 

The DoDAF Metamodel (DM2) defines architectural data elements and enables the integration  and  federation  of  Architectural  Descriptions.  It  establishes  a  basis  for  semantic  (i.e.,  understanding) consistency within and across Architectural Descriptions. In this manner, the  DM2  supports  the  exchange  and  reuse  of  architectural  information  among  Joint  Capability  Areas  (JCAs),  Components,  and  Federal  and  Coalition  partners,  thus  facilitating  the  understanding  and  implementation  of  interoperability  of  processes  and  systems.    Data  collected for and presented by a Reference Architecture should conform to the DM2 so the RA  can be federated into the DoD EA and shared with all appropriate users. 

Related elements may be developed for DoD that are not part of the Reference Architecture.  These include CONOPS and Transition Planning Guidance.  

10

DoD Reference Architecture Description

11

5 Summary  The purpose of this work was to provide guidance and direction to the DoD enterprise on the  better use of Reference Architectures for guiding and constraining architecture descriptions,  developments, and usages for current and future capabilities. The approach taken was to  research and leverage Reference Architecture information and best practices to develop a DoD  definition for Reference Architecture and describe the elements that compose a DoD‐wide  Referen  Ace rchitecture. The key points made in this document are: 

a. Reference Architecture is defined as an authoritative source of information about a  specific subject area that guides and constrains the instantiations of multiple  architectures and solutions. This definition is applicable to all of DoD. 

b. Reference Architecture may be developed by various organizations throughout  DoD for their own purposes and intended uses, but DoD‐wide Reference  Architecture must contain the five elements described in this document. 

c. DoD‐wide Reference Architecture is a specific Reference Architecture that provides  information and guidance that is applicable to all of DoD and contains five key  elements. 

d.  The v fi e key elements of a DoD‐wide Reference Architecture are:  

1)  Strategic Purpose ‐ explains context, scope, goals, purpose, and intended  uses. 

2)  Principles ‐ high‐level statements, general rules and guidelines that  constrain how an organization fulfills its mission.  

3)  Technical Positions ‐ technical guidance and standards that need to be  implemented as part of the solution.  

4)  Patterns ‐ reusable models for doing something.  

5)  Vocabulary ‐ key terms and definitions to promote common understanding  and use. A DoD‐wide Reference Architecture requires all five elements to  properly guide and constrain architectures and solutions. 

e. The goals and objectives of Reference Architecture are numerous. They solve a  specific (recurring) problem in a problem space; explain context, goals, purpose,  and problem being solved including when and how Reference Architecture should  be used; and provide concepts, elements and their relationships that are used to  direct/guide and constrain the instantiation of repeated concrete solutions and   architectures. 

f. Reference Architectures may address different levels of abstraction (from the  specific to the generalized) and at different levels of coverage (from patterns to full  end‐to‐end coverage). 

 

 

DoD Reference Architecture Description

A-1

Appendix   Refe  Architecture Sample Outline  The  following  sample  outline  is  the  Table  of  Contents  from  the  Enterprise‐wide  Access  to  Network  and  Collaboration  Services  (EANCS)  Reference  Architecture.  The  sample  outline  contains all the elements described in this paper. It is not meant to be prescriptive but serves  as a guide to assist in organizing Reference Architecture content. 

A: rence  

EANCS Reference Architecture  1   Introduction

  1.1 Overview  1.2 Scope 

  Sources 

 

1.3 Key Authoritative  2  oC ntext  2.1 2.2 nstra mptions 

  Guiding Principles    Co ints and Assu 2.2.1  Constraints  2.2.2  Assumptions     Joint Capability Areas (JCAs) and DoD IEA Priority Areas 2.3 Alignment with

  3  e n S rvice Capability Descriptio

  Control  3.1 Authentication  3.2 Authorization & Access 

 3.3 Activity Decomposition  nd Process4  r  Pattern(s)  P inciples/Rules a

4.1 4.2

  EANCS RA Principles and Rules 

    Process Pattern (s)  

  4.2.1 Combined Process Pattern  4.2.2 Authentication Process Pattern  4.2.3  Authorization and Access Control Process Pattern 

5  Technical Position  Appendix A. Acronyms  Appendix B. AV­2 Integrated Dictionary  A

 

ppendix C. OV­1, OV­5a, and OV­6c Diagrams 

DoD Reference Architecture Description

B-1

Appendix B: Examples of Reference Architectures   

B.1  OA The OASIS Reference Architecture for Service Oriented Architecture  [OASIS RA, 2008] follows  from the concepts and relationships defined in the OASIS Reference Model for Service Oriented  Architecture [OASIS RM, 2008]. OASIS RA  is an abstract realization of SOA,  focusing on the  elements and their relationships needed to enable SOA‐based systems to be used, realized and  owned; while avoiding reliance on specific concrete technologies. While it remains abstract in  nature, the OASIS RA describes one possible template upon which a SOA concrete architecture 

SIS SOA Reference Architecture 

can be built. 

The OASIS RA goal is to show how SOA fits into the life of users and stakeholders in a SOA  ecosystem, how SOA‐based systems may be realized effectively, and what is involved in owning  such a SOA‐based system. The following diagram taken from the OASIS Reference Model depicts  the overview of the OASIS SOA Reference Architecture and Reference Model space showing  levels of artifacts from concrete to abstract. 

 

Figure B­1 ­ Overview of the OASIS SOA RA and RM 

DoD Reference Architecture Description

B2.  The Open Group SOA Reference Architecture  The Open Group has published their SOA RA [TOGAF SOA RA, 2009]. This document provides  guidelines  for  making  SOA  architectural,  design,  and  implementation  decisions.  It  provides  patterns and insights for integrating the fundamental elements of a SOA solution composed of  architectural  building  blocks  (ABB)  within  a  9  layer  structure.  Their  SOA  Reference  Architecture serves as a blueprint that includes templates and guidelines for architects. These  will  enable  the  process  of  modeling  and  documenting  the  nine  architectural  layers,  their  architectural building blocks (ABB), options for layers and ABBs, mapping of products to the  ABBs and architectural and design decisions that contribute to the creation of a SOA. 

The nine layers of the Open Group’s SOA RA are designed to reinforce the various perspectives  of SOA business value. For each layer, there are two aspects: logical and physical. The logical  aspect includes all the architectural building blocks, design decisions, options, KPIs, etc.; the  physical aspect of each layer is to cover the realization of each logical aspect using technology  and products, and is determined by the different architectural decision points that get taken.  This  specification  focuses  on  the  logical  aspect  of  the  SOA  Reference  Architecture,  while  providing the model for the architectural decision points. 

Figure B­2 ­ Layers of the Open Group SOA Reference Architecture 

B-2

DoD Reference Architecture Description

B3.  Global Justice Reference Architecture (JRA)  The Justice Reference Architecture (JRA) is a product of the U.S. Department of Justice’s Global  Justice Information Sharing Initiative (Global) which serves as a Federal Advisory Committee  (FAC) and advises  the U.S. Attorney General on  justice  information sharing and  integration  initiatives [GISWG, 2009]. Global was created to support the broad scale exchange of pertinent  justice  and  public  safety  information.  It  promotes  standards‐based  electronic  information  exchange  to  provide  the  justice  community  with  timely,  accurate,  complete,  and  accessible  information in a secure and trusted environment. 

The Global JRA Specifications Version 1.4 is a SOA reference architecture for justice and public  safety information sharing and includes 1) a set of requirements for justice interoperability, 2)  describes  the  Justice  Reference  Architecture  (concepts,  relationships,  and  high‐level 

acomponents), and 3) provides specifications th t satisfy those requirements. 

Justice defines a Reference Architecture as a tool practitioners can use to make it easier to  develop  a  well‐conceived,  formal  approach  to  designing  information  sharing  solutions/systems. A key benefit of reference architecture for them is that it helps promote  consistent thinking and approaches among the people who use it, even if they have not shared  information with each other. In that context, they see a Justice Reference Architecture as a set  of  documents  that  the  technologists  —  developers,  architects,  project  managers  —  in  a  jurisdiction  can  use  to  accelerate  the  planning  process  for  information  sharing,  while  simultaneously aligning the final outcomes with proven best practices. 

B4. Architecture  The DoD  Information Enterprise Architecture [DoD IEA, 2009]  is an example of a Reference  Architecture  that  is  not  specifically  called  out  to  be  a  Reference  Architecture.  It  states  specifically “DoD IEA 1.1 highlights the key 

  DoD Information Enterprise 

principles, rules, constraints and best practices drawn  from collective policy to which applicable DoD programs, regardless of Component or portfolio,  must adhere in order to enable agile, collaborative net­centric operations”. This is in alignment  with  the  concept  of  a  Reference  Architecture  as  guiding  and  constraining  applicable  DoD  programs.  

The DoD IEA provides a set of principles, rules, and activities. The activities contain associated  constraints  and  mechanisms  that  are  akin  to  technical  positions.  The  hierarchical  activity  model  (acting as a pattern) provides a means  to navigate  the many policies and standards  applicable to the GIG and serves as a classification scheme for investment management. The  portion of the DoD IEA that encompasses the “DoD Information Enterprise Priorities” provides  a  common  taxonomy  and  lexicon  for  describing  the  use  of  GIG  services  and  capabilities.  Appendix D of the DoD IEA also defines where the DoD IEA should be applied, and explains the  process for applying it to DoD architectures. 

So, the case can be made that because it contains all the elements of a Reference Architecture,  achieves the goals and objectives outlined here and has many of the characteristics defined in  this paper, it could be considered as a Reference Architecture. As a Reference Architecture, the  focus area of the DoD IEA is the Information Enterprise (IE). The DoD IEA provides strategic  context,  principles,  rules,  technical  positions,  and  vocabulary  to  guide  and  constrain  architecture and solution development associated with the IE. 

B-3

DoD Reference Architecture Description

B5.  Service Oriented Architecture Foundation – Army, SOAF­ A  In 2007, the U.S. Army Communications‐Electronics Research, Development and Engineering  Center  (CERDEC),  a  subordinate  R&D  center  of  the  Army’s  Research,  Development  and  Engineering Command (RDECOM), put  forward a Service Oriented Architecture Foundation  ­  Army  (SOAF­A)  effort  intended  to  provide  the  Army  with  a  reusable  and  easily  deployable  baseline SOA capability. The goal was to foster the adoption and implementation of SOA across  information systems throughout the Army, and to ensure the interoperability of the individual  SOA instances. They established a series of baseline Reference Architecture documents for the  component  systems  within  the  SOA  Foundation.  These  documents  describe  the  capabilities  provided by the individual components and provide reference use cases and implementation  scenarios. The purpose of the documents was to assist enterprise architects throughout the  Army with understanding the capabilities offered by a SOA and the key issues to be considered  within each capability. 

Four such SOAF‐A 1.0 documents were produced. They were validated by Gartner Group and  follow the discussion on Bricks and Patterns [Schulman, 2004] which represents a model the  Army is hek (Army), 2009].  following for reference architectures in their practice [Damas

•  2007] Enterprise Directory Services (EDS) RA [CERDEC, EDS,

• Enterprise Service Bus (ESB) RA [CERDEC, ESB, 2007] 

• Enterprise Service Management (ESM) RA [CERDEC, ESM, 2007] 

• Security for Web Services (SWS) RA Guide [CERDEC, SWS, 2007] 

There are 3 common guiding principles across each SOAF‐A Reference Architecture: 

Open Standards: Prescribes1.  an open standards‐based approach to realize security  within an SOA environment. 

2. Iterative/Agile Realization: Each Reference Architecture will evolve and mature  iteratively with the goal of achieving a ubiquitous “identity management layer” for  EDS and EBS and “SOA Security layer” for SWS across the Army. 

3. Simplicity/Ease of Implementation: Guidance prescribed is intended to be both  simple to use and as non‐intrusive as possible to develop. 

The Army data strategy team is working on reference architecture in the Data space, but it's in  a seminal stage. The Army believes that a reference architecture template may actually vary  between strategic (enterprise), operational (segment) and tactical (solution) levels. As such,  the templates embodied in the SOA reference architectures follow a common template, based  on Gartner's work, for an enterprise‐level. The Army plans to establish the same for segment or  solution level architectures and integrate reference architecture development into the Army's  Methodology for Enterprise Transformation (MET), which represents an EA process. 

B-4

DoD Reference Architecture Description

B6.  IBM Insurance Application Architecture  The IBM Insurance Application Architecture is an example of a Reference Architecture within  the commercial insurance industry. It encapsulates Insurance focus area best practices in the  form of business process, business activities, business objects, business rules etc. [IBM, 2006].  The IAA supports over 80 percent of an insurer’s business requirements and is designed to be 

teasily customized and ex ended to cover any specific requirement. 

IAA  comprises  five  (5)  models  that  identify,  describe,  and  structure  all  of  the  insurance  business functions, data, and  rp ocesses. 

• Foundation  Models:  insurance  terms  and  definitions  for  communication  and  standardization 

• Information  Models:  insurance  data  content  for  an  enterprise‐wide  view  of  information and data rationalization 

• Process Models: insurance business processes content for areas such as business  process modeling, simulation, and execution 

• Integration Models: business services content for component based development  and services oriented architectures 

• Product Models: a method for accelerating insurance product design 

Figure B­3 ­ IBM Insurance Application Architecture 

B-5

DoD Reference Architecture Description

B-6

These five models ensure that business requirements for major initiatives are captured and  expressed in a manner that can be understood and used by the IT organization and that are  reflected in all subsequent levels of the application development process. 

DoD Reference Architecture Description

C-1

Appendix C: References  [A&C, 2007], The Importance of Reference Architecture, Architecture and Change (A&C), 2007, 

http://www.architectureandchange.com/2007/12/29/the‐importance‐of‐reference‐ architecture/ 

[Burk, 2007], Seven Rules for Using EA, Burke, R., IDGA’s 5th Annual DOD Architectures Summit,   ‘07 April 11,

[Burton, 2004], Reference Architecture Overview, Burton Group, Mar 9, ’04,  rtongroup.comwww.bu  

[Burton, 2008], Burton Group’s Reference Architecture Principles: Data Management Strategies,  , Burton Group, June 24, ‘08 Phil Schacter

[Buschmann, 1996], Pattern­Oriented Software Architecture: A System of Patterns, Buschmann,  F., Meunier, R., Rohnert H., Sommerlad, P., Stal, M., John Wiley and Sons, 1996, ISBN 0‐ 471‐95869‐7 

[CERDEC, EDS, 2007], SOAF­A 1.0, Enterprise Directory Services (EDS) Reference Architecture,  U.S. Army Communications Electronics Research, Development and Engineering Center 

, 28  ept ‘07 (CERDEC), v1.4 S

[CERDEC, ESB, 2007], SOAF‐A 1.0, Enterprise Service Bus (ESB) Reference Architecture, U.S.  Army Communications Electronics Research, Development and Engineering Center 

, 28 Sept ‘07 (CERDEC), v1.4

[CERDEC, ESM, 2007], SOAF­A 1.0, Enterprise Service Management (ESM) Reference  Architecture, U.S. Army Communications Electronics Research, Development and 

nter (CERDEC), v1.4, 28 Sept ‘07 Engineering Ce

[CERDEC, SWS, 2007], SOAF­A 1.0, Security for Web Services (SWS) Reference Architecture Guide,  U.S. Army Communications Electronics Research, Development and Engineering Center 

.4, 28 Sept ‘07 (CERDEC), v1

[Cloutier, Apr 2008], Is There a Role for Patterns in Enterprise Architecture?, Cloutier, K.,   Practice, April ‘08 Architecture &

[Cloutier, May 2006], Applying Pattern Concepts to Enterprise Architecture, Cloutier, R.J., Verma,  nterprise Architecture, pgs 34‐50, May ‘06 D., Journal of E

[Cloutier, May 2008], Applying the Concept of Patterns to Systems Architecture, Cloutier, R.J.,  , Stevens Institute of Technology, DOI 10.1002/sys, May, ‘08 Verma, D.

[Cureton, 2008], Network­Centric Operations Industry Consortium (NCOIC™) Interoperability  d Patterns Overview, CFramework (NIF) an ureton, K., Feb ’08, www.ncoic.org 

[Damashek (Army), 2009], Emails and Discussions, Damashek, R., Enterprise Architect,  Architecture Operations Network and Space (AONS) HQDA (SAIS‐AOE) / Binary Group, 

, Apr‐June ‘09, <mailto:[email protected]/G‐6 > 

[DoDAF, 2008], DoD Architecture Framework Version 2.0, Volumes I, II, and III, US Department  of Defense, 24 December ‘08,  https://dars1.army.mil/MetadataWizard/CommunityDocument.do?action=getGeneral PublicDocs 

DoD Reference Architecture Description

C-2

[DoD IEA, 2009], Department of Defense Information Enterprise Architecture Version (DoD IEA),  v1.1, Department of Defense (DoD) Office of the Chief Information Officer (CIO), May  ‘09 

[Fattah, 2009], Enterprise Reference Architecture: Addressing Key Challenges Facing EA and  Enterprise­wide Adoption of SOA, Ahmed Fattah, Executive IT Architect, IBM Australia, 

nterprise Architecture Practitioners Confere22nd E nce, London, UK, April 28‐30, ‘09 

[FCW, 2007], OMB, CIO Council Issue Architecture Principles, Federal Computer Week, Aug 27,  2007, retrieved from http://fcw.com/articles/2007/08/27/omb‐cio‐council‐issue‐ architecture‐principles.aspx 

[Gamby, 2002], Developing Identity Management and Directory Services Architecture Principles,   Positions, and Templates, Gamby, R., Blum., D., Burton Group, Nov ‘0Technical 2 

[GISWG, 2009], U.S. Department of Justice’s Global Justice Reference Architecture (JRA), Global  Infrastructure/Standards Working Group (GISWG), v1.7, Mar ‘09, retrieved from 

/it.ojp.gov/default.aspx?areahttp:/ =nationalInitiatives&page=1015 

[IBM, 2006], Industry Models for Insurance, The Insurance Application Architecture (IAA), IBM,  ‘06 

[Kreger, et. al, 2009], Navigating the SOA Opens Standards Landscape Around Architectures,  White Paper edited by Heather Kreger, IBM and Jeff Estefan, NASA/Jet Propulsion 

, Published by the Open Group, June ‘09 Laboratory

[OASIS RA, 2008], Reference Architecture for Service Oriented Architecture, Version 1.0, The  Organization for the Advancement of Structured Information Standards (OASIS), Public 

ft 1, 23 April ‘08 Review Dra

6], OASIS Reference Model for Ser[OASIS RM, 200 vice Oriented Architecture 1.0, 31 May ‘06 

[Rosen, 2006], What Is a Reference Architecture?, Rosen, M., Cutter Consortium Enterprise  e Practice, 15 Nov ‘06 Architectur

[Schulman, 2004], Patterns and Bricks are an Architects’ Two Best Friends, Schulman, J., Gartner  M‐ 1‐7390, 5 January ‘04 Research Note, CO 2

[TOGAF Patterns, 2005], The Open Group Version 8.1 Enterprise Edition, Architecture Patterns,  OGAF), Chapter 28, pgs 249‐256, 2005, www.opengroup.comThe Open Group (T  

[TOGAF Principles, 2005], The Open Group Version 8.1 Enterprise Edition, Architecture  Principles, The Open Group (TOGAF), Chapter 29, pgs 257‐273, ‘05, 

.comwww.opengroup  

[TOGAF SOA RA, 2009]. Technical Specification: SOA Reference Architecture, The Open Group,  May ‘09, www.opengroup.com 

  • Introduction
    • 1.1 Purpose
    • 1.2 Background
    • 1.3 Approach
    • 1.4 Document Structure
  • 2 Reference Architecture Definition
  • 3 DoD-wide Reference Architecture Description
    • 3.1 Strategic Purpose
    • 3.2 Principles
    • 3.3 Technical Positions
    • 3.4 Patterns
  • 4 DoDAF Models Utilized in RA
  • 5 Summary
  • B.1 OASIS SOA Reference Architecture
  • B2. The Open Group SOA Reference Architecture
  • B3. Global Justice Reference Architecture (JRA)
    • B4. DoD Information Enterprise Architecture
  • B5. Service Oriented Architecture Foundation – Army, SOAF-A
  • B6. IBM Insurance Application Architecture