IS 340 Enterprise Architecture

1. IS 340Enterprise Architecture Chapter-8 Guidelines for adapting the ADM 1438/1439 Semester 2 Information Systems Department

2. Outline 1) Applying Iteration to the ADM • The concept of iteration • Strategies for applying iterative concepts to the ADM 2) Security Architecture and the ADM • Specific security considerations that should be considered during different phases of the ADM. 3) Using TOGAF to Define and govern SOAs • SOA definitions • Advantages of SOA • Enterprise Architecture and SOA

3. 1) Applying Iteration to the ADM • Three types of concepts that are characterized as iteration : • Iteration to develop a comprehensive Architecture Landscape • Iteration within an ADM cycle (Architecture Development iteration) • Iteration to manage the Architecture Capability (Architecture Capability iteration)

4. 1) Applying Iteration to the ADMIteration to develop a comprehensive Architecture Landscape • Projects will exercise through the entire ADM cycle, commencing with Phase A. Each cycle of the ADM will be bound by a Request for Architecture Work. The architecture output will populate the Architecture Landscape, either extending the landscape described, or changing the landscape where required. • Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects. • One project may trigger the initiation of another project. Typically, this is used when higher-level architecture initiatives identify opportunities or solutions that require more detailed architecture, or when a project identifies landscape impacts outside the scope of its Request for Architecture Work.

5. 1) Applying Iteration to the ADMIteration within an ADM cycle (Architecture Development iteration) • Projects may operate multiple ADM phases concurrently. Typically, this is used to manage the inter-relationship between Business Architecture, Information Systems Architecture, and Technology Architecture. • Projects may cycle between ADM phases, in planned cycles covering multiple phases. Typically, this is used to converge on a detailed Target Architecture when higher-level architecture does not exist to provide context and constraint. • Projects may return to previous phases in order to circle back and update work products with new information. Typically, this is used to converge on an executable Architecture Roadmap or Implementation and Migration Plan.

6. 1) Applying Iteration to the ADMIteration to manage the Architecture Capability (Architecture Capability iteration) • Projects may require a new iteration of the Preliminary Phase to re-establish aspects of the Architecture Capability identified in Phase A to address a Request for Architecture Work. • Projects may require a new iteration of the Preliminary Phase to adjust the organization's Architecture Capability as a result of identifying new or changed requirements for Architecture Capability as a result of a Change Request in Phase H.

7. 1) Applying Iteration to the ADMIteration cycles The suggested iteration cycles for the TOGAF ADM are shown in the following figure and can be used to effectively group related architectural activities to achieve a specific purpose.

8. 1) Applying Iteration to the ADMIteration cycles • Architecture Capability: iterations support the creation and evolution of the required Architecture Capability. • Architecture Development: iterations allow the creation of architecture content by integrating Business Information Systems, and Technology Architecture phases. • Transition Planning: iterations support the creation of formal change roadmaps for a defined architecture. • Architecture Governance: iterations support governance of change activity progressing towards a defined Target Architecture.

9. 2) Applying the ADM across the Architecture Landscape Organizing the Architecture Landscape to Understand the State of the Enterprise The following characteristics are typically used to organize the Architecture Landscape: Breadth: The breadth area is generally the primary organizing characteristic for describing an Architecture Landscape. Architectures are functionally decomposed into a hierarchy of specific subject areas or segments. Depth: With broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexity. More specific subject matter areas will generally permit more detailed architectures. Time: For a specific breadth and depth an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the future. Broader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.

10. 3) Security Architecture and the ADM • Security architectures generally have the following characteristics: • Security architecture has its own discrete security methodology. • Security architecture composes its own discrete views and viewpoints. • Security architecture introduces its own normative flows through systems and among applications. • Security architecture introduces single-purpose components in the design.

11. 3) Security Architecture and the ADM Guidance on Security for the Architecture Domains • Security concerns are pervasive throughout the architecture domains and in all phases of the architecture development. • Security is called out separately because it is infrastructure that is rarely visible to the business function. Its fundamental purpose is to protect the value of the systems and information assets of the enterprise.  • The approach of the security architect considers not only the normal flow of the application, but also the abnormal flows, failure modes, and ways the systems and applications can be interrupted and fail.

12. 3) Security Architecture and the ADM Areas of concern for the security architect(1) • Authentication: The substantiation of the identity of a person or entity related to the enterprise or system in some way. • Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been established. • Audit: The ability to provide forensic data attesting that the systems have been used in accordance with stated security policies. • Assurance: The ability to test and prove that the enterprise architecture has the security attributes required to uphold the stated security policies.

13. 3) Security Architecture and the ADM Areas of concern for the security architect(2) • Availability: The ability of the enterprise to function without service interruption. • Asset Protection: The protection of information assets from loss and resources from unauthorized and unintended use. • Administration: The ability to add and change security policies, add or change how policies are implemented in the enterprise, and add or change the persons related to the systems. • Risk Management: The organization's attitude and tolerance for risk.

14. 3) Security Architecture and the ADM • Typical security architecture would include: • Business rules regarding handling of data/information assets • Written and published security policy • Codified data/information asset ownership and custody • Risk analysis documentation • Data classification policy documentation

15. 3) Security Architecture and the ADM Preliminary Phase • Security Inputs • Written security policy • Relevant statutes • List of applicable jurisdictions • Security Outputs • List of applicable regulations • List of applicable security policies • Security team roster • List of security assumptions and boundary conditions

16. 3) Security Architecture and the ADM Phase A: Architecture Vision • Security Inputs • List of applicable security policies • List of applicable jurisdictions • Complete disaster recovery and business continuity plans • Security Outputs • Physical security environment statement • Business security environment statement • Regulatory environment statement • Security policy cover letter signed by CEO or delegate • List of architecture development checkpoints for security sign-off • List of applicable disaster recovery and business continuity plans • Systems criticality statement

17. 3) Security Architecture and the ADM Phase B: Business Architecture • Security Inputs • Initial business and regulatory security environment statements • List of applicable disaster recovery and business continuity plans • List of applicable security policies and regulations • Security Outputs • List of forensic processes • List of new disaster recovery and business continuity requirements • Validated business and regulatory environment statements • List of validated security policies and regulations • List of target security processes • List of baseline security processes • Statement of security tolerance for each class of security actor • Asset list with values and owners • List of trust paths

18. 3) Security Architecture and the ADM Phase C: Information Systems Architectures • Security Inputs • Threat analysis matrix • Risk analysis • Documented forensic processes • Validated business policies and regulations • List of interconnecting systems • New disaster recovery and business continuity requirements • Security Outputs • Risk management strategy • Data lifecycle definitions • List of configurable system elements • Baseline list of security-related elements of the system • New security-related elements of the system • Revised disaster recovery and business continuity plans

19. 3) Security Architecture and the ADM Phase D: Technology Architecture • Security Inputs • List of security-related elements of the system • List of interconnected systems • List of applicable security standards • Risk management strategy • Validated security policies • Validated regulatory requirements • Security Outputs • Baseline list of security technologies • Validated interconnected systems list • Selected security standards list • Resource conservation plan • Security metrics and monitoring plan • User authorization policies • Risk management plan

20. 3) Security Architecture and the ADM Phase E: Opportunities & Solutions • Identify existing security services available for re-use • Engineer mitigation measures addressing identified risks • Evaluate tested and re-usable security software and security system resources. • Identify new code/resources/assets that are appropriate for re-use • Determine "what can go wrong?"

21. 3) Security Architecture and the ADM Phase F: Migration Planning • Phase F: Migration Planning • Assess the impact of new security measures upon other new components or existing leveraged systems • Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis • Identify correct secure installation parameters, initial conditions, and configurations,. • Implement disaster recovery and business continuity plans  • Determine "what can go wrong?"

22. 3) Security Architecture and the ADM Phase G: Implementation Governance • Establish architecture, design, and code reviews and define acceptance criteria for the successful implementation of the findings. • Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies. • Implement necessary training to: • ensure correct deployment, configuration, and operations of security-relevant subsystems and components • ensure awareness training of all users and non-privileged operators of the system and/or its components • Determine "what can go wrong?"

23. 3) Security Architecture and the ADM Phase H: Architecture Change Management • Incorporate security-relevant changes to the environment into the requirements for future enhancement. • Determine "what can go wrong?"

24. 4) Using TOGAF to define & govern SOAs Definitions • Service-Oriented Architecture (SOA)is an architectural style that supports service-orientation. • Service-orientationis a way of thinking in terms of services and service-based development and the outcomes of services. • A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports, etc.) and:

25. 4) Using TOGAF to define & govern SOAsAdvantages of SOA • As the business environment becomes more sophisticated, the challenges facing organizations are shifting away from questions of efficiency and automation towards questions of complexity management and business agility. • Complex webs of existing applications and interfaces create highly complex landscapes where change becomes more and more difficult and the impacts of change become harder to predict and understand. • The concept of Service-Oriented Architecture (SOA) provides an architectural style that is specifically intended to simplify the business and the interoperation of different parts of that business. • By structuring capability as meaningful, granular services as opposed to opaque it becomes possible to quickly identify functional capabilities of an organization, avoid duplicating similar capabilities across the organization and quickly assemble new capabilities.

26. 4) Using TOGAF to define & govern SOAs • Enterprise Architecture and SOA • Enterprise architecture provides frameworks, tools, and techniques to assist organizations with the development and maintenance of their SOAs. • Some of the key benefits that enterprise architecture provides include: • Consistent abstractions of high-level strategies and deliverables to support planning and analysis. • Linkage of different perspectives to a single business problem (e.g., business, information systems, technology) providing a consistent model to address various domains and tests for completeness.

27. 4) Using TOGAF to define & govern SOAs • Enterprise Architecture and SOA • Identification of clear roadmaps to achieve future state. • Traceability that links IT and other assets to the business they support • Support for impact assessment, risk/value analysis, and portfolio management • Identified and documented principles, constraints, frameworks, patterns, and standards • Governance frameworks and processes that ensure appropriate authority for decision-making