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

Guidelines and Tools for ADMGuidelines

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

What to keep in mind

Architecture Capability iterations Architecture Development iterations Transition Planning iterations Architecture Governance iterations

Types of iterations

Identification of Required Change Definition of Change Implementation of Change

Engagement for architects

Baseline First: Target First

Approaches to Architecture Development

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

Points for Iteration

Strategic Architecture Segment Architecture Capability Architecture

Architecture Landscape

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.

Landscapes

Criteria to decide the landscape

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.

Security

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

Why Separate ?

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

Concerns in Security

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

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

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 A

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 B

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 C: Information Systems Architectures

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 D: Technology Architecture

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 Opportunities & Solutions

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 F: Migration Planning

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 G: Implementation Governance

Determine ‘‘what has gone wrong?’’ Incorporate security-relevant changes to the environment into the

requirements for future enhancement (enhancement of existing objective)

Security considerations on Phase H: Architecture Change Management

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

SOA

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

TOGAF for SOA

How SOA is supported

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

Where SOA comes first

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)

Key Entities in SOA TOGAF content metamodel to be used in all other phases

E.g: Implementing SOA with BPEL