Business Architecture / IT Alignment Flashcards Preview

CBA > Business Architecture / IT Alignment > Flashcards

Flashcards in Business Architecture / IT Alignment Deck (415):
1

Business/IT architecture alignment is the fundamental link that enables ___ to be translated into IT architectural concepts and deployable solutions.

Business strategy, vision, design, and requirements

2

Business/IT architecture alignment is the fundamental link that enables business strategy, vision, design, and requirements to be translated into

IT architectural concepts and deployable solutions.

3

Have direct, traceable, and unambiguous relationships to IT application and data architecture.

Capabilities, value streams, and information concepts

4

Business/IT architecture alignment enables IT to leverage strategic impacts on the business architecture to drive __, __, __, and __ as appropriate to a given business strategy.

IT architecture planning, decision making, evolution, and transformation

5

The four aspects of IT architecture (___) collectively enable and automate business capabilities, value streams, and information concepts.

Application, data, technical and shadow system domains

6

Is a blueprint of the data and related data structures business professionals rely on to run the business.

Data architecture

7

Provides views into the business systems and services that deliver value to business professionals and customers.

Application architecture

8

Represents the underlying platforms, languages, operating systems, security software, middleware, and supporting technologies required to enable an overall IT environment.

Technical architecture

9

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.

Shadow systems

10

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

Application architecture

11

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

Higher IT maturity

12

When workflow rules are externalised and decoupled from application deployments, providing improved agility for modifying state transition and workflow automation there is

Higher IT maturity

13

Includes the formal and informal representations of the data used by the business.

Data architecture

14

Includes various types of conceptual, logical, and physical data models.

Data architecture

15

Represented by additional drawings, data layouts, or physical deployment views.

Current state data representations

16

Data architecture is an important component in a robust IT architecture because it formalises __ and enables __.

the management of business information, deployment of agile application architecture.

17

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.

Evolving data architectures from information concepts

18

Flexible information access enables more effective __, __, __, __, and timely __ to customers and other key stakeholders.

Customer management, financial reporting, market analysis, competitive analysis, and timely delivery of products and services

19

Any business-owned, business-maintained technology not under IT stewardship.

Shadow system

20

Support numerous critical business capabilities across an enterprise.

Shadow systems

21

Executive reports, business intelligence, or operational roles processed and supported by Excel, Access, or more sophisticated tools are examples of

Shadow systems

22

Augment manual tasks and limitations in data and application architectures.

Shadow systems

23

Often represent crucial automations that should be considered in a business/IT alignment effort.

Shadow systems

24

Informally automate portions of the application architecture and aspects of technical architecture that are beyond IT’s line of sight.

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.