Introduction to Business Architecture - Part 2

Introduction To Business
Architecture – Part 2
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney

Objectives
• Second part of Introduction to Business Architecture
− First part
https://www.slideshare.net/alanmcsweeney/introduction-to-
business-architecture-part-1
• This material describes conducting a specific business
architecture engagement
• Engagement process is generic and needs to be adapted to
each specific application and use
September 24, 2018 2

Business Architecture Engagement
• Formal process for gathering information and creating a
new business function model based on an analysis of that
information
• Formal process means information is gathered and
analysed in a structured way
• Analysis supports and justifies the new business model
• Reduces risks and increases the likelihood of success of the
implementation of the new business model

• The objective of the engagement is to produce results:
options and recommendations
− The engagement is a means to an end and not an end in itself
− It is a process that needs to be followed to completion
Activities
Information
Gathered
Information
Analysed and
Discussed Conclusions,
Options and
Recommendations

Scope of Business Architecture
• Scope can be a business function or entire business
Organisation
Business
Function/
Business
Area
Business
Function/
Business
Area
Business
Function/
Business
Area
Business
Function/
Business
Area

Scope
• Agree the scope of the engagement with the key business
stakeholders
• Depth and breadth of engagement
• Time and resources available
• Reason for the engagement – the problem to be addressed
and resolved, the challenge to be responded to, the
opportunity to be addressed

Initiation Steps
• Set initial engagement objectives and scope
• Refine and elaborate engagement scope
• Define the expected benefits of the engagement
• Identify sources of business knowledge
• Prepare preliminary engagement timeline
• Determine preliminary engagement costs
• Establish business user participation
• Identify source of engagement funding/resources
• Decide whether to continue with the engagement

Business Architecture – Core Internal Organisation
Areas
• Business
architecture is
concerned with
changes in one or
more of these areas
and co-ordinating
changes across
these areas to
deliver the greatest
benefit
Business
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation and
Structure

Areas
• Above The Line
− Concerned with the
organisation or the
business function
• Below The Line
− Concerned with the
technology and
infrastructure that
underpins and
enables the
operation of the
organisation or the
business function
Business
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation and
Structure

Extended View Of Information On Core Internal
Organisation Areas
• One of the objectives of the business architecture
engagement exercise is to define the target state along the
six core areas and their constituent elements
• This provides a comprehensive target structure for
information collection and analysis
• One of the purposes of business architecture is to define
the change across these six domains

Core Areas Of Business Architecture Changes
• Business-oriented areas
− Location and Offices – existing and new locations and facilities of the
organisation, their types and functions and the principles that govern the
selection of new locations
− Business Processes – current and future business process definitions,
requirements, characteristics, performance
− Organisation and Structure – organisation resources and arrangement,
business unit, function and team structures and composition, relationships,
reporting and management, roles and skills
• Technology-oriented areas
− Technology, Infrastructure and Communications – current and future
technical infrastructure including security, constraints, standards, technology
trends, characteristics, performance requirements
− Applications and Systems – current and future applications and systems,
characteristics, constraints, assumptions, requirements, design principles,
interface standards, connectivity to business processes
− Information and Data – data and information architecture, data integration,
master and reference data, data access and management

Factors Driving Business Architecture Engagement
• Organisations facing
multiple pressures
across the spectrum
of operations
• These require the
organisation to
develop new
organisation
architectures to
enable them to
respond and operate
effectively
• The objective of the
engagement is to
allow the business
develop responses
one or more of these
factors
Factors
Driving
Business
Architecture
Engagement
Globalisation
Transparency
Service
Focus and
Customer
Expectations
Challenging
Economic
Circumstances
Consolidation
Increased
Regulation
Business and
Technology
Changes and
New
Opportunities
Mobile and
Social
Computing
Changes
Competition
New Business
Models
Increased Pace
of Change

Core Areas Of Business Architecture Changes
• Business architecture engagements are concerned with
analysing these existing business core areas and creating a
target business architecture

Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure
Areas
• Organisation will
consist of multiple
business units each
with separate,
possibly partially
overlapping core
area domains
• Business functions
may be loosely
coupled and not
well integrated
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure

Business Architecture – Overall Organisation
Extended Areas
Overall
Organisation
Business
Strategy
Organisation
Operating
Environment
and Business
Landscape
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure
Business
Function
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation
and Structure

Organisation Operating Environment and Landscape
– Extended Business Architecture Elements
BusinessExtendedPotential
AreasofChange
Objectives These are what the organisation wants to needs to achieve. Individual business function objectives must
contribute to achieving the overall organisation objectives.
Strategy and
Methods
This is what the organisation will do to achieve its objectives. Individual business function strategy and
methods must contribute to those of the organization.
Success Factors
These are the core reasons of and contributors to success and achievement of the objectives. The
organisation must focused it attention on these for the company to achieve its objectives and fulfill its
mission. Individual business function success factors must conform with those of the organisation.
Critical Concerns Identify challenges, opportunities, questions, problems, trends, threats, risks or circumstances that must be
addressed and resolved.
Measurement
Framework
Set of measurement and indicators that show the degree to which the objectives are been met and the
success factors achieved
Engagement
Justification
Why are we proposing to do this, why it is needed, what is driving the requirement and what are the
timescales by which it must be complete.
Future State This is a brief description of the ideal or desired target future state in terms of business operations and
changes to key business domains
Essential Policies
and Approaches
How the business function or organisation currently achieves what it does.
Business Rules What underlies the way the business operates and how it organises its work and make decisions.

Objectives Of And Outputs From Engagement
• Objective is to create a realistic, achievable implementable
and operable target business architecture, supported by
information gathered and analysed
• Artefacts created are a means to an end and exist to
support and validate the target business architecture
• Artefacts are designed to support the conclusions and to
ensure the engagement was conducted with the necessary
and appropriate rigour
• Artefacts demonstrate evidence-based decision making

Business Architecture Engagement Components
Generalised Engagement
Activities And Their
Sequence
Generalised Deliverables
From Activities
Roles And Their
Involvement In The
Creation Of Deliverables
During Activities

• Generalised Engagement Activities And Their Sequence –
complete set of possible activities and their groups and
sequence and flow through the engagement from which
the specific engagement can be created
• Generalised Deliverables From Activities – complete set of
possible deliverables from the possible set of activities
• Generalised Engagement Roles And Their Involvement In
The Creation Of Deliverables During Activities –
identification of possible roles and their involvement in the
possible set of activities and the generation of the possible
set of deliverables

• Comprehensive and generalised set of components from
which the details of a specific engagement can be defined
• Create customised engagement from menu of options to
suit the specific needs

Create Specific And Customised Scope From
Available Menu Of Options
Activities And Their
Sequence
Generalised Deliverables
From Activities
Roles And Their
Involvement In The
Creation Of Deliverables
During Activities
Specific Customised
Engagement Activities
And Their Sequence
Specific Customised
Deliverables From
Activities
Specific Customised
Engagement Roles And
Their Involvement In
The Creation Of
Deliverables During
Activities
• Create customised path through
the business architecture
engagement process involves
agreeing activities to be
performed, deliverables from the
engagement and participating
roles

Business Architecture Engagement Scope
• Scope needs to be agreed and understood before
commencement
• Some of the steps can be iterated and repeated to increasing
levels of detail – but not too many iterations
− Information gathering and analysis needs to be time-limited
− Activities can occur in parallel by different sub-teams to optimise
elapsed time
− Always check for previously collected information and inventories to
avoid duplication
− Need to avoid analysis paralysis and move to a conclusion and set of
options quickly
• Intended to describe a structured and focussed engagement
• Suited to situations where detail and implementation structure
and framework are required

Objective Of Business Architecture Engagement
Organisation
and Structure
Locations and
Offices
Technology,
Infrastructure
And
Communications
Business
Processes
Organisation/
Business
Function
Landscape
Information
and Data
Applications
and Systems
Organisation and
Structure
Locations
And
Offices
Technology,
Infrastructure and
Communications
Business
Processes
Organisation/
Business
Function
Landscape
Information and Data
Applications and
Systems
From …
Current
Landscape To …
Target
Landscape
• Move from where we are now to an
agreed target of where we want to be

• Create a realistic and achievable target business
architecture to achieve the desired business change
• Business architecture is a structured approach to analysing
the operation of an existing business function or entire
organisation with a view to improving its operations or
developing a new business function, with a strong focus on
processes and technology
• Business architecture is not about business requirements –
it is about business solutions and organisation changes to
deliver business objectives

Where We Want To Be

• Define a target business architecture and a path to
transition to or transform into it across all the core
business domains
• Create a mapping from where the business is now to a
target future state
• Reason for documenting the current state is to provide a
basis for, a context and a justification of the definition of
the target state

Business Architecture Engagement High Level
Activities And Their Logical Sequence
0. Define And Agree
Engagement Scope
1. Information
Collection And
Assessment
2. Define Vision,
Business Principles And
System Principles
3. Document Business
Processes, Entity Model,
Capacity Planning And
Solution Approach
4. Document Solutions,
Applications And
Functions
5. Define Organisation,
Infrastructure And Data
6. Conduct Solution And
Product Evaluation And
Selection
7. Design Model
Architecture
8. Consolidate, Finalise
And Review Design

Business Architecture Engagement High Level
Activities And Their Logical Sequence
• The activities do not have to be performed in sequence
− The order can be agreed at the start of the engagement to suit the
available resources and time
0. Define And Agree
Engagement Scope
1. Information
Collection And
Assessment
2. Define Vision,
System Principles
Solution Approach
4. Document Solutions,
Applications And
Functions
Selection
7. Design Model
Architecture
And Review Design

Business Architecture Engagement Activities – 1
0. Define And Agree Engagement
Scope
0.1 Mobilise and Present Approach
to Sponsorship and Stakeholder
Team
0.2 Review Any Previous Work, if Any
0.3 Perform Initial Informal
Information Gathering
0.4 Review Information and Define
Scope of Introductory Workshop(s)
0.5 Define Team and Facilities
Required
0.6 Create Table of Contents (Scope)
of Engagement Deliverable
0.7 Conduct Introductory
Workshop(s)
0.8 Update Scope of Deliverables

1. Information Collection
And Assessment
1.1 Current Business
Review
1.2 Assess Customer (Or
External Party)
Perceptions
1.3 Review Current
Industry Best Practices
And Technology Changes
1.4 Analyse Current
Business Systems
1.5 Analyse Available
Solutions And Products
2. Define Vision,
System Principles
2.1 Define Vision For
Functional Business Area
2.2 Describe Functional
Business Area Principles,
Assumptions and
Limitations
2.3 Describe System
Principles, Assumptions
and Limitations
Solution Approach
3.1 Define And Document
Business Processes
3.2 Create Conceptual
Entity Model
3.3 Gather Capacity
Planning Information
3.4 Define Solution And
System Approach
3.5 Develop And Validate
Feasibility Prototype(s)
4. Document Systems,
Applications And
Functions
4.1 Document Systems,
Applications And
Functions

5.1 Define Organisation
And Resource
Requirements And
Structure
5.2 Define Application
And Data Organisation
5.3 Define Infrastructure
Requirements
Selection
6.1 Conduct Solution And
Selection
7. Design Infrastructure
Model Architecture
7.1 Design Infrastructure
Model Architecture
And Review Design
8.1 Finalise Application
Architecture
8.2 Define Benefits And
Costs
8.3 Create High Level
Phased Delivery Plan
8.4 Review And Agree
Business Architecture
Engagement

Business Architecture Engagement Organisation And
Landscape
Core
Team
Extended Team –
Direct Business
Participants and
Stakeholders
Wider Organisation –
Aware Of, Communicated
About And Affected By
Engagement

Workshops
• Workshops are an effective and necessary information
gathering tool as part of the business engagement exercise
• Workshops involve the core engagement team presenting
to and learning from the extended business team and the
wider organisation
• Workshops have two sets of purposes:
− Primary – achieve the stated objective, gather and confirm
information
− Secondary – build team, get acceptance and buy-in from
extended team and wider organisation, identify potential
organisation and personnel problems and hidden agendas, assist
with communication and control the message, assist with making
decisions, uncover conflicts

Workshops
• The effectiveness of workshops needs to be optimised with
careful preparation, planning and delivery
• Define and communicate objectives
• Identify and profile extended and wider team participants
• Allocate roles to core team participants
• Define schedule, timescale and duration
• Deal with issues such as facilities and equipment
• Prepare, review, agree and distribute inputs
• Create tables of contents of target deliverables
• Prepare, review, agree set of topics to be covered and
presentation material
• Document results and circulate for review and feedback

0. Define And Agree Engagement Scope

0.1 Mobilise And Present Approach To Sponsorship
And Stakeholder Team
• Ensure that the composition of the team sponsoring the
engagement and the stakeholders involved in the business area
covered by the engagement are agreed
• Prepare and review summary materials
• Present high-level approach – activities, deliverables, roles – of the
engagement
• Confirm scope and objectives
• Prepare and present work plan with indicative schedule
• Present the contents of the report from the engagement
• Agree the team composition
• Allocate resources and facilities
• This is the start of the continuous communication process during the
engagement
− It sets the tone for the remainder of the engagement

0.2 Review Any Previous Work, If Any
• There may have been other similar or related engagements
that generated outputs, relating to strategic business change
• Analyse results to determine what can be reused, if any
• Understand the issues identified during these previous
engagement
• Review how their recommendation were implemented, if at all
• Understand the reasons for the (partial or incomplete)
implementation
• This will inform how the current engagement should proceed
and how it should address problems previously encountered

0.3 Perform Initial Informal Information Gathering
• Prior to the formal introductory workshop(s) have informal and
preparatory individual meetings with engagement sponsor and some of
the key stakeholders
• Understand their vision, objectives and understanding of the business
• Ascertain the key underlying issues they are looking to resolve
• Identify their level of commitment
• Walk the floor of the current operation/business function
• Understand how work gets done
• Document the organisation structure and key people
• Present the likely workshop schedule
• Agree workshop participants
• Understand likely objections and resistance to the engagement process
and to any recommendations for change

0.4 Review Information And Define Scope Of
Introductory Workshop(s)
• Review the results of the informal meetings and
information gathered in the business area and previous
engagements
• Introductory workshop is intended to present the
engagement to those participants who will be contributing
to information gathering, issue analysis and identification
of resolutions
• The introductory workshop(s) need to be prepared
carefully to demonstrate professionalism and seriousness

Possible Topics To Cover In Introductory
Workshop(s)
Measurement Framework
•Key performance indicators across dimensions of:
•Service and product delivery – cost, time, quality, volume
•Financial – input costs, cost of product and service delivery, return
•Customer (external party) view – satisfaction, retention
•Organisation – ability to adopt changes and apply new ways of operating
Why The Engagement
•Why the engagement is taking place, what issues, challenges, needs are driving the
engagement – poor performance, service, loss of business, new regulations
•What is likely to happen if no action is taken
•What benefits are likely to accrue
Future Vision
•What does the future look like
Limitations
•What will constrain the range of solution options:
•Cost
•Time
The Team And Schedule
•Who will be involved in doing the work
•Who will contribute to the work
•Who will review the work
•How will the core and extended teams operate
•How long will it takeSeptember 24, 2018 40
Scope
•Business functions involved in the engagement
•Locations and jurisdictions involved in the work delivery
•Sets of products and services being provided
•Business processes, business rules
•Facilities, systems and applications used or that support service delivery
Why The Engagement
•Why the engagement is taking place, what issues, challenges, needs are driving the
engagement – poor performance, service, loss of business, new regulations
•What is likely to happen if no action is taken
•What benefits are likely to accrue
Indication Of Changes
•What are the likely changes across the core areas
Aims
•Business aims
•Success factors
Stakeholders
•Who needs to be involved

0.5 Define Team And Facilities Required
• Teams
− Core team that will do the work
− Extended team that will contribute to the work and review (some of
the) outputs
• Determine required competencies/skills/experience of core
team
• Create project delivery standards and templates
• Agree and document communication process
• Agree and document work delivery process including artefact
creation and review
• Acquire facilities
• Conduct team building and introductory round table session

Core Team Building And Introductory Round Table
Session
• Describe engagement, its objectives and deliverables
• Describe the known work programme and schedule
• Describe the planned work delivery process
• Describe the participants, stakeholders, organisation structure
• Define team roles, relationships and structures
• Understand team members’ experience and knowledge
• Define internal and external communication processes
• Define principles of operation such as:
− Document all interactions with extended team to avoid confusion and doubt later
− Information gathering needs to be timeboxed
• Define work delivery standards, performance, accountability and processes
• Detail internal and external meeting schedule including daily stand-ups
• Detail the team decision-making process
• Describe the boundaries:
− Between groups within the engagement team
− Between external stakeholders and participants
• Document team charter

0.6 Create Table Of Contents (Scope) Of
Engagement Deliverable
• Create an initial draft table of contents of the analysis and
report that will be generated from the business

Indicative Table Of Contents Of Output From
• Need to create a comprehensive deliverable that describes where the business function or
organisation wants to be and how this can be achieved
• This will be supported by the other more detailed artefacts created during the engagement
Summary Current State
Terms of Reference
Issues Driving Need for
Change
Current Organisation
Area Future State And
Structure
Volumetrics
Processes, Performance
and Service Levels
Business Case
Future State
Justification for Action
Target Organisation Area
Future State And
Structure
Volumetrics
Processes, Performance
and Service Levels
Impact of Change
Assumptions
Constraints
Supporting
Information
Benchmarks and Best
Practices
External and Internal
Drivers for Change
Possible Software
Products and Vendors
Cost and Benefit Analysis
Achieving The Future
State
Implementation Options
and Plans
Pilot, Phases and
Releases
Schedule and
Dependencies
Resources and People
Required

0.7 Conduct Introductory Workshop(s)
• Conduct introductory workshops with business participants aimed at
initiating the project and setting expectations
• These are designed to introduce the engagement based on the scope
agreed with the sponsor
• There are not detailed information collection sessions
• They are designed to present an overview of the envisaged end-to-end
process
• Present the proposed set of topics to be covered in subsequent
information gathering sessions
• Allow participants to comment
• Emphasise that the approach and workplan are subject to change during
the engagement
• The focus needs to be on producing quality deliverables within a
reasonable timescale and not analysing to a minute level of detail
• Produce sufficient information to allow management make an informed
decision

0.8 Update Scope Of Deliverables
• Based on the feedback from the introductory workshop(s),
update the deliverables produced so far

1. Information Collection And Assessment

1.1 Current Business Review
• Gather information on the structure and operation of
existing organisation or function operations including
locations, if this applies
• Objective is to have sufficient information on current
operations and business processes to understand
performance issues
• Document business processes
• Document organisation or function structure, locations
and interactions

Business Or Function Organisational Structure
• Create a model for the existing structure of the function being analysed
• The level of detail to be included in the model depends on the size of the
function: individual, functional group
• Classify each unit in the organisational structure:
− Roles, positions, levels/grades, functions, responsibilities, key personnel
− Decision making processes
− Work groups, work organisation, work types, work allocation and distribution, work
volumes
− Business processes operated, level and currency of documentation
− Performance, throughput, service levels, monitoring and reporting
− Technology used and staff opinion of technology
− Relationships between work groups and functions
− Interactions with other business functions
− Interactions with external product or service delivery partners
− Staff engagement, staff awareness of issues
− Issues and problems
− Planned changes

Support Processes And Systems
• Work allocation and planning systems
− How is work allocated, recorded and workload planned for
• Learning management
− Examine staff training processes and approaches
− How are business processes linked to training
• Time recording and management
• Performance recognition and reward
− How is good staff performance identified, recognised and rewarded
− How is poor performance handled
• Personnel development and talent management
− What is the approach to staff development and progression
• Staff communications
− Evaluate how staff are communicated with and how information is
disseminated

Business Or Function Locations
• Document each business or function location that comes
under the scope of the engagement
• Define location type: office, distribution, storage, service,
sales
• Describe details about the location: size, number of staff,
facilities

Business Process And Rule Examination
• This involves documenting existing business processes and associated rules
at a high-level – the detail may come later
• It is also not concerned with redesigning existing processes – this also
comes later
• Identify core business processes categories
• Document major processes within each process category
− What causes the process to be initiated?
− What information is required and where does it come from?
− What are the outcomes of the process?
− What are the key metrics about each process: time to complete, errors and rework,
cost, resources and skills required, systems used?
− How is process performance recorded and reported on?
− What rules and decision-making are applied to process operations?
− What restrictions, limitations and implied assumptions are applied to each process?
− Where are the manual steps and handoffs?
− What process documentation exists and how does it differ from the actual process
as performed?

Business Process And Rule Examination
• What work areas do not map to existing defined business
processes?
• What processes are shared between or performed at
multiple locations?
• What processes rely on external involvement and what is
that involvement?
• Where are processes and rules automated?
• Document each process category and major process within
category in a structured and common manner

Existing Technology And Information Systems
• Review systems and applications used
− Office support systems
− Applications
− Data structures
− Level of automation
− Manual workarounds
− Documentation and its currency
− Staff satisfaction

1.2 Assess Customer (Or External Party) Perceptions
• Identify some representative customers (or external parties)
that interact with the organisation or business function and
that agreed to be contacted to discuss their interactions and
experiences
− Products or services used or acquired
− How much, how frequently
− Alternatives evaluated
− Experiences of interactions and level of satisfaction
− Experiences of products or services and level of satisfaction
− Overall perception of organisation or business function
− Overall satisfaction
− Importance of organisation to customer
− Desired performance
− Views of how the organisation or business function should change or
can improve

Customer (External Party) Perceptions
• What products and services are used by the customer?
• How are products and services are used in customers’
businesses?
• What business issues do these customer face in using the
products and services?
• How do the products and services enable customers’
businesses succeed?
• What do customers like?
• What do customers not like?

What Do Customers (External Parties) Want?
• Customers (External Interacting Parties)
generally want the organisation to
demonstrate a mix of one, two or three
core values:
− Understanding and Closeness
(Enhancement) – demonstrate and act on
customer knowledge and offer customised
products and services to meet those exact
needs
− Product and Service Operational Excellence
(Efficiency/Utility) – provide reliable,
convenient, easy-to-use, cost-effective, value
for money products and services
− Product and Service Innovation and
Leadership (Transformational) – offer
products and services that are better, more
innovative, technologically advanced than
others

What Do Customers (External Parties) Want?
• Understand what your customers (external parties) want,
how they perceive you and what you can are capable of

What Issues Do Customers (External Parties)
Encounter?
• Identify issues customers encounter during business
interactions
− Access to information
− Quality of information
− Access to person
− Speed and quality of response
− Provision of response
− Ease of ordering products and services
− Order status
− Product and service delivery
− Product and service utility
− Price, billing
− Accuracy and rework
− Query and error handling and resolution
• Use process groups to identify points where problems arise

Sample Process For Buy Product Or Service
Buy Product/Service
Customer Contact
Management
Information Request
Fulfilment Response
Provide Quotation
Collect and Validate
Requirements
Process Information and
Create Quotation
Issue Quotation
Follow-up on Quotation
Manage Negotiations
Sell
Handle and Fulfil Order
Billing
Bill Invoicing
Bill Payments and
Receivables
Management
Bill Inquiry Handling
Receive Customer Bill
Inquiry
Assess Customer Bill
Inquiry
Authorise Customer Bill
Invoice Adjustment
Track and Manage
Customer Bill Inquiry
Resolution
Analyse Detailed Bill
Inquiry
Determine Appropriate
Bill Adjustment
Record Customer Bill
Invoice Adjustment
Issue Adjusted Bill
Report Customer Bill
Inquiry
Close Customer Bill
Inquiry
Handle Payment

Sample Customer Journey For Buy Product Or
Service
Look For
Information/
Awareness
And
Interest
Generated
Look For
Details on
Specific
Product/
Service/
Offer
Receive,
Evaluate
Offer,
Negotiate
and
Compare
Decide To
Buy
Product/
Service
Pass
Enrolment,
Buy/
Subscribe
and
Receive
Product/
Service
Receive
and Pay
Usage
Statements
and Bills
Query
Usage
Statement
and Bill,
Pay Bill
Report
Fault/
Complaint
Upgrade/
Buy
Additional
Product/
Service/
Respond to
Offer
Renew,
Evaluate
Alternatives
and
Negotiate
Decide to
Leave/
Cancel
Service
Accept
Counteroffer

Sample Customer Journey For Buy Product Or
Service – External To Internal Mapping
Look For
Information/
Awareness
And
Interest
Generated
Look For
Details on
Specific
Product/
Service/
Offer
Receive,
Evaluate
Offer,
Negotiate
and
Compare
Decide To
Buy
Product/
Service
Pass
Enrolment,
Buy/
Subscribe
and
Receive
Product/
Service
Receive
and Pay
Usage
Statements
and Bills
Query
Usage
Statement
and Bill,
Pay Bill
Report
Fault/
Complaint
Upgrade/
Buy
Additional
Product/
Service/
Respond to
Offer
Renew,
Evaluate
Alternatives
and
Negotiate
Decide to
Leave/
Cancel
Service
Accept
Counteroffer
Internal Processes and
Activities Needed to
Deliver Customer Journey
Customer End-to-End Journey

1.3 Review Current Industry Best Practices And
Technology Changes
• Review best practices within the industry area in which the
organisation or business operates and companies that
excel in areas of relevance
• Review what other competing organisations use and how
their performance compares
• Review business trends
• Review technologies and providers
• Review technology trends

Review Best Practices
• Purpose is to understand how comparable organisations achieve better performance
• Review organisations offering similar products and services
• Review organisations that excel in specific areas and that do not necessarily offer similar
products and services
− Customer service
− Brand development
− Innovation
− Cost reduction
− Sales
− Similar complexity of operation, products or services
− Supply chain management
− Efficiency, performance, throughput for numbers of staff
− Quality control, errors
− Use of technology
− Use of resources
− Organisation structure
• Look for excellence in the previously identified core process categories
• Look for how excellence was achieved and what the previous state was
• Examine the what – results and outcomes achieved – and the how
• Use the information to identify possible new approaches and options to operate the core
processes

• Source best practice information from:
− Search of publications and articles
− Industry experts
− Direct contacts
− Relevant industry associations
− Employees’ previous experience
− Customers’ (external party) experience
• Could consider using services of professional survey
organisation if time and budget allow and if the scope of
the work justifies it

• Classify the results of the best practice analysis using the previously
identified process categories and other analysis factors
− Customer service
− Brand development
− Innovation
− Cost reduction
− Sales
− Similar complexity of operation, products or services
− Supply chain management
− Efficiency, performance, throughput for numbers of staff
− Quality control, errors
− Use of technology
− Use of resources
− Organisation structure
• Identify those organisations that are achieve more and determine
gaps between the two organisation
• Quantify difference and describe the reasons for the difference

Review Technology Trends
• What new technologies are available?
• How commercially available are these new technologies?
• How can these new technologies be applied within the
organisation?
• How are other organisations using new technologies?
• Who are the vendors offering these new technologies?

1.4 Analyse Current Business Systems
• Examine the business system and technology landscape,
data and communications infrastructure

Review Data Stores
• Lists major data stores
− Subject area(s)
− Underlying applications
− Data source(s)
− Data types and formats
− Size, amount of data, number of transactions
− Technology and its currency
− Data quality issues
− Value and utility to the business
− Year of implementation, year of last major upgrade/update

Create Logical Data Topic Entity Model
• Create diagram(s) identify key data topics or classes
• Document high-level contents of each data topic
• Identify relationships and linkages between data topics
Data Details
Data Details
Data Details
Data Subject
Data Details
Data Details
Data Details
Data Subject
Data Details
Data Details
Data Details
Data Subject
Data Details
Data Details
Data Details
Data Subject
Data Details
Data Details
Data Details
Data Subject

Review Business Systems And Applications In Use
• Create an inventory of business systems and applications in use
• Describe their technology basis – product/custom-developed, software used,
technical infrastructure
• Detail the core functions provided by the systems and applications
• Link the business systems and applications to the core process categories and
their constituent processes
• Describe the state of these systems and applications
− Fitness for purpose and suitability for current business operations
− Value to the business
− Manual workarounds and manual handoffs to other systems
− Ease of use, usefulness
− Goodness of fit for planned and known future business changes
− Efficiency of operations
− User experiences of the system
− Level and currency of documentation and training material
− Volume of work, number of users, number of transactions
− Year of implementation, year of last major upgrade/update
− Internal or hosted

Review Business Systems And Applications In Use
• Evaluate the technical state of the business systems and
applications
− Reliability
− Availability
− Compliance with technical standards
− Compliance with data regulations
− Flexibility and ease of modification
− Vendor plans for packaged applications
− Version in use and current versions supported by vendor
− Issues with technical infrastructures - for example, operating system
and database versions
− Cost of operations, support and maintenance
− Fitness and appropriateness as a platform for future developments
− Compliance with organisation IT architecture standards

Review IT And Communications Infrastructure
• Create a diagram showing the infrastructural components,
including any network, and their relationships
• Identify major elements of the infrastructure
− External hosting and communications links
− Internal infrastructure – server operating systems, databases
− Security
− Application access
− User access devices

Categorise Business Systems And Applications
• Create four state
classification of reviewed
business systems and
applications based on two
factors (collected earlier
and reviewed now):
− Value to the business
− State of application and
underlying technology and
vendor
Value to the Business
Application
Technical
State
Retain or
Replace
Later
Retain
Replace
Now
Replace
Later
Low High
Poor
Good

Categorise Business Systems And Applications
• Application Technical State Poor Value to the Business Low =
Replace Now
− These applications need to be replaced or retired and their data converted to
new platforms
• Application Technical State Good Value to the Business Low = Retain
or Replace Later
− These applications may be considered for replacement in the future or may be
retained depending on the target business architecture, the associated
technology architecture and the systems needs to support its operation
• Application Technical State Poor Value to the Business High =
Replace Later
− These applications should be flagged for replacement in the future
• Application Technical State Good Value to the Business High =
Retain
− These applications should be retained unless there are better options readily
available that can be implemented easily and quickly with minimum disruption

1.5 Analyse Available Solutions And Products
• Objective is to evaluate possible options for business
systems and applications - package, in-house or hosted or
custom development - flagged for replacement now or in
the future
− High-level evaluation and sense-check that product is likely to
meet key requirements
− Not conducting a full tendering process
• Identify sources of possible sets of product information
• Prepare vendor contact approach including questionnaire

Production Options – Functional And Operational
Requirements
• Define high-level functional requirements based on
functionality provided by current products and likely
future business requirements
• Define high-level operational and product delivery
requirements – capacity, number of users, volume of data

Vendor Contact Questionnaire
• Vendor details – company size, duration in business, product
details, numbers of installations of product, maturity of
product
• Compliance with functional requirements
• Compliance with operational requirements
• Security model
• Product delivery options
• Customer satisfaction
• Implementation project resources and timescale
• Service management and support
• Outline financial analysis – initial cost, maintenance, cost of
ownership

Vendor Contact Summary
• Summarise information gathered from vendors, comparing
solutions across key requirement and evaluation factors

2. Define Vision, Business Principles And System
Principles

2.1 Define Initial Vision For Functional Business Area
• The vision is a high-level description of the desired future
operating model of the organisation or business function
• It is concerned with the desired future state and not how that
state can be achieved
• Vision contains:
− The expected environment in which the organisation or business
function operates:
• Products and services provided
• Customer segments supplied
• Physical distribution
• Competitors
• Economy
− The business function operating model in terms of its future core
business process groups and constituent business processes
• Structure of the business function core operating domains
• Organisation structure and operation
• Supporting and enabling technology

Initial Vision For Functional Business Area
• Use scenarios and process journeys to walk through the
internal and external operations for key business activities
and detail their flow
• Develop inventory of key scenarios and process journeys
• The approach breathes life into the operating model and
can be used to determine its validity
• There can be more than one vision or alternative versions
of the vision

Initial Vision For Functional Business Area
• Vision is the means for articulating the target of the
business architecture engagement
− Externally used to communicate what the engagement is
concerned with
− Internally used to organise and focus work effort and to define
the boundaries of the work

Factors To Consider When Developing Vision
Products and Services
• What products and services do we
supply
• How many types do we supply?
• How are they different from those of
other organisations?
• How do we deliver the products and
services ?
• How do we develop and enhance
them?
Customers
• Who do we provide products and
services to?
• How broad is the range of customers?
• Why do customers acquire our
products and services?
Suppliers and Partners
• Who are our suppliers and partners?
• How do we work with them?
• How many are there?
Competition
• Who do we compete with?
• How do we compete?
• How well do we compete?
• How are we different from our
competitors?
• How is competition changing?
Regulatory Landscape
• What is the regulatory landscape?
• How compliant are we with
regulations?
• How is it changing?
Business Processes
• How well defined are our business
processes?
• How optimised, integrated, efficient
and automated are they?
• How well do they work in terms of
cost and time to operate?
• How do we measure performance?
Organisation
• What is our organisation structure?
• Who does what?
• What does it cost to operate?
• How is the organisation operated and
managed?
• How do we recognise and reward talent
and performance?
Locations and Facilities
• Where do we operate from?
• How many types of locations do we
have?
Systems, Data and Technology
• What are the key business systems?
• How well do they meet the needs of the
organisation?
• How well integrated are they?
• What is the state of the organisation’s
technology infrastructure?
• Can customers and suppliers interact
with the organisations using technology?
• How well do we manage data?

Business Model Canvass
• Consider using the Business Model Canvass approach to describe the
vision for the functional business area
• Divides business into nine elements in four groups
− Infrastructure
• Key Partners - the key partners and suppliers needed to achieve the business model
• Key Activities - the most important activities the business must perform to ensure the
business model works
• Key Resources - the most important assets to make the business model work
− Offering
• Value Propositions - the value, products and services provided to the customer
− Customers
• Customer Relationships - the customer relationships that need to be created
• Channels - the channels through which the business reaches its customers
• Customer Segments - the types of customers being targetted by the business model
− Finances
• Cost Structure - the most important costs incurred by the business model
• Revenue Streams - the sources through which the business model gets revenue from
customers

Business Model Canvass
Key Partners
• Who are our key partners?
• Who are our key suppliers?
• What Key Resources do we acquire
from partners?
• What Key Activities do partners
perform?
MOTIVATIONS FOR
PARTNERSHIPS
• Optimisation and economy
• Reduction of risk and uncertainty
• Acquisition of resources and skills
Key Activities
• What key activities do our value
propositions require
• What are our distribution channels?
• What are our customer relationships?
• What are our revenue streams?
CATEGORIES
• Production
• Problem Solving
• Platform/Network
Value Propositions
• What value do we deliver to our
customers?
• Which of our customers’ problems are
we helping to solve?
• What bundles of products and
services do we offer to each customer
segment?
CHARACTERISTICS
• Novelty
• Performance
• Customisation
• “Getting the Job Done”
• Design
• Brand
• Status
• Cost Reduction
• Risk Reduction
• Accessibility
• Convenience/Usability
Customer Relationships
• What type of relationship does each of our
customer segments expect us to establish
and maintain with them?
• What ones have we already established?
• How are they integrated into our business
model?
• How much do they cost?
EXAMPLES
• Personal assistance
• Dedicated personal assistance
• Self-service
• Automated services
• Communities
• Co-creation
Customer
Segments
• For whom are we creating
value?
• Wo are our most important
customers?
• Mass market
• Niche market
• Segmented
• Diversified
• Multi-sided platform
Key Resources
What key resources are required by our
Value propositions Distribution channels
Customer relationships
Revenue streams
TYPES OF RESOURCES
Physical
Intellectual
Human
Financial
Channels
• Through which channels do our customer
segments want to be reached?
• How are we reaching them now?
• How are our channels integrated?
• Which ones are most cost-efficient?
• How are we integrating them with customer
processes?
CHANNEL PHASES
• Awareness - How do we raise awareness
about our products and services
• Evaluation – How do we help customers
evaluate our value proposition?
• Purchase – How do we allow customers
purchase specific products and services?
• Delivery – How do we deliver a value
proposition to customers?
• After Sales – How do we provide post-
purchase customer support?
Cost Structure
• What are the most important costs inherent in the business model?
• Which key resources are the most expensive?
• Which key activities are the most expensive?
IS THE BUSINESS MORE:
• Cost Driven – leanest cost structure, low price value proposition, maximum automation, extensive
outsourcing
• Value Driven – focussed on value creation, premium value proposition
SAMPLE CHARACTERISTICS
• Fixed costs
• Variable costs
• Economies of loading
• Economies of scale
Revenue Streams
• What value are customers really willing to pay for?
• What are they currently paying for?
• How are they currently paying?
• How would they prefer to pay?
How much does each revenue stream contribute to overall revenue?
TYPES FIXED PRICING DYNAMIC PRICING
• Asset sale • List price • Negotiation/bargaining
• Usage fee • Product feature dependent • Yield management
• Subscription fees • Customer segment dependent • Real-time market
• Lending/renting/leasing • Volume dependent
• Licensing
• Brokerage fees
• Advertising

Key Stakeholder Interviews
• Gather information from key stakeholders using structured
one-to-one interviews
• Summarise information collected to create initial view of
current and desired or target future state
• Clarify and align vision through collective workshops
• Document updated vision
• Communicate vision

Key Stakeholder Interviews
• Identify key stakeholders who are important to the achievement of
the target from the business architecture engagement or who know
about the business environment
− Business executives and heads of business functions
− Those involved in developing business strategy
− Those involved in analysing business and market trends
• Interviews will gather hard and soft information
− Hard – facts, numbers, detail
− Soft – stakeholder level of interest, engagement, commitment and enthusiasm,
possible resistance, amount and quality of information provided
• Collect information from multiple stakeholders to get different
perspectives
• Prepare structured interview notes using previously documented
vision factors and business model canvas
• Conduct stakeholder interviews, document information collected
and circulate for comments

Consolidate Stakeholder Interview Information
• Create starting vision based on consolidated information
collected and analysed
− Separate the What of the vision from the How of its actualisation
• Describing the vision
− Use scenarios and process journeys to walk through the internal
and external operations for key business activities and detail their
flow
− Develop inventory of key scenarios and process journeys
− Describe alternatives and options where they arose
− Identify differences and divergences where they arose in the
information collected
− Define the choices and decisions to be made

Vision Workshop
• Purpose is to present the consolidated vision, alternatives,
differences and decisions
− Again, separate the What of the vision from the How of its actualisation
− The How is a constraint that can be addressed later
• At this stage, a detailed analysis and discussion can be counter-
productive
• Objective is to achieve (some) consensus on the vision and to
create a netted list of disagreements and differences
• Present the information collected using the previous structures
and frameworks:
− Scenarios and process journeys
− Vision factors and business model canvas
− Use pictures and diagrams

Rich Pictures
• Detailed visualisations represent information more effectively
than lengthy narrative text
− More easily understood and engaged with
• Show relationships, interactions
• Provides a more concise illustration of state
• Better tool to elicit information
• Gaps, errors and omissions more easily identified
• Assists informed discussions
• Evolve and refine rich picture representations of as-in and to-
be situations throughout the engagement exercise
• Cannot expect to capture every piece of information – focus on
the important elements
• A rich picture is not a process map
24 September 2018 91

Rich Pictures – Typical Contents
• Not all picture need have all elements
• You can have multiple pictures and pictures can evolve
Element Description
Core Objective(s) Brief statement of the core purpose(s) of the situation where there is perceived to be a
problem – what the associated service is looking to achieve
Actor Persons or groups within the organisation or externally providing services to the
organisation involved in the delivery of the overall service
Consumer Persons or groups at whom the service is being directed or who use the service
Entities, Types and Roles Functional collections of persons or groups within the organisation or externally providing
services
Locations and Facilities Locations or interaction points where consumers avail of or are provided with services
Viewpoints Views or opinions of actors on the provision and operation of the service
Relationships and
Dependencies
Relationships and dependencies between other elements of the rich picture
Interactions Dealings and relations between entities, actors and consumers
Processes Processes that are used to deliver service or support its delivery
Options, Questions Options and questions relating to the core service objectives
Requirements, Obligations Requirements and obligations of actors and entities, relating to the core service objectives
Core Issues and Owners Issues relating to the core service objectives
Constraints, Limitations Any actual or perceived constraints and limitations relating to the provision and operation
of the service

Rich Picture Example
Entity 1 Entity 2 Entity 3
Entity 10 Entity 11
Entity 7 Entity 8 Entity 9
Entity 5 Entity 6
Entity 4
Location 1
Issue 1
Issue 2
Issue 3
Location 2
Viewpoint 1
Requirement 1
Requirement 6
Requirement 3
Requirement 4
Requirement 2
Viewpoint 2
Viewpoint 4
Viewpoint 3
Interaction
Interaction
Interaction
Interaction
Process 1
Process 2
Process 3
Viewpoint 5
Interaction
Interaction
Constraint 1
Constraint 2
Constraint 3
Requirement 5
Location 3
Core
Objectives
Consumer 1
Consumer 2

Rich Pictures
• Are not systematic views (yet)
• They do not contains system-related components such as
IT applications, infrastructure and data flows at this stage
− These are solution and implementation-related elements
• Resist the temptation to include systematic parts at the
investigation stage and pre-judge options for resolution
and transformation
− Transformation with a small “t”
• Jumping to conclusions at this stage will limit the scope of
information gathered

Refine And Communicate Vision
• Update the vision based on workshop contents and
outcomes
• Distribute to stakeholders

Achieving Organisational Change
• Achieving the ultimate target business architecture
involves organisation change
• The required changes may be resisted by some affected
stakeholders and other individuals or the organisation
itself may be unable to accommodate change
• It is important to identify potential blockers early in the
business architecture engagement and to continue this
throughout the engagement
− Early and often
• Actions need to be defined that address these blockers in
order to enable the required change to occur

• Actions can include:
− Supporting those that in favour of change
− Identifying and addressing the objections of those who resist
change
− Articulating the new culture that will facilitate change
− Defining the change message and communicating the need for
change
− Assembling suitable business representatives into a change forum
to whom the progress of the engagement and the benefits of
change
− Collect and respond to feedback
− Creating a communications portal with information that affirms
the need for change

• Plan to take a carrot and stick approach to change
• Plan to encourage and reward those who accept and
embrace change
• Demonstrate the benefits of change
• Emphasise that change is part of the future operating
model

2.2 Describe Functional Business Area Principles,
Assumptions and Limitations
• This is concerned with defining the principles, assumptions and
limitations for the overall business function and for each of the
individual six domains
− Principles, assumptions and limitations can be interchangeable
− Definitive categorisation is not important – just capture them for now
• Principles are values, codes, standards, guidelines, and
directions that underpin and govern the overall organisation or
business function
• Assumptions are used as the basis for decisions
− Assumptions need to be validated – they can be false
• Limitations are constraints that narrow range options and
scope of action

Principles, Assumptions And Limitations
Business
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation and
Structure
Principles
AssumptionsLimitations
Principles
Principles
Principles
Principles
Principles

Gathering Principles, Assumptions and Limitations
• Principles, assumptions and limitations affect the target
vision
• Understanding principles, assumptions and limitations are
important to creating a realistic and achievable vision that
meets the needs of the organisation
• Information on principles, assumptions and limitations can
be initially gathered through a focussed and dedicated
workshop
• Principles, assumptions and limitations should be refined
throughout the exercise

2.3 Describe Application And System Principles,
Assumptions and Limitations
• Concerned here with describing the usage of applications and systems and not the detail of
their construction – external rather than internal view
• Applications and Systems
− Current application and system selection, design, operation principles – rules that define usage and
actions
− User interfaces and interaction
− Integration
− Constraints that limit operation and use
− Assumptions on the applications and systems – extendability, growth, deployment and usage in different
ways
• Information and Data
− Who and how acquires, owns, uses, manages
− Limitations
− Assumptions on data – quality, integration, redundancy
• Technology and Infrastructure
− Current technology and infrastructure organisation, selection, design, operation principles – rules that
define usage and actions
− Security
− Standards and compliance
− Limitations
− Assumptions on technology and infrastructure – suitability, capacity, growth, adaptability

Describe Organisation Structure, Business Process and
Location Principles, Assumptions and Limitations
• Business Process
− Principles
• Process optimisation through compression of work and collapse of roles
• Include parallel processing
• Automation as much as possible
• Decision by exception rather than in all cases
− Assumptions
• Number of people available to process work
• Number of work items
− Limitations
• Levels of process workload

• Organisation and structure
− Principles
• Organisation structure, hierarchy, reporting
• Allocation and handling of work
• How do we want to interact with partners, suppliers, customers
− Assumptions
• Number of people in each function and role
• Skills and experience required
− Limitations
• Numbers of new staff, retraining
• What limitations apply to organisation change
• What is the regulatory environment

• Locations and offices
− Principles
• Number and type of locations and offices
• Consolidation of locations and offices as required
• Location of work processing
− Assumptions
• Size and quality of locations and offices
• Costs of locations and offices
− Limitations
• Restrictions on options to consolidate locations and offices
• Restrictions on options to relocate staff
• Restrictions on availability of suitable locations and offices

Collect Principles, Assumptions and Limitations
Through Workshop
• Present previously defined vision and information
collected during business review across six domains
− Location and Offices
− Business Processes
− Organisation and Structure
− Technology, Infrastructure and Communications
− Applications and Systems
− Information and Data
• Use this structure to understand principles, assumptions
and limitations

3. Document Business Processes, Entity Model,
Capacity Planning And Solution Approach

3.1 Define And Document Business Processes
• The objective of this activity is the design of the target business
processes
• Processes are important because they reflect and represent what
the organisation does and how it does it
• This can be based on the redesign of existing processes to make
them more efficient and effective or it can involve the definition of
entirely new business processes that replace existing ones
− Redesign of existing processes is usually termed Business Process
Improvement (BPI)
− Design of new business processes is usually termed Business Process Redesign
(BPR)
• The two approaches can be used in tandem for different processes
• This section will not cover business process design in detail – that is
best done elsewhere (for example, see
http://www.slideshare.net/alanmcsweeney/introduction-to-
business-process-management)

Business Process Generic Structure
Doing Processes
Administering, Gathering Information,
Controlling, Managing and Improving the
Doing Processes
Process
Group
Major
Process
Detailed
Process
Activity
Activity
Activity
Major
Process
Detailed
Process
Activity
Activity
Activity
Process
Group
Major
Process
Detailed
Process
Activity
Activity
Activity
Major
Process
Detailed
Process
Activity
Activity
Activity
Process
Group
Major
Process
Detailed
Process
Activity
Activity
Activity
Major
Process
Detailed
Process
Activity
Activity
Activity
Process
Group
Major
Process
Detailed
Process
Activity
Activity
Activity
Major
Process
Detailed
Process
Activity
Activity
Activity

Business Process Redesign – Compress And Collapse
• Compress – reduce unnecessary/non-value-adding steps
• Collapse – eliminate unnecessary handoffs and involvement
Collapse
Compress

Business Process Change Options
Left-to-Right Process Change - Process Performance Improvement
Right-to-Left Process Change – Output-Driven Process Redesign

Business Process Change/Design Options
• Business Process Redesign (BPR) – design a new process
to achieve the desired outputs
− Focus is on specifying new processes to replace existing ones so
less detail on existing processes needs to be collected
• Business Process Improvement (BPI) – modify current
process to eliminate problems
− Focus is on collecting detailed information on existing processes
so they can be improved
• BPR and BPI techniques are equally valid and can be
applied together

Business Process Change/Design Principles – Avoid
Waste
• Causes of waste – various definitions and lists available
from
− Six Sigma
− Lean Manufacturing
− Lean IT
• Originally seven causes of waste identified
• Increased over time to 8, 9, 10, 11 or 12
• Principles of identifying and avoiding waste can be applied
to business process design

Causes Of Waste
• Original Lean Manufacturing Seven Causes of Waste
1. Overproduction - manufacturing an item before it is actually required
2. Waiting - whenever goods are not moving or being processed
3. Transport - moving products between processes is a cost which adds no value to the product
4. Inventory – excess work in progress (WIP) cases by overproduction and waiting
5. Unnecessary / Excess Motion - people or equipment moving or walking more than is required
to perform the processing
6. Over/Inappropriate Processing - using expensive resources where simpler ones would be
sufficient
7. Defects - resulting in rework or scrap or the need for excessive quality control
• Additional causes of waste added over time
1. Wrong Product - manufacturing goods or services that do not meet customer demand or
specifications
2. People Unmatched to Role - waste of unused human talent/underutilising capabilities and skills
and allocating tasks to people with insufficient training to do the work
3. Inadequate Performance Measurement - working to the wrong performance metrics or to no
metrics
4. Uninvolved Personnel - not using staff fully by not allowing them to contribute ideas and
suggestions and be part of participative management
5. Inadequate Technology - improper use of information technology - inadequate or poorly
performing systems requiring manual workarounds, systems that deliver poor response times,
systems or the underlying data that are unreliable or inadequate training in the use of systems

Causes Of Process Waste
Cause Of Waste Business Process Approach to Avoiding Waste
Overproduction • Process work as it arises
Waiting • Reduce delays as work waits to be processed
• Reduce linear processing and include as much parallelism as possible
Transport • Reduce number of steps and movement and delays
• Ensure work in performed in the optimum location
• Reorganise work processing to optimise locations
Inventory • Eliminate batching of work rather and move individual cases through the process
Unnecessary / Excess
Motion
• Reduce unnecessary handoffs
• Reduce fragmentation of work
• Reduce the need to search for information
Over/Inappropriate
Processing
• Reduce unnecessary variation in work types
• Reduce the application of unnecessary steps to work
• Do not delay simple work with steps that only need to be applied to complex work
• Reduce non-value adding steps
• Eliminate unnecessary checks and controls

Causes Of Process Waste
Cause Of Waste Business Process Approach to Avoiding Waste
Defects • Reduce the need for inspection by automating quality checks and identifying
errors as early in the process as possible
• Do not allow work to start until necessary pre-requisites are available
Wrong Product • Organise work around processes rather than processes around work and focus
People Unmatched to
Role
• Ensure people are adequately and continuously trained
• Structure work around required functional competencies
Inadequate
Performance
Measurement
• Design process metrics to allow process efficiency be measured
• Implement process data collection, reporting and analysis
• Take decisions on process metrics
Uninvolved Personnel • Delegate decision-making and empower people to complete work
• Encourage, support and reward new ideas
• Encourage feedback from those performing the work
Inadequate Technology • Ensure people has access to the necessary technology to allow work to be done
efficiently
• Use technology to automate business processes
• Optimise technology
• Build knowledge-base and documentation into technology

Cross Functional Processes – Crossing “Vertical”
Operational Organisational Units

Cross Functional Processes – Crossing “Vertical”
Operational Organisational Units
• The organisation sees the structure vertically and in a
compartmentalised view and all to frequently does not see
the viewpoint of the entity that is the beneficiary of or the
recipient of the output of the process
• Cross-functional processes deliver value
− Value to the customer
− Value to the company
• Changing business process operations to take a cross-
functional view eliminate waste and inefficiencies
associated with work moving through organisational silos

Business Process Design Success Factors
Make the beneficiaries of the process the
centre of process change and process
value.
Focus On The Process Beneficiaries
Get the process activities needed to
achieve the process goals first. Then
examine and optimise process
performance.
Examine Process Delivery First and
Then Process Performance
The process drives value achieved.
Technology and organisation are enablers
of process operations. Value is derived
from process improvement.
Emphasise The Process And Not Its
Constraints
Your processes may interact with other
external processes. Consider extending
your analysis to these to understand the
complete process.
Extend Process Examination To
External Processes
Create a vision for process excellence
based on service, performance, delivery
and achievement of goals unconstrained
by limitations.
Create A Top-Down Process Vision
Learn from the experiences and
achievements of other organisations in
achieving process change to benefit from
them.
Look At What Others Have Achieved
The process consists of the activities, the
organisation functions that operate the
processes, the source of the process
initiation and technology. Look at all these
elements.
Examine The Entire Process Landscape
Document the existing rules, assumptions,
principles and constraints that underpin
the current process operation. Do not
accept these when redesigning processes.
Do Not Accept Current Beliefs

Process Analysis High Level Steps
Describe Current Process Landscape
Describe the current process landscape in enough
detail to allow business rules to be understood and for
issues, problems and improvements to be identified
Describe Current Process Performance and
Value Generated
Where appropriate (when current processes are being
redesigned), describe the effort, resources, cost,
duration, errors, rework and value generated for the
current processes
Identify and Design the Core Process
Landscape
Identify and (re)design the theoretical minimum set of
core processes required to achieved the required
outcomes and results assuming there are no constraints
Define Throughput Requirements and
Performance Measurement Framework
Define the performance and through required for the
process operation – effort, resources, costs, error,
quality, rework – and define the measurement
framework to create the data to assess this
Verify Core Process Landscape
Verify that the (re)designed set of core processes will
achieve the defined set of performance and throughput
requirements

Business Process Analysis Information Structure
Analysis Information
Structure
Current Situation
Business Process Model
Process Structure and
List
Process Definitions
Process Triggers
Process Outcomes/
Results
Process Conceptual
Representation
Process Flow
Representation
Process Performance
Structure
Process Beneficiary
Requirements
Comparative
Performance Summary
Process Performance
Metrics
Process Performance
Measurement Structure
Target Future State
Process Structure and
List
Process Definitions
Process Triggers
Process Outcomes/
Results
Process Conceptual
Representation
Process Flow
Representation
Process Performance
Structure
Process Beneficiary
Requirements
Comparative
Performance Summary
Process Performance
Metrics
Process Performance

Business Process Analysis Information Structure
• The intention is not to create an exhaustive and detailed
set of information deliverables
• The goals of information analysis are:
− Reduce uncertainty in the future state
− Reduce number of viable and realistic and achievable options
• You cannot collect and analyse information forever

Analysis Paralysis And Decision Avoidance
Analysis
and Design
Never Escape
Analysis
Stage –
Always
Looking For
More
Information
and
Perfection
Decision
Making
Decision Making
Request/ Response
Loop For More
Information –
Always Looking For
more Details,
Additional Options,
More Clarification
Never Escape
Decision
Stage

Characteristics Of Analysis Paralysis And Decision
Avoidance
• Two possible loops:
− Analysis Loop – where analysis
never finished
• Analysis and design do not want to
let go – always looking for
perfection and want to retain
ownership
− Decision/Analysis Loop –
where decision making is
deferred because of requests
for more analysis
• Fear of decision-making is masked
by endless requests for more
information and options
Analysis
Loop
Decision/
Analysis
Loop

Clearing The Analysis Paralysis And Decision
Avoidance Hurdles
Clear The
Decision
Avoidance
And Evasion
Hurdle
Clear The
Analysis And
Design
Paralysis
Hurdle
Move To Implementation,
Service Introduction,
Transition To Production
Plateau
Analysis And Design
Can Be Viewed By
Some As A Trough Of
Despair

Find The Information Saddle Point
• Do as little as possible to achieve as much as possible to make an
informed decision on whether and how to proceed at gate stage in
the business architecture engagement journey
• Key principle at this stage is satisficing – optimise effort and
resources during planning - satisfy requirements sufficiently
Minimise
Effort
Maximise
Results

Current Situation And Future State Deliverables
• Process Structure and List List the process hierarchy: major process groups and key processes within each
group. There will be two types of processes:
1. Delivery processes
2. Management processes that are concerned with the internal management
and operation of the business function
• Process Definitions Create high-level descriptions for the major process groups and key processes
within each group
• Process Triggers Detail what causes each of the key processes to be initiated
• Process Outcomes/ Results Detail the outcomes, deliverables and results of the key processes
• Process Conceptual
Representation
Conceptual representations are actor/entity-based pictures that communicate at
a high level how a business process works
• Process Flow Representation These are standard business process flows, typically represented as cross-
functional diagrams
Process Performance Structure
• Process Beneficiary Requirements What are the requirements of each of the main beneficiaries (such as customers)
want from the process, both in terms of performance (time to compete) and
results
• Comparative Performance
Summary
What do other organisations achieve for similar processes to similar beneficiaries
illustrating what is possible
• Process Performance Metrics What are the metrics for the processes: time to complete, cost, resources, steps,
number of process executions, errors, rework
• Process Performance
What is the measurement framework used to assess process performance and
throughput and how is the data collected, analysed and presented

Process Activity Decomposition And Description
Detail
• Processes can be represented at different levels of detail
• Document sufficient detail to allow problems and opportunities to be
identified
…
… …

Process Activity Decomposition And Description
Detail
• Create and agree an inventory of triggers and events to which
the business function reacts and responds
− Identify any new triggers and events required by new/changed
processes
• Create and agree an inventory of outputs and results generated
in response to triggers and events by process activities
− Identify any new outputs and results required by new/changed
processes
• Create and agree an inventory of outcomes achieved or desired
in response to triggers and events by process activities
− Identify any new outcomes required by new/changed processes
• Create and agree an inventory of key process activities
− Identify any new activities required by new/changed processes
− Decompose large monolithic activities into smaller more granular
representations of key process activities

Describe Current And Future Target Process Activity
Performance Attributes
• Not all process activities will share all performance attributes
− Performance attribute is one that has a cost, direct or indirect
• Detail the current and future targeted/desired/expected
performance characteristics
Process
Trigger(s)/
Event(s)
Required Input(s)
Output(s)/
Result(s)
Outcome(s)
Cost Resources
Skills/
Roles
Error Rate
Elapsed
Time
Inventory
Levels
Service
Levels
Effort(s)

Detail Skills, Experience, Competencies Required For
Target Process Roles
• Identify the roles required for the target processes and the
associated skills, experience, education, training and
competencies needed to perform them
− Include hard and soft skills
• Use this information to design the target organisation
structure

Define Target Business Function Locations
• Define the business function location types required to
operate the new target processes

Create Business Process Flows For Existing Processes
• For each of the current key processes, create a process
flow description/map at enough detail to ensure it can be
understood
• Describe the existing process at sufficient level to allow
problems, issues and opportunities for improvement to be
identified
• Existing process analysis is more important for BPI than for
BPR exercises
• Create an inventory of key processes and the associated
issues and opportunities

Assess Performance Of And Value Delivered by
Existing Processes
• Analyse the performance of the existing processes and determine the value the
create
− More important for BPI than for BPR analyses
• Extend the business process flow analysis by adding performance and value
dimension
• Determine prospects for improvement and quantify scope of possible
improvements
• Provides a target list for enhancements
− Longest process and process step elapsed time
− Longest process and process step elapsed time relative to processing time
− Greatest number of handoffs
− Processes and process steps with largest number of steps
− Processes and process steps crossing organisation functional boundaries
− Processes and process steps with data quality issues
− Processes and process steps with errors and rework
− Processes and process steps that do not add value
− Processes and process steps experiencing delays in getting responses to requests, internal or
external
• Use the list of types of wastes to identify most wasteful processes and process
steps and thus the top opportunities for improvement

Define Core Business Processes
• Define the core set of business processes required to
achieve the desired results and outputs
• Assume no constraints in skills, resources, technology,
external interactions or location
− These can be added later
• Create an inventory of these core business processes

Define Target Future State Process Model
• Define the new/redesigned target processes and process steps in detail
• There can be many options when defining the new/changed processes
• Options can involve organisation change such as:
− Case management approach with assigned case workers
− Team-based processing
− Upskilling teams
− Elimination of cross-functional handoffs
− Automation and technology changes
− Personnel relocation
− Outsourcing
− Integration with external parties
• Other changes can include:
− Introduction of parallel processing
− Work prioritisation
− Compression of steps
− Collapsing of roles
− Eliminating unnecessary inspections
− Unnecessary steps added for historical reasons to address exceptions and complexity
• Focus is on adding value and reducing unnecessary cost

Enhance Target Future State Process Model With
Personnel, Systems And Locations
• Extend the definition of the new/redesigned target
processes and process steps with details on:
− The roles that perform them
− When the work is performed
− What technology is used or required to perform the work
• Create matrix of extended process classification
Role Role 1 Role 2 Role 3
Technology Technology 1 Technology 2 Technology 1 Technology 2 Technology 1 Technology 2
Location Loc 1 Loc 2 Loc 3 Loc 1 Loc 2 Loc 3 Loc 1 Loc 2 Loc 3 Loc 1 Loc 2 Loc 3 Loc 1 Loc 2 Loc 3 Loc 1 Loc 2 Loc 3
Process Step 1
Process Step 2
Process Step 3
Process Step 4
Process Step 5

Validate Target Future State Process Measurement
And Performance
• Define the projected performance characteristics of the
future process state
• Validate the process performance through simulations,
automated or paper-based

Assess The Implementability Of The Future State
Process Options
• There may be more than one set of future state process
options
• If so, each needs to be considered with respect to
characteristics such as:
− Time to implement
− Likely cost
− Resources required
− Probability of success and risk of failure
− Degree of organisation change and expected amount of
disruption caused
− Degree to which the improvement objectives will be achieved
• Use these factors to determine the most suitable option or
subset of options

Identify The Management Processes Required For
The Target Future State Process Model
• Identify the management processes required to
administer, manage and assess the performance of the
target future state processes
− Collect, analyse and take action on process performance
information
− Measure the satisfaction of the process beneficiary
− Assess process quality, rework and error rate
− Review process cost
• There will be general management processes across all
operational processes and specific management processes
for specific operational processes

Implementation And Support Processes
• Specify at a high-level the processes to:
− Implement the target process model
− Support the operation and use of the target process model

3.2 Create Conceptual Entity Model
• Create an inventory of entities involved the operation of the
business function and the delivery of products and services
• Entities are objects about which data is stored and processed
• Entities are people, functions, events, products and can include
− Business roles and organisation functions involved in the work
− External parties contributing to the products and services
− Products and services
− Beneficiaries of the work done by the business function
− Offices and locations
• The conceptual entity model is an Entity Relationship Diagram
• This results in a picture of data flows and interactions within
the business function within the scope of the business

Sample Conceptual Entity Model
Customer
Order
Product
Service
Catalogue
Item
Storage
Location
Delivery
Transport
Order
History
Order Status
Returned
Order
External
Supplier
Cancelled
Order
Partner/
Reseller
Bulk Order
Installation
Customer
Agent
Installation
History Service
History

Sample For Energy Utility

Create Conceptual Entity Model
• Identify the types and groups of entities and the individual
entities of each type
• Describe each entity briefly and identify its main
characteristic
• Define the interactions and relationships between the
entities
• Define the direction and number of interactions and
relationships
• Quantify the volumes of interactions
• Identify the major business rules associated with the
interactions and relationships

3.3 Gather Capacity Planning Information
• Capacity planning covers all aspects of business volumetric
information
− Technology
− Personnel
− Location
− Physical product production capacity
− Physical product storage capacity
− Physical product transportation capacity
• Capacity and resource usage information will affect overall system(s)
performance and the choice of technology and ultimately the
solution options from the business architecture engagement
• It is important that capacity planning information is accurate and
that the underlying assumptions are understood and documented
• The business may not understand technical aspects of capacity
planning and so must be guided to an understanding and must
approve the estimates produced

Objective Of Technology Capacity Planning
• The objective is to determine the current and future
resource requirements:
− Processing capacity
− Storage capacity
− I/O data read/write capacity
− RAM capacity
− Network capacity
• There are many aspects of technology usage and
configuration that contribute to resource requirements

High-Level Technology Resource Model
Business
Users
Generate
Work
External
Users
RAM
Processing
Capacity
Data Must
Be Stored
Data Must Be Read
and Written
That
Consumes
Resources
External
Network
Capacity
Internal
Network
Capacity
Affects
Numbers
of

Gather Capacity Planning Information
• Capacity planning metrics depend on the type of work
being performed
− Number of transactions or events of each type
− Number of data entities of each type
− Average and peak numbers
− Past and expected future growth rates
− Resource types to perform work types
• Understand the technology resource requirements of
transactions and entity data

Operation Aspect Of Capacity Planning
• Operation requirements will affect capacity requirements:
− Availability
− Response times
− Service levels
− Acceptable failure rate
− Recovery time
• High operational requirements – highly available systems with very good
and consistent response times – will affect resource requirements and cost
• Understand the resource requirement impact of operational requirements
• Different elements of the overall operation of the business function will
have different operational requirements:
− Externally facing applications may need to be more highly available than internal
systems
• The business may not understand technical aspects of operational
requirements and so must be guided to an understanding and must
approve the estimates produced

Organisation Capacity Planning
• The business function will operate across different
locations and location types:
− Call centre
− Service centre
− Back office processing
− Physical product storage and delivery
• Each of these will also have different resource
requirements and operational characteristics

Resource Entity Model
• Create a resource entity model to understand the
structure and volumes of resource consuming entities
Customer
Order
Order Data
Order
Processing
Data
Order
Processing
Personnel
Customer
Data
Products
Product
Storage
Locations
Product
Delivery
Resources

Capacity Planning Model
• Create a structure capacity planning model that
• Captures inputs in terms of resource types and volumes
• Defines the rules used to translate inputs into system resources
• Explicitly define assumptions in terms of:
− Growth in volumes of resource utilisation
− Operational requirements and their resource implications
Resource
Consuming
Entities
Resource Model
Resource
Consuming
Entity Volumes Assumptions Rules
Resource
Capacity Plan

Validate And Signoff Capacity Planning
• Review and agree capacity plan with business

3.4 Define Solution And System Approach
• Consider and decide on whether to initiate a software
product evaluation and determination exercise at this
stage
• You may want to determine solution characteristics in
more detail before seeking to identify possible suitable
products
• Or there may be an overriding requirement to identify
likely solutions to meet urgent requirements now
• Agree the approach to solution selection
• Decide on whether to perform a parallel product and
solution selection exercise

The Complete Solution Is Always Much More Than
Just …
• … Just a bunch of software
• Complete solution is the entire set of components needed to
operate the associated business processes
• Successful solution requires the interoperation of all these
components and that the components are properly designed
and implemented
• Overall solution usage experience is the sum of the experience
of the usage of the components
• Solution architect must be aware of the usability of designed
solutions
• Usability is not an afterthought: it must be embedded in the
overall solution design from the start

Scope Of Complete Solution
Changes to Existing
Systems
New Custom
Developed
Applications Information Storage
Facilities
System
Integrations/Data
Transfers/Exchanges
Changes to Existing
Business Processes
Organisational
Changes
Existing Data
Conversions/
Migrations
New Data Loads
Training and
Documentation
Central, Distributed
and Communications
Infrastructure
Sets of Installation
and Implementation
Services
Cutover/Transfer to
Production
Operational
Functions and
Processes
Parallel Runs
New Business
Processes
Reporting and
Analysis Facilities
Sets of Maintenance,
Service Management
and Support Services
Application Hosting
and Management
Services
Acquired and
Customised Software
Products

Any Complete Solution Consists of:
• Zero or more of {Changes to Existing Systems}
• + Zero or more of {New Custom Developed Applications}
• + Zero or more of {Information Storage Facilities}
• + Zero or more of {Acquired and Customised Software Products}
• + Zero or more of {System Integrations/Data Transfers/Exchanges}
• + Zero or more of {Changes to Existing Business Processes}
• + Zero or more of {New Business Processes}
• + Zero or more of {Organisational Changes}
• + Zero or more of {Reporting and Analysis Facilities}
• + Zero or more of {Existing Data Conversions/Migrations}
• + Zero or more of {New Data Loads}
• + Zero or more of {Training and Documentation}
• + Zero or more of {Central, Distributed and Communications Infrastructure}
• + Zero or more of {Sets of Installation and Implementation Services}
• + Zero or more of {Cutover/Transfer to Production}
• + Zero or more of {Operational Functions and Processes}
• + Zero or more of {Parallel Runs}
• + Zero or more of {Sets of Maintenance, Service Management and Support Services}
• + Zero or more of {Application Hosting and Management Services}

Outsource
Operations
Consider Develop and Acquisition Options
• Spectrum of (not mutually exclusive) options available
• Separate options can be considered for different
components of the overall business function solution
Change
Existing
Processes
Develop
Customised
Solution(s)
Acquire
Software
Product(s) or
Services
Change
Processes
and Update
Existing
Systems

Two Dimensions Of Options
Product 1
Development
Option 1
Outsourcing
Option 1
Product 2
Development
Option 2
Outsourcing
Option 2
Product 3
Change
Existing
Processes
Change
Processes and
Update
Existing
Systems
Acquire
Software
Product(s) or
Services
Develop
Customised
Solution
Outsource
Operations

There Are Many Theoretical Options
• One of the objectives of the business architecture
engagement is to reduce the set of options to a small
number that are:
− Practical
− Realistic
− Achievable
− Affordable
− Usable
− Compliant with organisation strategy and principles
− Compliant with organisation’s enterprise architecture
− Compliant with organisation’s appetite for risk

Financial Analysis And Cost Estimation
• The buy rather than build option affects financial estimates
• Remember that the product acquisition cost is just one
(small) component of the overall solution acquisition and
implementation cost
• Sources for cost estimates for buy include:
− Issuing formal or informal RFP/RFS (request for proposal/request
for solution)
− Previous experiences, either within the organisation or elsewhere
− Vendor contacts
• Use indicative estimates if available
− Do not spend too much time getting detailed costs at this stage

Reference Class Forecasting
• Technique to improve accuracy in plans and projections by basing
them on actual performance in a reference class of comparable
actions
• Based on knowledge about actual performance
− Analyse distributions and probability of cost overruns
− Compare the proposed project with the reference class distribution to
establish the most likely outcome
• Accurate cost analysis and estimation is very important as it affects
decision-making
• Need to avoid problems with inaccurate cost forecasting
− Strategic Misrepresentation – Deliberate misrepresentation in budgeting
caused by distorted incentives
− Planning Fallacy – Systematic tendency to underestimate how long it will take
to complete a task even when there is past experience of similar tasks over-
running
− Optimism Bias – Systematic tendency to be overly optimistic about the
outcome of actions

Key Solution Approach Factors To Consider
• The key sets of factors in any decision are:
− Overall lifetime cost
− Risks associated with solution option
− Time to implement
− Compliance with organisation’s business strategy, IT strategy and
enterprise architecture
• Create evaluation model that can be reviewed and
updated during the engagement
• Accurate information may not be available at this stage
• Document the gaps and repeat the analysis when more
certain information is available

Cost Estimating Process
Step 1:
Define the
Purpose of
the Estimate
Step 2:
Develop the
Estimating
Plan
Step 3:
Define the
Project
Step 4:
Determine
the
Estimating
Approach
Step 5:
Identify
Ground Rules
and
Assumptions
Step 6:
Obtain Data
Step 7:
Develop
Point
Estimate
Step 8:
Conduct
Sensitivity
Analysis
Step 9:
Conduct Risk
and
Uncertainty
Analysis
Step 10:
Document
the Estimate
Step 11:
Present
Estimate for
Approval
Step 12:
Update
Estimate to
Reflect
Actual Costs
and Changes
Initiation and Research
The audience, what is
being estimated and why
It is being estimated are
very importance
Assessment
Cost assessment steps
are iterative and can be
accomplished in varying
order or concurrently
Analysis
The confidence in the
point or range of the
estimate is crucial to the
decision maker
Presentation
Documentation and
presentation can make or
break a cost estimating
decision outcome

Characteristics of Credible Cost Estimates
• Clear identification of requirements of the ultimate deliverable
• Broad participation in preparing estimates
• Availability of valid data for performing estimates – historical,
experience, benchmarks
• Standardised and comprehensive estimate structure that includes all
possible sources of cost
• Provision for uncertainties – include known costs explicitly and allow
for unknown costs
• Recognition of inflation
• Recognition of excluded costs
• Independent review of estimates for completeness and realism
• Revision of estimates for significant changes in requirements

Challenges of Developing Good Cost Estimates
• Requires detailed, stable, agreed requirements
• Agreed assumptions
• Access to detailed documentation and historical data for
comparison
• Trained and experienced analysts
• Risk and uncertainty analysis
• Identification of a range of confidence levels
• Adequate contingency and management reserves

Reasons for Good And Bad Cost Estimates
• Lost of reasons for and causes of inaccurate cost estimates

Sources of Risk and Uncertainty in Estimating Costs
• Lack of understanding of the project requirements
• Shortcomings of human language and differing
interpretations of meaning of project
• Behaviour of parties involved in the cost estimation
process
• Haste
• Deception
• Poor cost estimating and pricing practices

Specific Risks
• Sizing and Technology
− Overly optimistic developers
− Poor assumptions on the use of reused
code
− Vague or incomplete requirements
− Not planning for additional effort
associated with packages –
integration, testing
• Complexity
− Tools
− Applications: software purpose and
reliability
− Hardware limitations
− Number of modules affecting
integration effort
• Capability
− Mixed skills of team
− Optimistic assumption on
development tools
− Optimistic assumption on productivity
− Geographically dispersed team making
communication and coordination more
difficult
• Management
− Management’s dictating an unrealistic
schedule
− Incorporating a new method,
language, tool or process for the first
time
− Not handling creeping requirements
and change proactively
− Inadequate quality control, causing
delays in fixing unexpected defects
− Unanticipated risks associated with
package software upgrades and lack of
support

Importance of System Requirements and Solution
Lifecycle Costs
• System requirements drive costs, both implementation and operation
• A factor present in every successful project and absent in every unsuccessful project is sufficient
attention to requirements
• Half of all bugs can be traced to requirement errors
• Fixing these errors consumes 75% of project rework costs
• 25%- 40% percent of all spending on projects is wasted as a result of re-work
• 66% of software projects do not finish on time or on budget
• 56% of project defects originate in the requirements phase of the project
• Completed projects have only 52% of proposed functionality
• 75-80% of IT project failures are the result of requirements problems
• The average project exceeds its planned schedule by 120%
• 53% of projects will cost 189% of their original estimate
• 30% of projects are cancelled before completion
• 50% of projects are rolled back out of production
• The typical project expends least effort on analysis where most errors originate and whose errors
cost most to fix
• Requirements errors cost the most and that poor requirements are the main cause of project
failure

Requirements Drive Project Costs
• While minimal
costs have
actually been
spent at the
requirements
phase of the
entire project
process,
approximately
80% or more of
total life cycle
costs have
already been
determined at
this stage
• Need to get
requirements
right from the
outset to control
costs effectively
Development and
Implementation Starts
Design Finalised
Requirements Defined
and Agreed
0.0%
10.0%
20.0%
30.0%
40.0%
50.0%
60.0%
70.0%
80.0%
90.0%
100.0%
Project Timescale
CostsCommittedandSpent
Actual Money Spent Costs Determined by Decisions on Requirements and Design

Lessons Learned From Large Systems
Implementation
80 %
65 %
60 %
50 %
45 %
35 %
35 %
30 %
20 %
More attention on process optimisation
Align systematically to company goals
Pay more attention to understanding the subject area spanned
Outsource project management of the project to a third party
Increase investment in training
Greater employees involvement
Enforce changes more courageously
Identify and capture proof of benefits and saving as part of scope
Avoid big-bang implementations
55 % Implementation of a management information system as part of scope

Types of Cost Estimates
• Life Cycle Cost Estimate (LCCE) - includes independent cost
estimates, independent cost assessments and total ownership costs
− Encompasses all past (or sunk), present and future costs for every aspect of the
program, regardless of funding source
• Business Case Analysis (BCA) - includes an analysis of alternatives
and/or economic analyses
− Cost benefit or comparative analysis that presents facts and supporting details
among competing alternatives
− Includes life-cycle costs from LCCE and also quantifiable and unquantifiable
benefits
• Rough Order of Magnitude (ROM ) - developed when a quick
estimate is needed and few details are available
− Usually based on historical ratio information
− Typically developed to support what-if analyses
− Helpful for examining differences in high-level alternative see which are the
most feasible
− A rough order of analysis should never be considered a budget-quality cost
estimate

Life Cycle Cost Estimate (LCCE) Composition
•Hardware
•Software
•Development and
Implementation
•Management
•Installation
•Transition and
Cutover
•Conversion
BASIC SYSTEM COST •Training
•Documentation
•Support Facilities
•Parallel Running
•Warranty
TOTAL SYSTEM COST •External Support and
Maintenance
•Subscription
PROCUREMENT COST
•Planning, Research,
Analysis and Design
•Ongoing Test
Facilities
SYSTEM ACQUISITION
COST •Operations
•Internal Support
•Disposal
LIFE CYCLE COST

LCCE Cost Composition
• Depending on the life of the solution being implemented,
the operating costs can be 1-3 times the cost of acquisition
System Acquisition Cost
COST
YEARS
Operating and Support Cost
Total Cost of Ownership

IT Investment Management and Project and
Solution Lifecycle
Business Analysis
Solution
Operation
Solution
Architecture and
Design
Project Portfolio
Management
Structured Capture
and Management of
Requirements and
Cost Benefit Analysis
of Solution Costs
Design/Selection of
Cost Effective
Solutions to Meet
Requirements
Including
Evaluation of All
Options
Prioritisation of
Projects and
Investment
Decisions
Cost Effective
Delivery of
Projects and
Management of
Costs
Programme and
Project
Management
Cost Effective
Operation of
Delivered Solution
and Effective
Retirement/
Replacement/
Upgrade Decisions

Costs Across All Change Areas
• Examine likely costs
across the changes
areas
− Location and Offices
− Business Processes
− Technology,
Infrastructure and
Communications
− Applications and
Systems
− Information and Data
− Organisation and
Structure
• Use this as a checklist
to verify all costs are
included
Business
Architecture
Location and
Offices
Business
Processes
Technology,
Infrastructure
and
Communications
Applications and
Systems
Information and
Data
Organisation and
Structure

Solution Option Risks
• Product or hosted or outsourced service risks and costs
will generally be lower than a development option
− Product vendors tend to be specialists with more experience
− Product is readily available
− Product is already in use by other customers and proven (or
should be)
− Vendor is responsible for product support
− Product is enhanced ad maintained by the vendor and new
functionality is typically provided as part of maintenance and
support agreement

Levels Of Product Changes And Enhancements
• Product can be changed to suit the
exact requirements of the
organisation
− Standard – functionality included as
standard or that can be configured by
business users
− Configuration – features and functions
that can be added using configuration
tools
− Customisation – features and
functions not provided by the vendor
− Code Change, Developed Modules –
code changes to the product
• More complex changes involve
reimplementation and testing after
the product has been upgraded
• More complex changes involve cost
and risk throughout the life of the
solution
Code Change,
Developed
Modules
Customisation
Configuration
Standard

Product Functional Risks
• These are risks associated with the functionality provided (or
supposed to be provided) by the product and the vendor
− Business requirements are not clearly and subject to change
− Vendor does not understand the requirements of the business
− Business does not understand the functionality of the product
− Business cannot define the changes required
− Vendor misrepresents the functionality of the product
− Product is not accepted by business users
− Product requires too much customisation to meet the business
requirements
− Product may be too complex to change to suit the needs of the business
− Product cannot interface with external systems
− Legacy data cannot be migrated to the product
− Product is not easily usable

Product Technical And Technology Risks
• These are risks associated with the underlying technology
of the product
− The underlying technology is too old
− The underlying technology is too new
− The product or the technology may not meet the required
performance or operations requirements

Vendor Risks
• These are risks associated with vendor and their ability to
supply and support the product
− The product is new to the vendor
− The vendor’s direction with respect to the development of the
product is undefined or uncertain
− The vendor’s ability to support and develop the product are
unclear
− The technical quality of the product is poor
− The vendor may not have sufficient implementation skills
− The quality of the vendor’s training and documentation is poor
− The vendor’s contract may impose onerous or unsatisfactory
conditions

3.5 Develop And Validate Feasibility Prototype(s)
• Developing a prototype may useful in demonstrating and
presenting options or concepts
• They can be use to validate approaches or illustrate the
potential solution to the business
• Prototypes are not intended to be complete solutions
• They are intended to be throwaway developments

4. Document Solutions, Applications And Functions

4.1 Document Solutions, Applications And Functions
• The objective of this activity is to define the set of
solutions and applications that comprise the overall
solution required as part of the target business
architecture
• It may not be possible at this stage to identify the precise
set of applications and their boundaries
• The purpose of the applications is to operate the required
business processes and support business activities
• Applications can perform multiple functions or a single
function
• The set of applications can include existing legacy
applications that will be retained

Document Solutions, Applications And Functions
• The possible set of steps in this activity are:
− Analyse industry-specific applications
− Analyse existing application landscape
− Determine application integration, linkages and interfaces
− Determine business processing applications
− Determine data access approach and applications
− Determine management approach and applications
− Validate applications and previously-defined processes

Analyse Industry-Specific Applications And
Standards
• There may be standard products available for the industry in
which the organisation operates that are relevant to the
requirements of the business function within the scope of the
business architecture engagement
• Review such products and applications
• Review industry-specific standards to determine applicability to
the organisation’s requirements
• Analyse and classify the suitability of products and the
applicability of the standards
− Definitely suitable
− Potentially suitable
− Definitely unsuitable
• Create an inventory of standard products and industry-specific
standards and their classification

Analyse Existing Application Landscape
• Review the entire existing suite of applications in use to determine
which should be retained and which are candidates for replacement
− Include customisations (Excel macros)
− Include reporting and analytics tools
• Classify the type of application
− User productivity
− Reporting and analysis
− Package
− Custom developed
− Information sharing
− Transaction processing
• Analyse and classify the suitability of these existing applications
− Definitely retain
− Potentially retain
− Definitely replace
• Create an inventory of such applications and their classification

Determine Application Integration, Linkages And
Interfaces
• Identify the external applications that interface with the
previously identified existing suite of applications and the
interfaces between the existing applications
• Describe the nature of the interface: frequency, direction,
protocol, security, volume, method of interface and
exchange
• Describe the data that is exchanged in sufficient detail so
the effort to implement with new systems can be
accurately estimated

Determine Application Integration, Linkages And
Interfaces
• Create inventory of integrations, interfaces and exchanges
Interfacing
System
Interfaced Systems
Interfacing
System
Transfer
Mechanism
Protocol Direction Data FormatData
Content
Encryption Batch/
Realtime
Source Target Frequency
File transfer HTTP In CSV Yes Hourly
Mail HTTPS Out XML No Daily
Web service FTP BidirectionalJSON Weekly
Messaging FTPS XBRL On demand
Manual
transfer
SFTP XLSX
Replication TLS Proprietary
Proprietary SSH
API

Analyse Business Processing Applications
• Business applications are those that process business
transactions
• These are central to the successful operation of the
business function and need to be analysed in more detail
• For each application, list the key transactions
• List the data entities created or updated by these
transactions
• List the business processes that use the transactions within
the applications

Analyse Business Processing Applications
• Describe the architecture of the business transaction
processing systems
− Modular, componentised applications that are loosely integrated
− Monolithic applications with tightly coupled components
• Architecture determines the usefulness of the applications
in the future state model
• Monolithic applications do not lend themselves to some
future-state models:
− Some functions being outsourced
− Separate applications for some sets of functions
− New customer interface models

Determine Data Access Approach And Applications
• Analyse approaches and applications used to provide
access to data
• List data sources
• List data access, extraction and staging approaches

Determine Management Approach And Applications
• List the service management and administration processes
and applications that support the operation and use of the
business systems

Validate Applications And Previously-Defined
Processes
• Consolidate and validate the previously collected and analysed
information
− Inventory of industry-specific standards and the applicability
− Application landscape inventory and their potential future suitability
− Inventory of application integrations, interfaces and exchanges
− Transaction processing applications and their transaction types
− Inventory of data entities created or updated by these transactions
− Inventory of business processes that use the transactions within the
applications
− Description of the architecture of the business transaction processing
systems
− Inventory of approaches and applications used to provide access to data
− Inventory of service management and administration processes and
applications

5. Define Organisation, Application, Infrastructure
And Data

5.1 Define Organisation And Resource Requirements
And Structure
• Create a high-level future state organisation structure
options with details on the roles, staffing levels and
locations
• Define the high-level structures for allocation and
performing work and making decisions
• Define the work groups structure and their interactions
• Define the management, administration and escalation
processes
• Create a target organisation chart
• Define the differences between the current and future
state organisation structures

Define Future State Staffing Structures
• Map existing roles and structures to the proposed new
staffing structure
• Create a high-level plan to transition from the existing to
the proposed new staffing structure
• Staff transitions and organisation changes can be
problematic – such change can be resisted or its
achievement ineffective
• Prepare for and address such resistance to change or
reasons why change is not achieved to reduce potential
problems

Review Possible Resistance To Staffing Structures
And Organisation Change
• Resistance to change or reasons why change fails can be
explicit or concealed
• Explicit resistance or reasons can take forms such as
− Insufficient numbers of appropriate staff to handle workload
− Lack of personnel skill, experience, knowledge
− Lack of effective communication
− Inadequate organisation structures
− Ineffective management structures

Hidden Resistance Factors To Change
• There are many causes and ways in which organisations
and personnel demonstrate resistance to change
− Fear of job losses
− Fear of loss of status or authority after change
− Bypassing or circumventing new technologies
− Passive aggressive behaviours
− Passive sabotage
− Focussing on existing ways of working and the past rather than
the future
− Questioning the need for and the basis of the proposed changes
− Lack of co-operation
− Insistence in involving HR function in organisation change

Handling Resistance To Organisation Change
• Remove obvious obstacles
• Allocate sufficient resources
• Communication
• Design organisation interventions to address concerns that
give rise to resistance to change

5.2 Define Application And Data Organisation
• Logical application and data distribution and organisation
needs to take place before any physical and technical
design can take place
• Decide on the optimum location, organisation and
distribution of business processing applications and data
elements based on factors such as:
− Work types and volumes
− Agreed service levels for work types
− Business processes used to perform work
− Number of work locations
− Information technology architecture design principles
• This ensures there is rational basis for options,
recommendations and decisions

Define Application And Data Organisation
• Suggested set of activities:
− Map processing points and connections
− Map application and data usage to processing points
− Analyse service level for applications and data
− Describe options for application and data organisation
− Review options to minimise risks
− Create final application and data organisation options and
recommendations

Map Processing Points And Connections
• Identify the options for the location of work processing and the
connections between them
− Locations can include:
• Sales
• Service
• Support
• Warehouse
• Delivery
• Outsourced partners
− Not all organisations will have all location types
• Define the processes, activities within processes and the associated
data performed at each location
• Identify the allocation of work and the movement of work between
them
• Identify the work processing roles in each location
• Objective here is to identify logical and function distribution before
defining physical technology design

Map Application And Data Usage To Processing
Points
• Define the systems and applications and the associated
data required for the previously defined processing points
• Describe how data is used for processing

Analyse Service Level For Applications And Data
• Describe the usage factors that will determine the service
level requirements of the applications and data
− Security, privacy, confidentiality
− Frequency of use
− Volume of activity – read, update
• Define service requirements of applications
− Availability
− Recoverability
− Performance, response time and throughput

Describe Options For Application And Data
Organisation
• Define options and recommendations for the locations of
applications and data based on processing factor and service
requirements
• Use previously gathered information on application options to
map specific product and solution options to application and
data requirements
• Priorities are:
− Business processes
− Data
− Important work types and functionality
− Reduction of risk
• Consider operational systems, administration and management
and reporting/analysis/decision-support systems

Review Options To Minimise Risks
• Analyse previously gathered
information and options and consider
other non-technical and business
option
• Consider overall IT architecture
principles and standards and
organisation IT strategy
• Evaluate risks
• Avoid data redundancy
• Consider operational/non-functional
requirements and constraints
• Usable
• Affordable
• Deliverable
• Operable
• Supportable
• Maintainable
• Flexible
• Adaptable
• Capable
• Scalable
• Reliable
• Securable
• Available
• Auditable
• Recoverable
• Stable
• Testable
• Accessible

Create Final Application And Data Organisation
Options And Recommendations
• Create formal application and data model(s) that
consolidates previous information showing
− Locations
− Applications
− Processing
− Data

5.3 Define Technology Requirements
• Technology includes equipment, communications infrastructure and
supporting systems needed to allow the implementation, operation
and use of the applications that allow the business processes to
function
• Requirements need to be formally identified and validated to form
an input to the technology design activity
• Requirements define the features, functions and capabilities to be
provided
− They do not specify how they are to be provided – this comes later
• Technology requirements should be defined in the following
categories:
− Reuse of and extension of existing technology
− Financial and affordability constraints and limitations
− Enterprise architecture and IT strategy constraints, limitations and principles
− Operational business process requirements – functional and data

Define Technology Requirements
• Defining the requirements gathering and management process is
outside the scope of this material
• Requirements gathering is an iterative activity
• Requirements are impacted by characteristics such as locations and
connectivity, functionality, work teams
• Technology will be required at various levels:
− Individual users
− Work groups
− Office locations
− Centralised application functionality facilities, hosted internally or externally
− Centralised data facilities
− Decision support, reporting, analysis
− Communications and network access and connectivity
− Security
− Support, service, monitoring, management, administration
− Integration

Define Technology Requirements Activities
• Review the previously created inventory of business
processes and their constituent activities and the roles
that perform them at each location
• Identify the technology functionality needed to allow the
process activities to be performed
• Consider the operational dimension and its impact on
technology requirements:
− Performance/throughput/workload – capacity planning and
management across static and dynamic elements of the solution
− Availability
− Security
− Reliability

Technology Requirements Verification
• Verify that the technology requirements can address:
− Realtime transaction processing
− Batch processes and processing
− Data storage, access, movement
− Interfaces and data exchanges of all types
• Internal
− Existing interfaces
− Proposed new interfaces
• External
− Existing interfaces
− Proposed new interfaces
• Identify any inconsistencies
− Address these through revision of requirements

6. Conduct Solution And Product Evaluation And
Selection

Decide On Product Evaluation And Selection
• This is an optional step
• Decide on whether to conduct a product evaluation and
selection exercise as part of the overall business architecture
engagement
• Decide on the acquisition of a product rather than the
development of a customised solution, either by the
organisation’s IT development function or outsourced to a
development entity
• Determine the rigour and structure of the approach to
identifying suitable products:
− Formal tender
− Request for solution
− Direct contact with suitable vendors
• It is always best to have some form of structured and formal
approach to ensure the most suitable product(s) are identified

Approaches To Product Evaluation And Selection
Product
Focussed
Process
Focussed
Technology
Focussed

Approaches To Product Evaluation And Selection
• Three approaches to product evaluation and selection
− Product Focussed
• Focus of identifying functional product and change the business function
processes to those contained in the product
− Process Focussed
• Focus on the required business processes and identify those products that
can allow them to be implemented
− Technology Focussed
• Focus on technology and infrastructure requirements and constraints and
identify products that can meet them
• Approaches can be mixed

Product Evaluation And Selection - Product Focussed
Approach – Characteristics And Prerequisites
• Ideally looking for a single solution rather than a collection of products
• The organisation has decided that a product is the best solution to its
needs
• The organisation is willing to adapt its processes to those of a product
• The organisation accepts the technology, deployment and operational
model of the selected product
• The organisation will allow the product define the technology and data
architectures, development and release management approaches
• Resources will be made available to work on the product evaluation and
selection
• The finance required for a product acquisition is understood and
recognised
• The organisation will accept entering into a partnership with the product
vendor

Product Evaluation And Selection - Process Focussed
• The organisation understands that it wants to implement
a solution that enables its business processes
• The organisation understands that this approach will limit
the solution options
• This approach may mean longer
development/customisation and implementation effort,
cost and schedule
• The required business processes are understood and have
been defined
• The transaction volumes associated with the business
processes have been defined

Product Evaluation And Selection - Technology Focussed
• The organisation has or is defining a new technical
architecture and wants all products to comply with these
standards
• The organisation understands that this approach will limit
the solution options

Product Evaluation And Selection Process
• The objectives of the evaluation and selection process are:
− To select the most appropriate product/solution to meet requirements
− To create an evaluation audit trail and set of supporting documentation
that will support the evaluation process and final decision
• The output from the process will be a Vendor and Solution
Evaluation and Selection (VSES) report
• Any evaluation process is liable to subjectivity in areas such as:
− The selection of the evaluation factors and the relative weights assigned
− The scores assigned to each product and vendor
• The purposes of a formal evaluation process are:
− To eliminate subjectivity as much as possible from the evaluation
process
− To provide transparency in the evaluation process
− To ensure that all product and solution options are evaluated in the
same way

Product Evaluation And Selection Process – Core
Elements
Evaluation Team
• Individuals with
appropriate skills to be
able to evaluate
responses received
from vendors
Evaluation Process
• Set of steps to be
followed by the
evaluation team to
conduct an evaluation
of the options
Evaluation Factors
• Set of factors by which
the options will be
assessed
Evaluation Score
• Objective assessment
of the merits of a
solution option based
on the application of
the evaluation criteria
Evaluation Report
• Document describing
the evaluation process
and its results

Inputs To The Product Evaluation And Selection
Process
• The information that comprises the input to the evaluation
and selection process can be formal and structured tender
responses or less formal vendor and analyst-supplied
information

Output From The Product Evaluation And Selection
Process
• A formal structured report provides an audit trail for the
conclusions and recommendations
− Part A – Overview
• 1. Executive Summary
− Part B – Short List Selection
• 2. List of Vendors Contacted
• 3. Product Decision Model
• 4. Vendor Supplied Information Summary
• 5. Summary of Conclusions and Recommendation
− Part C – Finalist Selection
• 6. Reference Checks and Site Visits
• 7. Functional Demonstration Findings
• 8. Technical Review Findings
• 9. Solution Demonstration Planning Lab Findings
• 10. Summary of Finalist Recommendation
− Part D – Optional Appendices Containing Supporting Material

Product Evaluation And Selection Process – High
Level Steps
Confirm the Scope and Approach
of the Product Evaluation and
Selection Process
Establish and Train the Evaluation
and Selection Team
Compile and Agree
Functional Evaluation
Factors
Compile and Agree
Technical Evaluation
Factors
Compile and Agree
General and Business
Evaluation Factors
Define and Agree
Scoring Approach
Evaluate Vendor Supplied
Information
Develop
Evaluation Script
Cases
Select Initial Vendor and Product
Shortlist
Check Vendor References
Conduct Functional
and Operational
Review Meetings
Perform Technical
Review
Contact/Visit
Reference Sites
Perform Financial
Analysis
Repeat for Each Shortlisted Vendor
Score Vendors and Products
Select Most Suitable Solution
Complete ad Document
Evaluation and Selection
Start the Product Evaluation and
Selection Process

Level Steps 1
Step Details
Start the Product
Process
The amount of effort involved in starting the Vendor and Solution Evaluation and Selection
(VSES) activity depends on:
• How recently you made any VSES scope and direction decisions
• Whether the team has already been selected
• How familiar each team member is with the functional area within which the application is
to be deployed, and the systems currently in use
• How experienced the team is with vendor and solution evaluation and selection
Confirm the Scope and
Approach of the Product
Process
Review previous decisions made about the scope of the project. Discuss any scope changes and
adjust the work plan to reflect approved changes.
Consider the urgency of the need and determine how it impacts the selection strategy.
Determine the timing and general strategy for contract negotiation.
Determine what parties to involve in defining procurement procedures, handling legal
questions, and negotiating the contract so that the right people can be involved at appropriate
points.

Level Steps 2
Step Details
Establish and Train the
Team
Assemble and organise a solution evaluation and selection team:
• Include technical personnel who understand the systems management and support
processes that are being implemented
• Include business personnel who understand the operational objectives, business processes
and needs of Executive stakeholders and sponsors of the project.
• Include subject matter experts in Best Business practice in Business Performance reporting
as needed.
• Include experts who understand the market context within which the vendors operate so as
to ensure an understanding of:
• The capability and capacity of service providers on the local market where resources
will be required
• The extent to which the vendors solutions will need to be customised to meet the
requirements identified
• The market for services based activities (consulting/training/application development
etc)
• Provide for a workshop facilitator with a solid background in the subject area if you plan to
use facilitated workshops as part of the evaluation and selection process.
• Keep the core group small but representative of the functional areas the product most
affects.
• Include as support members anyone involved in defining procurement procedures, handling
legal questions, and negotiating the contract.
• Include management personnel responsible for approving the selection

Level Steps 3
Step Details
Establish and Train the
Team (Continued)
Once you have established the evaluation and selection team, designate team members to be
the primary and secondary vendor contacts. The secondary vendor contact works with the
vendor when the primary contact is unavailable, such as during vacation or illness. These
individuals represent the interests of the client and the systems integrator, answer questions
about the solution evaluation and selection process, strategise with the vendor, arrange vendor
contact with other members of the team, and are empowered to make informal commitments.
Next, designate a team administrator to administer the vendor scheduling, mail all vendor
requests, record all vendor contact, obtain and distribute vendor materials, and maintain a filing
system for vendor materials.
Walk through the evaluation and selection activities with team members to familiarise them
with the general process. If the team is relatively inexperienced with solution evaluation and
selection, consider using a team-building exercise to preview the process. Scale down and
simulate evaluation and selection activities. Save detailed discussions for just-in-time training
sessions.
Discuss the objectives and principles of the evaluation and selection process with the team to
ensure that everyone has a consistent understanding.

Level Steps 4
Step Details
Compile and Agree
Functional Evaluation
Factors
Compiling criteria when selecting a solution involves:
• Developing or gathering criteria appropriate to the evaluation method
• Avoiding excess precision
• Keeping the focus on business priorities
• Designing a score sheet that facilitates getting and analysing vendor responses
• Incorporating the criteria into the score sheet
These criteria will be taken from the request information sent to the vendors.
In this step, define the functional criteria - the requirements as seen from the business user’s
point of view. These requirements represent the business processes the solution needs to
accommodate.
Design functional criteria and group them as follows:
• Business processes
• Data
• External system interfaces
• Business performance measurement
Collate the functional criteria into a single document

Level Steps 5
Step Details
Compile and Agree
Technical Evaluation
Factors
Define technical criteria to represent the solution design and technical infrastructure aspects of
the solution. The technical requirements concern the solutions operation and infrastructure.
To enhance readability and minimise oversights, develop categories of technical criteria in the
areas of:
• Systems management and support process
• Operational interface
• Technical infrastructure
• Volume and technical performance.
Assemble the technical criteria into a single document.
These criteria will be taken from the request information sent to the vendors.

Level Steps 6
Step Details
Compile and Agree General
and Business Evaluation
Factors
The buyer of a solution is buying more than a service. In most cases he or she is also developing
a long-term relationship with the vendor, expecting some, if not all, of the following:
• Initial transition, configuration and implementation services
• Custom services
• Consulting services
• Future changes
• Customer support services, such as a support line, web portal and a user group
General factors include vendor and miscellaneous factors. These are factors that influence the
solution purchase decision but are not functional or technical in nature. General factors require
that you answer them through an iterative process, which requires different tactics.
Concentrate on factors that would eliminate vendors from the short list. Consult with legal and
purchasing personnel to extract general criteria that can quickly narrow the solution selection.
Add criteria to ensure the team understands the vendor’s decision-making and delivery
processes, schedules, and organisation before making a final solution selection and developing
an implementation plan.
With functional and technical factors, you are usually looking for a specific response. With
general factors questions, you are looking for potential risks and information needed for
deployment. Collect responses to these factors by asking the vendor directly, by asking
references who use the software, and by doing your own research.

Level Steps 7
Step Details
Define and Agree Scoring
Approach
To narrow solutions options to a reasonable number, design an overall product selection
framework to communicate and summarise findings. Use weightings to reflect the relative
importance of criteria. Use scoring to indicate how well the vendor’s solution meets the
requirements.
Weighting and scoring are often represented numerically, giving the appearance of objectivity.
Keep in mind that these numbers are really just a quick means to communicate subjective
judgments. When making the package decision, check that the bottom-line numbers are
consistent with your overall judgment.
Evaluate Vendor Supplied
Information
The objective of this activity is to obtain and evaluate the information provided by product
vendors that explain how their products meet the specific requirements and at what estimated
cost. The request for information sent to vendors should look for a formal and structured
response. Vendors are compared uniformly as to how well they meet the requirements and
present their solution.

Level Steps 8
Step Details
Develop Evaluation Script
Cases
During the solution meetings with vendors, the team needs to compare solutions fairly and
evenly, even though different solutions are being proposed and discussed. This is hard for the
team to do if each vendor is allowed to determine the meeting’s sequence, contents, and
emphasis. By prescribing that all vendors follow a planned sequence of requirements, or scripts,
you:
• Ensure consistency of content coverage across vendors
• Ensure the vendor is presenting those features most important to you, not just those the
vendor puts forward as strong points
• Can more easily spot features and functions that do not quite match expectations
• Can more easily distinguish how the features and functions differ among solutions
You can also use this material when checking vendor references and making reference site visits.
Select Initial Vendor and
Product Shortlist
Conduct a workshop to obtain team consensus on whether or not to proceed with solution
evaluation and to reduce the list of vendors under consideration to three or fewer. Use the
workshop approach for large solutions or solutions with a major impact such as the service
being requested.
Check Vendor References Check vendor references as another way to confirm that the vendors’ solution and services
could meet the requirements. Develop a questionnaire to record reference responses. Include
questions covering relevant functional, technical and general requirements. Involve members of
the team in reference checking. This distributes the work, counteracts individual bias, and
provides experience useful in subsequent VSES activities.

Level Steps 9
Step Details
Conduct Functional and
Operational Review
Meetings
Have the short list vendors conduct functional and operation walk-throughs using the script
cases provided, so you can:
• Confirm that the solution, can process operate to your satisfaction
• Determine, based on your own observations, which solution provides the best answer to
needs

Level Steps 10
Step Details
Perform Technical Review Conduct a technical review of the solution with the vendor’s technical staff. They are usually
involved in the provision of the solution and its underlying technical components. They are not
as oriented as the sales staff toward selling the solution. They usually provide a more realistic
view of the solution and the vendor’s ability to support it. They can also confirm technical
infrastructure details about operating the solution.
The technical review typically has several components:
• Demonstration of technical facilities and elements
• Review of remaining questions on technical and general criteria responses
• Support and operational model comparison
• Performance investigation
• Review of solution architecture
• Conceptual technical infrastructure design
• Review of services delivery and quality
• Software, support and operations costing
• Review the software release and patching strategy the vendor employs
During the technical review, each team member updates the relevant factor scores. The team
members take notes justifying the scores and identify other risk areas, strengths, and
weaknesses. At the end of the technical review, the team meets to reach consensus on the
technical review findings.

Level Steps 11
Step Details
Contact/Visit Reference
Sites
Decide whether to visit vendor reference sites. Plan the approach, visit the sites, then
consolidate the findings.
Perform Financial Analysis This activity is a critical juncture for confirming the vendor’s financial estimates. Ensure the
vendor’s cost estimates are as correct as possible by confirming the preliminary cost estimates.
Score Vendors and
Products
Review and summarise the scores of all the shortlisted products and vendors. Update the scores
if necessary based on additional information and any clarification sought from or provided by
the vendor.
Select Most Suitable
Solution
The team is now prepared to select a finalist. Review the decision to confirm that the solution
approach should still be pursued. Determine contract negotiation timing and approach. Conduct
a workshop or a work session to select the solution finalist. In general, use a workshop for a
large solution such as that being requested.

Level Steps 12
Step Details
Complete ad Document
Complete the evaluation process
Complete the project records
Finalise the evaluation report
Notify the losing vendors
Prepare for any vendor loss meetings
Conduct any vendor loss meetings
Assess satisfaction with the evaluation work
Summarise the work results and the lessons learned
Review and recognise the team performance
Close out the evaluation records

Product Evaluation And Selection Team
• The evaluation team may be structured along the following logical
lines
• The team size will depend on the size and complexity of the solution
being looked for
Evaluation
Team Manager
Functional
Team
Technical Team General Team
Technical
Specialist
Technical
Specialist

• The team will be lead by a team manager
• The team may be divided into a number of groups:
− Functional - this group will be responsible for evaluating the functional
aspects of the responses
− Technical - this group will be responsible for evaluating the technical
aspects of the responses
− General - this group will be responsible for evaluating general factors
such as the responding companies and the finances
• No members of the evaluation team will be connected with any
of the vendors
• The team manager may be assisted by a number of specialists
in particular aspects of the development and operation of a the
specific solution

• The responsibilities of the Evaluation Team Manager will be:
− Managing the evaluation process
− Consulting with specialists as required
− Documenting the evaluation process
− Assign weights to the evaluation factors in conjunction with the Group
Leaders
− Conducting meetings of the evaluation group leaders and of the whole
team
− Preparing the final report on the evaluation
− Reviewing and understanding responses from respondents
− Acting as the single point of contact between respondents and other
team members
− Allocating and scheduling work for the evaluation groups
− Reviewing the outputs from the evaluation groups and seeking
clarification

• The responsibilities of the evaluation group leaders will be:
− Conducting meetings of the evaluation group
− Preparing evaluation task lists and other material to assist
evaluation
− Co-ordinating any questions to and responses from respondents
from group members
− Documenting the work of the group
− Reporting to the team manager as required
− Allocating and scheduling work between the members of the
group
− Reviewing and discussing the work of the group as it takes place
− Summarising the results of the evaluation group

• The responsibilities of the members of the individual group
members will be:
− Understanding the evaluation process
− Documenting their work
− Performing their assigned work in a timely and efficient manner
− Seeking clarification where required
− Responding to queries and requests for updates from the group
leader and team manager

Update Business Engagement Solution Assumptions
• The outcome of the product evaluation and selection
exercise may cause changes in the expected solution costs
and timescales
• These may need to be reviewed and updated

7. Design Model Target Architecture

7.1 Design Model Target Architecture
• Design the architecture options for the solutions to be implemented as
part of the target business architecture
− Architecture here includes technical, security and hardware, software and
communications infrastructure details
− It does not include detailed solution architecture
• It will translate the information gathered in the following engagement
steps into architecture options
− 4. Document Solutions, Applications And Functions
− 6. Conduct Solution And Product Evaluation And Selection
• It may not be possible or desirable to define the detailed architecture at
this stage
• This will depend on the set of solutions being implemented and whether
they based on products or are being developed
− There may be a single architecture option or there may be multiple options
• The purpose of this activity is to document architecture options to be
included in the final business engagement output for completeness

Design Model Target Architecture Steps
• Decide on those factors that affect the architecture
options and designs
• Define the options available
• Review and identify the realistic and achievable target
architecture options
• Perform a detailed evaluation of the selected realistic and
achievable target architecture options
• Select the preferred target architecture
• Verify the implementability, operability, feasibility and
affordability of the preferred target architecture
• Document the architecture

Target Architecture Components
• There may be multiple components or layers to the target
architecture
− Communications
− Infrastructure
− Data storage
− Infrastructural/management/administration applications
− Business applications
− Integration
− Security
• These components and their options for each design will
need to be identified

Factors That Affect The Architecture Options And
Designs
• Define and elaborate on those factors that affect the architecture
options and designs, such as:
− Organisation (enterprise architecture) standards and constraints
− Options available from available products
− Available product deployment options
− Use and enhancement of existing applications to meet the requirements of the
target solutions
− Solution acquisition policy
− Compliance with relevant and important industry-specific standards
− Performance, throughput, capacity, transaction, user and data volumes
− Scalability along performance dimensions
− Availability, reliability, fault-tolerance
− Security
− Locations
− Approaches to interfaces with existing systems and applications and
integration
− Cost
− Organisation appetite for risk and new technologies

Factors That Affect The Architecture Options And
Designs
• Determine the appropriateness and the importance of
each of the factors and assign some form of weighting
• Decide on the approach to evaluating each of the factors

Define The Options Available
• Identify the set of options to be considered
• Review each option with respect to the previously agreed
factors that affect the architecture options and designs
• There may be multiple combinations of options for each
major technical infrastructure component

Component Options For Each Design
Component Design 1 Design 2 Design 3
Communications
Including Mobile
Evaluation against each
relevant factor
Physical Central
Infrastructure
Physical User
Infrastructure
Data Storage
Infrastructural/
Management/
Administration
Applications
Business Applications
Integration And
Interfaces
Security

Approaches To Existing Technical Infrastructure
• There may be existing technical infrastructure including applications and
data that needs to be considered as part of the future business
architecture
• Evaluate the options for each element of the existing technical
infrastructure
Replace the existing technical infrastructure with new set. Note that this may
require data migration
Replace Partially Or
Completely
Encapsulate the existing technical infrastructure elements with the proposed
new technical infrastructureEncapsulate
The new and existing technical infrastructure elements will operate in parallel
with possibly some form of integration or interface between themOperate in Parallel
Incorporate the existing new technical infrastructure elements into the new
technical infrastructure elements into a single infrastructure, ensuring the two
sets of elements are mutually compatible
Incorporate

Review And Identify The Realistic And Achievable
Target Architecture Options
• Analyse the longlist of possible options and create a
shortlist based on those options that most closely match
the key architecture factors
• Eliminate options that are not feasible or realistic or too
expensive

Perform A Detailed Evaluation Of The Selected
Realistic And Achievable Target Architecture Options
• For each of the shortlisted options create a detailed design
showing how it can be implemented, operated, supported,
used and its likely cost and time and resources required to
implement
• Evaluate the impact of the option against the six
organisation domains
• Determine how the solutions comply with the principles
defined in the engagement step:
− 2. Define Vision, Business Principles And System Principles

Evaluation Approach
• Use a structured evaluation approach to provide a formal
record of the process
• Score each of the short-listed architecture options
• Where the scores of options are similar, recheck scores
assigned to ensure they are valid

Select The Preferred Target Architecture
• Select the preferred architecture option based on the
analysis and scoring
• If there is no clear preferred option, then consider adding
extra evaluation factors to differentiate options

Verify The Implementability, Operability, Feasibility And
Affordability Of The Preferred Target Architecture
What It Does,
How It
Operates –
the
Functionality
Cost/Time/Risk
To Implement
The
“xAbles”

Target Architecture “xAbles” – Operational (Non-
Functional) Requirements
• Usable
• Affordable
• Deliverable
• Operable
• Supportable
• Maintainable
• Flexible
• Adaptable
• Capable
• Scalable
• Reliable
• Securable
• Available
• Auditable
• Recoverable
• Stable
• Testable
• Accessible
• Upgradeable
• These are very important operational
requirements that may not be articulated
by business users and stakeholders
• They are essential to the success of the set
of solutions that comprise the target
business architecture and its enduring
operation and use
• Evaluate the solution set with respect to
each of these factors

Verify Performance
• Walk through the preferred solution with respect to the
key processes and processing loads
• If necessary, conduct trials on key elements of the
preferred target architecture
• Consider implementing proof of concept prototypes to
validate key design elements

Document the Architecture
• Document the architecture design
• Create summary presentation material
• Present and review the architecture with the key business
representatives
• Update and finalise based on feedback

8. Consolidate, Finalise And Review Design

8.1 Finalise Application Architecture
• Finalise the application architecture based on the technical
infrastructure design selected
• Finalise the data model
• Finalise the list of interfaces
• Complete the documentation agreed in the engagement
step
− 0. Define And Agree Engagement Scope
• Create summary presentation material

8.2 Define Benefits And Costs
• Validate the detailed cost model

8.3 Create High Level Phased Delivery Plan
• Create a plan for the delivery of the solution defined
during the business engagement

8.4 Review And Agree Business Architecture
Engagement
• Create a draft presentation of the final analysis and
recommendations
• Present to key business representations
• Update and finalise based on feedback

More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney

Introduction to Business Architecture - Part 2

More Related Content

What's hot (20)

Similar to Introduction to Business Architecture - Part 2 (20)

More from Alan McSweeney (20)

Recently uploaded (20)

Introduction to Business Architecture - Part 2