Guidelines and Tools for ADM

1. Guidelines and Tools for ADM Guidelines

2. What to keep in mind • Applying Iteration to the ADM • Applying the ADM across the Architecture Landscape • Security Architecture and the ADM • Using TOGAF to Define & Govern SOAs

3. What to keep in mind • Architecture Principles • Stakeholder Management • Architecture Patterns • Business Scenarios

4. What to keep in mind • Gap Analysis • Migration Planning Techniques • Interoperability Requirements • Business Transformation Readiness Assessment • Risk Management • Capability-Based Planning

5. Types of iterations • Architecture Capability iterations • Architecture Development iterations • Transition Planning iterations • Architecture Governance iterations

6. Engagement for architects • Identification of Required Change • Definition of Change • Implementation of Change

7. Approaches to Architecture Development • Baseline First: • Target First

8. Points for iteration • 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. Points for Iteration • Attitude to risk. • The class of engagement

10. Architecture Landscape • Strategic Architecture • Segment Architecture • Capability Architecture

11. Landscapes • 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. Criteria to decide the landscape

13. Security • The focus of the security architect is enforcement of security policies of the enterprise

14. Security • 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. Why Separate ? • Security is called out separately because it is infrastructure that is rarely visible to the business function

16. Concerns in Security • Authentication • Authorization: • Audit: • Assurance • Availability: • Asset Protection • Administration: • Risk Management

17. How • 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. Security - Preliminary Phase • 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. Security considerations on Phase A • 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. Security considerations on Phase B • 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. Security considerations on Phase C: Information Systems Architectures • 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. Security considerations on Phase D: Technology Architecture • 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. Security considerations on Phase 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?’’

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

25. Security considerations on Phase G: Implementation Governance • 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. Security considerations on Phase H: Architecture Change Management • Determine ‘‘what has gone wrong?’’ • Incorporate security-relevant changes to the environment into the requirements for future enhancement (enhancement of existing objective)

27. SOA • 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. SOA

29. TOGAF for SOA • Preliminary Phase • Principle of Service-Orientation • Governance and Support Strategy • Partitions and Centers of Excellence • Architecture Repository

30. How SOA is supported

31. Where SOA comes first • Phase A: Architecture Vision • Stakeholders, Concerns, and Business Requirements

32. Key Entities in SOA TOGAF content metamodel to be used in all other phases • 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. E.g: Implementing SOA with BPEL