Presentation is loading. Please wait.

Presentation is loading. Please wait.

Guidelines.  Applying Iteration to the ADM  Applying the ADM across the Architecture Landscape  Security Architecture and the ADM  Using TOGAF to.

Similar presentations


Presentation on theme: "Guidelines.  Applying Iteration to the ADM  Applying the ADM across the Architecture Landscape  Security Architecture and the ADM  Using TOGAF to."— Presentation transcript:

1 Guidelines

2  Applying Iteration to the ADM  Applying the ADM across the Architecture Landscape  Security Architecture and the ADM  Using TOGAF to Define & Govern SOAs

3  Architecture Principles  Stakeholder Management  Architecture Patterns  Business Scenarios

4  Gap Analysis  Migration Planning Techniques  Interoperability Requirements  Business Transformation Readiness Assessment  Risk Management  Capability-Based Planning

5  Architecture Capability iterations  Architecture Development iterations  Transition Planning iterations  Architecture Governance iterations

6  Identification of Required Change  Definition of Change  Implementation of Change

7  Baseline First:  Target First

8  The formality and nature of established process checkpoints within the organization.  The level of stakeholder involvement expected within the process.  The number of teams involved and the relationships between different teams  The maturity of the solution area and the expected amount of rework and refinement required to arrive at an acceptable solution.

9  Attitude to risk.  The class of engagement

10  Strategic Architecture  Segment Architecture  Capability Architecture

11  Landscape maps are a technique for visualizing enterprise architectures. They present architectural elements in the form of an easy to understand 2D ’map’. A landscape map view on architectures provides non-technical stake- holders, such as managers, with a high-level overview, without burdening them with technicalities of architectural drawings.

12

13  The focus of the security architect is enforcement of security policies of the enterprise

14  Security architecture has its own discrete security methodology.  Security architecture composes its own discrete views and viewpoints.  Security architecture addresses non-normative flows through systems and among applications.  Security architecture introduces its own normative flows through systems and among applications.  Security architecture introduces unique, single-purpose components in the design.  Security architecture calls for its own unique set of skills and competencies of the enterprise and IT architects.

15  Security is called out separately because it is infrastructure that is rarely visible to the business function

16  Authentication  Authorization:  Audit:  Assurance  Availability:  Asset Protection  Administration:  Risk Management

17  Scope the enterprise organizations impacted by the security architecture  Define and document applicable regulatory and security policy requirements  Define the required security capability as part of Architecture Capability  Implement security architecture tools

18  Scope the enterprise organizations impacted by the security architecture  Define and document applicable regulatory and security policy requirements  Define the required security capability as part of Architecture Capability  Implement security architecture tools

19  Obtain management support for security measures  Define necessary security-related management sign-off milestones of this architecture development cycle  Determine and document applicable disaster recover y or business continuity plans/requirements  Identify and document the anticipated physical/business/regulator y environment(s) in which the system(s) will be deployed  Determine and document the criticality of the system: safety- critical/mission-critical/noncritical

20  Determine who are the legitimate actors who will interact with the  product/service/process  Assess and baseline current security-specific business processes (enhancement of  existing objective)  Determine whom/how much it is acceptable to inconvenience in utilizing security  Measures  Identify and document interconnecting systems beyond project control  Determine the assets at risk if something goes wrong — ‘‘What are we trying to protect?’’  Determine the cost (both qualitative and quantitative) of asset loss/impact in failure cases  Identify and document the ownership of assets  Determine and document appropriate security forensic processes  Identify the criticality of the availability and correct operation of the overall service  Determine and document how much security (cost) is justified by the threats and the  value of the assets at risk  Reassess and confirm Architecture Vision decisions  Assess alignment or conflict of identified security policies with business goals  Determine ‘‘what can go wrong?’’

21  Assess and baseline current security-specific architecture elements (enhancement of existing objective)  Identify safe default actions and failure states  Identify and evaluate applicable recognized guidelines and standards  Revisit assumptions regarding interconnecting systems beyond project control  Determine and document the sensitivity or classification level of information  stored/created/used  Identify and document custody of assets  Identify the criticality of the availability and correct operation of each function  Determine the relationship of the system under design with existing business  disaster/continuity plans  Identify what aspects of the system must be configurable to reflect changes in policy/business environment/access control  Identify lifespan of information used as defined by business needs and regulatory Requirements  Determine approaches to address identified risks:  Identify actions/events that warrant logging for later review or triggering forensic Processes  Identify and document requirements for rigor in proving accuracy of logged events (nonrepudiation)  Identify potential/likely avenues of attack  Determine ‘‘what can go wrong?’’

22  Assess and baseline current security-specific technologies (enhancement of existing objective)  Revisit assumptions regarding interconnecting systems beyond project control  Identify and evaluate applicable recognized guidelines and standards  Identify methods to regulate consumption of resources  Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis  Identify the trust (clearance) level of:  Identify minimal privileges required for any entity to achieve a technical or business Objective  Identify mitigating security measures, where justified by risk assessment  Determine ‘‘what can go wrong?’’

23  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?’’

24  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 recover y and business continuity plans or modifications  Determine ‘‘what can go wrong?’’

25  Establish architecture artifact, 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;  Determine ‘‘what has gone wrong?’’

26  Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

27  SOA focuses on structuring applications in a way that facilitates system flexibility and agility  Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.  Service-orientation is a way of thinking in terms of services and service- based development and the outcomes of services.  SOA places unique requirements on the infrastructure

28

29  Preliminary Phase  Principle of Service-Orientation  Governance and Support Strategy  Partitions and Centers of Excellence  Architecture Repository

30

31  Phase A: Architecture Vision  Stakeholders, Concerns, and Business Requirements

32  Key entities include:  Event  Process  Business Service  IS Service  Platform ser vice  Logical Application and Technology Component  Physical Application and Technology Component  Data entity  Role  Service Quality  Contract  Location  Business Information (not in metamodel)  Logical Information Components (not in metamodel)  Business Rules (not in metamodel)

33


Download ppt "Guidelines.  Applying Iteration to the ADM  Applying the ADM across the Architecture Landscape  Security Architecture and the ADM  Using TOGAF to."

Similar presentations


Ads by Google