Business Architecture / IT Alignment Flashcards
1
Q
Business/IT architecture alignment is the fundamental link that enables ___ to be translated into IT architectural concepts and deployable solutions.
A
Business strategy, vision, design, and requirements
2
Q
Business/IT architecture alignment is the fundamental link that enables business strategy, vision, design, and requirements to be translated into
A
IT architectural concepts and deployable solutions.
3
Q
Have direct, traceable, and unambiguous relationships to IT application and data architecture.
A
Capabilities, value streams, and information concepts
4
Q
Business/IT architecture alignment enables IT to leverage strategic impacts on the business architecture to drive __, __, __, and __ as appropriate to a given business strategy.
A
IT architecture planning, decision making, evolution, and transformation
5
Q
The four aspects of IT architecture (___) collectively enable and automate business capabilities, value streams, and information concepts.
A
Application, data, technical and shadow system domains
6
Q
Is a blueprint of the data and related data structures business professionals rely on to run the business.
A
Data architecture
7
Q
Provides views into the business systems and services that deliver value to business professionals and customers.
A
Application architecture
8
Q
Represents the underlying platforms, languages, operating systems, security software, middleware, and supporting technologies required to enable an overall IT environment.
A
Technical architecture
9
Q
Lie beyond the line of sight of IT and create a fourth category of automation deployed by the business and frequently omitted from representations of IT architecture.
A
Shadow systems
10
Q
The most visible aspect of IT architecture to the business and is comprised of in-house application software and services, third party software, and external systems such as found within cloud implementations
A
Application architecture
11
Q
Deployment of reusable, automated business services that can be leveraged broadly across any number of front-end, process automation, case management, and other automation environments is a sign of
A
Higher IT maturity
12
Q
When workflow rules are externalised and decoupled from application deployments, providing improved agility for modifying state transition and workflow automation there is
A
Higher IT maturity
13
Q
Includes the formal and informal representations of the data used by the business.
A
Data architecture
14
Q
Includes various types of conceptual, logical, and physical data models.
A
Data architecture
15
Q
Represented by additional drawings, data layouts, or physical deployment views.
A
Current state data representations
16
Q
Data architecture is an important component in a robust IT architecture because it formalises __ and enables __.
A
the management of business information, deployment of agile application architecture.
17
Q
Ensures that data architecture reflects business information so that rapid, flexible access to information is established as the norm in organisations and not as the exception.
A
Evolving data architectures from information concepts
18
Q
Flexible information access enables more effective __, __, __, __, and timely __ to customers and other key stakeholders.
A
Customer management, financial reporting, market analysis, competitive analysis, and timely delivery of products and services
19
Q
Any business-owned, business-maintained technology not under IT stewardship.
A
Shadow system
20
Q
Support numerous critical business capabilities across an enterprise.
A
Shadow systems
21
Q
Executive reports, business intelligence, or operational roles processed and supported by Excel, Access, or more sophisticated tools are examples of
A
Shadow systems
22
Q
Augment manual tasks and limitations in data and application architectures.
A
Shadow systems
23
Q
Often represent crucial automations that should be considered in a business/IT alignment effort.
A
Shadow systems
24
Q
Informally automate portions of the application architecture and aspects of technical architecture that are beyond IT’s line of sight.
A
Shadow systems
25
Data often resides within shadow systems that do not
Exist within the formal view of data architecture.
26
Shadow systems can be thought of as the ___, often resulting in shadow architectures that are misaligned with formal data and application architectures.
Opaque application and data architectures
27
Analogous to the wiring and plumbing that runs through a building, ship, or city.
Technical architecture
28
Enables data architecture, application architecture, and shadow systems that directly service business professionals
Technical architecture
29
A secondary consideration in business- driven, business/IT architecture alignment.
Technical architecture
30
If improvements or transformation requirements can be established from an application and data architecture perspective, IT can apply best practices to
define and implement a technical architecture that enables the appropriate application and data architectures.
31
The information map is implemented by
Data architecture
32
The value map is the basis for prioritising & packaging requirements for
Process & Case Management Automation, Service Choreography, UI Deployment
33
The capability map is the basis for prioritising & packaging requirements for
Deployable Business Services
34
The importance of information-to-data mapping is that it provides a foundation of __ and __ that equip data architects with concise, agreed-upon building blocks for the data architecture.
Business semantics and basic relationship concepts
35
The importance of information-to-data mapping is that it provides a foundation of business semantics and basic relationship concepts that equip data architects with
Concise, agreed-upon building blocks for the data architecture.
36
Value streams provide a framework for envisioning how the business can establish ___ to enable a case to visibly transition across and among value streams.
Innovative solutions for managing stakeholder interaction and automation
37
Value streams provide a framework for envisioning how the business can establish innovative solutions for managing
Stakeholder interaction and automation to enable a case to visibly transition across and among value streams.
38
Provides a basis for transforming application architecture, including establishment and use of new automated business services
Capability mapping
39
Capabilities can be mapped directly to current state application architecture, which allows a business to ___, ___, and ___ to address these and related challenges.
Determine where a given capability is automated, if it is automated consistently, and what type of strategy should be employed
40
Where no mapping to IT automation exists, it is a sign of a capability that has __, or __, which can also be incorporated into analysis.
No automation, or may be automated through shadow systems,
41
Capability to application architecture mapping provides business and IT with a concise set of ___ and, as a result, provide insights into design, transformation, modernisation, and automation options.
conceptual business/IT mappings that can be driven down to a significant degree of detail
42
Capability to application architecture mapping provides business and IT with a concise set of conceptual business/IT mappings that can be driven down to a significant degree of detail and, as a result, provide insights into
Design, transformation, modernisation, and automation options.
43
1. Establish baseline capability, value, and information maps as discussed in the BIZBOK® Guide part 2.
Business/IT Architecture Mapping Guideline
44
2. Craft business strategy, business model interpretation, and business priorities in the context of their impact on the business architecture.
Business/IT Architecture Mapping Guideline
45
3. Use the business information map and related business objectives to craft target state data architecture or modify current-state data architecture.
Business/IT Architecture Mapping Guideline
46
4. Use value stream priorities and related business designs to drive end-to-end process, case management, and user interface deployment designs.
Business/IT Architecture Mapping Guideline
47
5. Use capability map and related business objectives to identify current state application architecture strategies.
Business/IT Architecture Mapping Guideline
48
6. Use capability map to identify and specify target state services requirements.
Business/IT Architecture Mapping Guideline
49
7. Apply variations on the above guidelines based on specific situations, requirements, scenarios, and funding availability.
Business/IT Architecture Mapping Guideline
50
Support new financial fund models that the market is increasingly demanding
Business/IT Architecture Alignment Usage Scenario Example
51
Deploy certain new products that the application systems were never built to support
Business/IT Architecture Alignment Usage Scenario Example
52
Address new regional expansion requirements that place demands on individual applications that had to be addressed in externally developed systems or desktop solutions
Business/IT Architecture Alignment Usage Scenario Example
53
Align business information for executive reporting, competitive analysis, profitability analysis, and streamline deployment of new requirements.
Business/IT Architecture Alignment Usage Scenario Example
54
Business architecture represents a business in the absence of any IT architecture while enterprise architecture provides
An overarching framework for business and IT architecture.
55
Business architecture represents __ while enterprise architecture provides an overarching framework for business and IT architecture.
A business in the absence of any IT architecture
56
A widely practiced discipline for understanding an organisation and furthering that organisation’s mission, goals, and practices.
Enterprise architecture
57
Subject Area: Describes architecture in terms of the subjects (typically called domains) that it covers. In general, each domain can be decomposed into more detailed subject areas.
Architectural Foundation
58
Artefacts: Describes architecture in terms of the blueprints that are produced.
Architectural Foundation
59
Methods: Describe architecture in terms of the activities that are performed by
architects to produce the artefacts specific to each domain.
Architectural Foundation
60
Business Architecture Foundational Domains:
Capability, Value, Information, Organisation
61
Business Architecture Extended Domains:
Vision, Strategy, Tactics; Products and Services; Policies, Rules, Regulations; Events; Stakeholders; Initiatives and Projects; Measures and Metrics
62
Business Architecture Foundational Artefacts:
Capability Map, Value Map, Information Map, Organisation Map, Cross Mappings
63
Business Architecture Extended Artefacts:
Strategy Map, Initiative Map, Stakeholder Map, Product Map
64
Business Architecture Methods:
Capability Mapping, Value Mapping, Information Mapping, Organisation Mapping, Cross-mapping, Extended Domain Mappings, Scenario Analysis, Root Cause Analysis; etc.
65
Enterprise Architecture Foundations:
Business Architecture Data Architecture Application Architecture Technology Architecture
66
For each architectural domain, there is an associated set of concerns, goals, or concepts.
Concerns, goals, or concepts.
67
For each architectural domain, each set of concerns, goals, or concepts can be described by some kind of
Conceptual model and perhaps documented in a commonly used formal model.
68
An important factor is the scope of a particular architecture effort or focus:
Enterprise level scope, and project level scope.
69
The business architect is concerned with defining the business such that strategies and goals
Can be clearly articulated
70
The business architect is concerned with defining the business such that management decisions
Can be based on facts
71
The business architect is concerned with defining the business such that transformations
Can be focused on the most important aspects
72
The business architect is concerned with defining the business such that issues
Can be addressed based on clarity and facts, rather than hunches.
73
At the project level, business architects seek ___ with systems implementations, often within a single business unit.
To align business requirements, established in an enterprise context,
74
The data architect is concerned with providing a managed information environment for
Operational and transactional data.
75
The data architect is concerned with transforming data into
Information to support business analysis and reporting.
76
At the enterprise level, the data architect wants to provide a
Consistent view and usage of operational data across multiple applications
77
At the enterprise level, the data architect wants to rationalise
Data and information storage to minimise duplication and simplify access.
78
The data architect is interested in commonality, specifically in providing a common mechanism for ___, sometimes called data flow architecture.
Moving and transforming operational data into analytical data
79
The data architect is interested in commonality, specifically in providing a common mechanism for moving and transforming operational data into analytical data, sometimes called
Data flow architecture.
80
Information models are typically created as conceptual Entity Relationship Diagrams (ERD) where the important concepts are
Enterprise entities, and the relationships and constraints associated with them.
81
At the project level, the information architect is concerned with information that has a more limited scope:
Access and utilisation of the information is based on business rules and is governed by security and privacy requirements of both the enterprise and the application.
82
Access and utilisation of the information is based on __ and is governed by security and privacy requirements of both the enterprise and the application.
Business rules
83
Access and utilisation of the information is based on business rules and is governed by
Security and privacy requirements of both the enterprise and the application.
84
At the project level, a data model describes the application level information, which is likely to be
Different than (but related to) the common enterprise information model.
85
The application architect is concerned with commonality
In applications.
86
At the enterprise level, this means creating reference models and standards that specify a common structure or architectural style that promotes sharing
Of common responsibilities
87
At the enterprise level, this means creating reference models and standards that specify a common structure or architectural style that promotes using
Common services in a consistent fashion
88
At the enterprise level, this means creating reference models and standards that specify a common structure or architectural style that promotes supporting
A common user interaction style and configuration mechanisms
89
At the enterprise level, this means creating reference models and standards that specify a common structure or architectural style that promotes using
A standard technology platform, having common management, monitoring and operations procedures, etc.
90
The application architect is concerned with commonality in applications to improve
Integration between applications
91
The application architect is concerned with commonality in applications to allow for
Sharing of common information
92
The application architect is concerned with commonality in applications to have
Consistent results for the same operation no matter how it is performed
93
The application architect is concerned with commonality in applications to reduce
The cost and complexity of maintenance and enhancements.
94
To achieve commonality in applications goals, the application architect first specifies the
Architectural styles to be used and specific roles and responsibilities of the architectural elements that make up that style.
95
Technology aspects such as __, __, __, and __ are factored into the reference architecture, not each individual project.
Performance, scalability, reliability, and security
96
A formal modelling discipline for specifying architecture.
Unified Modeling Language (UML)
97
At the project level, the application architect is concerned with applying ___ to a specific project.
The enterprise context (reference models, patterns, standards, guidelines, templates)
98
It is the responsibility of the application/solution architect to help the project meet requirements in a way
That conforms to the enterprise application architecture.
99
The technology architect is responsible for providing common platforms that support
The different (hopefully few) application architecture styles with the appropriate quality of service.
100
At the project level, technology is tasked with ___ and integrating it into the common management, security, backup, services, and related systems and plans.
Provisioning a specific instance of the standard platform for the specific application
101
At the project level, technology is tasked with provisioning a specific instance of the standard platform for the specific application and
Integrating it into the common management, security, backup, services, and related systems and plans.
102
Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders
Architecture Framework
103
Information identifying the framework
Vocabulary and taxonomy
One or more concerns or abstractions
One or more stakeholders having those concerns
One or more architecture viewpoints and their specifications Rules that integrate the viewpoints
Conditions on applicability.
Specified by architecture frameworks
104
A schema for describing all aspects of the enterprise in terms of fundamental, unique primitives.
Zachman Framework
105
The largest and most well-known component of TOGAF
Architecture Development Method (ADM)
106
DoDAF describes a system in terms of eight different viewpoints:
All Viewpoint (AV), Capability Viewpoint (CV), Data and Information Viewpoint (DIV), Operational Viewpoint (OV), Project Viewpoint (PV), Services Viewpoint (SvcV), Standard Viewpoint (StdV), and Systems Viewpoint (SV)
107
The Zachman Framework focuses on the core value of the framework as an
Ontology of fundamental enterprise concepts, or primitives
108
The Zachman primitives are defined from the intersection of six interrogative categories: What, How, Where, Who, When, Why, and six perspectives: Executive, Business Management, Architect, Engineer, Technician, and Enterprise.
Executive, Business Management, Architect, Engineer, Technician, and Enterprise.
109
The Zachman primitives are defined from the intersection of six interrogative categories: ___, and six perspectives:
What, How, Where, Who, When, Why
110
The business architect is interested in the top two audience perspectives (rows) in the Zachman Framework
The Executive Perspective and the Business Management Perspective
111
Zachman - What:
The information map describes “what” information the enterprise needs
112
Zachman - How:
Capability: From the perspective of the Zachman framework, the How column is defining what business transformations an organisation performs, not how those transformations are executed.
113
Zachman - Where:
The organisation map describes “where” in the enterprise things are done.
114
Zachman - Who:
Stakeholder identification describes “who” (customers, employees, suppliers, partners) interacts with the enterprise (internally and externally) and what their responsibilities are.
115
Zachman - When:
No current mapping.
116
Zachman - Why:
Business Strategy Maps and the Business Motivation Model describe why things are done and how to measure them.
117
Identifying a unique primitive (like the capability), allows us to create
Composites (mappings) that bring clarity to the redundancies, gaps, and inefficiencies.
118
BIZBOK Business Blueprint: Business Strategy Map
Zachman Framework Concept: Motivation Types; Buiness Ends, Business Means
119
BIZBOK Business Blueprint: Capability Map
Zachman Framework Concept: Business Transformations
120
BIZBOK Business Blueprint: Organization Map
Zachman Framework Concept: Distribution Types; Locations
121
BIZBOK Business Blueprint: Value Map
Zachman Framework Concept: Composite of: Process Types, Transforms; Business Ends; Responsibiliy Types
122
BIZBOK Business Blueprint: Business Information Map
Zachman Framework Concept: Inventory Types; Business Entities
123
BIZBOK Business Blueprint: Initiative Map
Zachman Framework Concept: No Mapping
124
BIZBOK Business Blueprint: Stakeholder Map
Zachman Framework Concept: Responsibility Types; Busines Roles
125
BIZBOK Business Blueprint: Performance Measurement
Zachman Framework Concept: No Mapping
126
BIZBOK Business Blueprint: Product Map
Zachman Framework Concept: Composite of: Business Entity; Business Transform; Business Location
127
TOGAF is an architecture framework that provides
The methods and tools for assisting in the acceptance, production, use, and maintenance of enterprise architecture.
128
TOGAF is based on
An iterative process model supported by best practices and a re-usable set of existing architecture assets
129
A step-by-step approach to developing the enterprise architecture
TOGAF Architecture Development Method
130
A collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM
ADM Guidelines and Techniques
131
A structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables
Architecture Content Framework
132
Appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise
Enterprise Continuum & Tools
133
A selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Integration Reference Model
TOGAF Reference Models
134
The organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise
Architecture Capability Framework
135
Align the TOGAF ADM with the BIZBOK:
Adapt the ADM to use the BIZBOK® Guide for business architecture
136
Align the TOGAF Guidelines and Techniques with the BIZBOK
The BIZBOK® Guide contains specific guidelines and techniques for the practice of business architecture. Although these could be included in the guidelines and techniques section, we have not attempted to do this.
137
Align the TOGAF Architecture Content Framework with the BIZBOK
Extend the content framework and metamodel to include the models in the BIZBOK® Guide. Cross reference the current context framework with the BIZBOK® Guide.
138
Align the TOGAF Enterprise Continuum and Tools with the BIZBOK
Provide references to appropriate business architecture content, models, and best practices.
139
Align the TOGAF Architecture Capability Framework with the BIZBOK
Extend the capability framework to include specific business architecture capabilities.
140
BIZBOK® Guide is used to adapt the terminology, process, and content of TOGAF:
Phase B, Business Architecture
141
BIZBOK® Guide is used to adapt the terminology, process, and content of TOGAF Phase B, Business Architecture during:
Phase 0, the Preliminary Phase, Step 5, called “Tailor TOGAF”
142
BIZBOK adaptation to TOGAF Phase B - Objectives
The objectives have been expanded slightly to be more specific about items that were listed in the “approach” section of standard TOGAF.
143
BIZBOK adaptation to TOGAF Phase B - Approach
The basic method described in the BIZBOK® Guide using scenarios has been substituted for the approach section. In particular, the section on Business Modelling (TOGAF 8.2.3) has been replaced. TOGAF recommends UML Activity, Use Case, and Class Models as the basis of Business Modelling. The BIZBOK® Guide foundational models have been used instead.
144
BIZBOK adaptation to TOGAF Phase B - Inputs
The non-architectural inputs have been strengthened to be more specific about the business strategy and sponsorship. In general, many of the architectural inputs could be simplified, but we have left them here to keep the TOGAF flavour of the adaptation.
145
BIZBOK adaptation to TOGAF Phase B - Steps
| 1. Select Reference Models, Viewpoints, and Tools
The BIZBOK® Guide viewpoints and mappings have been used rather than TOGAF recommended artefacts (diagrams, list, and matrices).
146
BIZBOK adaptation to TOGAF Phase B - Steps
| 4. Perform Gap Analysis
Gap Analysis has been focused on using capabilities as the concept of comparison and planning.
147
BIZBOK adaptation to TOGAF Phase B - Steps
| 8. Finalize the Business Architecture
The use of “Architecture Building Blocks” for the business architecture has been dropped. We expect that knowledge and artefacts from the process will be reused and kept in the Architecture Knowledge Base (repository). However, we find the attempt to formalise these as ABBs tends to cause confusion.
148
BIZBOK adaptation to TOGAF Phase B - Steps
| 9. Create Architecture Definition Document
The content of the business section of the ADD has been adjusted to use the BIZBOK® Guide artefacts.
149
BIZBOK adaptation to TOGAF Phase B - Outputs
The content of the target business architecture has been adjusted to use the BIZBOK® Guide artefacts.
150
Although TOGAF doesn’t explicitly include capability as part of their Business Architecture domain, it does include it as part of
The architecture context.
151
The TOGAF concept of Role/Actor is addressed through the BIZBOK® Guide concept of
Stakeholder.
152
TOGAF Business Architecture Artefacts: Business goals and objectives, driver/goal/objective catalog
BIZBOK Business Architecture Blueprint: Business Strategy Map
153
TOGAF Business Architecture Artefacts: Business service/function catalog, business footprint diagram, functional decomposition diagram
BIZBOK Business Architecture Blueprint: Capability Map
154
TOGAF Business Architecture Artefacts: Organization structure, organization decomposition diagram, business functions, business roles, location catalog, correlation of organization and functions, organization/actor catalog, role catalog, actor/role matrix
BIZBOK Business Architecture Blueprint: Organization Map
155
TOGAF Business Architecture Artefacts: Business processes, business services, process flow diagram, process/event/control/product catalog, business interaction matrix, product lifecycle diagram, goal/objective/service diagram, business use-case diagram, event diagram
BIZBOK Business Architecture Blueprint: Value Map
156
TOGAF Business Architecture Artefacts: Business data model, business service/information diagram
BIZBOK Business Architecture Blueprint: Business Information Map
157
BIZBOK Business Architecture Blueprint: Initiative Map
TOGAF Business Architecture Artefacts: No Mapping
158
TOGAF Business Architecture Artefacts: Actor catalog, actor role matrix
BIZBOK Business Architecture Blueprint: Stakeholder Map
159
BIZBOK Business Architecture Blueprint: Product & Service Map
TOGAF Business Architecture Artefacts: No Mapping
160
TOGAF Business Architecture Artefacts: Contract/measure catalog
BIZBOK Business Architecture Blueprint: Performance Measurement
161
TOGAF Rationale for Enterprise Architecture: Business Transformation Preparation
```
BIZBOK Business Scenarios:
Shift to Customer Centric Business Model
Merger & Acquisition Analysis
New Product / Service Rollout
Globalisation
Business Capability Outsourcing
Supply Chain Streamlining
Divestiture
Regulatory Compliance
Change Management
Joint Venture Deployment
```
162
BIZBOK Business Scenarios: Investment Analysis
TOGAF Rationale for Enterprise Architecture: No Mapping
163
TOGAF Rationale for Enterprise Architecture: Radical Infrastructure Change
BIZBOK Business Scenarios: Operational Cost Reduction
164
BIZBOK Business Architecture Knowledgebase: Business Unit
TOGAF Content Metamodel: Organization unit, Location
165
BIZBOK Business Architecture Knowledgebase: Information Concept
TOGAF Content Metamodel: Data entity
166
BIZBOK Business Architecture Knowledgebase: Capability
TOGAF Content Metamodel: Capability (in architecture context), Function
167
BIZBOK Business Architecture Knowledgebase: Value Stream, Value Stream Stage
TOGAF Content Metamodel: Process
168
BIZBOK Business Architecture Knowledgebase: Policy, Rule
TOGAF Content Metamodel: No mapping
169
BIZBOK Business Architecture Knowledgebase: Regulation
TOGAF Content Metamodel: Driver
170
BIZBOK Business Architecture Knowledgebase: Customer, Partner, Competitor
TOGAF Content Metamodel: Actor
171
BIZBOK Business Architecture Knowledgebase: Vision
TOGAF Content Metamodel: Architecture vision
172
BIZBOK Business Architecture Knowledgebase: Strategy, Tactic
TOGAF Content Metamodel: No mapping
173
BIZBOK Business Architecture Knowledgebase: Initiative, Project
TOGAF Content Metamodel: Work package
174
BIZBOK Business Architecture Knowledgebase: Decision
TOGAF Content Metamodel: Control
175
BIZBOK Business Architecture Knowledgebase: Event
TOGAF Content Metamodel: Event
176
BIZBOK Business Architecture Knowledgebase: Metric
TOGAF Content Metamodel: Measure
177
BIZBOK Business Architecture Knowledgebase: Measure
TOGAF Content Metamodel: Measure, goal, objective
178
BIZBOK Business Architecture Knowledgebase: Product
TOGAF Content Metamodel: Product
179
BIZBOK Business Architecture Knowledgebase: Service
TOGAF Content Metamodel: Business service, contract
180
A framework used by IT organizations to define the path taken to plan, specify, design, build, deploy, and maintain software systems
The system development lifecycle
181
A process followed for a software project that defines how to develop, maintain, replace, alter or enhance IT architecture
The system development lifecycle
182
1. Establish the business architecture artifacts as a required business input utilized by the project definition stage of the SDLC
Guideline for leveraging business architecture as input to SDLC related stages
183
2. Ensure traceability back to business objectives and value perspectives
Guideline for leveraging business architecture as input to SDLC related stages
184
3. State business scope in terms of value streams, capabilities, and stakeholders
Guideline for leveraging business architecture as input to SDLC related stages
185
4. Inform all data architecture work in terms of input from the business architecture information map and related business architecture perspectives
Guideline for leveraging business architecture as input to SDLC related stages
186
5. Inform the solution architecture, particularly SOA services definition, by the value streams and capabilities the services will automate
Guideline for leveraging business architecture as input to SDLC related stages
187
6. Frame all project requirements in reference to the capabilities, within value stage perspective, indicating the stakeholder or stakeholders involved
Guideline for leveraging business architecture as input to SDLC related stages
188
7. Ensure that the business architecture is used to frame and track deployed system artifacts and assets
Guideline for leveraging business architecture as input to SDLC related stages
189
A state in which “business information, capabilities, and value streams are appropriately represented and deployed from an IT automation perspective"
Business/IT architecture alignment
190
A common IT approach for managing software investments
Application Portfolio Management (APM)
191
An approach used by IT executives to view, assess, and refine technology investments.
Application Portfolio Management (APM)
192
The common terminology used to characterise a collection of software assets that automates and enables a bounded set of capabilities and is identifiable by name and other characteristics.
Application
193
In complex environments, major investment decisions hinge on the ability to
Determine the business value of an application in relation to numerous other applications, desk top solutions, and manual techniques that enable one or more business capabilities.
194
A lack of information means that application decisions are being based on an IT rather than a business value perspective, which can hinder
Overall business agility and competitiveness.
195
Define everything that a business does from a purely business perspective.
Capabilities
196
Providing a business capability/application relationship mapping enables executives to
Assess multiple applications with shared capabilities in aggregate
197
Providing a business capability/application relationship mapping enables executives to
Assess business gaps in application portfolios.
198
The discipline applied to managing software assets to justify and measure the financial benefits of each application in comparison to the costs of the application's maintenance and operations.
Application Portfolio Management (APM)
199
Results from degrading technical and application architectures resulting from not having the time to deliver an architecturally complete or elegant product.
Technical debt
200
Many businesses have multiple applications supporting the multiple capabilities, and the impact of this fragmentation and redundancy may not be evident to the business, contributing to
Complexity of mapping concepts between capability and application in reality.
201
Value Stream Decomposes into
Value Stream Stage
202
Value Stream Stage is Enabled by
Capability
203
Capability is Automated by
Application
204
Business Unit Has a
Capability
205
Application Decomposes into
Subsystem
206
Application Supports
Application
207
1. Ensure that the organisation has a robust inventory of application software assets.
Capability/APM Alignment Guideline
208
2. Verify that the capability map has been established to a level 3 mapping.
Capability/APM Alignment Guideline
209
3. Verify that capabilities have been appropriately mapped to value stream stages and business units where required to improve APM.
Capability/APM Alignment Guideline
210
4. Work with application teams to establish level 1-2-3 capability mappings to applications of interest (note that there is no need for lower level mappings unless a transformation effort is envisioned).
Capability/APM Alignment Guideline
211
5. Where subject matter expertise is lacking, rely on documentation or software analysis tools to augment the analysis.
Capability/APM Alignment Guideline
212
6. Systematically map the capabilities of interest to the applications that automate those capabilities.
Capability/APM Alignment Guideline
213
7. Work with various business units to use value stream/capability mappings to determine the overall business value of each capability and the degree of automation provided by the mapped application.
Capability/APM Alignment Guideline
214
8. Determine the percentage of manual work required by the application for each capability.
Capability/APM Alignment Guideline
215
9. Determine the technical debt being incurred in various applications to assess the future ability of a given application to support improvements or future requirements associated with each capability (note that the capability heat map provides insights into future capability improvement requirements).
Capability/APM Alignment Guideline
216
10. Use this information to inform APM investment, transformation, or modification planning.
Capability/APM Alignment Guideline
217
Shadow systems by their very nature increase technical debt because they are
Hard to manage, hard to find, and increase risks associated with a lack of management rigour.
218
Refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules.
Technical Debt
219
Just like financial debt, some technical debts can serve ___. Other technical debts are simply counterproductive.
Valuable business purposes
220
A set of principles and methodologies for designing and developing software using a concept called a “service”
Service-oriented architecture (SOA)
221
When a business needs to improve or even add capabilities based on any number of business scenarios, capabilities and value streams provide architects with a framework for
Business service and service orchestration requirements.
222
SOA analysis and design teams benefit from having a clear business foundation for
Business service design and orchestration.
223
SOA philosophy
“One way to do one thing. One place to get one kind of information”
224
SOA relies on application architecture as the basis for defining three important concepts: (1)
1. The fundamental reference architecture that defines how applications will be constructed
225
SOA relies on application architecture as the basis for defining three important concepts: (2)
2. The integration of applications (both functions and data)
226
SOA relies on application architecture as the basis for defining three important concepts: (3)
3. Maintaining a portfolio of applications and systems
227
The top layer in the SOA layered reference architecture
Business processes
228
A series of operations that are executed in an ordered sequence according to a set of business rules.
Business process
229
The second layer in the SOA layered reference architecture
Business and information services
230
Business services provide
High-level business functionality throughout the enterprise.
231
Information services provide
Consolidated, cleaned, and rationalised data about business entities.
232
This layer provides a service interface abstraction and integration of the layer below, breaking the direct dependence between processes, entities, and existing systems.
Business and information services
233
A managed, governed set of enterprise assets responsible for ensuring conformance to service-level agreements (SLAs)
Services
234
Represent logical groupings of operations.
Business services
235
The third layer in the SOA layered reference architecture
Integration services
236
Integration services provide
Integration between and access to existing applications.
237
The separation between the integration services and the business services is critical to
Maintaining a flexible enterprise environment.
238
This involves transformation of data and capabilities from existing systems to the business service level.
Integration services
239
The bottom layer in the SOA layered reference architecture
Operational resources
240
This layer consists of existing applications, legacy, and commercial-off-the-shelf (COTS) software, which includes customer relationship management (CRM) and enterprise resource planning (ERP) applications.
Operational resources
241
Operational resources applications provide business operations —
Transactions that represent single logical units of work in the enterprise’s operational systems.
242
Execution of an operation will typically cause one or more persistent data records to be
Read, written, or modified in a system of record (SOR).
243
Data at this layer resides in existing applications or databases.
Operational resources
244
A robust capability map that provides a true and accurate representation of the business with detailed decompositions for any area involved in SOA alignment
(1/5) essential requirements common to most business architecture / SOA alignment efforts.
245
Value stream definitions for all stakeholder focused areas of interest
(2/5) Essential requirements common to most business architecture / SOA alignment efforts.
246
An information map that identifies the major enterprise business entities and the common definition/vocabulary that details them
(3/5) Essential requirements common to most business architecture / SOA alignment efforts.
247
Value stream / capability cross-mappings
(4/5) Essential requirements common to most business architecture / SOA alignment efforts.
248
Ability to design, develop, and deploy services.
(5/5) Essential requirements common to most business architecture / SOA alignment efforts.
249
Capabilities map to value streams, business entities, business processes, and business services.
Business/IT architecture mapping provides the basis for this alignment concept. (1/3)
250
Information views are derived from business information concepts and capabilities
Business/IT architecture mapping provides the basis for this alignment concept. (2/3)
251
Value streams map to business processes, which in turn provide an orchestration context for deployable services.
Business/IT architecture mapping provides the basis for this alignment concept. (3/3)
252
1. Determine priority value streams and stages to be improved upon based on business objectives and priorities.
Business Architecture / SOA Alignment Guideline
253
2. Target selected capabilities for automation or automation improvement based on the role they play in identified value streams and business objectives and priorities.
Business Architecture / SOA Alignment Guideline
254
3. Review information requirements for the services based on information concepts that map to targeted capabilities.
Business Architecture / SOA Alignment Guideline
255
4. Assess current state deployments of targeted capabilities to determine service usage and deployment options.
Business Architecture / SOA Alignment Guideline
256
5. Review capabilities with solution architects to assess the approach required to design related services.
Business Architecture / SOA Alignment Guideline
257
6. Review orchestration options based on value stream / process mappings.
Business Architecture / SOA Alignment Guideline
258
7. Establish deployment plans based on where to plug services into the current state application architecture.
Business Architecture / SOA Alignment Guideline
259
Information, in both explicit and implicit forms, is crucial to
The success of business strategy and operations.
260
Informs decisions and makes routine operations more efficient
Information
261
Can prevent mistakes, including missed opportunities, and facilitate learning
Information
262
Without this, a business becomes an uncoordinated collection of individual accomplishments.
Communication
263
Collective decision making is a critical component of
Coordinated activity.
264
Information is most effectively communicated when it is
Explicit.
265
Data is an explicit representation of
Information
266
Aligning business information and data management insures that the data is representative of the performance of
The business, suppliers, clients, and partners
267
Aligning business information and data management insures that the data is relevant to
Those who guide and monitor the business.
268
Misalignment of business information and data management tends to result in
The collection and storing of data that has low value to the business managers
269
Misalignment of business information and data management tends to result in
Failure to collect data that can enhance decision making and operational control.
270
An expansive view of what constitutes data includes
Printed works, images, sounds, as well as structured, semi-structured, and unstructured electronic forms.
271
The business information map incorporates the discovery and making explicit of
Patterns of information analysis, information provenance and information governance
272
The business information map guides the implementation of IT and human processes of
Application management, data management, data provenance, and data governance.
273
A principal element in the collaboration between the business architect and the application/data architects.
The information map
274
Planning, supervision, and control over data management and use
Data Governance
275
Defining the blueprint for managing data assets
Data Architecture Management
276
Analysis, design, implementation, testing, deployment, maintenance
Data Development
277
Providing support from data acquisition to purging
Data Operations Management
278
Ensuring privacy, confidentiality, and appropriate access
Data Security Management
279
Defining, monitoring, and improving data quality
Data Quality Management
280
Managing golden versions and replicas
Reference and Master Data Management
281
Enabling reporting and analysis
Data Warehousing and Business Intelligence Management
282
Managing data found outside of databases
Document and Content Management
283
Integrating, controlling, and providing meta-data
Meta-data Management
284
Relates to data governance and data security management.
Information governance
285
Relates to data architecture, reference, and master data management, data warehousing and business intelligence, document and content management, and meta-data management.
Information analysis
286
Relates to application architecture data service when this is the logical place to manage constraints that cannot otherwise be managed.
Information analysis
287
Relates to data quality management and data development.
Information provenance
288
Information governance will typically be linked with and derived from
Capabilities associated with monitoring the business and its environment.
289
While the practice of business architecture cannot guarantee that appropriate business and technology decisions will always be made, it does place the relationships between
All of the business capabilities and their associated Classes and Roles on the table for discussion
290
While the practice of business architecture cannot guarantee that appropriate business and technology decisions will always be made
It does insure that the requirements of compliance and risk managers are not overlooked.
291
Information provenance is typically linked with
Capabilities that are strongly dependent on information to perform their functions.
292
Operational data about the business is key information for
Operations management and business strategy.
293
Capabilities that are strongly dependent on information to perform their functions will want to insure that the information they receive and act on
Accurately reflects the state of the business and cannot be manipulated.
294
Techniques such as ___ and ___ can be used to detect data manipulation.
Comparing data obtained from multiple sources and performing historical analysis
295
The information and capability maps provide a medium of
Discussion about the requirements for data quality.
296
The combination of value streams, capability maps and information maps makes it possible to consider
All of the ways in which corrupt data can enter the IT system and what measures can be taken to reduce its occurrence.
297
It can be very challenging to make knowledge explicit as data
when the knowledge is about the behaviour and intent of competitors
298
It can be very challenging to make knowledge explicit as data, especially when the knowledge is about
How clients view the business and its competition.
299
The linkage from information map through capability map to value stream will point out
Information that has strategic importance.
300
The answer to this question can be taken directly from the information map through the linkage to the capability map.
What data is needed by the business?
301
By examining the linkage between the capability map and the organisation map, one can determine
The organisation units that will have interest in the information.
302
1. Select a Class that has a business identity (i.e., it corresponds to a Business Entity)
What does the data look like?
| A relational schema can be extracted from an information map by following this procedure (1/4):
303
2. Identify the attributes of that Class that serve to identify Individuals in the Class – these will become the natural keys
What does the data look like?
| A relational schema can be extracted from an information map by following this procedure (2/4):
304
3. Identify all Roles the selected Class participates in that have 1-1 relationships with the Class and whose target Individuals are lifetime dependent on the existence of Individuals in the selected Class – these will be the columns of the Class
What does the data look like?
| A relational schema can be extracted from an information map by following this procedure (3/4):
305
4. Identify all other Roles and implement them as foreign key or association tables relationships
What does the data look like?
| A relational schema can be extracted from an information map by following this procedure (4/4):
306
If it is the case that the Business Entity modelled by a Class will have characteristics that cannot be directly observed.
What does the data look like?
| A proxy data set may be substituted.
307
As the data architecture is defined, its elements can be linked back to the information map. The result is a
What does the data look like?
| Kind of data dictionary that is associated with the business architecture.
308
The business architecture (information) provides the business context for
What does the data look like?
| The data elements and relations.
309
Some business functions create or collect information and make it tangible as data, modelled as
Where and how often to get the data?
| Capabilities that are linked by Roles to Classes.
310
Separation of capabilities allows the development
Where and how often to get the data?
| Of efficiency producing specialisation.
311
Separation of capabilities allows the enterprise to scale by
Where and how often to get the data?
| Adjusting the amount of each kind of skill it can deploy to the capabilities.
312
If the data may not be known because it would be created in a future that has not yet occurred
Where and how often to get the data?
| Historical data may be used to predict the future.
313
Where the data is not directly available, a proxy that
Where and how often to get the data?
| Correlates well with the information that is sought but not available as data can be used.
314
Cases involving non-operational data must be analysed and often involves information governance considerations such as
Where and how often to get the data?
| Privacy, intellectual property rights, and data collection ethics such as the use of third parties.
315
Cases involving non-operational data must be analysed and often involves thinking about information provenance, particularly
Where and how often to get the data?
| The reliability of the technique used to proxy the data that is desired.
316
Linkages among concepts in the information structure map and capabilities should indicate the nature of use of the concepts and relationships.
Who gets to change or delete the data?
| Some capabilities create information, others change it, and others destroy it.
317
Information is often representative of
Who gets to change or delete the data?
| Some physical thing
318
If a physical thing ceases to exist, the information item
Who gets to change or delete the data?
| May no longer be needed.
319
This is also (along with change / delete) determined by examining the nature of the capability's use of the information.
Who gets to view the data?
320
Each capability in a value stream may have a different
Who gets to view the data?
| Perspective on the information concepts.
321
The information structure map will contain both __ and should contain the derivation linkages between them.
How will the data be presented to various viewers?
| Base and derived information concepts
322
The information structure map will contain both base and derived information concepts and should contain
How will the data be presented to various viewers?
| The derivation linkages between them.
323
It will be necessary to completely and unambiguously define what is meant by __, and __.
How will the data be presented to various viewers?Groupings of the corresponding data
Alignment of unconnected information items
324
A rough assessment of potential data quality problems can be obtained from analysing the
How will the quality of the data be assured?
| Source capability of the corresponding information concept.
325
If the source is known to produce unreliable data, then a second source may be sought and
How will the quality of the data be assured?
| The two sources used to improve the data reliability.
326
If the source capability is implemented by a person, recording errors will occur and the
How will the quality of the data be assured?
| Consistency rules from the information structure model can be used to derive checks to be performed.
327
Automated data collection devices must be
How will the quality of the data be assured?
| Periodically recalibrated.
328
If it is properly crafted, the information map will represent the consensus understanding of
The information concepts, lifecycle, governance, and provenance.
329
The enterprise may decide that it wishes to have a policy of ___ alignment.
Periodic or continuous
330
Will involve periodic joint audits of the information map and the IT architecture to remedy differences.
Periodic alignment
331
The evolution of the information map will precede the evolution of the IT architecture and the IT architecture will be changed according to the alignment with the information map.
Continuous alignment
332
A discipline focused on framing automation and technical delivery of targeted business initiatives.
Solution architecture
333
Often takes the form of understanding and interpreting business strategy and updating current state system functionality
Solution architecture
334
Often takes the form of designing new ___s that go beyond current state architectural perspectives.
Solution architecture
335
The solution architect’s familiarity with business architecture plays a key role in
Aligning technical solutions to deliver business value.
336
The discipline of generating a creative and communicable technical design that aligns a feasible business solution with stakeholder expectation within the bounds of mandated delivery parameters.
Solution architecture
337
Solution architects are commonly tasked with determining
IT automation approaches that will deliver value within the scope of a defined program or initiative.
338
If a solution architect effectively aligns to business architecture, successive incremental alignments to the business architecture will be
More straightforward and of less impact to affected stakeholders.
339
During the course of solution __, __, __, and __, architects may uncover refinements that can be incorporated into the business architecture as a result of more granular analysis into a given business area.
Definition, creation, implementation, and maintenance
340
During the course of solution definition, creation, implementation, and maintenance, architects may uncover ___ as a result of more granular analysis into a given business area.
Refinements that can be incorporated into the business architecture
341
During the course of solution definition, creation, implementation, and maintenance, architects may uncover refinements that can be incorporated into the business architecture as a result of
More granular analysis into a given business area.
342
1. Establish the business architecture as a required business input into solution architecture.
Solution Architecture / Business Architecture Guidelines (1/6)
343
2. Use the business architecture to establish traceability from business objectives and value perspectives through requirements and solution deployments.
Solution Architecture / Business Architecture Guidelines (2/6)
344
3. State business assets in terms of the vocabulary defined by the value streams, capabilities, and stakeholders.
Solution Architecture / Business Architecture Guidelines (3/6)
345
4. Frame the solution architecture, particularly SOA services definition, by the value streams and capabilities of the services to be automated.
Solution Architecture / Business Architecture Guidelines (4/6)
346
5. Verify that the solution architecture does not contradict defined business architecture artefacts; desired or necessary changes to the business architecture should be reviewed and approved by the business architect or business architecture team.
Solution Architecture / Business Architecture Guidelines (5/6)
347
6. As part of a larger, holistic assessment, leverage the business architecture to assess the effectiveness, impacts, breadth, and automation levels of a business capabilities and value streams.
Solution Architecture / Business Architecture Guidelines (6/6)
348
Solution architects should consider the ___, and other components of business architecture as they develop their solution architecture.
Value streams, value stages, capabilities, information
349
After the initial implementation of the solution, an ongoing cycle should be established where the
Solution architecture is evaluated for potential refinements as the business continues to evolve.
350
Business/IT architecture transformation is the means of
Achieving business/IT architecture alignment.
351
Transformation focuses on a strategic, business-driven target and involves
Multiple projects or project phases that are typically executed over a period of years.
352
Involves systemic changes driven by business vision, objectives, and overall strategy.
Transformation
353
In most cases, the tactical approach would not achieve these business objectives ___, and tactical approaches are architecturally constrained.
Because current state IT architectures cannot accommodate this vision
354
In most cases, the tactical approach would not achieve these business objectives because current state IT architectures cannot accommodate this vision, and
Tactical approaches are architecturally constrained.
355
One challenge that can stymie transformation efforts is a scenario where business professionals have given up on their vision because
Getting even small changes through IT is already too difficult.
356
Applying standard enhancement and maintenance changes
A traditional IT change approaches
357
Adding another database or data warehouse
A traditional IT change approaches
358
Tacking on a new subsystem
A traditional IT change approaches
359
Incorporating more system-to-system interfaces
A traditional IT change approaches
360
Plugging in a software package
A traditional IT change approaches
361
Building more user interface layers
A traditional IT change approaches
362
When the the business cannot stem the tide of customer or revenue losses
Investigate alternatives to traditional IT options
363
When a business is forced to cede competitive advantage to the competition
Investigate alternatives to traditional IT options
364
When IT fails to deliver the substantive changes a business is demanding,
Investigate alternatives to traditional IT options
365
The overall practice of addressing systemic business challenges is called
Business/IT architecture transformation.
366
Requires the use of various transformation techniques, interim architecture deployments, and realignment of application architectures to accommodate new business design patterns.
Business/IT architecture transformation.
367
Requires the use of interim architecture deployments.
Business/IT architecture transformation.
368
Requires the realignment of application architectures to accommodate new business design patterns.
Business/IT architecture transformation.
369
Required for business/IT architecture transformation.
Business architecture, aligned vision, and a business-driven, target state IT architecture.
370
In the “rainbow model”, the uppermost level is the business architecture, supported in turn by
Application and data architectures.
371
In the “rainbow model”, data and application architecture are enabled by the lowest level:
The technical architecture.
372
The rainbow model involves
Current-to-target transformational paths
373
Target state IT architecture is defined by aligning
Business vision, business architecture, and IT best practices.
374
Paths to achieving target state IT architecture can vary dramatically and, due to current state architectural complexities
Is often taken in a series of phases.
375
The second major concept depicted in the rainbow model involves cross-impacts on
Various architectural layers.
376
At the most simplistic level, a technical architecture transformation moves from one technical platform, language, database, and/or other technical implementation to another which has
Minimal business impact and therefore does little to achieve business objectives.
377
Data and application architectures have a direct relationship to
Capabilities, value streams, and information concepts.
378
Organisations can define the impact of clearly articulated business objectives on value streams and capabilities and, in turn
Related impacts may be interpreted and identified within current state data and application architectures.
379
Once current state impacts on data and application architectures have been identified, IT architects can craft
Target state data and application architectures that will enable business transformation to occur.
380
The transformation framework has four foundational components:
Business architecture, business vision, current state IT architecture, and target state IT architecture.
381
The four foundational components of the transformation framework must be in place to articulate a ___ in a way that is realistic and delivers interim business value along the way.
Well-informed, viable solution roadmap that will move the business closer and closer to the business vision
382
The four foundational components of the transformation framework must be in place to articulate a well-informed, viable solution roadmap that will move the business closer and closer to the business vision in a way that
Is realistic and delivers interim business value along the way.
383
Undertaking business/IT architecture transformation in the absence of foundational transformation components is like performing complex, multiple surgeries
Without having done any diagnostic analysis or even understanding what is remotely wrong with the patient.
384
The transformation journey, depicted by the left to right arrows, is realised through a series of
Coordinated initiatives that move the business from the current state towards the desired target state.
385
The transformation framework approach may be superimposed over an existing set of initiatives that could then be
Realigned to achieve business and IT objectives from a more strategic perspective.
386
Drafting the business architecture shown in the upper left portion of the transformation framework
Business/IT Architecture Transformation Approach (1/4)
387
Articulating business vision and objectives in terms of business capability, value stream, and information impacts, as represented in the upper right portion of the framework
Business/IT Architecture Transformation Approach (2/4)
388
Building a baseline understanding of current state IT architecture shown in the bottom left of the figure
Business/IT Architecture Transformation Approach (3/4)
389
Crafting a target state IT architecture required to achieve the business vision, in alignment with business architecture
Business/IT Architecture Transformation Approach (4/4)
390
Before discussing the current-to-target state transformational approach, it is important to
Align business and IT architectures across current and target states.
391
To provide a basis for determining transformation requirements, challenges, approaches, and costs.
Align business and IT perspectives
392
Current state business/IT architecture mappings on the left side, depicted by the bi-directional vertical arrow, expose
Weaknesses in current state IT deployments.
393
The bi-directional vertical arrow on the right side represents how the target state architecture is crafted, based on
The business architecture articulated business vision.
394
The target state IT architecture is based on
Business vision, business architecture, and best practices.
395
Mapping out a high-level target state IT architecture, coupled with the current state issues and limitations aligned on the left side of the figure sets the stage for
Crafting a transformation strategy.
396
Scoping the transformation effort from a business perspective, which ensures that all impacted business areas are considered under an overall strategy
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
397
Scaling the overall scope into manageable chunks based on business and IT considerations
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
398
Assessing the business’s ability and appetite to absorb change associated with a business/IT transformation roadmap – in pursuit of business objectives
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
399
Determining if the current state data architecture can evolve into the target state incrementally or if a major reworking of the data architecture limits this option
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
400
Examining the opportunities and complexities of decoupling and modernizing the current state application architecture into components that evolve into the target state
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
401
Considering standing up a parallel, target state architecture and migrating the business piecemeal into that architecture
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
402
Seeking and refining alternative hybrid architectural options that would move the business incrementally into the current state
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
403
Crafting and deploying a risk-managed approach for data and application architecture transformation
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
404
Managing phased deployment to the new target architecture
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
405
Accommodating near-term and mid-term business demands as part of the overall effort
Must occur (in the portions of the framework depicted by the horizontal arrows) to successfully map out a viable transformation roadmap.
406
1. Ensure the availability of baseline capability, value, and information maps
Business/IT Architecture Transformation Guideline (1/8)
407
2. Define business vision with clear, comprehensive business objectives
Business/IT Architecture Transformation Guideline (2/8)
408
3. Craft business vision and related objectives through the lens of the business architecture
Business/IT Architecture Transformation Guideline (3/8)
409
4. Prioritize deployment of the vision and objectives and refine this as time progresses
Business/IT Architecture Transformation Guideline (4/8)
410
5. Map enough of the dependencies of the business architecture on the current state IT architecture to gain an understanding of potential transformation complexities and roadblocks
Business/IT Architecture Transformation Guideline (5/8)
411
6. Define the target state IT architecture based on the business architecture positioned vision and IT architecture best practices
Business/IT Architecture Transformation Guideline (6/8)
412
7. Define transformation roadmap that addresses the business’s ability to manage and absorb change as well as the ability of IT to deliver on the overall approach
Business/IT Architecture Transformation Guideline (7/8)
413
8. Deploy the roadmap in phases, refining priorities and approaches on an ongoing basis
Business/IT Architecture Transformation Guideline (8/8)
414
The transformation roadmap approach is NOT
A big bang, single project approach.
415
The transformation roadmap approach represents a series of projects that are delivered
On an ongoing basis to continuously move towards a common, business vision.
