Guidelines and Tools for ADM

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

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

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

Types of iterations Architecture Capability iterations Architecture Development iterations Transition Planning iterations Architecture Governance iterations

Engagement for architects Identification of Required Change Definition of Change Implementation of Change

Approaches to Architecture Development Baseline First: Target First

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.

Points for Iteration Attitude to risk. The class of engagement

Architecture Landscape Strategic Architecture Segment Architecture Capability Architecture

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.

Criteria to decide the landscape

Security The focus of the security architect is enforcement of security policies of the enterprise

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.

Why Separate ? Security is called out separately because it is infrastructure that is rarely visible to the business function

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

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

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

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

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

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

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

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

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

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

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)

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

SOA

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

How SOA is supported

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

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)

E.g: Implementing SOA with BPEL