MACCIS 2.0 An Architecture Description Framework for Technical Infostructures and their Enterprise Environment

Transkript

1 MACCIS 2.0 An Architecture Framework for Technical Infostructures and their Enterprise Environment Brian Elvesæter, Tor Neple, Jan Øyvind Aagedal, Rolf Kenneth Rolfsen, le Øyvind Stensli

2 Problem area Defense increasingly changing Need flexible systems Assemblies from standard components Must respond to requirements Should capture relevant information Should be standardised Common architectural description framework that prescribes component-based system models

3 History RM-DP Extensions to C4ISR-AF Componentbased technology Enterprise support RM-DP C4ISR-AF MACCIS 1.0 MACCIS 2.0 MACCIS 2.0 Enterprise Edition MACCIS 2.0 Infostructure Edition

4 bjectives Create framework that allows users in different communities to create architecture descriptions using a common terminology and set of concepts. The framework should provide means to describe the same as C4ISR AF (and later DoD AF [10-12]), but should add concepts to specifically describe distributed and component-based systems. Civilian and military standards should be used as the basis whenever possible. The Unified Modeling Language (UML) should be used as the language for notation, in addition to structured text. Where more expression power is needed one should opt to utilise the standard extension mechanisms provided by UML. The framework should be simple enough to actually be used, yet have enough expression power to be useful for describing C2IS and C2 architectures. The framework should support both the process of defining and procuring a new system, and maintaining and extending existing systems. The main focus of the framework is to be description of the architectures of information infrastructures and their enterprise environments. The main problem domain is to be Command and Control, Communications, Computers and Intelligence (C4I).

5 Foundations and content MACCIS 2.0 Enterprise Edition MACCIS 2.0 Infostructure Edition Model-based Architecture Framework Conceptual Model Structuring rule Principles Terminology Architecture description typology Language mapping Methodology IEEE Std C4ISR AF RM-DP Component -oriented concepts UML

6 Components everywhere Legacy Name Title User Interface Name Name Title Title rganisation Actors Processes Information User Service Business Service Service Entity Service Entity Component Infrastructure Infostructures Data DataService Components of the Enterprise Components of the Infostructure

7 Model world Real world M2EE Enterprise Architecture Name Title Name Name Title Title rganisation Business Actors Processes Information Policies rganisation Rules Processes Enterprise Infostructures Information M2IE Infostructure Architecture User Interface User Service Business Service Data Service Entity Service Entity DataService Component Infrastructure Legacy Processing Information Software Databases Infostructure

8 Integration by viewpoints & concerns Business Stakeholder IT Architect Stakeholder Business Viewpoint Component Viewpoint Concern Concern View Business Model Business Model View Component Model Component Model Architecture of Enterprise or Infostructure

9 Generic structuring rule Concerns Concern1 Concern2 Viewpoints Concern... ConcernN Viewpoint1 Viewpoint2 Viewpoint... ViewpointN View = Viewpoint2 x (Concern1...N) Filtered View = Viewpoint2 x Concern2

10 Enterprise Architecture M2EE Viewpoints x Concerns Models perational Distribution perational Context Model Distribution Context Enterprise Model Enterprise perational Distribution Realisation Realisation Model perational Distribution

11 Infostructure Architecture Viewpoints x Concerns M2IE Models perational Distribution perational Business Model Distribution Business Functionality Distribution Requirements Model QoS Usability Requirements Component Component Model Platform Functionality Distribution QoS Functionality Distribution QoS Usability Functionality Distribution Platform Model QoS

12 Use: C2IS procurement FEFAS ARCADE system CPdistributor Lower Echelon Unit Joint Level Army Command TASKRG CP 1. Pre-planning FFAS bør kunne oppdatere ARCADE : CP Actual and planned Establish/maintain frequency pool P lan CP <<include>> <<include>> ARCADE data draft TASKRG : Frequency requirements Receive ARCADE data Receive CP Receive frequency requirements from lower level K2IS/NRCCIS II 2. Planning 3. Calculate frequency requirements From Div 6, F/I, KA mobile avd, LV Plan <<include>> cryptokeys final TASKRG : Frequency requirements new operation Verify Frequency list new campaign Generate Frequency list 4. Allocate frequencies CryptoCustodian list : Frequencies temporary list : Frequencies <<include>> Verify security level CP <<include>> perationalplande vel oper <<include>> <<include>> 8. Manage Communication Name Title verified list : Frequencies new operation Distribute Frequency list new campaign Distribute temporary Frequency list 5. Verify frequencies 7. Manage SI 6. Search options UML Use Case Model C2IS Functionality Name Name Title Title Users rganisation? Services Processes Network temp verified list : Frequencies UML Activity Model C2 Processes Data Server Components Addressee Telephone Directory cryptokeys Decoding list SI CP Frequency requirements - emittertype - emiss ointype - area - class of station[mobile, point-point, ground-air] - timerange - usage[send, receive,...] - securitylabel[(nat) unclassified, restricted, confidential, s ecret] Main frequencies - emittertype - frequency - emissiontype - area(polygon, circle) - class of station(mobile, point-point, ground-air) Frequencies Subnet - nettid - netttype - name - frequency - frequencychangetime - newfrequency - frequencyfmprai - frequencydigpray - areacode - KVTid - KVTchangeTime UML Class Model C2IS Information Interfaces

13 Future work RM-DP C4ISR-AF RM-DP Extensions to C4ISR-AF MACCIS 1.0 Component -based technology MACCIS 2.0 Enterprise support MACCIS 2.0 Enterprise Edition MACCIS 2.0 Infostructure Edition More enterprise support MACCIS 2.x Enterprise Edition MACCIS 2.x Infostructure Edition MAFE/ Milops/C2 MAFIS/ C2IS DoD AF 1.0 (draft) MACCIS and DoD AF harmonisation

14

15 System levels Business2 Business1 Business3 Business4 (Virtual) Enterprise Decomposition rgunit1 Infostructure1 rgunit2 Infostructure2 Business Decomposition Component1 Component2 Component3 Component4 (Technical) Infostructure Decomposition bject3 bject4 bject1 bject2 (Technical) Component

16 Stakeholders and concerns Stakeholders & Concerns Model world Real world Name Title Name Title Name Title rganisation Enterprise Stakeholder #1 Actors rgani sation Autho rities Processes Polici es Informa tion Databa ses Proc esses Information Coaliti ons Softw are Rules Proces sing Technical infostructures Societ y Enterprise Stakeholder #2 Corpo ration s C2 context (environment of C2) C2 enterprise (context of C2IS) C2IS infostructure (realisation of C2)

17 Use: Automatic protection (fro m FL ) (from FL) : Premissgiver : Sikkerhetsloven : DSFM (from FM) (from FL) Enhet i FM : Kunde Definere brukerkrav Ta i bruk installert (from FM) (from FM) (from FL) FL : Totalleverandør Utforme kravspek Bestille elektronisk sikring Levere elektronisk sikring (from F) (from FM) Bestille nøkkelferdig bygg EBA : Kravspesifikasjon Levere nøkkelferdig bygg (f rom F L) (f rom F ) (from FM) FB : Leverandør EBA ingen krav til Levere EBA FB : Leverandør krav til Inngå kontrakt med FL/IKT Prossesere kravspek for Levere elektronisk sikring FL/IKT : Underleverandør Inngå kontrakt med sivil underleverandør Levere elektronisk sikring Sivil leverandør : Underleverandør Levere systemkomponenter : Premissgiver : Sikkerhetsloven : DSFM : Forsvarets sikkerhetsbestemmelse : Regelverk for Definere brukerkrav Utforme kravspek Forsvarsbygg : Kunde Bestille elektronisk sikring Elektronisk sikring : Kravspesifikasjon Ta i bruk installert FL/IKT : Leverandør Prossesere kravspek for Levere elektronisk sikring Inngå kontrakt med sivil underleverandør Sivil leverandør : Underleverandør Levere og motere sikringskomponenter : Premissgiver Enhet i FM : Kunde Forsvarsbygg : Leverandør EBA FL/IKT : Leverandør : Sivil leverandør FL/IKT : IKT-kontrollør <<rgunit>> FHK <<rgunit>> F <<rgunit>> FD <<rgunit>> FB <<rgunit>> F/I <<rgunit>> NSM <<rgunit>> F/S * Forvalter av Multisafe og * Ansvar for sikkerhet rammeavtale med Securitas AS i henhold til * Fagmyndighet i elektronisk Sikkerhetsloven sikring (internt i FL) * Forvalter av rammeavtaler Lokal virksomhetsleder FL/Land * Leveranse og reservedelslager av CIII/CIV * Levere sikre IKT-tjenester i systemkomponenter i fred, krise og krig henhold til rammeavtale * Hovedforvalter av IKT-systemer i Forsvaret FL/IKT * Sikre FDN og drifte SNRRE-systemet * Leveranse og Remsdaq Norge * Rammeavtale med reservedelslager av Remsdaq Multisafe systemkomponenter i henhold til * Ansvar for sine rammeavtale <<Responsibility>> Securitas AS Elektronisk sikring FL/Luft Remsdaq installasjoner : Sikkerhetsloven : DSFM : Forsvarets sikkerhetsbestemmelse : Regelverk for Definere brukerkrav Bestille elektronisk sikring Bestille nøkkelferdig bygg EBA : Kravspesifikasjon Prosessere kravspek for EBA krav til Inngå underkontrakt for ingen krav til Inngå underkontrakt med sivil leverandør Levere og montere systemkomponenter <<rgunit>> FL <<rgunit>> SBUKS <<rgunit>> AK <<rgunit>> FSA * Rykke ut ved alarm etter avtale med Forsvaret Politiet FL/Sjø * Ansvar for sine Remsdaq installasjoner Elektronisk sikring : Kravspesifikasjon Ta i bruk nøkkelferdig EBA Levere nøkkelferdig bygg Prosessere kravspek for <<rgunit>> FL/IKT <<rgunit>> FL/Land <<rgunit>> FL/Luft <<rgunit >> FL/Sjø UML Class Model SBUKS * pplæring av Forsvarets personell på alle elektroniske sikkerhetssystemer som Forsvaret har rammeavtale for * Test-, kontroll-, rådgivings- og veiledningsoppgaver Forsvarsbygg 1. Describe organisational structures, organisational roles and responsibilities. * Eier og forvalter av EBA * Leier ut EBA til Forsvarets kunder * Fagmyndighet i UML Use Case Model Ta i bruk installert underleverandør til EBA hovedleverandør av Levere elektronisk sikring UML Activity Model 2. Describe processes performed by organisations and organisational roles. Kontrollere installasjon av 4. Assign process roles to performers and describe alternative/new processes. Electronic System - Management? - Supply -peration 3. Extract and define process roles for the processes described. Alternative UML Activity Models UML Use Case Model : Forsvarets sikkerhetsbestemmelse : Regelverk for Stiller krav til leveranse av elektronisk sikring. P Premis sgiver P Kunde Bestiller av EBA og. Beskriver virksomheten som skal utføres og definerer brukerkrav. Prosessere kravspek for EBA P P Ta i bruk nøkkelferdig EBA Elektronisk sikring : Kravspesifikasjon Har ansvaret for å kontrollere inst allas jon av mot Forsvarets IKT-infrastruktur. IK T-kontrol lør <<Process>> Leveranse av Leverandør EBA Forsvarets hovedleverandør av eiendom, bygg og P P anlegg (EBA). Alternative a Alternative b Sivil leverandør Leverer systemkomponenter til Forsvaret i henhold til eksisterende rammeavtaler. Leverandør elektronisk sikring Forsvarets hovedleverandør av.

18 Use: NCW Enterprise grid Process rgunit #1 rgunit #2 requires produces <<Information>> Required <<Information>> Produced provides consumes Information grid ipull <<Component>> InformationService #1 inotification ipush <<Component>> InformationService #2 iprocess <<Component>> NotificationService ipublish <<Component>> ProcessingService Communication grid Deployed Unit #1 Satelite InformationService #1 Information Radio Command Center InformationService #2 ProcessingService iprocess Information Deployed Unit #2 NotificationService inotification ipublish Ethernet

19 M2EE models: Context model Model Sub-model Concern Context Model verview and Summary The overview and summary model is an informal model that focuses on the purpose and scope of the enterprise, the actors and artefacts involved, and the operational concepts. This model may include descriptions of missions, products, society, authorities and corporations that are relevant to the enterprise. Distribution Context D The distribution context model describes the geographical locations and distribution of the enterprise. Context S The security context model describes security policies and regulations that enterprise must adhere to.

20 M2EE models: Enterprise model Model Sub-model Concern Enterprise Model Vision The purpose of this model artefact is to identify and describe the enterprise vision. Enterprise Goals The purpose of this model is to describe a hierarchical goal structure that can be agreed upon with the stakeholders so that a set of required high-level processes can be identified for further analysis in the areas of responsibility. rganisation Structure, D The purpose of this model is to describe the organisation of the enterprise, both formal and informal structures. Stakeholders & Concerns The purpose of this model is to identify the stakeholders and their concerns for the enterprise in order to clarify the scope of the enterprise and possibly resolve potential conflicts of interest. rganisation roles & Responsibilities The purpose of this model is to describe organisation roles and corresponding areas of responsibilities in order to relate enterprise activities, enterprise goals, organisation structures and enterprise resources. Enterprise Processes & Process Roles The purpose of this model is to describe the enterprise processes and the corresponding process roles required to perform the activities of the processes. Enterprise Resources, D, S The purpose of this model is to describe enterprise resources such as information and equipment that are needed by the enterprise processes. This model can be extended with distribution and security descriptions of the resources. Role-Distribution, D The purpose of this model is to describe physical distribution of the different business roles, e.g. organisation roles. Role-Activity-Distribution, D The purpose of this model is to describe the distribution units with its roles and the activities in each of the units. Activity-Distribution, D The purpose of this model is to describe the distribution units and the activities from each of the units. S The purpose of this model is to describe security constraints related to how actors carry out their duties and how information is treated. Risk Assessment Model S The purpose of this model is to describe the strengths, weaknesses, opportunities, threats, unwanted incidents and risks related to the enterprise.

21 M2EE models: Realisation model Model Sub-model Concern Realisation Model Work Analysis Refinement Model The purpose of this model is to refine the enterprise processes and the enterprise resources in order to identify the activities where infostructures are used and what information objects they manage. Infostructure Distribution Model D The purpose of this model is to describe the distribution of the information systems and the communication infrastructure of the enterprise. Threatment Model S The purpose of this model is to describe the security measures and treatments that must be provided by the infostructure.

22 M2EE symbols Concept UML mapping Icon Artillery Ground Track Unit Combat Field Artillery Class <<rgunit_artillery>> Support Electronic Warfare Ground Track Unit Combat Support Military Intelligence Electronic Warfare Class <<rgunit_supportew>> Support Explosive rdnance Disposal Ground Track Unit Combat Support Explosive rdnance Disposal Class <<rgunit_supported>> Support Military Intelligence Ground Track Unit Combat Support Military Intelligence Class <<rgunit_supportmi>> Infantry Ground Track Unit Combat Infantry Class <<rgunit_infantry>> Support Information Warfare Unit Ground Track Unit Combat Support Information Warfare Unit Class <<rgunit_supportiw>> Engineer Ground Track Unit Combat Engineer Class <<rgunit_engineer>> Service Support Supply Ground Track Unit Combat Service Support Supply Class <<rgunit_servicesupply>>...

23 M2IE models: Business and requirements models Model Sub-model Concern Business Model Enterprise Processes, Enterprise Resources, Distribution,, Work Analysis, D, S The business model contains the subset of model artefacts that are relevant to the infostructure we are describing the architecture of. The sub-models listed are those we have found relevant in most cases. Requirements Model Requirements F, D, S, Q, U The purpose of this model is to describe the system boundaries, the main actors and their responsibilities, and the main services offered by the system. Requirements related to distribution, security, QoS and usability can also be added to this model. User Interface Model F, Q, U The purpose of this model is to define the boundaries of the information system towards the user. This model can be extended with quality of service requirements put forward by the users and user interface sketches that addresses system usability.

24 M2IE models: Component model Model Sub-model Concern Component Model System Dependency Model F, D The purpose of this model is to describe how the system at hand fits into the set of existing systems that are currently in use. System Decomposition Model F The purpose of this model is to describe the system as divided into different subsystems or components, and how these are related to form a coherent whole. Interface Model F, Q The purpose of this model is to describe the interfaces of a component or subsystem in a manner that the software artefact can be understood and possibly reused. The interface descriptions can be annotated with QoS specifications. Structure Model F, D, S The purpose of this model is to specify relationships between information objects that must always be true (invariants). The structure model can also be used to describe the distribution and security classification of the information objects. Instance Model F The purpose of this model is to expresses assertions that must be true at a single point in time. Typically, an instance model is used to specify the states of information objects. Processing Model F The purpose of this model is to specify how the information can evolve as the system operates. System Model S The purpose of this model is to describe the different security mechanisms that are used in the system. Distribution Model D, Q The purpose of this model is to describe logical units consisting of a set of subsystems that must be distributed and deployed together. QoS requirements can be described for the communication links. Distribution Patterns D The purpose of this model is to describe general solutions to RM-DP defined distribution transparencies or identified distribution concerns for the system. Distributed Component Profile F, D The purpose of this model is to describe the design specification for the implementation of the system components in a technology-independent manner.

25 M2IE models: Platform model Model Sub-model Concern Platform Model Standards F, D, S, Q, U The purpose of this model is to provide a normative reference list of the standards being used. Deployment Model D, Q The purpose of this model is to describe the physical relationships among software and hardware components in the system. Architecture Extension Model F, D, S The purpose of this model is to document non-standard technology-specific extensions that are used. Technology Component Profile Model F, D, S The purpose of this model is to give a detailed view of the design and implementation of the system components in the chosen component technologies. Data Storage Model F, D, S The purpose of this model is to describe the implementation of the data model at a level of detail that makes it possible to maintain and change the system implementation as the system evolves over time.