The LEADing Practice Enterprise Security Standards

Transcription

1 The LEADing Practice Enterprise Standards Integrating Architecture and Enterprise Architecture Presenter: James Thomas LEAD Enterprise Architect at Knotion

2 Copyright note on Intellectual Capital: ALL RIGHTS RESERVED LEADing Practice ApS respects the intellectual property of others, and we ask others to do the same. All information and materials contained in the LEAD frameworks, methods and approaches with associated tools and templates, such as maps, matrices and models is Intellectual Capital (IC) and Intellectual Property (IP) of LEADing Practice ApS and limitations apply to the reuse of this IC/IP. The intellectual Property Rights (IPR) consists of information, knowledge, objects, artifacts, experience, insight and/or ideas, that are structured to enable reuse to deliver value creation and realization. The LEADing Practice ApS, often referred to as LEAD, intellectual capital is protected by law, including, but not limited to, internationally recognized United States and European Union IPR copyright law. Except as specifically indicated otherwise in writing, LEADing Practice ApS is the owner of the copyright in the entire LEAD Frameworks content (including images, text and look and feel attributes) and LEADing Practice ApS reserves all rights in that regard. Use or misuse of the IPR, the trademarks, service mark or logos is expressly prohibited and may violate country, federal and state law. LEADing Practice ApS is an open architecture and community open source standard and therefore provides open access to all deliverables for certified LEAD practitioners, thereby ensuring that modelling principles are applied correctly. A open architecture and open standard community has been set in place to encourage sharing, learning and reuse of information and thereby increase knowledge among LEAD community practitioners, and with this ultimately improvement of one s project, engagement and the LEAD development. Use of the LEAD frameworks, methods and approaches is restricted to certified LEAD community members in good practitioner standing, who are able to use these items solely for their non-commercial internal use. Legal access to the detail of LEAD will be provided to you with your membership. Members are prohibited from sharing the LEAD material in its entirety with other parties who are not members of LEAD community since the concepts and models are protected by intellectual property rights. Guidelines for LEAD community members using the IPR material As a LEAD member comes greater personal responsibility and the following intellectual property conditions apply: Can be used free of charge for LEAD certified practitioners. Cannot be share, copied or made available for non-community member, which are not LEAD certified practitioners. When using any materials, it must include a source notice either in an adjacent area or as a footnote to indicate the source. The source should be specified the following way : Source: A part of the LEAD Frameworks and possibly indicate the LEAD work product family, such as Part of LEAD Process Framework. Cannot be systematically given away do not download all our content and simply hand it over to other colleagues or clients that are not trained and certified. To ensure correct usage, any company usage of the LEAD material e.g. templates and tools has to be tailored and agreed upon by LEADing Practice ApS. LEADing Practice ApS may, in appropriate circumstances and at its discretion, terminate the access/accounts of users who infringe the intellectual property rights and pursue legal action. Guidelines for non-lead community members using the IPR material The following conditions apply to use of the LEAD Intellectual Property for non-community members: Can be used free of charge for lecturing and research at any University and Business School Material available at can be used in a non-commercial way for knowledge sharing. When using any materials, it must include a source should be specified the following way : Source: A part of the LEAD Frameworks and possibly indicate the LEAD work product family, such as Part of LEAD Process Framework. General guidelines that apply for all LEAD IPR material Any use of original texts, graphics, images, screen shots, and other materials from LEAD sources must be approved by LEADing Practice ApS. Any material cannot be generally distributed to colleagues, clients and or an undefined audience without written permission from LEADing Practice ApS. Cannot be altered or changed (the using company) in any way without explicit written permission from LEADing Practice ApS. In most cases, the LEADing Practice ApS acts as a distribution channel for the Publisher and Authors of the material provided. LEADing Practice ApS may, in appropriate circumstances of infringement of the intellectual property rights pursue legal action. For questions, please get in touch with us at info@leadingpractice.com.

3 Agenda Situation: is more critical than ever Complications: Focus areas and many options We need a holistic architecture methodology Integrating and Enterprise Architecture Applying LEADing Practices Reference Content Lessons Learned or Pitfalls Conclusion: Takeaways

4 Situation is becoming more critical than ever The number of exposures and high profile breaches are increasing Attacks are more sophisticated New opportunities bring new threats and vulnerabilities mobile, social, cloud, etc.. Many links in the chain are increasing the risk of a breach information supply chains

5 Analyze/Identify Existing Strategies Business Innovation & Transformation Enablement

6 is top concern in 2014 for state CIOs "It is significant that security has now risen to the number one priority on our top 10 list. As I presented in congressional testimony before the Committee on Homeland last week, cyber-attacks against state governments are growing in number and becoming increasingly sophisticated. has to be the top priority for all sectors. Clearly from our top 10 voting results, the state CIOs agree on this. - NASCIO President and Mississippi Chief Information Officer, Craig Orgeron In ranked order, the top 10 priorities for strategy, management processes and solutions are: Consolidation / Optimization Cloud services Project and portfolio management Strategic IT planning Budget and cost control Mobile services / mobility Shared services Interoperable nationwide public safety broadband network (FirstNet) Healthcare is top concern in 2014 for state CIOs - FierceCIO National Association of State Chief Information Officers, November 5, 2013

7 CIO Barometer CSC Nearly three-quarters of respondents said that more-effective management of IT security and cybersecurity is a priority for their 2014 IT budgets. When asked to identify the IT department s main contributions, more than 60 percent cited securing the business. And when it comes to major challenges facing their IT departments, nearly 80 percent cited the management of expanding IT security, making it their top challenge. As the world continues to revolve on a digital axis, IT security becomes more and more critical. Last year alone (2012), there were more than 2,500 separate incidents, exposing more than 250 million records. Copyright 2013 Computer Sciences Corporation - The CIO s New Role: Core Strategy Enabler, CIO Barometer 2013 Private and semi-public companies and public institutions with a minimum of 500 employees 681 managers were interviewed on five continents and in 18 countries. These managers represent the following target positions: CIO; IT director; IT manager

8 Data Breach Trends Data Breach QuickView - An Executive s Guide to 2013: Data Breach Trends Sponsored by: Risk Based ; Open Foundation February 2014

9 Cyberrisk in banking: A review of the key industry threats and responses ahead September 2013 Both technologies and threats are evolving Mobile devices and applications are primary examples of the balance between greater efficiency and new kinds of cyberrisks Awareness remains low 30% rate limited customer awareness as a key challenge Preparedness for cyberrisks remains patchy Less than one in four banks believe their internal resources are highly prepared Trust trumps financial losses Banks are only spending just enough on cybersecurity to make customers trust them A lack of cooperation is hindering progress Because many banks are typically only financially liable when their own systems are compromised, there is little incentive for them to cooperate with other stakeholders when it comes to cybersecurity. Response strategies are evolving A shift in thinking: from trying to prevent all risks, to instead trying to identify key weaknesses The quantitative findings presented in this report come from a survey of 250 respondents in financial services, with 55 percent in retail banking and 45 percent in commercial banking, conducted by Longitude Research September 2013.

10 Complication Many initiatives working on improving the Enterprise Risk and Information landscape The market is already flooded with too many checklists has traditionally been the realm of Techies Enterprise Risk Management is being driven from a business perspective, while IT is still tool -focused Where to start with so many options?

11 So many options... Calder-Moir IT Governance Framework CobiT King III ISC2 BoK (CISSP) IT-Grundschutz STIGs (US Govt Guidelines) TickIT (Software Development) FIPS200 SSE-CMM O-ISM3 SABSA OSA FEAF FAIR COSO GAIT OCTAVE NIST SP FISMA (FIPS199, FIPS200, SP800-30,37,39,53,53A,60) ISO (ISMS) ISO (Controls) ISO (ISMS Implementation, Processes) ISO (Measures & Measurement) ISO (ISec. Risk Management) ISO ( Techniques) ISO (ISMS Auditing) ISO (ISM Controls Auditing) ISO (Governance of information security) ISF ITIL NIST SP800 (Series) Sarbanes-Oxley (SOX) Basel I, II, III PCI-DSS

12 Need for a holistic methodology IT has to evolve: information TECHNOLOGY INFORMATION technology BUSINESS SECURITY / ENTERPRISE SECURITY Enterprise Risk models are essential can t be an afterthought any more has to be architected-in from the start Identify the most sensitive areas of the business, the most likely threats, and a holistic defence strategy - an architecture of technology and processes - designed specifically to protect the business

13 Architecture to date some examples Enterprise Architecture Frameworks FEAF DoDAF TOGAF Architecture Frameworks Federal Enterprise Architecture and Privacy Profile (FEA-SPP) Open Architecture (OSA) Sherwood Applied Business Architecture (SABSA) Are these attempts sufficient?

14 FEAF

15 DoDAF

16 TOGAF

17 FEA-SPP Framework

18 OSA Taxonomy

19 SABSA Model 19

20 SABSA Operational Risk Model

21 Attempts to Integrate Architecture and Enterprise Architecture

22 TOGAF and SABSA

23 Some Challenges

24 Applying LEADing practices Overview of the LEADing Practice Reference Framework

25 Objective of Reference Framework What is the LEADing Practice Reference Framework? The LEADing Practice Reference Framework is based on a collection of best and leading practice Modelling and Architecture disciplines. The Reference Framework is the essential starting point with guiding principles for any practitioner working with and around aspects. It provides a structural concept around strategic definitions e.g. wants, needs, identification, goals, issues and problems. Therefore the Reference Framework is a basis of reference content to analyze, appraise, approximate, assess and capture a Objects and or artifacts idea, design, plan, scheme and structure in order to understand the underlying concept, thought, view, vision as well as perspective. Why is it used? The purpose of the Reference Framework is to define how to organize and structure the viewpoints and objects associated with Modelling and Architecture. The Reference Framework serves as guiding principles to establish a common practice for creating, interpreting, analyzing and using objects within a particular domain and/or layers of an enterprise or an organization. Using the Reference Framework is done through a set of principles e.g. how and where can the Objects be related (and where not). The Reference Framework can be used with the 6 LEAD methods and 4 LEAD approaches that are all integrated with each other and with supporting maps, matrices and models.

26 Enterprise Modelling and Enterprise Architecture an integrated part of the LEADing Practice Frameworks, Method and Approaches Enterprise Modelling is the abstract representation, description and definition of a structure. It is the discipline of representing and replicating the area that is being modelled to have a simplified representation of the real enterprise business. Then it sculptures and forms and designs/redesigns the specific area that is being modelled to improve its performance. Examples of Enterprise Modelling Service Model renewal Optimization Improvement Business Model Value management Performance management Measurements Rules Modelling Knowledge Management Information Modelling Decision Modelling Reporting Strategy Management Governance Modelling ITIL COBIT BPM Notations Val IT

27 Enterprise Architecture an integrated part of the LEADing Practice Frameworks, Method and Approaches Enterprise Architecture: The organization, administration of conceptual, logical and physical relationships and connectivity of specific objects and artifacts to each other (and the environment) in order to understand complexity and manage structure to enable transformation, performance or value. Example of Enterprise Architecture Business Architecture Architecture Value Architecture Data Architecture Information Architecture Cloud Architecture Solution Architecture Application Architecture Platform Architecture Infrastructure Architecture Technology Architecture Service-Oriented Architecture

28 Identification of common objects within Enterprise Modelling and Enterprise Architecture Strategy Resources Goals Competencies Critical Success Factors (CSFs) Requirements PPIs Business Functions/Tasks Business Services SLA Tasks Events KPIs SPIs Data Components Data Entities Data Service Data Objects Appl. Functions Appl. Feature Application Service Infrastructure Devices Application Components Infrastructure Services Platform Service Platform device Infrastructure Components Platform Components

29 Enterprise Modelling and Enterprise Architecture is an integrated part of the LEADing Practice Frameworks, Methods and Approaches

30 Enterprise Modelling and Enterprise Architecture is an integrated part of the LEADing Practice Reference Framework Rule Engine Compliance Rules Business Rule Goal Logical Design Conceptual Context Complexity Reporting Decision Table Object Connections Physical Execution Decision Table Measurements Business Measurements Optimization Area Groups Steps Activity Artifacts Performance Information Knowledge Management Efficiency Effectiveness

31 Working with Enterprise Modelling and Enterprise Architecture through the LEAD Objects In the LEAD object modelling principles, a LEAD object refers to a specific, specialized object that is used by the Decomposition & Composition principles within the LEADing Practice Frameworks, LEADing Practice Methods and LEADing Practice Approaches. In terms of the LEAD Way of Working within Modelling and Architecture using the LEAD meta objects and the classification* of any of the general LEAD objects, which are categorized** in the following 17 object groups: Requirement & Goal Rules Services Owner Flow Application Platform Media Channel Business Competency Object (categorization) Roles Measurement Data Infrastructure Compliance *Classify = to assemble by order **Categorize = to divide into groups

32 The LEADing Practice Reference Framework Structural Way of Working

33 The Structural Way Through The Layers 33

34 Modelling and Architecture through working with the LEAD Objects The purpose of LEAD Object modelling is to: Decompose the Objects into the smallest parts that can, should and needs to be modelled, and then compose the Objects entities before building them (through mapping, simulation and scenarios). Visualize and clarify Object relationships with the LEAD artifacts by using maps, matrices and models (alternative representation of information). Reduce and/or enhance complexity of Modelling and Architecture principles applying the decomposition and composition method or modelling it through the architectural layers (Layered Architecture Method). Adding Requirements Communicate Value to the customers throughout the entire LifeCycle. Blueprinting and Implementation.

35 The LEADing Practice Reference Framework Decomposition & Composition

36 The LEADing Practice AGILE Concept The LEADing Practice AGILE Concept has been created in order to describe the requirement relationship between the LEAD Way of Thinking, Way of Working and Way of Modelling with both objects and domains within the Business, Application and Technology Layers of the LEADing Practice Reference Frameworks using interrogatives (what, who, why, etc.) and behavior (conceptual, logical, physical, etc.).

37 Some Basics around the Interrogatives used within the LEAD AGILE Concept Interrogative Context Meaning Whence Source Pertaining to source, origin, foundation or cause Who Personal/actor used to identify a particular person or persons involved Why Reason Pertaining to the motivation or reason What Context Pertaining to identity, nature, or value of a object or matter Where Location Location, place or area Whether Options Choosing between alternatives and/or options How Manner Pertaining to manner, method or way When Time Pertaining to time or timing

38

39 The LEAD Way of Thinking around Architecture and Modelling The LEADing Practice Way of Thinking around Architecture and Modelling disciplines, is the essential starting point that creates the guiding principles. Providing a structural concept around strategic definitions e.g. wants, needs, value identification, goals, issues and problems. The way of thinking postulates what ought to be with the right value abstraction level that can analyze, appraise, approximate, assess and capture Objects and/or artifacts idea, design, plan, scheme and structure in order to understand the underlying concept, thought, view, vision as well as perspective, philosophy and belief.

40 Objective of the LEADing Practice Reference Framework - How is it used Relation to Strategy Understand business model security drivers Outline goals Identify performance and value opportunities Capture value and performance expectations and drivers Align value drivers to business strategy Define innovation and transformation Define Transformation potential Develop and formalize change potential Focus Area Analyze business strategy and the relation Identify requirements to security Focus on value issues and Identify internal and external security drivers (competitive forces) weaknesses cluster Develop standards Ensure measurements (across business areas) Apply continuous improvements Ensure strategic reporting and decision flow strategy development Value Based design through the layers Business model linked to Develop competitive and differentiated advantage Business Transformation & Innovation Enablement (BITE) related to security aspects

41 LEADing Practice Maps A LEAD Map is an accurate list and representation of the decomposed and/or composed Objects. A LEAD Map is often in the form of a list that can be in a simple row as well as a catalog, and has the purpose of building an inventory or index list of the Objects that are to be either decomposed and/or composed in the different LEAD Layers (business, application and technology).

42 LEADing Practice Maps: Forces & Drivers (FD) Map Forces & Drivers External Driver/Forces For Why specification: Internal Driver/Forces For Where specification: Business, Service, Role, Technology, etc.

43 LEADing Practice Maps: Requirement (Rq) Map Requirement Who/Whom specification e.g. Stakeholder/Owner Where specification e.g. Layer, Objects, Area (, service, data, infrastructure) etc What specification: High Level Requirements What specification: Detailed Requirements

44 LEADing Practice Maps: Measurement & Reporting (MR) Map What/which specification: Where specification: Who/whom specification: Measuremen t & Reporting Objective (CSF, plan, forecast, budget) Performance Indicator (Strategic/Tactical /Operational) Service Measurements (Service Level Agreements) Process Measurements (PPI) Reporting System Reports

45 LEADing Practice Maps: Information (I) Map Information What/which specification: Object (Business, Information or Data) Data Entity How specification: Data Compliance (Including security) Who/whom specification: Business Owner Reporting

46 LEADing Practice Maps: Rule (Ru) Map Securit y Rule Business Rules Service Tier Service Rules What/which specification: Process Rules Gateways Business Object Information Object How specification: Business Compliance

47 LEADing Practice Maps: Process (P) Map What specification: Who/Whose specification: Process Business Process Area Process Groups Business process Process Steps Process Activities Stakeholder involved Process Owner Managers involved Roles/Resourc es involved

48 LEADing Practice Maps: Process Measurement Map Process Measurement Name Definition Rationale Dimension Application Function/Task

49 LEADing Practice Maps: Process Compliance Map Process Process Compliance Process Rule Process Description Process Rationale

50 LEADing Practice Maps: Service (Se) Map What specification Who/Whose specification Service Service Area Service Group Business Service Service Channel Stakeholder Involved Service Owner Manager Involved Role/Resourc e Involved

51 LEADing Practice Maps: Application (A) Map Component Whence specification: Version number Logical/Physical Component Application Module What/Which specification: Application Function Application Feature Application Task

52 LEADing Practice Maps: Application Service (AS) Map What/Which : What : Where : Who : Whose : Why : Application Service Application Service Service Description Business Service Service Provider Service Consumer Service Owner Service Requirement

53 LEADing Practice Maps: System Measurement & Reporting (AM) Map What/Which specification: Measurement Measurement Name Measurement Definition Rationale Dimension Application Function/System Report

54 LEADing Practice Maps: Application Screen (Asc) Map Screen What/Which specification: Who/Whom specification: Screen Name Screen Description Application Service Application Task Input or Output Application Role

55 LEADing Practice Maps: Application Role (ARo) Map Role Who/Whom specification: What/Which specification: Application Role Role Description Rationale

56 LEADing Practice Maps: Application Rule (AR) Map Rule What/Which specification: Application Rule Rule Description Rationale Nature

57 LEADing Practice Maps: Application Rule (AR) Map Compliance Application Compliance What/Which specification: Application Rule Compliance Description Rationale

58 LEADing Practice Maps: Application Goal & Requirement Map What/Which specification: Who/Whom specification: Goal/Require ment Objective Expectation Requirement, Specification or Assumption Details Business Process Application Component Application Function or Application Service Stakeholder

59 LEADing Practice Maps: Data (D) Map What/which specification: Who is involved: Where is it used: Data Data Component Data Object (information/ data) Data Entity Data Type Data Service Data Owner Data Users Data Channel Channel

60 LEADing Practice Maps: Data Rule (DR) Map What/Which What Where Whose Why Rule Data Rule Data Rule Description Data Compliance Data Rule Owner Data Rule Rationale

61 LEADing Practice Maps: Platform (PL) Map What/Which Who is involved: Where Platfor m Logical/Physical Component Device Function Service Owner Users Channel Media

62 LEADing Practice Maps: Platform Service (PLS) Map What/which Where Whose Who Why Platform Serv Service ice Name Platform Service Business Descripti Service on Applicati on Service Applicati on Function Data Service Infrastruc ture Service Service Flow Data Flow Service Provider Service Owner Service Consume r Service Require ment

63 LEADing Practice Maps: Platform Rule (PLR) Map What/Which What Where Whose Why Rule Platform Rule Platform Rule Description Platform Compliance Platform Rule Owner Platform Rule Rationale

64 LEADing Practice Maps: Platform Distribution (PLD) Map What/Which What Where Whose Why Distributi on Platform Distribution Name Logical Application Component Platform Distribution Description Platform Service Platform Distribution Owner Platform Distribution Requirement

65 LEADing Practice Maps: Infrastructure (IF) Map What/Which specification: Who is involved: Where is it used: Infrastructure Logical/Physical Component Device Function Feature Service Owner Users Channel

66 LEADing Practice Maps: Infrastructure Rules (IFR) Map What/Which What Where Whose Why Rule Infrastructure Rule Infrastructure Rule Description Infrastructure Rule Compliance Infrastructure Rule Owner Infrastructure Rule Rationale

67

68 LEAD Requirement Management Method - Conceptual Description Why Stakeholder (ST) Matrix What in terms of security context e.g. Performance/Val ue Expectation Why specification e.g. Goal/Reason How - specification e.g. Expected areas What in terms of security context e.g. Performance/Val ue Expectation Why specification e.g. Goal/Reason How - specification e.g. Expected areas Who security specification: Stakehol der Stakeholder Who - in terms of security ownership: Stakeholder (Business Unit) Stakeholder (Department) Stakeholder (Operational Manager) Where specification: Business Area or Technology Area, etc. Business/Tec hnology Area Business Area Technology Area

69 The concept of the LEAD Requirement Management Reference Method

70 LEAD Requirement Management Method-Conceptual Context: Example of how to link the What to the Why in the Business Competency Object Group What (Objects) Business Competency Organizational Construct/Design Resources and security aspects Why (Value Expectation) Revenue Model Service Model Cost Model Performance Model Value Model Operating Model Develop the organizational competencies X X Slim line and optimize the Organizational Compliance Construct X X Redesign the organizational business areas according to security construct and compliance aspects X (X) X Improve balance between buy and lease security forces (X) X Reduce organizational complexity (X) X X Integrate and standardize business functions and service X (X) Better resource and skills security performance X X Improve security management skills of staff (X) X Improve ability to attract security talents (X) X Optimize security resources (X) X X Capabilities Cross Organizational development and optimization (X) X X Select which and activity can be integrated or standardized X X Choose the aspects and events that have direct customer and supplier interaction (X) X X X Improve integration of business Securities across partner networks X X X Identify the management for better reporting and decision making X X Services Classify the main 's for optimization (X) X X Categorize the supporting 's for possible standardization and cost cutting X (X) X (X) High Importants X = Targeted Align pricing with service strategies according to revenue stream X X Medium Importants (X) = XSecondary target Low Importants

71

72 The LEADing Practice Reference Framework Business Decomposition & Composition

73

74 LEAD Requirement Management Method-Conceptual Description and Relations: Relating the Stakeholder Needs and Wants to the Objects and Layers

75 Applying the Objects to the Layers using the Decomposition & Composition Method (example: )

76 LEAD Requirement Management Method - Conceptual Description Why Requirement Matrix Why, in terms of reason security specification e.g. Motivation and Drivers for Whither specification e.g. Goal & Objectives (Business/Application/Technol ogy) Requirem ent Who/Whom specification e.g. Stakeholder/Owner Where specification e.g. Layer, Objects, Area (, service, data, infrastructure) etc What specification: High Level Requirements What specification: Detailed Requirements Which expectation specification e.g. Value/Performance Why, in terms of reason security specification e.g. Motivation and Drivers for Whither specification e.g. Goal & Objectives (Business/Application/Technol ogy) Which expectation specification e.g. Value/Performance

77 Layered Architecture method: Architecture The main principle behind the Leading Enterprise Architecture Development (LEAD) concept, and what makes it differ from other traditional Enterprise Architecture frameworks, is the fact that it does not only work in domains, but across layers (business, application and technology) within multiple domains through using the decomposition and composition method to integrate effortlessly across the different layers when interlinking the different modelling principles. As shown in the below example, each layer s Objects are defined by the specific layers requirements, the capability of the object, the resources, tasks and. The functions that a layer provides can be seen as the layer s services since a layer provides a set of functions and tasks and thereby services to its upper layer. In turn, the upper layer uses the lower layer s services (functionality and tasks) to achieve its own functions (services). The n th layer (+1 and/or 1) can therefore be seen as a service requester or provider since it ether gives input or uses the services provided by its lower layer.

78 Layered Architecture method: Architecture The LEAD layered method is built upon the concept of interlinking the objects that are within and work across the layers. While the layers and their specific objects may/will have different modelling principles, they do still have correlations, relationships and/or connections with other layers and these need to be related/connected in the right way: The Business Layer describes the objects within the Business layer e.g. the Business Goals, Business Requirements and Business Competencies are linked to Business Securities, Business Services and business workflow. The Application Layer describes the deliverables within the application, date and Information Architecture. The maps, matrices and models depicts how Data Goals, Data Flow & Service, Data Requirements and Data Components are linked to Application Goals, Information Flow & Service, Application Requirements and Application Flow & Component. The Technology Layer describes the deliverables within the platform and infrastructure areas. The maps, matrices and models depicts how Platform Goals, Platform Flow & Service, Platform Requirements and Platform Components are linked to Infrastructure Goal, Infrastructure Flow & Service, Infrastructure Requirements and Infrastructure Component.