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
Business Transformation Readiness Assessment
Determine Readiness Factors
Accountability is the assignment of specific and appropriate responsibility, recognition of measurable expectations by all concerned parties, and alignment of decision-making with areas of responsibility and with where the impact of the decisions will be felt
Workable Approach and Execution Model is an approach that makes sense relative to the task, with a supporting environment, modeled after a proven approach
IT Capacity to Execute is the ability to perform all the IT tasks required by the project, including the skills, tools, processes, and management capability
Enterprise Capacity to Execute is the ability of the enterprise to perform all the tasks required by the endeavor, in areas outside of IT, including the ability to make decisions within the tight time constraints typical to project environments based upon the recent successful execution of a similar endeavor of at least half the size and complexity
Enterprise Ability to Implement and Operate the transformation elements and their related business processes, absorb the changes arising from implementation, and ongoing ability to operate in the new environment
Business Transformation Readiness Assessment
Assess Readiness Factors
- The assessment should address three things, namely:
- ■ Readiness Factor Vision
- ■ Readiness Factor Rating
- ■ Urgency, whereby if a readiness factor is urgent, it means that action is needed before a transformation initiative can begin
- ■ Readiness Status, which is rated as either Low (needs substantial work before proceeding), Fair (needs some work before proceeding), Acceptable (some readiness issues exist; no showstoppers), Good (relatively minor issues exist), or High (no readiness issues)
- ■ Degree of Difficulty to Fix rates the effort required to overcome any issues identified as either No Action Needed, Easy, Moderate, or Difficult
- ■ Readiness Factor Risks & Actions
Business Transformation Readiness Assessment
The assessment exercise will provide a realistic assessment of the organization and will be a key input into the strategic migration planning that will be initiated in Phase E and completed in Phase F.
The readiness factors, as part of an overall Implementation and Migration Plan, will have to be continuously monitored (Phase G) and rapid corrective actions taken through the IT governance framework to ensure that the defined architectures can be implemented.
Risk Management
Risk management, which is a technique used to mitigate risk when implementing an architecture project.
There are two levels of risk that should be considered, namely:
- Initial Level of Risk: risk categorization prior to determining and implementing mitigating actions
- Residual Level of Risk: risk categorization after implementation of mitigating actions (if any)
The process for risk management is described in the following sections and consists of the following activities:
■ Risk classification ■ Risk identification ■ Initial risk assessment ■ Risk mitigation and residual risk assessment ■ Risk monitoring
Risk Assessment
Catastrophic infers critical financial loss that could result in bankruptcy of the organization
Risk Management
Risk Assessment
Effect
- Catastrophic infers critical financial loss that could result in bankruptcy of the organization
- Critical infers serious financial loss in more than one line of business leading to a loss in productivity and no return on investment on the IT investment
- Marginal infers a minor financial loss in a line of business and a reduced return on investment on the IT investment
- Negligible infers a minimal impact on a line of business’ ability to deliver services and/or products
Frequency
- Frequent: likely to occur very often and/or continuously
- Likely: occurs several times over the course of a transformation cycle
- Occasional: occurs sporadically
- Seldom: remotely possible and would probably occur not more than once in the course of a transformation cycle
- Unlikely: will probably not occur during the course of a transformation cycle
Risk Management
Risk Assessment
A potential scheme to assess corporate impact could be as follows:
- Extremely High Risk (E): the transformation effort will most likely fail with severe consequences
- High Risk (H): significant failure of parts of the transformation effort resulting in certain goals not being achieved
- Moderate Risk (M): noticeable failure of parts of the transformation effort threatening the success of certain goals
- Low Risk (L): certain goals will not be wholly successful
Risk Monitoring and Governance (Phase G)
Capability-Based Planning
Capability-based planning, a business planning technique that focuses on business outcomes. It also copes well with the friction of co-ordinating projects across corporate functional domains that together enable the enterprise to achieve that capability (for example, electronic service delivery)
Capability-based planning frames all phases of the architecture development in the context of business outcomes, clearly linking the IT vision, architectures (ABBs and SBBs), and the Implementation and Migration Plans with the corporate strategic, business, and line-of-business plans.
Capability Increments
Specific capabilities targeted for completion will be the focus of the Architecture Definition (Phases B, C, and D) and, based upon the identified work packages, Phase E projects will be conceived. The capability increments will be the drivers for the Transition Architectures (Phase E) that will structure the project increments. The actual delivery will be co-ordinated through the Implementation and Migration Plans (Phase F)
