Transcript Guidelines and Tools for ADM

Guidelines




Applying Iteration to the ADM
Applying the ADM across the Architecture Landscape
Security Architecture and the ADM
Using TOGAF to Define & Govern SOAs




Architecture Principles
Stakeholder Management
Architecture Patterns
Business Scenarios






Gap Analysis
Migration Planning Techniques
Interoperability Requirements
Business Transformation Readiness Assessment
Risk Management
Capability-Based Planning




Architecture Capability iterations
Architecture Development iterations
Transition Planning iterations
Architecture Governance iterations



Identification of Required Change
Definition of Change
Implementation of Change


Baseline First:
Target First




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.


Attitude to risk.
The class of engagement



Strategic Architecture
Segment Architecture
Capability Architecture

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 stakeholders, such as managers, with a high-level overview, without burdening
them with technicalities of architectural drawings.

The focus of the security architect is enforcement of security policies of the
enterprise






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 is called out separately because it is infrastructure that is rarely
visible to the business function








Authentication
Authorization:
Audit:
Assurance
Availability:
Asset Protection
Administration:
Risk Management




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




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





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: safetycritical/mission-critical/noncritical

















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?’’

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?’’









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?’’





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?’’





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?’’




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?’’


Determine ‘‘what has gone wrong?’’
Incorporate security-relevant changes to the environment into the
requirements for future enhancement (enhancement of existing objective)




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 servicebased development and the outcomes of services.
SOA places unique requirements on the infrastructure





Preliminary Phase
Principle of Service-Orientation
Governance and Support Strategy
Partitions and Centers of Excellence
Architecture Repository

Phase A: Architecture Vision

Stakeholders, Concerns, and Business Requirements
















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)