1. Guidelines and Tools for ADM

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