Enterprise architecture for complex system of-systems contexts
•
2 likes•1,263 views
An enterprise architecture is an accepted, widely used means for an organization to capture the relationship of its business operations to the systems and data that support them. Increasingly, enterprises are participating in complex system-of-systems contexts in order to meet changing customer demands that require them to collaborate with other enterprises in new and innovative ways. For a complex system-of-systems context, a shortcoming of enterprise architecture is that it presumes a single enterprise or a single, ultimate source of control. This paper explores an approach to reasoning about distributed collaboration in the complex system-of-systems, multi-enterprise context, in which this single, ultimate source of control does not exist. It outlines the ways in which the long-used Zachman Framework for enterprise architecture would need to be modified to account for multi-enterprise collaboration and decentralized governance. It proposes a concept of stratification to meet this need and puts forward the main characteristics of the methods needed to model the stratified relationships of complex systems-of-systems to their contexts-of-use.
Recommended
Recommended
More Related Content
Similar to Enterprise architecture for complex system of-systems contexts
Similar to Enterprise architecture for complex system of-systems contexts (20)
More from Boxer Research Ltd
More from Boxer Research Ltd (13)
Recently uploaded
Recently uploaded (20)
Enterprise architecture for complex system of-systems contexts
- 1. Enterprise Architecture for Complex System-of-Systems Contexts Philip Boxer and Suzanne Garcia March 25th 2009 1Copyright © Philip Boxer 2009
- 2. Agenda Double challenge facing collaborating players (4) Enterprise architecture and beyond (6) Modeling the relation to the ‘beyond’ (3) 2Copyright © Philip Boxer 2009
- 3. Collaborative: The central players collectively provide some means of enforcing and maintaining standards. (e.g., global information grid) Relatively few dominant players Systems of Systems: there are these 4 kinds central management authority and centrally agreed upon purpose? NoYes component systems interact voluntarily to fulfill agreed upon central purposes? No Yes component systems retain independent ownership, objectives, funding, development and sustainment approaches? No Yes Virtual: Large-scale behavior emerges—and may be desirable—but this type of SoS must rely upon relatively invisible mechanisms to maintain it. (e.g., ULS systems) Many players, none dominant Acknowledged: changes in the (component) systems are based on collaboration between the SoS and the (component) system(s) (e.g., equipment capability portfolios) One player given dominance Directed: the integrated system-of-systems is built and managed to fulfill the specific centrally managed purposes of its owners (e.g., Future Combat Systems ) One player has dominance Source of definitions: Systems Engineering Guide for Systems of Systems, OSD, Version 1.0 August 2008. Brackets added. 3Copyright © Philip Boxer 2009
- 4. Collaborating Players: face a Double Challenge There is a Double Challenge to prevent disparity between: – The governance of the collaborating players’ relationship to the SoS – The value relationship through which the collaboration creates value for its customers Single collaboration with its dominant player Types of value-creating relationship with user-customers Defined 1:Directed or 2:Acknowledged SoS Relatively few emergent collaborations and some dominant players Few Emergent 3: Collaborative SoS Large numbers of emergent collaborations and players Emergent in large numbers 4: Virtual SoS Systems of Systems (SoS) are both social and technical in nature • A Collaborative SoS has to support multiple socio-technical collaborations.. Multiple collaborations with governance relationships between their players Multiple value relationships to user-customers 4Copyright © Philip Boxer 2009
- 5. Governance in a Collaborative SoS: involves separating the collaboration from its supporting infrastructure The players in a collaboration can be spread across multiple enterprises and/or different parts of an enterprise: Larger context of drivers Governance Collaborations of Players Value-creating relationships It is the players participating in a particular collaboration who will define • Their system-of-interest and its environment • The stakeholders they judge to be relevant • The way they want their collaboration supported by a system of systems Supporting Infrastructure 5Copyright © Philip Boxer 2009 Preventing disparity between the infrastructure relationship and the value-creating relationships
- 6. And so… Collaborative SoS present a different order of complexity This complexity arises because multiple collaborations exist concurrently, supported by a shared infrastructure This means understanding both – the relationships between the players in each collaboration, and – the infrastructure supporting the collaborations Largercontextofdrivers SupportingInfrastructure Collaborations of Players 6Copyright © Philip Boxer 2009
- 7. Agenda Double challenge facing collaborating players (4) Enterprise architecture and beyond (6) Modeling the relation to the ‘beyond’ (3) 7Copyright © Philip Boxer 2009
- 8. Describing the way the enterprise creates value: Zachman roots Source of coloured squares: Zachman Framework, www.zifa.com SCOPE (Competitive context) Planning BUSINESS MODEL (Conceptual) Owning SYSTEM MODEL (Logical) Designing TECHNOLOGY MODEL (Physical) Building DETAILED REPRESENTATIONS (out-of-modelling-context) Subcontracting DATA (WHAT) e.g. data MOTIVATION (WHY) e.g. strategy TIME (WHEN) e.g. schedule PEOPLE (WHO) e.g. organisation NETWORK (WHERE) e.g. network FUNCTION (HOW) e.g. function The context defining that focus is the directing enterprise Focus on the defined value- creating relationships 8Copyright © Philip Boxer 2009
- 9. The Infrastructure perspective on the enterprise: the focus is on the supporting socio-technical SoS Defined value-creating relationships enable the other two vertices to be approached from the infrastructure perspective Value proposition in response to Demand Governance Value-creating relationship CollaborationSocio-Technical Governance of the infrastructure Supporting Infrastructure Demand for value- creating relationship Behaviors in support of the collaboration 9Copyright © Philip Boxer 2009
- 10. Multiple collaborations: it becomes necessary to make the demand-side perspective explicit Demand for value- creating relationships CollaborationsSocio-Technical Value propositions in response to Demand Behaviors supporting the value propositions Governance of the infrastructure The demand-side perspective on the value- creating relationships to demand Multiple Collaborations Governance Value-creating relationships The (supply-side) infrastructure perspective on the behavior of systems of systems Supporting Infrastructure 10Copyright © Philip Boxer 2009
- 11. Source of gaps: Philip Boxer, Modeling structure-determining processes, http://www.asymmetricdesign.com/archives/59, December 2006 SCOPE (Competitive context) Planning BUSINESS MODEL (Conceptual) Owning SYSTEM MODEL (Logical) Designing TECHNOLOGY MODEL (Physical) Building DETAILED REPRESENTATIONS (out-of-modelling-context) Subcontracting DATA (WHAT) e.g. data MOTIVATION (WHY) e.g. strategy TIME (WHEN) e.g. schedule PEOPLE (WHO) e.g. organisation NETWORK (WHERE) e.g. network FUNCTION (HOW) e.g. function COLLABORATIVE MODEL (Collaboration) Governance Multiple players in multiple collaborations Multiple Players in multiple collaborations USE CONTEXT (WHO for WHOM) e.g. particular client Different collaborations imply different types of value- creating relation to demand Different collaborations imply different types of value- creating relation to demand EVENT (WHAT) e.g. things done Different collaborations imply different physical realities Different collaborations imply different physical realities The demand-side perspective: creates gaps in Zachman 11Copyright © Philip Boxer 2009
- 12. Modeling the ‘beyond’ of the Enterprise Architecture: three modeling perspectives Demand for value- creating relationships CollaborationsSocio-Technical Value propositions in response to Demand Behaviors supporting the value propositions Governance of the infrastructure Shape granularity/modularity and alignment of supporting behaviors Multiple Collaborations Constrains possible value propositions of collaborations Supporting Infrastructure Analysis of model needs to examine the way all three modeling perspectives constrain each other Analysis of model needs to examine the way all three modeling perspectives constrain each other Analysis of model needs to examine the way all three modeling perspectives constrain each other 12Copyright © Philip Boxer 2009
- 13. Engineering constraints And So… Stratification describes how services are aligned to demand in order to meet these constraints 6: Decisive Points 5: Mission Command 4: Force structure pragmatic constraints Each collaboration introduces its own set of pragmatic constraints 3: Operational Capabilities 2: Fielded Equipment 1: Equipment demand-sidesupply-side 13Copyright © Philip Boxer 2009 Each collaboration defines a working edge
- 14. Agenda Double challenge facing collaborating players (4) Enterprise architecture and beyond (6) Modeling the relation to the ‘beyond’ (3) 14Copyright © Philip Boxer 2009
- 15. Complex systems of systems: socio-technical Structure-function view – design dependencies 15Copyright © Philip Boxer 2009
- 16. Complex systems of systems: socio-technical State/trace view – state variables and controls 16Copyright © Philip Boxer 2009
- 17. Complex systems of systems: collaborations Hierarchy view – vertical accountabilities 17Copyright © Philip Boxer 2009
- 18. horizontal synchronization/ data fusion view – cross-cutting processes Complex systems of systems: collaborations 18Copyright © Philip Boxer 2009
- 19. Effects/Demand view – horizontal accountabilities Complex systems of systems: demands 19Copyright © Philip Boxer 2009
- 20. Complex systems of systems: all three modeling perspectives become necessary Socio-technical = Structure-function + Data/Trace Collaborations = + Hierarchy + Fusion/ Synchronization Demands = Demand situations + Effects drivers These perspectives and their relationships generate a knowledge base, the properties of which can be analyzed 20Copyright © Philip Boxer 2009
- 21. Identifying interoperability risks: leads to a different kind of analysis Source: Anderson, Boxer & Browsword (2006) An Examination of a Structural Modeling Risk Probe Technique, Special Report, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-2006-SR-017, October 2006. http://www.sei.cmu.edu/publications/documents/06.reports/06sr017.html Special permission to use PAN in this Technical Probe was granted by Boxer Research Limited. Identifying Gaps in the different strata Analysis of Granularity Collaborations across socio-technical SoS in relation to Demand Defining the relationships between the three different modeling perspectives Demand forvalue- creating relationships CollaborationsSocio- Technical Analyzing the alignment to demand by collaborations of the SoS infrastructure Engineering constraints 6: Decisive Points 5: Mission Command 4: Agile force structure pragmatic constraints 3: Operational Capabilities 2: Fielded Equipment 1: Equipment demand-sidesupply-side 21Copyright © Philip Boxer 2009
- 22. Conclusion Collaborative Systems of Systems involve multiple concurrent collaborations supported by SoS Infrastructure – Both supply-side and demand-side perspectives have to be modeled in order to understand • How infrastructure supports varieties of demand • How collaborations differ • What forms of alignment and granularity of services are needed. – This has involved • Extending modeling to include demand-side perspectives • Adding new forms of analysis of alignment between supply- and demand-side perspectives Engineering constraints 6: Decisive Points 5: Mission Command 4: Agile force structure pragmatic constraints 3: Operational Capabilities 2: Fielded Equipment 1: Equipment demand-sidesupply-side 22Copyright © Philip Boxer 2009
- 23. END 23Copyright © Philip Boxer 2009
- 24. The type of governance relationship to the infrastructure The type of value-creating relationship to the customer’s demand Responsibility-for-what Accountability-to-whom Relationship to Customer’s Timing & Logistics Functionality offered by supplier problem solver product developer service provider cost minimiser strict hierarchy X-cutting teams under hierarchy task force multiple collaborations Preventing disparity: between the infrastructure relationship and the value-creating relationships This demands that there can be multiple concurrent collaborations that are emergent Source: Philip Boxer, The Double Challenge, http://www.asymmetricdesign.com/archives/26, March 2006 These white boxes all involve defined value-creating relationships These white boxes all involve defined value-creating relationships These white boxes all involve defined value-creating relationships This demands a collaborative SoS as a supporting infrastructure These white boxes can all come under a single player These white boxes can all come under a single player These white boxes can all come under a single player 24Copyright © Philip Boxer 2009
- 25. Synchronization of the composite value proposition with the customer situation Each ‘ring’ represents a supply-side service (W)edge process – a working edge of the collaborative SoS * This set of services has an SoS architecture Orchestration of a set of customized services* that need to interoperate to deliver the composite value proposition Customization of the way each service is used Each collaboration defines a working edge Each (w)edge represents particular collaboration Source: Philip Boxer, Finding the edge, http://www.asymmetricdesign.com/archives/56, December 2006 25Copyright © Philip Boxer 2009