Business Architecture / IT Alignment Flashcards
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
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.
Have direct, traceable, and unambiguous relationships to IT application and data architecture.
Capabilities, value streams, and information concepts
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
The four aspects of IT architecture (___) collectively enable and automate business capabilities, value streams, and information concepts.
Application, data, technical and shadow system domains
Is a blueprint of the data and related data structures business professionals rely on to run the business.
Data architecture
Provides views into the business systems and services that deliver value to business professionals and customers.
Application architecture
Represents the underlying platforms, languages, operating systems, security software, middleware, and supporting technologies required to enable an overall IT environment.
Technical architecture
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
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
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
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
Includes the formal and informal representations of the data used by the business.
Data architecture
Includes various types of conceptual, logical, and physical data models.
Data architecture
Represented by additional drawings, data layouts, or physical deployment views.
Current state data representations
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.
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
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
Any business-owned, business-maintained technology not under IT stewardship.
Shadow system
Support numerous critical business capabilities across an enterprise.
Shadow systems
Executive reports, business intelligence, or operational roles processed and supported by Excel, Access, or more sophisticated tools are examples of
Shadow systems
Augment manual tasks and limitations in data and application architectures.
Shadow systems
Often represent crucial automations that should be considered in a business/IT alignment effort.
Shadow systems
Informally automate portions of the application architecture and aspects of technical architecture that are beyond IT’s line of sight.
Shadow systems
Data often resides within shadow systems that do not
Exist within the formal view of data architecture.
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
Analogous to the wiring and plumbing that runs through a building, ship, or city.
Technical architecture
Enables data architecture, application architecture, and shadow systems that directly service business professionals
Technical architecture
A secondary consideration in business- driven, business/IT architecture alignment.
Technical architecture
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.
The information map is implemented by
Data architecture
The value map is the basis for prioritising & packaging requirements for
Process & Case Management Automation, Service Choreography, UI Deployment
The capability map is the basis for prioritising & packaging requirements for
Deployable Business Services
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
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.
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
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.
Provides a basis for transforming application architecture, including establishment and use of new automated business services
Capability mapping
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
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,
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
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.
- Establish baseline capability, value, and information maps as discussed in the BIZBOK® Guide part 2.
Business/IT Architecture Mapping Guideline
- Craft business strategy, business model interpretation, and business priorities in the context of their impact on the business architecture.
Business/IT Architecture Mapping Guideline
- 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
- 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
- Use capability map and related business objectives to identify current state application architecture strategies.
Business/IT Architecture Mapping Guideline
- Use capability map to identify and specify target state services requirements.
Business/IT Architecture Mapping Guideline
- Apply variations on the above guidelines based on specific situations, requirements, scenarios, and funding availability.
Business/IT Architecture Mapping Guideline
Support new financial fund models that the market is increasingly demanding
Business/IT Architecture Alignment Usage Scenario Example
Deploy certain new products that the application systems were never built to support
Business/IT Architecture Alignment Usage Scenario Example
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
Align business information for executive reporting, competitive analysis, profitability analysis, and streamline deployment of new requirements.
Business/IT Architecture Alignment Usage Scenario Example
Business architecture represents a business in the absence of any IT architecture while enterprise architecture provides
An overarching framework for business and IT architecture.
Business architecture represents __ while enterprise architecture provides an overarching framework for business and IT architecture.
A business in the absence of any IT architecture
A widely practiced discipline for understanding an organisation and furthering that organisation’s mission, goals, and practices.
Enterprise architecture
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
Artefacts: Describes architecture in terms of the blueprints that are produced.
Architectural Foundation
Methods: Describe architecture in terms of the activities that are performed by
architects to produce the artefacts specific to each domain.
Architectural Foundation
Business Architecture Foundational Domains:
Capability, Value, Information, Organisation
Business Architecture Extended Domains:
Vision, Strategy, Tactics; Products and Services; Policies, Rules, Regulations; Events; Stakeholders; Initiatives and Projects; Measures and Metrics
Business Architecture Foundational Artefacts:
Capability Map, Value Map, Information Map, Organisation Map, Cross Mappings
Business Architecture Extended Artefacts:
Strategy Map, Initiative Map, Stakeholder Map, Product Map
Business Architecture Methods:
Capability Mapping, Value Mapping, Information Mapping, Organisation Mapping, Cross-mapping, Extended Domain Mappings, Scenario Analysis, Root Cause Analysis; etc.
Enterprise Architecture Foundations:
Business Architecture Data Architecture Application Architecture Technology Architecture
For each architectural domain, there is an associated set of concerns, goals, or concepts.
Concerns, goals, or concepts.
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.
An important factor is the scope of a particular architecture effort or focus:
Enterprise level scope, and project level scope.
The business architect is concerned with defining the business such that strategies and goals
Can be clearly articulated
The business architect is concerned with defining the business such that management decisions
Can be based on facts
The business architect is concerned with defining the business such that transformations
Can be focused on the most important aspects
The business architect is concerned with defining the business such that issues
Can be addressed based on clarity and facts, rather than hunches.
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,
The data architect is concerned with providing a managed information environment for
Operational and transactional data.
The data architect is concerned with transforming data into
Information to support business analysis and reporting.
At the enterprise level, the data architect wants to provide a
Consistent view and usage of operational data across multiple applications
At the enterprise level, the data architect wants to rationalise
Data and information storage to minimise duplication and simplify access.
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
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.
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.
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.
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
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.
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.
The application architect is concerned with commonality
In applications.
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
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
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
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.
The application architect is concerned with commonality in applications to improve
Integration between applications
The application architect is concerned with commonality in applications to allow for
Sharing of common information
The application architect is concerned with commonality in applications to have
Consistent results for the same operation no matter how it is performed
The application architect is concerned with commonality in applications to reduce
The cost and complexity of maintenance and enhancements.
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.
Technology aspects such as __, __, __, and __ are factored into the reference architecture, not each individual project.
Performance, scalability, reliability, and security
A formal modelling discipline for specifying architecture.
Unified Modeling Language (UML)
At the project level, the application architect is concerned with applying ___ to a specific project.
The enterprise context (reference models, patterns, standards, guidelines, templates)
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.
The technology architect is responsible for providing common platforms that support
The different (hopefully few) application architecture styles with the appropriate quality of service.
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
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.
Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders
Architecture Framework
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
A schema for describing all aspects of the enterprise in terms of fundamental, unique primitives.
Zachman Framework
The largest and most well-known component of TOGAF
Architecture Development Method (ADM)
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)
The Zachman Framework focuses on the core value of the framework as an
Ontology of fundamental enterprise concepts, or primitives
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.
The Zachman primitives are defined from the intersection of six interrogative categories: ___, and six perspectives:
What, How, Where, Who, When, Why
The business architect is interested in the top two audience perspectives (rows) in the Zachman Framework
The Executive Perspective and the Business Management Perspective
Zachman - What:
The information map describes “what” information the enterprise needs
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.
Zachman - Where:
The organisation map describes “where” in the enterprise things are done.
Zachman - Who:
Stakeholder identification describes “who” (customers, employees, suppliers, partners) interacts with the enterprise (internally and externally) and what their responsibilities are.
Zachman - When:
No current mapping.
Zachman - Why:
Business Strategy Maps and the Business Motivation Model describe why things are done and how to measure them.
Identifying a unique primitive (like the capability), allows us to create
Composites (mappings) that bring clarity to the redundancies, gaps, and inefficiencies.
BIZBOK Business Blueprint: Business Strategy Map
Zachman Framework Concept: Motivation Types; Buiness Ends, Business Means
BIZBOK Business Blueprint: Capability Map
Zachman Framework Concept: Business Transformations
BIZBOK Business Blueprint: Organization Map
Zachman Framework Concept: Distribution Types; Locations
BIZBOK Business Blueprint: Value Map
Zachman Framework Concept: Composite of: Process Types, Transforms; Business Ends; Responsibiliy Types
BIZBOK Business Blueprint: Business Information Map
Zachman Framework Concept: Inventory Types; Business Entities
BIZBOK Business Blueprint: Initiative Map
Zachman Framework Concept: No Mapping
BIZBOK Business Blueprint: Stakeholder Map
Zachman Framework Concept: Responsibility Types; Busines Roles
BIZBOK Business Blueprint: Performance Measurement
Zachman Framework Concept: No Mapping
BIZBOK Business Blueprint: Product Map
Zachman Framework Concept: Composite of: Business Entity; Business Transform; Business Location
TOGAF is an architecture framework that provides
The methods and tools for assisting in the acceptance, production, use, and maintenance of enterprise architecture.
TOGAF is based on
An iterative process model supported by best practices and a re-usable set of existing architecture assets
A step-by-step approach to developing the enterprise architecture
TOGAF Architecture Development Method
A collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM
ADM Guidelines and Techniques
A structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables
Architecture Content Framework
Appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise
Enterprise Continuum & Tools
A selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Integration Reference Model
TOGAF Reference Models
The organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise
Architecture Capability Framework
Align the TOGAF ADM with the BIZBOK:
Adapt the ADM to use the BIZBOK® Guide for business architecture
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.
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.
Align the TOGAF Enterprise Continuum and Tools with the BIZBOK
Provide references to appropriate business architecture content, models, and best practices.
Align the TOGAF Architecture Capability Framework with the BIZBOK
Extend the capability framework to include specific business architecture capabilities.
BIZBOK® Guide is used to adapt the terminology, process, and content of TOGAF:
Phase B, Business Architecture
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”
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.
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.
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.
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).
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.
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.
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.
BIZBOK adaptation to TOGAF Phase B - Outputs
The content of the target business architecture has been adjusted to use the BIZBOK® Guide artefacts.
Although TOGAF doesn’t explicitly include capability as part of their Business Architecture domain, it does include it as part of
The architecture context.
The TOGAF concept of Role/Actor is addressed through the BIZBOK® Guide concept of
Stakeholder.
TOGAF Business Architecture Artefacts: Business goals and objectives, driver/goal/objective catalog
BIZBOK Business Architecture Blueprint: Business Strategy Map
TOGAF Business Architecture Artefacts: Business service/function catalog, business footprint diagram, functional decomposition diagram
BIZBOK Business Architecture Blueprint: Capability Map
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
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
TOGAF Business Architecture Artefacts: Business data model, business service/information diagram
BIZBOK Business Architecture Blueprint: Business Information Map
BIZBOK Business Architecture Blueprint: Initiative Map
TOGAF Business Architecture Artefacts: No Mapping
TOGAF Business Architecture Artefacts: Actor catalog, actor role matrix
BIZBOK Business Architecture Blueprint: Stakeholder Map
BIZBOK Business Architecture Blueprint: Product & Service Map
TOGAF Business Architecture Artefacts: No Mapping
TOGAF Business Architecture Artefacts: Contract/measure catalog
BIZBOK Business Architecture Blueprint: Performance Measurement
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
BIZBOK Business Scenarios: Investment Analysis
TOGAF Rationale for Enterprise Architecture: No Mapping
TOGAF Rationale for Enterprise Architecture: Radical Infrastructure Change
BIZBOK Business Scenarios: Operational Cost Reduction
BIZBOK Business Architecture Knowledgebase: Business Unit
TOGAF Content Metamodel: Organization unit, Location
BIZBOK Business Architecture Knowledgebase: Information Concept
TOGAF Content Metamodel: Data entity
BIZBOK Business Architecture Knowledgebase: Capability
TOGAF Content Metamodel: Capability (in architecture context), Function
BIZBOK Business Architecture Knowledgebase: Value Stream, Value Stream Stage
TOGAF Content Metamodel: Process
BIZBOK Business Architecture Knowledgebase: Policy, Rule
TOGAF Content Metamodel: No mapping
BIZBOK Business Architecture Knowledgebase: Regulation
TOGAF Content Metamodel: Driver
BIZBOK Business Architecture Knowledgebase: Customer, Partner, Competitor
TOGAF Content Metamodel: Actor
BIZBOK Business Architecture Knowledgebase: Vision
TOGAF Content Metamodel: Architecture vision
BIZBOK Business Architecture Knowledgebase: Strategy, Tactic
TOGAF Content Metamodel: No mapping
BIZBOK Business Architecture Knowledgebase: Initiative, Project
TOGAF Content Metamodel: Work package
BIZBOK Business Architecture Knowledgebase: Decision
TOGAF Content Metamodel: Control
BIZBOK Business Architecture Knowledgebase: Event
TOGAF Content Metamodel: Event
BIZBOK Business Architecture Knowledgebase: Metric
TOGAF Content Metamodel: Measure
BIZBOK Business Architecture Knowledgebase: Measure
TOGAF Content Metamodel: Measure, goal, objective
BIZBOK Business Architecture Knowledgebase: Product
TOGAF Content Metamodel: Product
BIZBOK Business Architecture Knowledgebase: Service
TOGAF Content Metamodel: Business service, contract
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
A process followed for a software project that defines how to develop, maintain, replace, alter or enhance IT architecture
The system development lifecycle
- 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
- Ensure traceability back to business objectives and value perspectives
Guideline for leveraging business architecture as input to SDLC related stages
- State business scope in terms of value streams, capabilities, and stakeholders
Guideline for leveraging business architecture as input to SDLC related stages
- 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
- 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
- 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
- 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
A state in which “business information, capabilities, and value streams are appropriately represented and deployed from an IT automation perspective”
Business/IT architecture alignment
A common IT approach for managing software investments
Application Portfolio Management (APM)
An approach used by IT executives to view, assess, and refine technology investments.
Application Portfolio Management (APM)
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
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.
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.
Define everything that a business does from a purely business perspective.
Capabilities
Providing a business capability/application relationship mapping enables executives to
Assess multiple applications with shared capabilities in aggregate
Providing a business capability/application relationship mapping enables executives to
Assess business gaps in application portfolios.
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)
Results from degrading technical and application architectures resulting from not having the time to deliver an architecturally complete or elegant product.
Technical debt
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.
Value Stream Decomposes into
Value Stream Stage
Value Stream Stage is Enabled by
Capability
Capability is Automated by
Application
Business Unit Has a
Capability
Application Decomposes into
Subsystem
Application Supports
Application
- Ensure that the organisation has a robust inventory of application software assets.
Capability/APM Alignment Guideline
- Verify that the capability map has been established to a level 3 mapping.
Capability/APM Alignment Guideline
- Verify that capabilities have been appropriately mapped to value stream stages and business units where required to improve APM.
Capability/APM Alignment Guideline
- 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
- Where subject matter expertise is lacking, rely on documentation or software analysis tools to augment the analysis.
Capability/APM Alignment Guideline
- Systematically map the capabilities of interest to the applications that automate those capabilities.
Capability/APM Alignment Guideline
- 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
- Determine the percentage of manual work required by the application for each capability.
Capability/APM Alignment Guideline
- 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
- Use this information to inform APM investment, transformation, or modification planning.
Capability/APM Alignment Guideline
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.
Refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules.
Technical Debt
Just like financial debt, some technical debts can serve ___. Other technical debts are simply counterproductive.
Valuable business purposes
A set of principles and methodologies for designing and developing software using a concept called a “service”
Service-oriented architecture (SOA)
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.
SOA analysis and design teams benefit from having a clear business foundation for
Business service design and orchestration.
SOA philosophy
“One way to do one thing. One place to get one kind of information”
SOA relies on application architecture as the basis for defining three important concepts: (1)
- The fundamental reference architecture that defines how applications will be constructed
SOA relies on application architecture as the basis for defining three important concepts: (2)
- The integration of applications (both functions and data)
SOA relies on application architecture as the basis for defining three important concepts: (3)
- Maintaining a portfolio of applications and systems
The top layer in the SOA layered reference architecture
Business processes
A series of operations that are executed in an ordered sequence according to a set of business rules.
Business process
The second layer in the SOA layered reference architecture
Business and information services
Business services provide
High-level business functionality throughout the enterprise.
Information services provide
Consolidated, cleaned, and rationalised data about business entities.
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
A managed, governed set of enterprise assets responsible for ensuring conformance to service-level agreements (SLAs)
Services
Represent logical groupings of operations.
Business services
The third layer in the SOA layered reference architecture
Integration services
Integration services provide
Integration between and access to existing applications.
The separation between the integration services and the business services is critical to
Maintaining a flexible enterprise environment.
This involves transformation of data and capabilities from existing systems to the business service level.
Integration services
The bottom layer in the SOA layered reference architecture
Operational resources
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
Operational resources applications provide business operations —
Transactions that represent single logical units of work in the enterprise’s operational systems.
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).
Data at this layer resides in existing applications or databases.
Operational resources
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.
Value stream definitions for all stakeholder focused areas of interest
(2/5) Essential requirements common to most business architecture / SOA alignment efforts.
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.
Value stream / capability cross-mappings
(4/5) Essential requirements common to most business architecture / SOA alignment efforts.
Ability to design, develop, and deploy services.
(5/5) Essential requirements common to most business architecture / SOA alignment efforts.
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)
Information views are derived from business information concepts and capabilities
Business/IT architecture mapping provides the basis for this alignment concept. (2/3)
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)
- Determine priority value streams and stages to be improved upon based on business objectives and priorities.
Business Architecture / SOA Alignment Guideline
- 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
- Review information requirements for the services based on information concepts that map to targeted capabilities.
Business Architecture / SOA Alignment Guideline
- Assess current state deployments of targeted capabilities to determine service usage and deployment options.
Business Architecture / SOA Alignment Guideline
- Review capabilities with solution architects to assess the approach required to design related services.
Business Architecture / SOA Alignment Guideline
- Review orchestration options based on value stream / process mappings.
Business Architecture / SOA Alignment Guideline
- Establish deployment plans based on where to plug services into the current state application architecture.
Business Architecture / SOA Alignment Guideline
Information, in both explicit and implicit forms, is crucial to
The success of business strategy and operations.
Informs decisions and makes routine operations more efficient
Information
Can prevent mistakes, including missed opportunities, and facilitate learning
Information
Without this, a business becomes an uncoordinated collection of individual accomplishments.
Communication
Collective decision making is a critical component of
Coordinated activity.
Information is most effectively communicated when it is
Explicit.
Data is an explicit representation of
Information
Aligning business information and data management insures that the data is representative of the performance of
The business, suppliers, clients, and partners
Aligning business information and data management insures that the data is relevant to
Those who guide and monitor the business.
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
Misalignment of business information and data management tends to result in
Failure to collect data that can enhance decision making and operational control.
An expansive view of what constitutes data includes
Printed works, images, sounds, as well as structured, semi-structured, and unstructured electronic forms.
The business information map incorporates the discovery and making explicit of
Patterns of information analysis, information provenance and information governance
The business information map guides the implementation of IT and human processes of
Application management, data management, data provenance, and data governance.
A principal element in the collaboration between the business architect and the application/data architects.
The information map
Planning, supervision, and control over data management and use
Data Governance
Defining the blueprint for managing data assets
Data Architecture Management
Analysis, design, implementation, testing, deployment, maintenance
Data Development
Providing support from data acquisition to purging
Data Operations Management
Ensuring privacy, confidentiality, and appropriate access
Data Security Management
Defining, monitoring, and improving data quality
Data Quality Management
Managing golden versions and replicas
Reference and Master Data Management
Enabling reporting and analysis
Data Warehousing and Business Intelligence Management
Managing data found outside of databases
Document and Content Management
Integrating, controlling, and providing meta-data
Meta-data Management
Relates to data governance and data security management.
Information governance
Relates to data architecture, reference, and master data management, data warehousing and business intelligence, document and content management, and meta-data management.
Information analysis
Relates to application architecture data service when this is the logical place to manage constraints that cannot otherwise be managed.
Information analysis
Relates to data quality management and data development.
Information provenance
Information governance will typically be linked with and derived from
Capabilities associated with monitoring the business and its environment.
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
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.
Information provenance is typically linked with
Capabilities that are strongly dependent on information to perform their functions.
Operational data about the business is key information for
Operations management and business strategy.
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.
Techniques such as ___ and ___ can be used to detect data manipulation.
Comparing data obtained from multiple sources and performing historical analysis
The information and capability maps provide a medium of
Discussion about the requirements for data quality.
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.
It can be very challenging to make knowledge explicit as data
when the knowledge is about the behaviour and intent of competitors
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.
The linkage from information map through capability map to value stream will point out
Information that has strategic importance.
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?
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.
- 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):
- 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):
- 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):
- 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):
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.
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.
The business architecture (information) provides the business context for
What does the data look like?
The data elements and relations.
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.
Separation of capabilities allows the development
Where and how often to get the data?
Of efficiency producing specialisation.
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.
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.
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.
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.
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.
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.
Information is often representative of
Who gets to change or delete the data?
Some physical thing
If a physical thing ceases to exist, the information item
Who gets to change or delete the data?
May no longer be needed.
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?
Each capability in a value stream may have a different
Who gets to view the data?
Perspective on the information concepts.
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
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.
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
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.
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.
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.
Automated data collection devices must be
How will the quality of the data be assured?
Periodically recalibrated.
If it is properly crafted, the information map will represent the consensus understanding of
The information concepts, lifecycle, governance, and provenance.
The enterprise may decide that it wishes to have a policy of ___ alignment.
Periodic or continuous
Will involve periodic joint audits of the information map and the IT architecture to remedy differences.
Periodic alignment
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
A discipline focused on framing automation and technical delivery of targeted business initiatives.
Solution architecture
Often takes the form of understanding and interpreting business strategy and updating current state system functionality
Solution architecture
Often takes the form of designing new ___s that go beyond current state architectural perspectives.
Solution architecture
The solution architect’s familiarity with business architecture plays a key role in
Aligning technical solutions to deliver business value.
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
Solution architects are commonly tasked with determining
IT automation approaches that will deliver value within the scope of a defined program or initiative.
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.
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
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
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.
- Establish the business architecture as a required business input into solution architecture.
Solution Architecture / Business Architecture Guidelines (1/6)
- 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)
- State business assets in terms of the vocabulary defined by the value streams, capabilities, and stakeholders.
Solution Architecture / Business Architecture Guidelines (3/6)
- 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)
- 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)
- 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)
Solution architects should consider the ___, and other components of business architecture as they develop their solution architecture.
Value streams, value stages, capabilities, information
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.
Business/IT architecture transformation is the means of
Achieving business/IT architecture alignment.
Transformation focuses on a strategic, business-driven target and involves
Multiple projects or project phases that are typically executed over a period of years.
Involves systemic changes driven by business vision, objectives, and overall strategy.
Transformation
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
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.
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.
Applying standard enhancement and maintenance changes
A traditional IT change approaches
Adding another database or data warehouse
A traditional IT change approaches
Tacking on a new subsystem
A traditional IT change approaches
Incorporating more system-to-system interfaces
A traditional IT change approaches
Plugging in a software package
A traditional IT change approaches
Building more user interface layers
A traditional IT change approaches
When the the business cannot stem the tide of customer or revenue losses
Investigate alternatives to traditional IT options
When a business is forced to cede competitive advantage to the competition
Investigate alternatives to traditional IT options
When IT fails to deliver the substantive changes a business is demanding,
Investigate alternatives to traditional IT options
The overall practice of addressing systemic business challenges is called
Business/IT architecture transformation.
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.
Requires the use of interim architecture deployments.
Business/IT architecture transformation.
Requires the realignment of application architectures to accommodate new business design patterns.
Business/IT architecture transformation.
Required for business/IT architecture transformation.
Business architecture, aligned vision, and a business-driven, target state IT architecture.
In the “rainbow model”, the uppermost level is the business architecture, supported in turn by
Application and data architectures.
In the “rainbow model”, data and application architecture are enabled by the lowest level:
The technical architecture.
The rainbow model involves
Current-to-target transformational paths
Target state IT architecture is defined by aligning
Business vision, business architecture, and IT best practices.
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.
The second major concept depicted in the rainbow model involves cross-impacts on
Various architectural layers.
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.
Data and application architectures have a direct relationship to
Capabilities, value streams, and information concepts.
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.
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.
The transformation framework has four foundational components:
Business architecture, business vision, current state IT architecture, and target state IT architecture.
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
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.
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.
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.
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.
Drafting the business architecture shown in the upper left portion of the transformation framework
Business/IT Architecture Transformation Approach (1/4)
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)
Building a baseline understanding of current state IT architecture shown in the bottom left of the figure
Business/IT Architecture Transformation Approach (3/4)
Crafting a target state IT architecture required to achieve the business vision, in alignment with business architecture
Business/IT Architecture Transformation Approach (4/4)
Before discussing the current-to-target state transformational approach, it is important to
Align business and IT architectures across current and target states.
To provide a basis for determining transformation requirements, challenges, approaches, and costs.
Align business and IT perspectives
Current state business/IT architecture mappings on the left side, depicted by the bi-directional vertical arrow, expose
Weaknesses in current state IT deployments.
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.
The target state IT architecture is based on
Business vision, business architecture, and best practices.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- Ensure the availability of baseline capability, value, and information maps
Business/IT Architecture Transformation Guideline (1/8)
- Define business vision with clear, comprehensive business objectives
Business/IT Architecture Transformation Guideline (2/8)
- Craft business vision and related objectives through the lens of the business architecture
Business/IT Architecture Transformation Guideline (3/8)
- Prioritize deployment of the vision and objectives and refine this as time progresses
Business/IT Architecture Transformation Guideline (4/8)
- 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)
- 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)
- 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)
- Deploy the roadmap in phases, refining priorities and approaches on an ongoing basis
Business/IT Architecture Transformation Guideline (8/8)
The transformation roadmap approach is NOT
A big bang, single project approach.
The transformation roadmap approach represents a series of projects that are delivered
On an ongoing basis to continuously move towards a common, business vision.
