First Steps in the Development of a Program Organizational Architectural Framework (POAF)

Transcription

1 First Steps in the Development of a Program Organizational Architectural Framework (POAF) Jeffery L. Williams* and Jerrell T. Stracener Regular Paper Lyle School of Engineering, Systems Engineering Program, Southern Methodist University, Dallas, TX FIRST STEPS IN THE DEVELOPMENT OF A POAF Received 10 March 2011; Revised 7 January 2012; Accepted 7 January 2012, after one or more revisions Published online 11 July 2012 in Wiley Online Library (wileyonlinelibrary.com). DOI /sys ABSTRACT The target audiences for this paper are systems engineers and architects involved in the design of complex systems such as program organizations. This is the first in a series exploring how the design of program organizations developed for the purpose of designing and developing aerospace and defense systems can be optimized. The objective of this paper is to lay the groundwork for an architecture framework for the development of a program organization. The draft standard ISO/IEC is used to define the structural requirements of the architecture framework. In addition, we use the Zachman Architecture Framework TM to organize the framework and the Department of Defense Architecture Framework Version 2.0 (DoDAF 2.0) to create the model environment for the Program Organizational Architecture Framework (POAF). This approach to defining the POAF ensured that we would have the data needed to support our objective to optimize the design of the program organization and hopefully reduce the number of defects inherent in the design. We also believe that we have sufficiently defined the characteristics of a POAF to spur more research in this area Wiley Periodicals, Inc. Syst Eng 16: 45 70, 2013 Key words: system architecture; architecture framework; organization 1. INTRODUCTION 1.1. Perspective As the authors began to research the process of designing a program organization for the purpose of designing and developing large scale aerospace and defense products, it became apparent that the most mature work related to organizational design focused on the sociological aspects of the design process. One of the most notable works in this area was by R. * Author to whom all correspondence should be addressed ( Jeffrey.Williams@incose.org; jerrell@engr.smu.edu). Systems Engineering Vol. 16, No. 1, Wiley Periodicals, Inc. M. Burton and B. Obel; their text, Strategic Organizational Diagnosis and Design: The Dynamics of Fit [Burton and Obel, 2005], defines the principles for a theoretical framework of multiple contingency organizational design that captures the effect of leadership and management personality types for classes of organizations. Even though Burton s and Obel s research is important, we did not view their process as the first step in the process of developing a design of a program organization. The first step considers the organization as a system (or in this case a machine may be an appropriate metaphor) that is designed to efficiently produce products associated with the creation of a design and development (or manufacturing) process. Once the design of the organization as a system has been completed and optimized, then the methodologies characterized by Burton s and Obel s [2005] framework can be applied to address the sociological aspects of the design of the 45

2 46 WILLIAMS AND STRACENER organization. At this point the design of the organization should be near the ideal state defined by E. Rechtin: The architecture of the product, its construction process, and the organization that manages them [emphasis added] should fit each other [Rechtin, 2000, p. 159]. J.R. Galbraith has written extensively on the design of organizations. His papers on the design of innovating organizations [Galbraith, 1999] and matrix organizations [Galbraith, 1971] provide important information for defining the constraints when establishing a methodology for optimizing the design of an organization. However, Galbraith stops short of defining how to architect an organization for the purpose of designing and developing the large scale systems common to aerospace and defense. This paper focuses on the first step in the process, the design of the program organization as a system. The primary focus is to establish a framework for defining the architecture of a program organization. It stops short at defining how to optimize the design, leaving that to second paper in the series Motivation and Hypothesis Development The motivation for this paper is an outgrowth of research to determine if the design of a program organization created for the purpose of developing defense systems can be optimized; it quickly became apparent that if a design is optimized for a given set of constraints and objective functions, the result will not necessarily be a good design. This statement may appear to contradict itself; however, the authors have witnessed program organizations that when originally designed satisfied the stated objectives and constraints and then failed to achieve those objectives without violating the constraints. These designs were often driven by invalid assumptions and a faulty understanding of the dependencies of tasks associated with the development of a capability. Therefore, the authors decided to first focus on the basic design process of a program organization. This lead to the recognition that an Architecture Framework (AF) developed for the purpose of defining a program organization was needed. As this research progressed, it became apparent that a Program Organizational Architectural Framework (POAF) can be of benefit to the development of major commercial systems as well. However, because of the abundance of information in open literature on the defense acquisition process and the fact that corporations tend to treat their internal design and development lifecycle processes as proprietary information, this paper will focus on the development of program organizations for the purpose of designing defense related systems. It will be left to the readers to tailor the POAF for their internal design and development life cycle. Melvin Conway stated [Conway, 1968, pp ], organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of the organization. Frederick Brooks in his book The Mythical Man-Month [Brooks, 1995] was the first [Conway, 2010] to refer to Conway s thesis as Conway s Law. Conway goes on to add: This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time [Conway, 1968: 28 31]. Colfer and Baldwin [2010] refer to this as the Mirroring Hypothesis. The hypothesis predicts that the organizational patterns of a development project will correspond to the product breakdown structure of the system under development. In fact, the data they analyzed supported this hypothesis in 69% of their case studies. The inference that can be made from this statement is that the defects within the program organization s communication structure will also carry over to the design of the system. Ideally, what is needed is a method for designing the program organization responsible for the design of the system such that communication needlines can be identified early and incorporated in the design of the program organization. This observation leads to the authors first conjecture. First Conjecture: If a description of the architecture of the program organization responsible for the design and development of a product is created, then the communication needlines can be identified early and factored into the design of the program organization. Not only are today s Aerospace and Defense (A&D) systems becoming increasingly complicated, the defense acquisition process is a complex phase-gated process that forces A&D system developers to continually restructure their program organizations in order to respond to changing demands. Each A&D system developer needs to redefine its program organization at the start of each acquisition phase (and at key decision points within a phase) in order to accomplish the objectives of that phase in the most efficient manner possible. The need to redefine (or evolve) the program organization leads to the second conjecture. Second Conjecture: If a description of the architecture of the program organization responsible for the design and development of a product is created, then the transition points where the design of the program organization must evolve can be identified in advance. The first and second conjectures lead to the third conjecture. Third Conjecture: If a standard framework for creating the architecture descriptions of the program organizations can be established, then an enterprise can standardize its processes, methods, and tools for the development and evaluation of the resultant program architectures. Tyson Browning identified a Product Development Process [PDP] as a kind of complex system and he discussed the need for research regarding the application of AFs to the development of PDPs [Browning, 2009]. Eppinger and Salminen [2001] described how tightly coupled the product, process, and organization domains are. These observations lead to the fourth and final conjecture. Fourth Conjecture: Development of a POAF will have to be accomplished with an understanding of the interactions of the product, process and organization domains. These four conjectures lead to the hypothesis that was the motivation for the initiation of the development of the POAF.

3 FIRST STEPS IN THE DEVELOPMENT OF A POAF 47 Hypothesis: If a POAF is used to produce the architecture description of a program organization responsible for the design and development of a product, then the program organization and its communication needlines will evolve as both the product design and the acquisition environment evolve. The proof of the hypothesis stated above will be left to subsequent papers. This paper will focus strictly on defining characteristics of a POAF Overview of Method Applied In the previous section the importance of defining the lines of communication or needlines was discussed. The necessity to evolve the program organization as the A&D systems being designed and developed evolved, and the requirements of the acquisition process changed from phase to phase was also discussed. These observations resulted in the authors concluding that the program organizations designing and developing A&D systems have become as complex as the products they are producing. Therefore, the process for designing the program organization would benefit from the application of the methods, tools, and processes typically applied to the design of the A&D systems. The method of architecting the program organization will require an architecture framework that enables the definition of the environment in which the program organization exists, its inputs, outputs, and any feedback regarding its performance. Figure 1 is an adaptation of the A-B-C-D Systems Model [Haines, 1998]. The model illustrates how the program organization exists to produce an output or product, the feedback loop provides information as to how well the program organization is performing relative to the desired products and the input is where the corrective actions are developed to ensure the program organization is on track to producing the desired products. This program organizational system exists within a larger enterprise environment that may include a prime contractor, corporate teammates, subcontractors, and, of course, the customer. While this approach to viewing the organization is useful, the organization will need to be decomposed into its parts and their interactions understood as well. Thus, the architect needs a method that brings together the systems thinking commonly associated with understanding complex systems and reductionist thinking associated with traditional engineering. Prior to diving into the description of the POAF it is important to discuss two topics. First, it will be highly unlikely that the stakeholders identified in this paper will have the required skill set necessary to develop the architecture of a program organization. That task will fall on the shoulders of an architectural team that coordinates with the stakeholders to create the architecture. No further discussion of the architectural team will take place in this paper. The team is assumed to be present and responsible for the coordination and development of the architecture. Second is the definition of an AF. The current draft of ISO/IEC [ISO/IEEE, 2011, p. 10] defines a number of important characteristics about an AF and the POAF complies with that definition. The following summary of the definition contained in this standard is important to substantiating the compliance of the POAF with the standard. An AF is the generalized set of guidelines by which an architectural description of a specific instance of a system type is defined. Therefore, the POAF establishes the architectural guidelines for a class of systems referred to as Program Organizations. The Architectural Description (AD) of the program organization developed by the joint team of the X and Y companies for the program Zulu is a specific instantiation of the POAF. Figure 2 depicts the relationship between an AF and an AD. As previously stated, ISO/IEC [ISO/IEEE, 2011] defines a number of important characteristics about an AF. The first characteristic is that an AF identifies its stakeholders and their concerns. The second characteristic is that an AF will have at least one stakeholder and each stakeholder will have at least one concern. The third characteristic is that an AF will have at least one viewpoint which will frame one or more concerns for a stakeholder. Each viewpoint will have at least one model kind which will provide a description of some aspect of the system of interest and simultaneously address some aspect of the concerns associated with the corresponding viewpoint. The fourth characteristic is that an AF will have a set of correspondence rules. The correspondence rules maintain consistencies between and among the sets of models contained in the AF s viewpoints. Figure 1. System view of program organization. Figure 2. Example of an Architecture Framework and an Architecture Description relationship [OMG, 2010].

4 48 WILLIAMS AND STRACENER It should be evident that the AF defined by Zachman [Zachman, 1987] satisfies each of these four characteristics. Zachman defines the stakeholders: Planner, Owner, Designer, Builder, and Subcontractor. Each of the stakeholders has specific concerns associated with the system of interest and each stakeholder establishes a unique viewpoint. It is not necessary that a stakeholder and a viewpoint map one-to-one; however, in the case of the Zachman Architecture Framework (ZAF) they do. The six interrogatives ( What?, How?, Where?, When?, Who?, and Why? ) posed by Zachman provide an opportunity to define a description of a specific aspect of the system of interest while simultaneously addressing some aspect of the concerns associated with the viewpoint. Thus, the response to each of the interrogatives can be considered a model or collection of models. Figure 5 in ISO/IEC [ISO/IEEE, 2011] is redrawn as Figure 3 below to show how the ZAF complies with the standard. D. Emery and R. Hilliard explained how the ZAF complied with the ISO/IEC in their paper Every Architecture Description Needs a Framework: Expressing Architecture Frameworks Using ISO/IEC [Emery and Hilliard, 2009]. This recognition of how the ZAF addresses each of the characteristics defined by ISO/IEC [ISO/IEEE, 2011] solidified the authors opinion that the ZAF provided an ideal structure upon which to develop the POAF. The authors also noted that a program organization has many similar characteristics shared by many complex defense systems such as a Task Force. Both have a command structure and a defined set of communications needlines. The stakeholders are hierarchically based and each has specific concerns; however, the concerns of a specific stakeholder have a dependency relationship with the stakeholders above and below. These relationships are governed by specific rules (or correspondence rules). Therefore, AFs used for the development of defense systems should also be useful in the development of a POAF. The defense-related AFs considered were limited to the U.S. Department of Defense Architecture Framework (Do- DAF) versions 1.5 and 2.0 and the U.K. Ministry of Defense Architecture Framework (MODAF) version 1.2. These frameworks were chosen because other defense related AFs use these three AFs as their basis. For example, the NATO Architecture Framework (NAF) is based on both the DoDAF and MODAF. The resultant comparison of the three AFs is shown in Table I. The obvious result was that both DoDAF 2.0 and MODAF 1.2 were both equally suited for supporting the development of a POAF. With no clear superior AF to use to support the development of a POAF, the authors chose the DoDAF 2.0 based purely on their need to maintain a working knowledge of this AF. With the selection of the ZAF and the DoDAF 2.0 as the two primary contributing AFs for the development of the POAF; the resultant structure was also defined. Table II illustrates the resultant structure of the POAF. As with any system architecture, the DoDAF models require some degree of tailoring in order to define an architecture that satisfies a specific set of objectives. For the POAF, the process starts with the definition of each stakeholder. Next, each stakeholder frames their concerns in terms of the decisions they are responsible for and the information requirements associated with each interrogative. Figure 3. Zachman Architecture Framework TM complies with ISO/IEC [ISO/IEC, 2011; OMG, 2010].

5 FIRST STEPS IN THE DEVELOPMENT OF A POAF 49 Table I. Evaluation of Defense-Related AFs for Use in the Development of a POAF Next, those DoDAF models that can be tailored to address the information requirements associated with each interrogative are identified. Note that information from multiple Do- DAF models may be required to define the artifacts necessary to fully address a stakeholder s information needs for that interrogative. The process for defining the elements of the POAF is defined as a five-step process shown in Figure 4. The process is a tailoring of the DoDAF 2.0 tailoring process defined in Volume 1 of the DoDAF 2.0 [DoD, 2009]. The DoDAF 2.0 process defines a six-step process for preparing a DoDAF presentation to decision makers. Those steps were tailored to produce the five steps of Figure The Great System Architecture Fallacy Prior to proceeding with the description of how the POAF was developed and its description, the Great System Architecture Fallacy must be addressed. The fallacy is simply the belief that the development of the system architecture is just another box to be checked, another task to be completed because it was directed. Just as Figure 1 depicts a model of the program organization, it can also depict an AD of the program organization. Optimization of the architecture for a program organization is a continuous process that must evaluate performance and changes to environmental variables and adapt the architecture. Figure 4. POAF five-step process. The authors emphasize that an AD should be viewed as a living and adapting architecture, as opposed to a one-time data item. As the system is developed there is a learning process that results in an evolution of the architecture and as the system is deployed the new applications reveal new operational needs. These too result in an evolution of the architecture. In order to reap the maximum benefits of an AD of a program organization, its architecture must also be viewed as a living and evolving entity as opposed to a static model that loses its relevance with time. 2. IDENTIFICATION OF THE STEPS FOR TAILORING DoDAF 2.0 FOR DEVELOPMENT OF A POAF The five steps shown in Figure 4 define the structure for the following sections. Each section focuses on addressing the objective of each step in order to define a POAF that can be used to define the architecture of a program organization. Table II. Resultant Structure of the POAF When Using Both the ZAF and the DoDAF 2.0

6 50 WILLIAMS AND STRACENER 2.1. Step 1: Define Stakeholders In order to have a generic model that can be tailored to suit many different applications, it was decided that if the stakeholders could be mapped to the five stakeholder types of the ZAF, then defining the characteristics of the stakeholders would be much easier. Figure 5 illustrates the relationships between the five ZAF stakeholder groups as well as how they were defined. The first stakeholder that Zachman [1987] identifies is the Planner. The Planner is concerned with the scope of the program and its impact on the bigger enterprise. For the development of the POAF the members of what will be Figure 5. POAF stakeholders and their relationships [OMG, 2010].

7 FIRST STEPS IN THE DEVELOPMENT OF A POAF 51 referred to as the Planner set are program managers and executive leadership. The second stakeholder is the Owner. The Owner is concerned with the definition of the organization responsible for the execution of the program. The members of what will be referred to as the Owner set are the program manager and the leadership team (e.g., chief engineer, logistics lead, manufacturing lead, etc.). Therefore, the program manager of the program whose organization is being architected is a member of two stakeholder sets the Planner and Owner. This is because decisions made regarding the development of the program organization may impact other programs and possibly larger enterprise objectives. As a result, the program manager must be aware of these impacts and how to balance those with the objectives of the program. The third stakeholder is the Designer. The Designer is concerned with the day to day operations of the program and ensuring satisfaction of the stated objectives of the program. The members of what will be referred to as the Designer set are the program manager s leadership team. The members of the program manager s leadership team are joint members of both the Owner and Designer stakeholder sets. They participate in both formulating the decisions made in the Owner stakeholder set and then determining how those decisions impact the organizational elements each member of the program manager s leadership team is responsible for. Therefore, each decision made by the Owner will result in at least one decision having to be made by the Designer in order to carry out the decision. The fourth stakeholder is the Builder. The Builder is concerned with the production of products within the time, schedule, and cost constraints imposed. The members of what will be referred to as the Builder set are the process, functional, and product team leads defined by the architecture of the program s organization. The fifth and final stakeholder is the Subcontractor. The Subcontractor is concerned with the performance of the tasks associated with the development of the products for which the Builder set is responsible. The Subcontractor set consists of the teams and individual contributors that make up the teams directed by the Builder set. Missing from this discussion is the integration of two or more corporations to form a program organization that are responsible for execution of the program. The issues that will have to be addressed include where the highest level of integration will occur. Will it be at the Planner or Owner level? For some subcontractors (versus teammates) the integration will occur at the Designer level, whereas some suppliers are managed by the Builder. Steps 2 and 3 may be of help in determining how the integration of multiple corporations can be integrated into the Program Organization Step 2: Document the Decisions Made by the Stakeholders The sequence diagram shown in Figure 6 is one perspective regarding the interaction of the stakeholders relative to designing the organization for execution. In this diagram, the primary decision makers regarding the development of the organizational design are the Planner, Owner, and Designer. The Builder may provide input upon request; however, both the Builder and the Subcontractor are largely responsible for execution. A review of Zachman s original paper [Zachman, 1987] indicates that both the Builder and Subcontractor would be at the execution level or out-of-context from an organizational design perspective. Therefore, the major contributors to the design of the organization would be the Planner, Owner, and Designer and the decisions made by these stakeholders are the defining decisions regarding the organizational design. The decisions made by the stakeholders relate to their concerns and how the available information addresses the six interrogatives: What?, How?, Where?, When?, Who?, and Why?. In Zachman s Framework the interrogative What? is synonymous with data, How? with function, Where? with network, When? with time, Who? with people, and Why? with motivation. Using these relationships, it is possible to identify the types of data that each of the stakeholders will need in order to address each interrogative. Zachman also wrote a short definition of the cell definitions [Zachman, 2002]. These cell definitions are focused on the development of architectures for computing services; however, they provide significant insight to the types of questions to be asked for a POAF. Table III collapses approximately 3 pages of information into a single table by focusing on the core information needed to address each concern Step 3: Define Information Requirements for Decisions The following breaks down each of the six interrogatives in terms of the information required by each principal decision maker. Although the following sections are organized in a top-down hierarchical order, the compilation of the data to support the decision process seldom occurs in a strict linear process. Some of the process will be initiated at the level of the Planner, and others will be initiated by the Owner. The Designer will typically provide supporting data to the Planner and Owner and develop data at the Designer level as required to provide that support Information Required by the Planner to Make Decisions The Planner is concerned with the scope of the program and its impact on the bigger enterprise. Therefore, the information requirements will be focused on satisfying strategic goals and objectives. Table IV compresses the information needs into a simple table Information Required by the Owner To Make Decisions The Owner is concerned with the definition of organization responsible for the execution of the program. Table V identifies the information the Owner will need in order to define a program architecture that identifies how the participating enterprises will work together as an efficient team. In Table V we introduce for the first time the term WBS (Work Breakdown Structure). The WBS is the tool used to

8 52 WILLIAMS AND STRACENER Figure 6. Simplified stakeholder sequence diagram [OMG, 2010]. define discrete work elements to be performed by specific teams. The WBS may be hierarchically decomposed until an end node is reached. For the Owner s needs 3 levels of decomposition (tier 3) is often the maximum depth required. Each of the WBS tasks also corresponds to a task (one-to-one) in the Integrated Master Schedule (IMS); therefore, a tier 3 IMS corresponds with a Level 3 WBS.

9 FIRST STEPS IN THE DEVELOPMENT OF A POAF 53 Table III. Stakeholder Concerns Correlated with the Information Needs for Each Interrogative Information Required by the Designer To Make Decisions The Designer is concerned with the day to day operations of the program enterprise and ensuring satisfaction of the stated objectives of the program. Table VI defines the information for the Designer to translate the primarily operational descriptions of the Planner and Owner into a system capable of producing the products required. Because the Designer is concerned with the day to day operations, the level of decomposition for the WBS and the IMS will have a maximum level of decomposition to the 5th level (tier 5). Table IV. Planner Information Needs

10 54 WILLIAMS AND STRACENER Table V. Owner Information Needs Table VI. Designer Information Needs

11 FIRST STEPS IN THE DEVELOPMENT OF A POAF 55 Table VII. Mapping of DoDAF 2.0 Models to the Planner s Viewpoint 2.4. Step 4: Tailor DoDAF Models To Support Decisions The purpose of the following sections is to examine the DoDAF 2.0 model elements [DoD, 2009] and determine which would be useful for assimilating the information necessary to both support the decision process and serve as the foundation for execution. Therefore, the information needs of each stakeholder are examined and the corresponding Do- DAF 2.0 model elements are mapped to each interrogative. The description of each DoDAF 2.0 model is largely an adaptation of the information available in Volume 2 [DoD, 2009] of the DoDAF 2.0 for the POAF. The mapping produces the definition of each of the three viewpoints for the POAF: the Planner, Owner, and Designer Viewpoints DoDAF Models That Support the Planner s Information Needs Table VII identifies the mapping of the DoDAF 2.0 models to each interrogative for the Planner s viewpoint. The following discussion defines how the DoDAF 2.0 model is tailored to support the collection of the information for the Planner s viewpoint. In order to satisfy the interrogative What? for the Planner, a model that enables the creation of the list of things important to the enterprise is needed. That model is the DIV-1, Conceptual Data Model. Figure 7 illustrates how the DIV-1 can be tailored to address those things important to the enterprise: in this example, the selling of products; providing of services; obtaining a market share; and balancing risks versus opportunity costs. The interrogative How? requires that information associated with the functions (or activities) to be performed as part of the program to be defined. The OV-5a, Operational Activity Decomposition Tree, is used to define the capabilities and activities (operational activities) organized in a hierarchical structure. For the Planner, the OV-5a will provide the list of functions performed by the enterprise. It will also identify those functions either missing from the enterprise or inadequate for pursuit and execution of the opportunity. The result would simply be a correlation of capabilities required to in house capabilities as shown in Figure 8. The result can be shown as graphically or tabular; we have chosen to show the results graphically. To get to the results shown in Figure 8, the capabilities within the organization have to be mapped against the required capabilities. In this example, the required capability RC5 does not map to any of the organizational capabilities. Thus, a deficiency has been identified that must be addressed. Therefore, the OV-5a for How? and the OV-2 for Where? are closely coupled. For the Planner the interrogative Where? is concerned with the correlation of organizations with required capabilities necessary to satisfy the program s requirements. The organizations that make up this correlation matrix may or may not be a part of the Planner s enterprise. The OV-2, Operational Resource Flow Description, will initially show that correlation. As the OV-2 evolves under the guidance of the Owner and the Designer, it will associate the organizations with activities and the needlines that identify the flow of resources. The two DoDAF models CV-3 (Capability Phasing) and PV-1 (Project Portfolio Relationships) are required to address the interrogative When?. The interrogative When? is associated with the major events and milestones associated with the program. Most importantly, it is associated with the phasing of the capabilities required by the program in order to execute. Therefore, the CV-3, Capability Phasing model, is ideal for defining the planned achievement of capabilities at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions In order to manage the phasing of the capabilities along with the satisfaction of the program events and milestones, the project is divided into portfolios. Portfolios may be executed in parallel or serially. The DoDAF 2.0 model PV-1, Project Portfolio Relationships, describes the dependency relationships between the organizations and projects and the organizational structures needed to manage a portfolio of projects. When the CV-3 and PV-1 are combined into a single model, the result will look similar to Figure 9. In this example, the purpose of Project B is to develop the missing capability C6 which is required by Project C. The interrogative Who? is concerned with the identification of those organizations required to perform the work associated with the execution of the program. The DoDAF model OV-4, Organizational Relationships Chart, identifies the organizational context, role, or other relationships among organizations. For the Planner the OV-4 is role-based. Figure 10 shows the role of each organization resource.

12 56 WILLIAMS AND STRACENER Figure 7. Example DIV-1 result for the Planner [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.] Figure 8. Example OV-5a result for the Planner [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

13 FIRST STEPS IN THE DEVELOPMENT OF A POAF 57 Figure 9. Combined CV-3 and PV-1 [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.] Figure 10. Example OV-4 showing relationships for the participating organizations [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

14 58 WILLIAMS AND STRACENER Figure 11. Combined AV-1, CV-1, and OV-1 used by the Planner to address Why? [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.] For the Planner, three DoDAF models are required to address the interrogative Why?. First the OV-1, High- Level Operational Concept Graphic, provides a high-level graphical and textual description of the organization that will ultimately execute the program. Next the CV-1, Vision, provides the context for the transformational activities required by the enterprise to achieve the ultimate capability depicted in the OV-1. Finally, the AV-1, Overview and Summary Information, frames the context for the Architectural Description of the program s organization. It includes assumptions, constraints, and limitations that may affect high-level decisions. In addition, the AV-1 defines the process for developing the POAF. It establishes which DoDAF model elements will be created and how the collective information will be presented. Both the AV-1 and CV-1 are narrative in nature; therefore, Figure 11 is representative of the Planner s response to Why? DoDAF Models That Support the Owner s Information Needs Table VIII identifies the mapping of the DoDAF 2.0 models to each interrogative for the Owner s viewpoint. The following discussion defines how the DoDAF 2.0 model is tailored to support the collection of the information needs for the Owner s viewpoint. In order to address the interrogative What?, the Owner requires information relevant to the business entities that will be involved in the capture and execution of the business opportunity. Two DoDAF models are useful for organizing that data. The first is the DIV-2, Logical Data Model. The DIV-2 is used for documenting the data requirements and structural business process (activity) rules. Figure 12 is a simple example of such a data model. The second model is the AV-2, Integrated Dictionary. The AV-2 establishes an architectural data repository with defini-

15 FIRST STEPS IN THE DEVELOPMENT OF A POAF 59 Table VIII. Mapping of the DoDAF 2.0 Models to the Owner s Viewpoint Figure 12. Example DIV-2, Logical Data Model for the Owner [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

16 60 WILLIAMS AND STRACENER tions of all terms used throughout the architectural data and presentations. Proper use of the AV-2 enables the creation of an integrated set of architectural descriptions for the enterprise. One example of such an integration would be to create an architecture of the enterprise as a functional organization and then to create architectures for each program. The program architectures interface with the functional organizations for resources and support. The functional organization resolves conflicting demands and ensures each program has the resources required. Resources in this context may be personnel, products, or information. For personnel resources, the functional organization would assign those resources as program assets based on its rules governing such assignments. Those resource needs not satisfying the assignment rules would continue depend upon the functional organization to execute the assignments required of those resources. There are many variations of this example; however, the objective of the example is that once a set of architectures are established and interaction process for programs and the enterprise is defined, then it becomes possible to reuse elements of program architectures to create architectures for new programs. For the Planner, the DoDAF model required to address the interrogative How? was the OV-5a, Operational Activity Decomposition Tree. For the Owner the activity descriptions of the OV-5a are translated into a behavior model with rules and state transitions. Three DoDAF models are required to provide that information to the Owner. They are the OV-5b, Operational Activity Model, the OV-6a, Operational Rules Model, and the OV-6b, State Transition Description. The OV-5b provides the context of capabilities and activities (operational activities) and their relationships among activities, inputs, and outputs. The OV-5b defines the process flow associated with each activity and the associated inputs and outputs. The OV-6a defines the business rules that constrain the execution of the program s activities. The rules define what function or activity is performed for the given conditions. The OV-6b defines the events that will result in a state change for the program organization. While the program organization is expected to experience a limited evolution as a result of performance assessments on the feedback loop of Figure 1; the state transitions defined by the OV-6b can result in radical changes in the program organization. How the three models interact is best shown using Figure 13. In Figure 13 the change of states both in a major acquisition phase and within a subphase are illustrated. The rules governing the transition of one phase (Protoype Detailed Design) to another (Prototype Demonstration) are controlled by the rules associated with the Prototype Critical Design Review (PCDR). The activities that are to be performed in the Prototype Demonstration activity are illustrated. The integration of these models provides the information required by the Owner to address How?. For both the Planner and the Owner, the DoDAF model required to address Where? is the OV-2, Operational Resource Flow Description. For the Planner, the OV-2 identified the organizations and their correlation to the required capabilities. For the Owner, any trade studies needed to select between organizations with the same capabilities has been completed and the correlation to the top level activities has been accomplished. The information used to address Where? provides necessary data to address When?. Five DoDAF models are required by the Planner in order to address When?. The aggregate information from these five DoDAF models provides the necessary data to create the network of activities that will result in the integrated master schedule. The models are the OV-6c, Event-Trace Description, the CV-2, Capability Taxonomy, the CV-3, Capability Phasing, the CV-4, Capability Dependencies, and the PV-2, Project Timelines. When the results of these five models are combined with the results of the OV-2 developed in response to the interrogative Where?, the end item artifact is an integrated schedule. The schedule shown in Figure 14 is referred to as a tier 3 schedule because it shows detail to the 3rd level of decomposition. The tailoring of the five DoDAF models required to address When? are as follows. The OV-6c traces actions in a scenario or sequence of events. It provides a time-ordered examination of the resource flows as a result of a particular scenario. The CV-2 provides a hierarchy of capabilities which specifies all the capabilities that are referenced throughout one or more Architectural Descriptions. The capabilities are represented in the context of a timeline thus, showing the required capabilities for current and future activities. The CV-3 is a shared element of the architecture needed to support decision making for both the Planner and the Owner. However, it is the more detailed planning that takes place with the Owner that is rolled up into the presentation of the CV-3 information necessary to support decisions by the Planner. The Owner uses the CV-3 to define the planned achievement of capabilities at different points in time or during specific periods of time. The CV-3 shows the capability phasing in terms of the activities, conditions, desired effects, rules complied with, resource consumption and production, and measures, without regard to the performer and location solutions. The CV-4 describes the dependencies between planned capabilities and defines logical groupings of capabilities. In particular, the dependencies and groupings establish specific interactions between projects as the enterprise endeavors to achieve the overall capability. The PV-2 provides a timeline perspective for programs or projects, along with the key milestones and interdependencies. The Owner requires two DoDAF models to address Who?. The first is the OV-3, Operational Resource Flow Matrix. The OV-3 address the resource flows between organizations during the execution of activities. Thus, those resource transfers necessary to support operations are identified. The second DoDAF model required by the Owner is the OV-4, Organizational Relationships Chart. The OV-4 is also a shared element of the architecture needed to support decision making for both the Planner and the Owner. The OV-4 shows organizational structures and interactions. For the Planner the OV-4 is primarily role-based and depicts the organizational composition. For the Owner the OV-4 is an actual organization of the program at particular

17 FIRST STEPS IN THE DEVELOPMENT OF A POAF 61 Figure 13. Combined OV-5b, OV-6a, and OV-6b [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.] points in time. The actual organization identifies the resource types required for that particular project or phase of the program. Figure 15 illustrates the required detail added to the OV-4. The Owner requires three DoDAF models to address Why?. Two of the models are shared with the Planner, the AV-1, Overview and Summary Information, and the CV-1, Vision. The Owner develops the AV-1 and shares that with the Planner as a part of the presentation by the Owner to the Planner. The Owner also develops the details of the CV-1. Those details include the blueprint for transformational initiatives, the identification of goals, desired outcomes, and measurable benefits associated with those initiatives.

18 62 WILLIAMS AND STRACENER Figure 14. Example Tier 3 schedule that integrates the results for the Owner s interrogatives Where? and When?. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.] Figure 15. Example Ov-4 for the Owner [OMG, 2010]. [Color figure can be viewed in the online issue, which is available at wileyonlinelibrary.com.]

19 FIRST STEPS IN THE DEVELOPMENT OF A POAF 63 Table IX. Mapping of the DoDAF 2.0 Models to the Designer s Viewpoint The Owner also requires the PV-3, Project to Capability Mapping, DoDAF model to address Why?. The PV-3 is the mapping of required capabilities and capability initiatives to project portfolios. The portfolios are mapped to particular time frames and their interdependencies are defined DoDAF Models That Support the Designer s Information Needs Table IX identifies the mapping of the DoDAF 2.0 models to each interrogative for the Designer s viewpoint. The following discussion defines how the DoDAF 2.0 model is tailored to support the collection of the information needs for the Designer s viewpoint. The Planner and Owner s perspectives in terms of DoDAF models were primarily from an operational perspective. They see the program architecture from larger perspective that defines its place in the bigger enterprise and its interaction with external enterprises. The Designer sees the program in terms of its daily execution. Therefore, the Designer is responsible for the translation of the operational descriptions of the program organization into an executable design and then executing to that design. Therefore, for the Designer the separation of architecture and design tend to blur. In order for the Designer to accomplish the task of developing an executable design, the Designer decomposes the organization inherited from the Planner and Owner into execution teams. These teams may consist of heterogeneous or homogenous sets of resources provided by the participating organizations. Depending on the complexity of the tasks to be performed, the teams may be further decomposed into subteams and those subteams may be decomposed. The dynamics of these teams ultimately define the characteristics of the program organization. In order to describe how the Designer accomplishes the task of defining the teams, the DoDAF 2.0 models used to define the content of each interrogative are examined. Particular attention is focused on the relationships of the models as opposed to creating specific examples of the models. The first interrogative examined is the interrogative What?. The Designer requires three DoDAF 2.0 models: the DIV-3, Physical Data Model, the SV-1, Systems Interface Description, and the SV-3, Systems-Systems Matrix. The DIV-3 defines the structure of the data that will be developed and provided to either customers or between organizations. The SV-1 shows the resource structure by identifying the primary capabilities required to perform each activity and their interactions. For the POAF, the SV-1 is the executable analogue of the OV-2 Operational Resource Flow Description. The SV-3 shows the relationships among the participating organizations (internal and external). It provides the summary of the SV-1 interfaces between the organizations. Figure 16 shows the relationships with these three models and other models in the Designer s viewpoint. Relationship 1 establishes the data requirements. Relationship 2 establishes the data to information flow relationships. Relationship 3 establishes the standards for future data definitions. Relationship 4 establishes data resource flow requirements. Relationship 5 defines the data artifacts necessary to transition from one program state to another. Relationship 6 ensures that data in use are defined in accordance with current standards. Relationship 7 identifies the resource interaction at the program organizational interfaces. Relationship 8 describes the resources required. Relationship 9 established the top level

20 64 WILLIAMS AND STRACENER shown in Figure 17 is Stakeholder:Interrogative:Model. The stakeholder identifiers are P for Planner, O for Owner, and D for Designer. The interrogative and model identifiers are evident. The relationships between each of the models are as follows: Figure 16. Relationships of Designer s DoDAF 2.0 models for the interrogative What? with the other interrogatives. requirements. Relationship 10 defines how the resources are exchanged. For the Designer, addressing How? is the most difficult and complex of the interrogatives to address. The Designer s response to this interrogative will ultimately define the details associated with execution model of the program and its organization. The seven DoDAF 2.0 models shown in Table IX are required to obtain the necessary perspective information to formulate the Designer s response to How?. The relationships between those models and other models in the POAF are shown in Figure 17. The SV-4, Systems Functional Description is at the center because it provides the information necessary to integrate all of the models. The naming convention for each of the models a. Translates the activity tree of the OV-5a into activity diagrams showing flow and relationships b. Translates the activity diagrams of the OV-5b into diagrams defining functions performed by the program organization c. Defines the resource flow between functions d. Creates the mapping of system functions to performers e. Creates the mapping of operational capabilities to performers f. Specifies the characteristics of the resource flow between the organizational teams g. Identifies the standards to be complied with during execution of the functions defined in the SV-4 h. Identifies the sequencing of functions defined in the SV-4 that will result in a state change for the program organization i. Identifies the standards to be complied with regarding the flow of resources between teams j. Defines the performance metrics associated with the required flow of resources k. Describes the dynamic behavior of resources during the transition between states. In order for the Designer to address Where?, the Do- DAF 2.0 model SV-2, Systems Resource Flow Description, is used. For each of the organizations defined in the SV-4, Systems Functionality Description, a description of Resource Flows exchanged between organizations is developed. A precise description of the interface between the organizations is developed that establishes timing and content. Figure 17. Relationships of the DoDAF 2.0 models associated with the Designer s response to the interrogative How? [OMG, 2010].

21 FIRST STEPS IN THE DEVELOPMENT OF A POAF 65 Figure 18. Relationships of the DoDAF 2.0 models associated with the Designer s response to the interrogative When? [OMG, 2010]. Figure 19. Relationships of the DoDAF 2.0 models associated with the Designer s response to the interrogative Who? [OMG, 2010]. The four DoDAF 2.0 models shown in Table IX are used by the Designer to address the interrogative When?. The interrelationships of the four DoDAF 2.0 models and important defining relationships with models outside the domain of the current interrogative are shown in Figure 18. Two DoDAF models are used by the Designer to address the interrogative Who?. The first is the OV-2, Operational Resource Flow Description. The OV-2 is the only DoDAF model used by each stakeholder set, i.e., Planner, Owner, and Designer. The Designer uses the information in the OV-2 to develop the detailed resource flows at the system level. That information feeds the second DoDAF model, the SV-6, System Resource Flow Matrix, as shown in Figure 19. The SV-6 is shared with both interrogatives How? and Who?. Therefore, Figure 19 reuses the interfaces defined in Figure 17. As a result the definitions of relationships f, g, i, and j remain unchanged. The Designer uses three DoDAF models to address the interrogative Why?. The first is the SV-10a, Systems Rules Model. The SV-10a identifies constraints that are imposed on the functionality of the Program Organization due to some Figure 20. Relationships of the DoDAF 2.0 models associated with the Designer s response to the interrogative Why? [OMG, 2010].

22 66 WILLIAMS AND STRACENER aspect of the design or implementation of the organization. As shown in Figure 20, these rules constrain the organization to organization interfaces defined in the SV-3 and establish the rules governing the state transitions defined in the SV-10c. The second DoDAF model is the CV-6, Capability to Operational Activities Mapping. The CV-6 describes the mapping between the capabilities required and the activities that enable those capabilities. As shown in Figure 20, the CV-1 establishes the baseline of required capabilities; however, the CV-6 then maps those capabilities to (a) the taxonomies defined by the CV-2 and (b) the activities defined in OV-5b that will enable those capabilities. The final DoDAF model used by the Designer to address the interrogative Why? is the StdV-2, Standards Forecast. The StdV-2 provides the description of emerging standards and potential impact on the current program organization design, within a set of time frames. The StdV-2 contains expected changes in technology related standards, operational standards, or business standards and conventions, which are documented in the StdV-1 model. Figure 20 shows that the timing of the implementation of the standards is defined by the SV-8 System Evolution Description Step 5: Align Information Requirements and Develop Artifacts In Section 2.2 we established the concerns of each stakeholder set with respect to the six interrogatives. In Section 2.3 we established the information needs of the stakeholder sets to address those concerns. In Section 2.4 we established which Table X. Identification of Artifacts That Support the Planner s (Executive Leadership s) Information Needs

23 FIRST STEPS IN THE DEVELOPMENT OF A POAF 67 DoDAF 2.0 models can be tailored to provide the information required by each stakeholder. However, the DoDAF 2.0 models are often too abstract or too information dense to be used by the stakeholders. The architects supporting the stakeholders must translate those products into a set of usable artifacts. Table X establishes the artifacts derived from the DoDAF 2.0 models that will provide the information needed to address the concerns of the Planner stakeholder set. Similarly Tables XI and XII establish the artifacts required for both the Owner and Designer sets. The artifacts identified in Tables X, XI, and XII provide information that leaders of enterprises have desired; however, they were often unable to obtain. The traditional methods of program planning, competitive assessment, and packaging of information was not capable of providing all of the information available in the artifacts. In addition, the creation of Program Organization Architectural Descriptions (POADs) that comply with the POAF enables the development of standardized models and artifact characteristics. These will ultimately speed up the process of developing a POAD. This is especially true if the enterprise and its programs maintain their architectures and ultimately identify reusable architectural elements. 3. CONCLUSIONS AND FUTURE WORK 3.1. Conclusions The method for developing a Program Organizational Architectural Framework (POAF) is driven by ongoing research to establish a method for optimizing the design of Program Organizations. Early research and anecdotal data from discussions with multiple personnel associated with several developmental programs revealed that the program organizations are not designed from a systems perspective. Therefore, if the organization was to be optimized, it first had to be designed from a systems perspective, applying the same tools, methods, and processes applied to the design of the defense systems. The method defined in this paper establishes a systems approach to developing a POAF that accounts for the complex nature of the organization. The transformation points are points of directed evolution of the organization in order to ensure it is focused on satisfying its changing objectives. Tables X, XI, and XII not only define the final set of artifacts for the primary stakeholders, they also provides a Zachman-styled description of the resultant architecture framework. Table XI. Identification of Artifacts That Support the Owner s (Program Manager s) Information Needs

24 68 WILLIAMS AND STRACENER Table XII. Identification of Artifacts That Support the Designer s (Program Leadership Team s) Information Needs 3.2. Future Work There are two research activities planned as a follow on to this effort. The first is to establish the optimization method for the resultant program organization. The second is to apply the POAF and optimization to an ongoing program in order to validate the methodology and hopefully prove the hypothesis. 4. DEFINITION OF TERMS Table XIII defines the terms used in this paper.

25 FIRST STEPS IN THE DEVELOPMENT OF A POAF 69 Table XIII. Definition of Terms REFERENCES F.P. Brooks, The mythical man-month: Essays on software engineering, Addison-Wesley, Reading, MA, T.R. Browning, The many views of a process: Toward a process architecture framework for product development processes, Syst Eng 12(1) (2009), R.M. Burton and B. Obel, Strategic organizational diagnosis and design: The dynamics of fit, Springer, New York, L. Colfer and C.Y. Baldwin, The mirroring hypothesis: Theory, evidence and exceptions, No , Harvard Business School, Cambridge, MA, 2010, p. 39. M.E. Conway, How do committees invent?, Datamation, F.D. Thompson, M.E. Conway, Conway s law, M.E. Conway (Editor), DoD, Dod architecture framework version 2.0, Vol. 1. Introduction, overview, and concepts: Manager s guide and Vol. 2. Architeture data models: Architect s guide, Department of Defense, Washington, DC, D. Emery and R. Hilliard, Every architecture description needs a framework: Expressing architecture frameworks using ISO/IEC 42010, Software Architecture 2009 & Eur Conf Software Architecture, WICSA/ECSA 2009, Joint Working IEEE/IFIP Conf, IEEE, 2009, pp S.D. Eppinger and V. Salminnen, Patterns of product development interactions, Int Conf Eng Des (ICED), Glasgow, J.R. Galbraith, Designing the innovating organization, CEO Publication G99-7 (366), Center for Effective Organizations, Marshall School of Business, University of Southern California, Los Angeles, CA, J.R. Galbraith, Matrix organization designs how to combine functional and project forms, Bus Horizons 14(1) (February 1971), S.G. Haines, The manager s pocket guide to systems thinking & learning, HRD Press, Amherst, MA, ISO/IEEE, ISO/IEC FDIS 42010, Systems and software engineering architecture description, International Organization for Standardization, Geneva, Switzerland, Object Management Group (OMG), OMG Systems Modeling Language (OMG SysML TM ), Version 1.2, OMG Document Number: formal/ , Needham, MA, E. Rechtin, Systems architecting of organizations: Why eagles can t swim, CRC Press, Boca Raton, FL, J.A. Zachman, A framework for information systems architecture, IBM Syst J 26(3) (1987), J.A. Zachman, The framework for enterprise architecture: Cell definitions, Zachman Institute for Framework Advancement, 2002.

26 70 WILLIAMS AND STRACENER Jeff Williams has over 35 years of systems engineering experience. From 1975 through 1984 he conducted weapon systems and mission analysis for the US Air Force, Navy, and Marine Corps. During the SDI days of the 1980s he participated in a number of special projects developing simulations, conducting analysis, and developing the requirements for ballistic missile defense command and control systems. Mr. Williams was the first system architect for the Theater High Altitude Air Defense (THAAD) Battle Management Command, Control and Communication (BMC3) system. During the 1990s Mr. Williams led several concept development studies to create new air defense command and control systems both in the United States and abroad. He also functioned as the Principal systems engineer for the fielding of the Common Hardware and Software (CHS) equipment developed by Litton Data Systems for the US Army. Mr. Williams moved to Texas in December of 1999 and has been working as a systems engineer for L-3 Communications Link Simulation & Training, EFW, Bell Helicopter, and the Train Dynamic Systems Division of New York Air Brake. Since 2003, Mr. Williams has served the North Texas Chapter of INCOSE as Treasurer, Vice President, President, Board Member, and Vice President of Technical Development. He is currently a PhD Candidate in SMU s Systems Engineering Program. Jeff Williams earned both his bachelor and master s degree in mathematics from the University of West Florida. Jerrell T. Stracener is Associate Professor and founding Director of the Southern Methodist University (SMU) Systems Engineering Program. He teaches graduate-level courses in systems analysis methods and applications, and directs and conducts systems engineering research. He is the SMU Lead Senior Researcher in the DoD-funded Systems Engineering Research Center (SERC). Prior to joining SMU full-time in January 2000, Dr. Stracener was employed by LTV/Vought/Northrop Grumman. He conducted and directed systems engineering studies and analysis, with focus on systems reliability and supportability, on many of the nation s most advanced military aircraft. Jerrell was cofounder and leader of the SAE Reliability, Maintainability and Supportability (RMS) Division (G-11). He is an SAE Fellow and AIAA Associate Fellow. Dr. Stracener earned PhD and MS degrees in Mathematical Statistics from SMU and a BS in Math from Arlington State College (now the University of Texas at Arlington).