ADM Guidelines & Techniques Flashcards
Part III: ADM Guidelines & Techniques.
Techniques for Architecture Development
- Architecture Principles
- Stakeholder Management
- Architecture Patterns
- Gap Analysis
- Migration Planning Techniques
- Interoperability Requirements
- Business Transformation Readiness Assessment
- Risk Management
- Capability-Based Planning
Part III: ADM Guidelines & Techniques.
Architecture Capability iterations Preliminary - Phase H
Architecture Development - Phase B - Phase F
Transition Planning Phase E - Phase F
Architecture Governance Phase G - Phase H
Applying the ADM Across the Architecture Landscape
Levels provide a framework for dividing the Architecture Landscape into three levels of granularity:
- Strategic Architecture provides an organizing framework for operational and change activity and allows for direction setting at an executive level.
- Segment Architecture provides an organizing framework for operational and change activity and allows for direction setting and the development of effective architecture roadmaps at a program or portfolio level.
- Capability Architecture provides an organizing framework for change activity and the development of effective architecture roadmaps realizing capability increments.
Architecture Principles
Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.
Enterprise Principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission
Architecture Principles areaset of principles that relate to architecture work
Name :easy to remember,Specific technology platforms should not be mentioned,Avoid ambiguous words
Statement:Should succinctly and unambiguously communicate the fundamental rul
Rationale:Should highlight the business benefits of adhering to the principle, using business terminology.
Implications:Should highlight the requirements, both for the business and IT, for carrying out the principle — in terms of resources, costs, and activities/tasks.
Architecture Principles
Developing Architecture Principles
Specifically, the development of Architecture Principles is typically influenced by the following:
- Enterprise mission and plans: the mission, plans, and organizational infrastructure of the enterprise
- Enterprise strategic initiatives: the characteristics of the enterprise — its strengths, weaknesses, opportunities, and threats — and its current enterprise-wide initiatives (such as process improvement and quality management)
- External constraints: market factors (time-to-market imperatives, customer expectations, etc.); existing and potential legislation
- Current systems and technology: the set of information resources deployed within the enterprise, including systems documentation, equipment inventories, network configuration diagrams, policies, and procedures
- Emerging industry trends: predictions about economic, political, technical, and market factors that influence the enterprise environment
Architecture Principles
Qualities of Principles
There are five criteria that distinguish a good set of principles:
- Understandable: the underlying tenets can be quickly grasped and understood by individuals throughout the organization The intention of the principle is clear and unambiguous, so that violations, whether intentional or not, are minimized.
- Robust: enable good quality decisions about architectures and plans to be made, and enforceable policies and standards to be created Each principle should be sufficiently definitive and precise to support consistent decisionmaking in complex, potentially controversial situations.
- Complete: every potentially important principle governing the management of information and technology for the organization is defined — the principles cover every situation perceived
- Consistent: strict adherence to one principle may requirealoose interpretation of another principle
- Stable: principles should be enduring, yet able to accommodate changes
Stakeholder Management
Stakeholder analysis should be used during Phase A (Architecture Vision) to identify the key players in the engagement, and also be updated throughout each phase; different stakeholders may be uncovered as the engagement progresses through into Opportunities & Solutions, Migration Planning, and Architecture Change Management.
readiness of each stakeholder to behave in a supportive manner
a power/interest matrix,
Stakeholder Map
Architecture Patterns
A “pattern” has been defined as: “an idea that has been useful in one practical context and will probably be useful in others”
Name-Problem-Context-Forces-Solution-Resulting Context -Examples-Rationale-Related Patterns - Known Uses
An Architecture Pattern expresses a fundamental structural organization or schema for software systems
A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them
An Idiom is a low-level pattern specific to a programming language
Gap Analysis
The basic premise is to highlight a shortfall between the Baseline Architecture and the Target.
Potential sources of gaps include:
Business domain gaps: — People gaps (e.g., cross-training requirements) — Process gaps (e.g., process inefficiencies) — Tools gaps (e.g., duplicate or missing tool functionality) — Information gaps — Measurement gaps — Financial gaps — Facilities gaps (buildings, office space, etc.)
Data domain gaps: — Data not of sufficient currency — Data not located where it is needed — Not the data that is needed — Data not available when needed — Data not created — Data not consumed — Data relationship gaps
Applications impacted, eliminated, or created
Technologies impacted, eliminated, or created
Migration Planning Techniques
Implementation Factor Assessment & Deduction Matrix (Phase E - Phase F)
The technique of creating an Implementation Factor Assessment and Deduction matrix can be used to document factors impacting the architecture Implementation and Migration Plan.
Factors typically include: ■ Risks ■ Issues ■ Assumptions ■ Dependencies ■ Actions ■ Impacts
Consolidated Gaps, Solutions, & Dependencies Matrix (work packages Phase E - Phase F)
The technique of creating a Consolidated Gaps, Solutions, and Dependencies matrix allows the architect to group the gaps identified in the domain architecture gap analysis results and assess potential solutions and dependencies to one or more gaps
Migration Planning Techniques
Architecture Definition Increments Table
The technique of creating an Architecture Definition Increments table allows the architect to plan a series of Transition Architectures outlining the status of the Enterprise Architecture at specified times.
Transition Architecture State Evolution Table
The technique of creating the Transition Architecture State Evolution table allows the architect to show the proposed state of the architectures at various levels using the defined taxonomy
Business Value Assessment Technique
Interoperability Requirements
A definition of interoperability is “the ability to share information and services”.
The determination of interoperability is present throughout the Architecture Development Method (ADM) as follows:
- In the Architecture Vision (Phase A), the nature and security considerations of the information and service exchanges are first revealed within the business scenarios
- In the Business Architecture (Phase B), the information and service exchanges are further defined in business terms
- In the Data Architecture (Phase C), the content of the information exchanges is detailed using the corporate data and/or information exchange model
- In the Application Architecture (Phase C), the way that the various applications are to share the information and services is specified
- In the Technology Architecture (Phase D), the appropriate technical mechanisms to permit the information and service exchanges are specified
- In Opportunities & Solutions (Phase E), the actual solutions (e.g., Commercial Off-TheShelf (COTS) packages) are selected
- In Migration Planning (Phase F), the interoperability is logically implemented
Interoperability Requirements
Many organizations find it useful to categorize interoperability as follows:
- Operational or Business Interoperability defines how business processes are to be shared
- Information Interoperability defines how information is to be shared
- Technical Interoperability defines how technical services are to be shared or at least connect to one another
From an IT perspective, it is also useful to consider interoperability in a similar vein to Enterprise Application Integration (EAI); specifically:
Presentation Integration/Interoperability is where a common look-and-feel approach through a common portal-like solution guides the user to the underlying functionality of the set of systems
Information Integration/Interoperability is where the corporate information is seamlessly shared between the various corporate applications to achieve, for example, a common set of client information Normally this is based upon a commonly accepted corporate ontology and shared services for the structure, quality, access, and security/privacy for the information.
Application Integration/Interoperability is where the corporate functionality is integrated and shareable so that the applications are not duplicated (e.g., one change of address service/component; not one for every application) and are seamlessly linked together through functionality such as workflow This impacts the business and infrastructure applications and is very closely linked to corporate business process unification/interoperability.
Technical Integration/Interoperability includes common methods and shared services for the communication, storage, processing, and access to data primarily in the application platform and communications infrastructure domains
Interoperability Requirements
The corporate operating model will normally indicate what type of interoperability approach will be appropriate. This model should be determined in Phase A (Architecture Vision) if not in Phase B (Business Architecture), and definitely by Phase E (Opportunities & Solutions).
Implementing interoperability requires the creation, management, acceptance, and enforcement of realistic standards that are SMART (Specific, Measurable, Actionable, Realistic, and Timebound). Clear measures of interoperability are key to success.
four degrees of interoperability as follows
Degree 1: Unstructured Data Exchange involves the exchange of human-interpretable unstructured data, such as the free text found in operational estimates, analysis, and papers
Degree 2: Structured Data Exchange involves the exchange of human-interpretable structured data intended for manual and/or automated handling, but requires manual compilation, receipt, and/or message dispatch
Degree 3: Seamless Sharing of Data involves the automated sharing of data amongst systems based on a common exchange model
Degree 4: Seamless Sharing of Information is an extension of Degree 3 to the universal interpretation of information through data processing based on co-operating applications
Business Transformation Readiness Assessment
Business Transformation Readiness Assessment, used for evaluating and quantifying an organization’s readiness to undergo change.
The recommended activities in an assessment of an organization’s readiness to address business transformation are:
- Determine the readiness factors that will impact the organization
- Present the readiness factors using maturity models
- Assess the readiness factors, including determination of readiness factor ratings
- Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
- Work these actions into Phase E and F Implementation and Migration Plan
The Canadian Government Business Transformation Enablement Program (BTEP
Business Transformation Readiness Assessment
Determine Readiness Factors
Vision is the ability to clearly define and communicate what is to be achieved
Desire, Willingness, and Resolve is the presence of a desire to achieve the results, willingness to accept the impact of doing the work, and the resolve to follow through and complete the endeavor
Need, in that there is a compelling need to execute the endeavor
Business Case exists that creates a strong focus for the project, identifying benefits that must be achieved and thereby creating an imperative to succeed
Funding, in the form of a clear source of fiscal resources, exists that meets the endeavor’s potential expenditures
Sponsorship and Leadership exists and is broadly shared, but not so broad as to diffuse accountability
Governance is the ability to engage the involvement and support of all parties with an interest in or responsibility to the endeavor with the objective of ensuring that the corporate interests are served and the objectives achieved
