Your SlideShare is downloading. ×
PowerPoint Presentation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

PowerPoint Presentation

523
views

Published on

Published in: Technology, News & Politics

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
523
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 80s – stove piped 90s – process oriented 00s – collaborative, “just-in-time” applications How important will this be refers to an article called “Net Zero” in October 2004 Scientific American and an article in an IEEE Spectrum Magazine October 2004 “Sensor Based Nation”.
  • Architecture view stack. Top layer could be Zachman. DoDAF is Program operational and below. DoDAF is a mission oriented Arch.
  • CPN is consistently mathematically based Discrete event has no consistent basis for their algorithms underlying their tool. Executable UML is focused on the “state” of software. Does not consider time. Prime focus is can I reach a state. BPMN/BPEL focus is Service oriented architectures. BPEL is the XML output from BPMN.
  • Zachman pillers are in the middle. Activities are aligned with system functions. Roles may be systems. A performer has a certain set of K,S and A necessary to fulfill a role. An asset is physical thing
  • Click on any box and should be able to get its relationship info.
  • DoDAF does not understand the org relationship e.g. between role, org and system.
  • DOTMLPF Army created says it all.
  • Artist paint on blank canvas.
  • This shows 3 scenarios.
  • Aka boanparte!
  • Transcript

    • 1. The Road to Executable Architectures Dennis Wisnosky, Wizdom Systems Inc., [email_address] Joseph Vogel, Wizdom Systems Inc., jvogel@wizdom.com Steven Ring, Mitre Corporation, [email_address] Mitre Approved for Public Release, Distribution Unlimited, Case #04-0351 ©2004 The MITRE Corporation. All rights reserved ©2004 Wizdom Systems Inc., All rights reserved * Activity-Based Methodology is a concept developed by The MITRE Corporation and Lockheed-Martin, Copyright © 2003 * DoDAF Minimalist Methodology is a concept developed by Wizdom Systems Inc., Copyright © 2004 © 2004 Wizdom Systems, Inc. All rights reserved © 2004 The MITRE Corporation. All rights reserved
    • 2. Agenda
      • Start With Integrated DoDAF Architectures
      • Present Activity-Based Methodology (ABM)
      • Present ABM Architecture Specification Model – “ASM”
      • Show steps to integrated Operational and System Architecture Descriptions- the “ Art of Architecting ”
      • Show Transition To “Dynamic” Executable Models
      • Present Executable Architecture Model Parameters
      • Show “dynamic” methodologies for executable architecture analysis
      • Present linking integrated and executable architecture analysis with investment portfolio strategies and selections
    • 3. What Are Executable Architectures?
      • Static Operational Models only show that Activities “ must be capable of ” producing and consuming Information
        • No details on event sequencing
        • No details on how or what conditions information is produced/ consumed
        • No details on producers/ consumers themselves or other resources used
      • Dynamic (over time) Executable Architecture Models go beyond “ must be capable of ” – “ WHEN ”
        • Defines precise sequential/ concurrent event model
        • Defines precisely under what conditions Information is produced/ consumed
        • Defines details on producers/ consumers (number and process ordering) and other resources (when [not] available)
      Dynamic model of Activities and their event sequencing performed at an Operational Node by Roles (within Organizations) using Resources (Systems) to produce and consume Information © 2004 The MITRE Corporation. All rights reserved
    • 4. Agile Organizations Require Adaptable Integrated Architectures 1980’s and earlier
      • Organization Focus
      • Mainframe centric
      • Monolithic
      • Internal use
      1990’s
      • Business Process Focus
      • Client/Server
      • Monolithic
      • Business-to-business via EDI - file transfer
      • Virtual organizations
      • Distributed Functions
      • Service oriented
      • Componentized
      • Real-time
      • Nework Centric Warfare & E-commerce
      Modified from Advisory Council Enterprise Architecture SIG, Succeeding with Component-based Architectures – Draft , 2002 How important will this be? © 2004 Wizdom Systems, Inc. All rights reserved New Millennium 3rd party service providers Extranet Internet Customers
    • 5. Build Integrated/Dynamic Architectures
      • Before you can use architecture descriptions for any type of analysis purposes you must first have an architecture that is
        • Integrated, unambiguous, and consistent
      • What’s an Integrated Architecture?
        • Based on DOD Architecture Framework (DoDAF) products
          • AV-1, AV-2, OV-2, OV-3, OV-5, SV-1, and TV-1
          • + OV-4 the forgotten product, key to DOTLMPF
        • Defined by a conceptual Architecture Specification Model (ASM)
      • Most DoDAF architectures are static representations of activities, roles, systems, nodes, …
      • Must supplement static representations with Dynamic, time-dependent behavior models of processes, organizations, and resources
          • Enables a more expanded and comprehensive analysis
          • Support funding decisions, acquisitions, system engineering
      © 2004 The MITRE Corporation. All rights reserved DoD Architecture Framework 1.0 DoD Architecture Framework v1.0
    • 6. Approach To Dynamic Architecture
      • Develop fully integrated, unambiguous, and consistent DoDAF views
        • DoDAF Minimalist Methodology* is a tool-independent approach to building DoDAF work products
          • 11 step process for building those work products necessary to support the DoDAF “Integrated Architecture.”
          • Includes steps for producing work products that support the Joint Capabilities Integration Development System (JCIDS)
          • Uses IDEF0, IDEF1X, and UML modeling approaches interchangeably to develop DoDAF work products.
        • Activity-Based Methodology (ABM)* is a tool-independent approach to integrated DoDAF architectures
          • Enables both “As-Is” (now) and “To-Be” (future) architecture development, gap-analysis, and assessment
          • Uses data centric architecture elements and product renderings and cross-product relationships based on core set of architecture elements
          • Captures sufficient representations of architectures to transition to “dynamic” executable process models
      * Activity-Based Methodology is a concept developed by The MITRE Corporation and Lockheed-Martin, Copyright © 2003 * DoDAF Minimalist Methodology is a concept developed by Wizdom Systems Inc., Copyright © 2004 © 2004 The MITRE Corporation. All rights reserved © 2004 Wizdom Systems, Inc. All rights reserved
    • 7. “Architecture View” Stack … . using Physical Resources (systems) in producing & consuming information and data Characterized by models of operations (Activities) performed by Human Resources (people) …. © 2004 The MITRE Corporation. All rights reserved Enterprise Program (Operational/ System/Tech) Hardware Software
    • 8. Executable Architecture Modeling Technologies Colored Petri-Net (CPN) Discrete Event BPMN/BPEL Executable UML © 2004 The MITRE Corporation. All rights reserved
    • 9. DoD Framework Products Different Information Views Rules, guidance, and product descriptions for developing and presenting architectures that ensure a common denominator for understanding, comparing, and integrating architectures CADM: Core Architecture Data Model Dynamic Models Static Models Spreadsheets * Mandatory © 2004 The MITRE Corporation. All rights reserved OPERATIONAL (OV) SYSTEMS (SV) 1: High-Level Operational Concept Graphic * 2: Operational Node Connectivity Description * 3: Operational Information Exchange Matrix * 4: Command Relationships Chart 5: Activity Model * 6a: Operational Rules Model 6b: Operational State Transition Description 6c: Operational Event/Trace Description 7: Logical Data Model 1: System Interface Description * 2: Systems Communications Desc. 3: Systems Matrix 4: Systems Functionality Description 5: Operational Activity to System Function Traceability Matrix 6: Sys Information Exchange Matrix 7: Sys Performance Parameters Matrix 8: System Evolution Description 9: System Technology Forecast 10a: Systems Rules Model 10b: System State Transition Description 10c: Systems Event/Trace Description 11: Physical Data Model TECHNICAL (TV) 1: Technical Architecture Profile * 2: Standards Technology Forecast
    • 10. Wizdom Minimalist Methodology © 2004 Wizdom Systems, Inc. All rights reserved
    • 11. Executable Architectures Consist of Reconfigured OA-SA-TA Views supported by KPP’s and KPI’s Rules/Constraints But, Standards and Methods: Don’t Exist! And, is this important? © 2004 The MITRE Corporation. All rights reserved OA SA TA Process View Resource Views DoD Architecture Framework 1.0
    • 12. Symmetrically Aligned DoDAF Architecture Objects are Building Blocks of ABM Integrated Architectures Where How What Container Asset Function Product Who Operational System Entities Relationships Attributes Relationships Attributes Entities Org Network Knowledge Skills & Abilities Performance Activity Info CONOPS (rules) Role Data Design Rules System Transfer Link Characteristic Structure Why Strategy Cycles Cycles When Behavior Need Line Info Exchange Interface Data Exchange System Function Op Node System Node Performer Asset © 2004 The MITRE Corporation. All rights reserved Generated Objects Core Objects
    • 13. ABM Triple 3-Way Associations between Core Entities Op Node Role  System Org Unit  Role  System Org Unit OV-4 Produced Consumed Activity  Op Node  Role Op Node  Role Role  Activity Activity OV-5 Op Node  Activity OV-4 Produced Consumed Function  Sys Node  System Sys Node  System Function SV-4 System  Function Sys Node  Function System SV-7 Data SV-4 SV-5 Op Node OV-2 Sys Node SV-1 © 2004 The MITRE Corporation. All rights reserved Operational Activity Info Info Sys Node System Function Data Data Role Info OV-5
    • 14. ABM Intersections of Core Entities Activity Role System Function System Org Unit System Role System Node Op Node © 2004 The MITRE Corporation. All rights reserved Op Nodes Op Activities Role Role Sys Nodes Sys Functions Sys Sys System Role Org Org
    • 15. Integrated Architecture Represented as Conceptual A rchitecture S pecification M odel – “ASM” Supports Supports Performed At Performed At Located At Located At Performs Performs Supports Consists Of Consists Of Function Activity Info Data Role System Org Unit Op Node Sys Node © 2004 The MITRE Corporation. All rights reserved
    • 16. Mapping ASM to DOTMLPF Org Unit Function Activity Info Data System Op Node Sys Node © 2004 The MITRE Corporation. All rights reserved L eadership T raining octrine D M aterial ersonnel P rganization O acilities F Role
    • 17. Steps to an Integrated Operational Architecture - Detailed Manual 3-way Associations OV-5 OV-2 Nodes OV-4 Roles Role Activity Info Op Node © 2004 The MITRE Corporation. All rights reserved Art of Architecture Info Exchange Render Information Exchanges Render 3-way associations NodeA “ Act1~RoleX ” RoleX “NodeA~Act1” Act1 “ NodeA~RoleX” OV-2 OV-2 Need Line Complete OV-2 Generate OV-3 Automation Op Nodes Op Activities Role Role Op Node Activity Role Data Entry
    • 18. Steps to an Integrated Systems Architecture - Detailed Manual 3-way Associations SV-7 Systems SV-1 Nodes SV-4 System System Node © 2004 The MITRE Corporation. All rights reserved Art of Architecture Automation Complete SV-1 Interface Render 3-way associations NodeA “Func1 ~SysX ” SysX “NodeA~Func1” Func1 “ NodeA~SysX” Data Exchange Render System Data Exchanges Generate SV-6 SV-6 Sys Nodes Sys Functions System System System Function Sys Node System Data Entry System Function Data
    • 19. Chained Leaf Activities Produce Candidate Activity Thread (Scenario) Models Of Sequenced Actions
      • External Activities/ Nodes PINK
      • Lowest activities in node tree chain (No further decomposition)
      • Leaf activities signified by Blue Boxes
      • OV-6 generation
      • Information Exchanges and Need Lines built only from Leaf Activities
      • Use Cases/ System Functions/ BPMN Message Flows (**)
      Gets us to! © 2004 The MITRE Corporation. All rights reserved Act 11 “ Wash DC ” Act 121 “ Boston ” Act 122 “ LA ” Act 21 “ Cleveland ” Act 221 “ Miami ” Act 222 “ New York ” Act 14 “ KC ” Act 13 “ Chicago ” Act 11 “ Wash DC ” Act 121 “ Boston ” Act 122 “ LA ” Act 21 “ Cleveland ” Act 221 “ Miami ” Act 222 “ New York ” Act 14 “ KC ” Act 13 “ Chicago ” Ordering of Leaf Activities Follows OV-5 Information Flow
    • 20. Anatomy of an Executable Operational Architecture Organization Chart Actual Organization Unit - 1-8 Armor BN, Widget Fin Dept Job Titles Business Entities Human Roles, Jobs: - Wing Cdr, S3, XO, VP, clerk Organizational Structure - BN, Wing, Fleet, Finance Dept But we need KPPs and KPIs! Resources Info Containers Activities Information Applications, Databases, Servers, Networks Systems, W/S, Satellites, Equipment, Techniques, Tools, ATM, Networks Call for Fire, Produce ATO Conduct Mission Planning, Process Loan Application Inputs/Outputs Triggers Inputs/Outputs Process Model
    • 21. Transition To Executable Models Processing time and its statistical time distribution + average wait time before processing + continuation strategy + cost$ + Input conditions + Output conditions Transport time and its statistical time distribution + quantity + cost$ Hourly and fixed cost$ + single/periodic unavailability times + set up time + capacity (quantity) + processing strategy (FIFO, etc.) “ Static-Land” “ Dynamic-Land” KPPs and KPis Leaf Operational Activity + + + Roles, Systems Resources Sends Info Resources, Job Titles Activity, Task Process + © 2004 The MITRE Corporation. All rights reserved Information Exchanges Connections between Processes IEX Process Node IEX Process IEX
    • 22. Transformation to Dynamic Process Models OV-5 Leaf Activities Rearranged to Match OV-2 OV-3 Info Exch + Architecture Tools Mapping Static -to_ Dynamic OV-4 Org/ Roles Executable Modeling Tools Integrated Architectures Executable Architectures Generated OV-6a © 2004 The MITRE Corporation. All rights reserved
    • 23. Three Attributes of Analysis for Executable Models: Constraints Within/Without Bounds Activities - Processes Roles – Human Resources Systems – Physical Resources Time Capacity (#) Cost ($) Comms Measures of Merit - Performance Related - Resource related - Reliability related Time : Activity - clock time to perform Role – availability over 24 hrs Capacity : # of Resource elements (Roles, systems) Cost : Dollar cost associated with usage of resource element Time Capacity Cost 1 2 n Examine and optimize(?) operational attributes of Time, Capacity and Co$t © 2004 The MITRE Corporation. All rights reserved
    • 24. Three Measures of Merit Performance Resources Reliability
      • Time to perform Activity…delays due to bottlenecks – resource not available
          • Increase number of resources
          • Have resources available more often
      • Time to Send information…delays due to comm’s network or task interdependency
          • Alternate ways of communicating information among resources
          • Automate manual tasks
      • Utilization of Resources (Human or Mechanical)
        • Bottlenecks (Over-utilized), Idle (Under-utilized)
      • Cost of Resources
        • Static (Price tag), Dynamic (Operating Cost)
      • Marginal Utility of Additional Resource
        • Benefit gained by adding additional resource
      • Health of the Operation
        • Impact of single point of failure
          • Mission Failure, Loss of Life, Task Failure, Minimal Impact
        • Availability of alternate/back-up resources when they’re needed
      • Recoverability
        • Time to recover from a failure
        • Adaptability to changes in environment
          • Time, Quality, Mission Success, Losses
        • Graceful degradation
          • Mission tasks completed prior to shutdown
          • Mission accomplished prior to status changed to combat ineffective
      © 2004 The MITRE Corporation. All rights reserved
    • 25. Executable Architecture Modeling Parameters & Rules
      • Resources – human producers/consumers and physical systems
        • Capacity - how many of each?
        • Assignment - who does what?
        • Time allocation and when [not] available (24 hour clock)?
        • Ordering - when multiple resources do same activity together – who is first up-to-bat?
        • Concurrency - when multiple resources do same activity simultaneously?
        • Costs – direct and indirect?
      • Activity
        • Time duration (how long to accomplish)
        • Sequential/ concurrent activity event process ordering
        • Input/Output Conditions under which information is produced/consumed
        • Costs – direct and indirect?
      • Information Flow
        • Transfer times and information flows
    • 26. Executable Architecture Sub-Process Model
      • Jobs (Tokens)
        • Enter at top
        • Exit at bottom
        • Four end-end paths
      Act A16 I1 O2 Act 17 Act A18 Act A11 Act A12 Act A13 Act A15 Act A14 O1 © 2004 The MITRE Corporation. All rights reserved I1 O2 O1
    • 27. Individual Mission Paths – In Context Of… Act A11 Act A13 Act 17 O2 Act A11 Act A13 Act 17 O1 Act A18 Act A11 Act A12 Act A15 Act A16 O1 Act A18 Act A11 Act A12 Act A14 Act A16 Act A18 O1 I1 I1 I1 I1 © 2004 The MITRE Corporation. All rights reserved
    • 28. Dynamic Analysis Cycle Edit Process Model Run Process Model Maintain same event triggers for each run/ analysis cycle Events Analyze © 2004 The MITRE Corporation. All rights reserved Run Combat Simulation Model Edit combat model when only process models analysis is complete Capture new event Trigger times when Combat model changes Run Combat Simulation Model Events
    • 29. Emerging Technical Issues (1 of 2)
      • Stale (duplicate) information in the business process model
      • Fault analysis - major changes to process flow (e.g., staff cell or sensor destroyed, or system fails, network fails) – how to reroute information flow
      • Applying contextual updates among combat simulation, business process model and network communications model
        • Combat simulation updates node locations in comms model
        • Combat simulation updates node status (destroyed, non-operational) in process model and comms model
        • Process model sends orders to specific unit in combat simulation
      • Allocating activities in mission thread to the appropriate simulation
        • Some activities represent physical actions – more appropriate for the combat simulation to execute
        • Some activities represent information processing actions – more appropriate to stay in the business process model
      © 2004 The MITRE Corporation. All rights reserved
    • 30. Emerging Technical Issues (2 of 2)
      • Incorporating dynamic cost analysis to address operational costs of a resources
      • How to adjust interactions in mission threads (business processes) to better separate command/staff activities & unit/system activities ?
        • Currently defined mission threads intertwine activities represented in process model and combat model
        • Need to modify mission threads to handle actions between process model and combat simulation
      • How to create interactions between combat simulation and process models ?
        • Mapping Key Events to start of a Mission Thread
      • Standards for Models and Products
      • How to define the measures of merit that we want and then get the models to provide them ?
      © 2004 The MITRE Corporation. All rights reserved
    • 31. The Road Reviewed Architecture Tools + DoDAF CADM Activity-Based Methodology Guidance + Compliant Tools and Methodology Render Integrated Architectures Integrated Architectures Integrated Architectures + Executable Architectures + Analytical Tools and Methods Render Quantative Actionable Architectures To be used for Funding decisions, acquisitions, system engineering, investment strategy,… + + Analysis Methods Analytical Tools Actionable Architectures Integrated Architectures Scenarios Executable Modeling Tools Integrated Architectures + Simulation Tools and Scenarios (context) Render Executable Architectures + Executable Architectures
    • 32. SUMMARY And in Conclusion! © 2004 Wizdom Systems, Inc. All rights reserved Issue 1: For CCA Business Case Need Key Performance Indicators (KPI) Chapter 6 of DoDAF Wizdom Issue 2: Because the world is not stopping Need Dynamic Models This Presentation
    • 33. DoDAF does not provide answers questions such as: © 2004 Wizdom Systems, Inc. All rights reserved What Direction to go? How to Build what I want? How to not get Hurt?
    • 34. Presented by: Dennis Wisnosky, Wizdom Systems Inc., [email_address] Joseph Vogel, Wizdom Systems Inc., jvogel@wizdom.com Steve Ring, Mitre Corporation, [email_address] The Road to Executable Architectures November 2004 Wizdom Systems Inc., and MITRE Approved for Public Release Distribution Unlimited, Case #04-0351 ©2004 The MITRE Corporation. All rights reserved ©2004 Wizdom Systems Inc., All rights reserved * Activity-Based Methodology is a concept developed by The MITRE Corporation and Lockheed-Martin, Copyright © 2003 * DoDAF Minimalist Methodology is a concept developed by Wizdom Systems Inc., Copyright © 2004 Thank You!