Beyond a Product View of Architecture

Tim Hunnicutt Senior Associate Booz Allen Hamilton Session Title: Beyond a Product View of Architecture

Session Overview This session will discuss the application of presentation and visualization techniques to break out of the product-centric focus of most architecture (examples are primarily within the Department of Defense). The challenges facing a product-only architecture in gaining acceptance and application will be addressed. Additionally, it will be discussed how to leverage presentation/visualization techniques such as dashboards, graphical depictions, reference models, fusion products and composite products. The session will focus on a common example, centering around a complex BMPN-based process model and how a set of well-formed information-rich visualizations can be developed to enhance the application of architecture for business problems.

The primary usage of architecture… Wallpaper

The foundation of any architecture is integrated information… Before we can create presentation and visualizations, we have to go through a process of gathering and relating information about the enterprise. Using some sort of modeling notation and tool.

The DoDAF is a traditional product-based architecture framework… Typical Analysis Areas: Investment Review Board Analysis Business Process Re-engineering Data Management IT Portfolio Analysis

BPMN Relationship to DoDAF The OV-6c portrays a relative order to Operational Activity execution Each Operational Activity has a trigger (start) Each Operational Activity has a conclusion (end) The process flows within each diagram are categorized by the Actor responsible for the activity/event These “swimlanes” also map to the OV-2 roles All process models use a common modeling notation (BPMN) Data Objects map to OV-3 Information Exchanges Gateways reflect OV-6a Business Rules

The product-centric view in DoDAF is a compromise between Zachman and most modeling notions

DoDAF 1.5 seems to be only a partial solution wrt to Zachman… DoDAF Products Mapped to the Zachman Framework Presentation and visualization can help fill in the gaps. Integrated Dictionary Activity Model (List) Operational Node Connectivity Description Command Relationships Chart Operational Event Trace Logical Data Model Activity Model Information Exchange Matrix Physical Data Model System Functionality Description System Interface Description (Detailed) Operational Activity to System Function Matrix System Interface Description (High-Level) System Interface Description (Detailed) System COMMS Description System Interface Description (Detailed) Activity Model Operational Event Trace/System Event Trace An Aspect Of Multiple Products DoD Architecture Framework Products Operational View System View Technical View* *Rules Not Explicit in Zachman

During this session we’re going to take several looks at how process modeling relates to this… Phase 4 Integrate (Weeks 13-15): The example process model had 304 “steps”, plus multiple swimlanes and dozens of data objects. We’re going to relate this to both DoDAF and presentation/visualization.

The DoDAF is moving to a “Fit-for-Purpose” concept… The intent is to go beyond the product-centric view to a data-centric view. This will be more flexible and address the gaps in the current framework. To understand the implications of this change we have to look “under the hood”.

Using Presentation and Visualization techniques INCREASES the need for well-formed architecture data… Before we can create presentation and visualizations, we have to really understand the information that is the core of architecture.

The building blocks of architecture align to the primitives in the Zachman framework. Policy Standards Information Exchanges System Data Exchanges Data Operational Activities Systems Business Processes Business Rules System Functions Operational Roles

The heart of the DoDAF (or any framework) is the relationships between these primitive concepts…

Policy is a documented plan of action to guide decisions and achieve rational outcomes. It guides the process of making important organizational decisions, such as programs or spending priorities, and choosing among them on the basis of the impact they will have. Policy

Department of Defense ● Human Resources Management Civilian Human Resources Management ● Military Health System ● Military and Other Human Resources Management Operational Activities ACART DITPR Reference Models Operational Activities populate the BEA Operational Activities organize RMs Operational Activities are fed to DITPR for mapping Operational Activities are fed to ACART for mapping BEA Operational activities describe the capabilities that are normally conducted in the course of achieving a mission or a business goal. They represent a hierarchical decomposition of business activities and are discovered through reference analysis and SME interviews.

The team created an Operational Activity, Node Tree (OV-5) by abstracting the detailed process steps… Phase 5 Validate & Refine (Weeks 16-18):

Reference Models DoD Net-Centric Data Strategy BEA Information Exchanges Information Exchanges identify who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur. Information exchanges express the relationship across operational activities, operational nodes, and information flow. Information Exchanges populate the BEA Information Exchanges are mapped in RMs Information Exchanges identify authorized and anticipated users for the NCDS Information Exchanges are mapped to Core HR Information Standards Core Human Resources Information Standards

Operational roles define who is responsible for what activities within an organization, what information is exchanged between roles, and how responsibilities within an organization shift over time. Organizational roles can also define stakeholder relationships. BEA Reference Models DoD Net-Centric Data Strategy Operational Roles identify net-centric service providers Operational Roles are mapped in RMs Operational Roles populate the BEA Operational Roles

* Source: MODAF Version 1.1 Data is used to document the business information requirements and structural business process rules of the architecture. It describes the information that is associated with the information exchanges of the architecture and that are required to support a mission or business goals. It includes data elements, their attributes, their relationships and data-specific business rules. BEA Reference Models DoD Net-Centric Data Strategy Core Human Resources Information Standards ACART Data populates the BEA Data organizes Data RMs Data is fed to ACART for mapping Data is built to support the NC Data Strategy Data is the core of the HR Information Standards Data

They created 35 high-level data objects… Met weekly with representatives from the Services, DoD, and VA. Created 15 process models and 1 integrated model which included 304 processes and 35 data objects which define: Continuation of Military Service Decision Conversion to Ability Assessment Components of Compensation Continuum of Care Care Management Team (CMT) Coordination of Recovery Care Plan (RCP) Consolidated Access to Benefits Convergence of Information

BEA Reference Models Business Processes populate the BEA Business Processes are mapped in RMs Business Processes Business processes describe a time-ordered examination of the information exchanges that occur between operational roles. They help define the role interactions and capture end-to-end business processes.

The group was very resistant to “architecture”, but comfortable with “process modeling”… Process models represented stakeholder interactions, information exchanges, and key concepts Phase 2 Design & Build (Weeks 3-7):

Business Rules specify operational or business rules that are constraints on the way that business is done in the enterprise. At a top level, rules will at least embody the concepts of operations and will provide guidelines for the development and definition of more detailed rules and behavioral definitions that will occur later in the architecture definition process. BEA Business Rules Core Human Resources Information Standards Business Rules populate the BEA Business Rules constrain HR Information Standards ACART Business Rules are fed to ACART for mapping

System Data Exchanges BEA System Data Exchanges populate the BEA System Data Exchanges specify the characteristics of the system data exchanged between systems. System data exchanges focus on the specific aspects of the system data flow and the system data content.

System functions are actions performed by systems to support the operational activities required by a mission or business goal. System functions BEA System Functions populate the BEA Reference Models System Functions populate RMs for system mapping ACART System Functions are fed to ACART for mapping DITPR System Functions are fed to DITPR for mapping System Functions

Systems BEA ACART DITPR Systems populate the BEA Systems are fed to ACART for mapping Systems are fed to DITPR for mapping Systems support organizations and operational roles by automating the information exchanges between operational activities that support a mission or capability.

Standards Standards guide the development of systems by providing requirements with which systems developers must comply. Standards also provide guidelines against which the system evaluators can gauge technical parameters of the system

Well-formed architecture data, residing in a capable repository presents infinite opportunities for business use… Working with the DoDAF community, we are trying to create some best-practices to help the architecture and business communities understand each other.

An architect’s two primary jobs are communication and mediation… The EA MUST be understandable to ALL the stakeholders! But not ALL of the EA has to be understandable to ALL stakeholders! Graphics Reference Models Low detail Highly structured models Physical models Highly Detailed Graphics Logical Models Moderate detail

(CIOs) (Strategic Architects) (Capability Architects) (System Architects) (Developers) Understanding stakeholder requirements is vital for successful presentation of EA data… Combat Developers Material Developers Chief engineers Development system architects Developers Requirements/functional analysts System engineers Testers Tool vendors/industry support partners Operational developers/architects Requirements/functional analysts Acquisition managers Analysts (Operational) Capability Analysts Information assurance Program managers Warfighters Capability/portfolio managers Defense Acquisition Board (DAB) Doctrine developers Joint Staff J-6 JROC Operational planners: ROI analysis Stakeholders Level 5: Developer Level 4: Integrator Level 3: Program Managers Level 2: Process Owners Level 1: Planners/Decision Authority Descriptions Levels Defined as implementers of the initiative as well as system owners and functional managers affected by the implementation Require documents/information detailing the specifics of initiative implementation and workload Must understand the impact that implementation will have on organizational positions, workload, and process Defined as the system developers / coders Require specific details and documentation on how to implement the products Must understand the how of implementation as well as the necessary system changes Defined as the system architects and functional managers affected by the implementation Require specific details and documentation on how to implement and use the products Must understand the how and why of implementation as well as the necessary system changes and their benefits Defined as programs managers and/or process owners with direct staff oversight and perhaps technical systems expertise and have some level of control and/or budget authority Require high-level conceptual briefings detailing process and progress of effort Must understand what overall impact the architecture product will have on their organization Defined as senior level decision makers who review and make final approvals or strategic decisions Require high-level overviews which quickly touch on the key concepts of the architecture products Must understand why the initiative will be beneficial to the DoD at large

Presentation Technique: Dashboards Integrate architecture information to create business context Number of Systems supporting an Operational Activity Number of Systems modifying a Data Element Fuse Architecture Information with other Business Information Cost per System Function Training Requirements Per Operational Role

Presentation Technique: Graphical Depictions Graphics enable understanding of and add accessibility to architecture information Operational Concept Graphics aligned to business capabilities and enterprise priorities within the architecture engage stakeholders and attract them to the more detailed portions of the architecture The use of graphics in products facilitate instant understanding. Most people understand pictures faster and easier than they do text or model-based document. What’s the downside to using graphics?

Graphical representations must tie back to the architecture they introduce… Major operational concepts called out. Highest level actors identified. Strategic goals integrated into the graphic.

Our example Operational Concept Graphic abstracts very detailed process model data… Phase 5 Validate & Refine (Weeks 16-18):

Presentation Technique: Reference Models Reference models provide linkages from operational activities to key architectural concepts, both within and outside of the enterprise Presenting the architecture linkages in a desk reference, versus a set of diagrams and reports, provides a means for quickly retrieving multiple pieces of information BRM driven by underlying OV-5 What’s the role of taxonomy in enterprise architecture?

Presentation Technique: Composite Products Most business owners are interested only in their particular business area and its immediate interconnections Creating specific sub-architecture product sets tailored to specific business user groups by building sub-architecture graphics This allows for small “snapshots” of the architecture to be captured and displayed to a particular business owner.

Presentation Technique: Fusion Products Fusion products accommodate the need to occasionally have formal ties between data not stored in the architecture and architecture informant. Examples: COST per system function Cost per business process step Detailed System Metadata per system The intent is to facilitate detailed analysis without the unintended consequence of the EA data been categorized as “Sensitive” or worse.

Conclusion - Architecting and Engineering ─ Two Sides of the Same Problem* Architecture Specification Engineerible Requirements collective vision, goals, constraints, and other needs of the stakeholders representations of economically producible components that can be assembled to construct the functional whole Analysis of Function Synthesis of Form Engineering Architecting Critical point *Walt Okon, DoD Architecture Training Town Hall Meeting Dec 12, 2007 If architecture and engineering are not the same thing, then the approaches might be different. Iteratively decompose and separate a primarily functional representation of a whole Iteratively compose separate elements to form a coherent whole

Thank You! Tim Hunnicutt Senior Associate Booz Allen Hamilton Contact Information: 703-772-8539 [email_address]

Segment Architecture: Depiction Segment architecture development is a collaborative process forming a bridge between enterprise-level planning and the development and implementation of solution architecture. It is used to provide a detailed results-oriented architecture (baseline and target) and a transition strategy for a portion or segment of the enterprise. Recommended by the Federal Enterprise Architecture Program Management Office, OMB

EA Product Audiences Management – Primarily concerned with cost, compliance, and schedule Executives Certification Analysts Portfolio Managers Functional – Primarily concerned with function and human factors (acceptance, usability, etc.) Stakeholders SMEs Action Officers End-Users Technical – Primarily concerned with technical solutions and standards Information Assurance Managers Net-Centric Implementers SOA Implementers Technical Standards Managers Developers and Implementers (Transformation Analysts) – Primarily concerned with suitability of documentation to their needs) Business Analysis Process Re-engineers Emerging Technology Analysts

Though originally directed to only use BPMN, as complexity increased, stakeholders found value in using other EA products too Achieved consensus by adapting to fit stakeholder needs Individual Process Models 15 process models consisting of 304 processes and 35 data objects High Level Process Model 19 processes outlining the entire continuum and the simultaneous and iterative nature of many processes Node Tree (OV-5) 80 operational activities providing an overview of all 15 process models High Level Operational Concept Graphic (OV-1) Executive-level diagram to socialize new concepts Integrated Process Model 1 process model including all processes, data objects, swim lanes, and gateways from the 15 sub-process models Integrated Dictionary (AV-2) Definitions for all processes, events, gateways, data objects, and swim lanes

Beyond a Product View of Architecture

Recommended

More Related Content

Similar to Beyond a Product View of Architecture (20)

More from Nathaniel Palmer (20)

Recently uploaded (20)

Beyond a Product View of Architecture