Perspectives

Chapter Study Group

Learning Materials
2015, International Institute of Business Analysis™
(IIBA®).

Permission is granted to IIBA Chapters to use and

modify this content to support chapter activities.

All other rights reserved.

2
INTRODUCTION

“Perspectives are used within business

analysis work to provide focus to tasks
and techniques specific to the context of
the initiative.”
– A Guide to the Business Analysis Body of Knowledge -­BABOK
v3

Perspectives 3
INTRODUCTION – THE 5 PERSPECTIVES
“Perspectives are used within business analysis work to provide
focus to tasks and techniques specific to the context of the
initiative.”
– A Guide to the Business Analysis Body of Knowledge -­BABOK
v3

Business Information
Agile
Intelligence
Technolog
y
Business
Business Process
Architecture Management

Perspectives 4
INTRODUCTION – PERSPECTIVE STRUCTURE
• Perspectives help Business Analysts to understand the tasks and
knowledge areas in the BABOK Guide from the standpoint of
the context of the current initiative.

Change Scope

Business Analysis Scope

Methodologies and Approaches

Underlying Competencies

Impact on Knowledge Areas

Perspectives 5
11.1 The Agile
Perspectives
INTRODUCTION – THE AGILE PERSPECTIVE

• The Agile Perspective highlights the unique characteristics of business

analysis practiced in the context of agile environments.
• Agile is a philosophy and approach to delivery.
• It’s a set of values and principles that promotes collaboration, continuous
improvement, evolving requirements, and adapting to change.

• The four values of agile1

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

1. Source: www.AgileManifesto.org

The Agile Perspective 7

INTRODUCTION – THE AGILE PERSPECTIVE

• Business analysts conduct analysis and deliver work products

at the last responsible moment to allow flexibility for change.
• The focus is on detailed analysis work needed in the near term while
analysis needed in the future is less detailed or delayed and completed
just in time for use by the agile team.
• Allows for flexibility and encourages rapid response to change
without wasted effort.
• Business analysis work is performed continuously throughout the
initiative.

The Agile Perspective 8

11.1.1 CHANGE SCOPE
• Scope for agile initiatives constantly evolves
• Scope changes are managed through the backlog.
• Backlog is continuously reviewed, reprioritized, and refined.
• Continuous backlog refinement allows teams to meet the evolving
needs of the business.
Introduction

• A project may be suspended and reassessed if a change emerges

that significantly impacts the goal and value.

The Agile Perspective 9

11.1.1 CHANGE SCOPE
• Agile approaches may be used for software development
projects as well as non-­software related changes such as
process improvement.
Breadth of Change

• Agile projects may be contained within a single

department
or span multiple divisions and teams.

• Organizations new to agile should focus on continuous

improvement, behavioral change, and incremental
improvement to move toward adopting an agile mindset
rather than thinking of agile as a methodology.

The Agile Perspective 10

11.1.1 CHANGE SCOPE
• Agile practices are often applied to initiatives in which:
• There is commitment from the customer and active engagement
of empowered subject matter experts
• The business need or proposed solution is complex
Depth of Change

• Business needs are likely to change or are still emerging

• An agile approach can be used:

• For initiatives that are developing a new solution for the first time
• For maintaining and enhancing an existing solution
• As part of a larger program of work in which other elements are
developed using agile or another methodology depending on the
need

The Agile Perspective 11

11.1.1 CHANGE SCOPE
• An Agile approach emphasizes
• Delivering value early
Value and Solutions Delivered

• Collaboration
• Adaptive planning with a focus on continuous improvement

• Agile teams adapt to change through frequent product

reviews and seeking feedback
• Stakeholders frequently review the product and provide
feedback.
• Team adapts based on feedback.
• Frequent reviews may uncover missed requirements and allows
the solution to evolve over time.
• Enables team to deliver value that meets changing stakeholder
needs.
The Agile Perspective 12
11.1.1 CHANGE SCOPE
• Some example agile approaches include:
• Scrum
• Kanban
• Extreme Programming (XP)
Delivery Approach

• Crystal
• Dynamic Systems Development Method (DSDM)

• Agile approaches focus on personal interactions,

adapting to change, and continuous delivery of value.

• Each approach has a unique set of characteristics

• Teams can select the approach that best fits the initiative.
• Teams often combine elements from more than one agile
approach based on unique team composition, skills, experience,
operating environment, and other factors.
The Agile Perspective 13
11.1.1 CHANGE SCOPE
• Assumptions in an agile environment align to the values
and principles in the Agile Manifesto
• We welcome changing requirements, even late in development.
Major Assumptions

• Business problems can be reduced to a set of needs that can be

solved through some combination of technology and business
process change.
• Initiatives have highly engaged customers and empowered subject
matter experts (SMEs).

The Agile Perspective 14

11.1.1 CHANGE SCOPE
• Assumptions for agile teams
• Team membership is constant – members are not moved to other
teams.
• Teams are co-­located to encourage face-­to-­face communication.
Major Assumptions

However, agile can work well with distributed teams if effective

communication practices are followed.
• Team members are multi-­skilled and can perform more than one
role within the team if needed.
• Team members have a continuous improvement mindset and
accurately deliver value through regular review and feedback.
• Teams are built around motivated, self-­organizing individuals and
are empowered.

The Agile Perspective 15

11.1.2 BUSINESS ANALYSIS SCOPE
• The sponsor of an agile initiative must:
• Be familiar with agile philosophy, mindset, and approaches
• Be open to frequent feedback
• Accepts the use of adaptive planning over predictive planning
Change Sponsor

• Accepts the use of a fixed time period for a work cycle

• Understand the need and value of active sponsor involvement

• These characteristics are critical so that the sponsor can:

• Understand the product under development
• Provide the team with continuous feedback
• Adjust the product as customer needs change

The Agile Perspective 16

11.1.2 BUSINESS ANALYSIS SCOPE
• The change agent is a stakeholder and can include:
• Agile Team Leader: Uses servant leadership to facilitate the work
of the team. Allows team to perform tasks of planning, scheduling,
and prioritization of work.
• Product Owner (Scrum) or Customer representative (XP):
Change Agents

Active team member responsible for ensuring that the change

being developed by the team meets the needs of the customer.
• Team members: Specialists or domain experts responsible for
delivering the needed change. May include technical and
customer representation.
• External stakeholders: Stakeholders outside of the team who are
interested in the project outcome or are needed for its completion.

The Agile Perspective 17

11.1.2 BUSINESS ANALYSIS SCOPE
• Who performs business analysis activities on agile
teams?
• The preference for cross-­skilled team members on agile teams
means that teams may have one or more individuals with business
Business Analysis

analysis skills performing those activities.

• Team members may or may not have the title of business analyst.

• Business analysis activities may be performed by:

• A business analyst who is a member of the team
• The product owner / customer representative
• The activities may be distributed throughout the team
• A combination of the above

The Agile Perspective 18

11.1.2 BUSINESS ANALYSIS SCOPE
• Successful business analysis enables key outcomes in
agile projects
Business Analysis Outcomes

• Open communication and collaboration.

• Project vision and direction align with organizational goals and
business need.
• Acceptance criteria and strategic criteria for project completion are
defined.
• Product vision statement is well defined and understood.
• Create just-­in-­time documentation

The Agile Perspective 19

11.1.3 APPROACHES AND TECHNIQUES
• All Agile approaches use business analysis but few
define the business analysis role
• Teams may use one or a combination of approaches to
more effectively deliver value given the nature of the
project and their work environment
Approaches

• Scrum: A lightweight framework in which work is planned for and

performed in a series of fixed length iterations (Sprints) lasting 1 to
4 weeks. The goal of each sprint is to produce working software
that is potentially shippable or delivered to the customer.

Scrum Process
Source: Agile Extension to the
BABOK Guide

The Agile Perspective 20

11.1.3 APPROACHES AND TECHNIQUES
• Feature Driven Development (FDD): Focuses on delivering
functionality based on customer value. Once a feature list is
identified, all planning and development performed by the team are
based on those feature sets.
• Extreme Programming (XP): Focuses on technical development
processes and effective software engineering practices. Practices
Approaches

include pair programming, test driven development (TDD), and

other approaches to software craftsmanship. XP practices are
often used with one of the agile frameworks.

XP Process
Source: Agile Extension to
the BABOK Guide

The Agile Perspective 21

11.1.3 APPROACHES AND TECHNIQUES
• Kanban: Focuses on completing work through a continuous flow of
activity by limiting the amount of work in progress (WIP). Kanban
does not use fixed iterations and instead is a pull system in which
work may begin only when it is needed to maintain downstream
flow and after the previous item has been completed.
• Disciplined Agile Delivery (DAD): A decision process framework
Approaches

incorporating aspects of other agile approaches. Allows teams to

customize their product development lifecycles and approaches
from initiation through delivery.
• Evolutionary Project Management (Evo): A project management
method for developing and delivering a product incrementally. The
focus of Evo is on quantifying stakeholder value and planning
increments to deliver that value. Uses impact estimation tables for
assessing solutions based on value for a given cost.

The Agile Perspective 22

11.1.3 APPROACHES AND TECHNIQUES
• Crystal Clear: Part of a family of Crystal methodologies based on
hardness (business criticality or potential to cause harm) and color
(complexity/heaviness of the project across several dimensions
including project risk and number of people needed). As hardness
increases, more rigor and predictive planning is required.
• Dynamic Systems Development Method (DSDM): A framework
Approaches

focused on fixed cost, quality, and time while managing a

contingency by varying the features to be delivered. Work is
managed through short periods of time (time boxes) with defined
goals. MoSCoW prioritization is used for scope management.
• Scaled Agile Framework (SAFe™): A framework for
implementing agile at enterprise scale. SAFe provides a
framework with roles, activities, and artifacts needed to scale agile
from the team to the program level and to the enterprise level.

The Agile Perspective 23

11.1.3 APPROACHES AND TECHNIQUES
• Techniques used with agile approaches
• Behavior Driven Development (BDD): An approach that
expresses product needs using concrete examples to facilitate
communication between team members and stakeholders.
• Kano Analysis: A technique for understanding which product
features will drive customer satisfaction.
Techniques

• Lightweight Documentation: An agile principle to ensure any

documentation produced fulfills a need, has value to stakeholders,
and does not create unnecessary overhead. Documentation
should be just enough to meet the need.
The Agile Perspective 24
11.1.3 APPROACHES AND TECHNIQUES
• MoSCoW Prioritization: A prioritization method to develop a
common understanding or the relative importance of delivering a
piece of product value. MoSCoW stands for Must have, Should
have, Could have, Won’t have.
• Personas: Fictional characters, avatars, or archetypes that
demonstrate the way a person of similar characteristics may
Techniques

interact with the product.

• Planning Workshop: A collaborative workshop that allows an
agile team or group of teams to determine what value can be
delivered over a time period such as an iteration or release.

The Agile Perspective 25

11.1.3 APPROACHES AND TECHNIQUES
• Purpose Alignment Model: A model used to assess ideas in
terms of value to the customer.
Techniques

Purpose Alignment Model

Source: Agile Extension to
the BABOK Guide

• Real Options: An approach to help understand when to make

decisions rather than how.
• Relative Estimation: An estimation technique allowing teams to
understand the development effort required to deliver a piece of
product value. Common estimates include the use of story points
(represent the relative complexity of a user story) and ideal days.
The Agile Perspective 26
11.1.3 APPROACHES AND TECHNIQUES
• Retrospectives: A process similar to Lessons Learned in which
teams focus on continuous improvement at regular intervals (often
at the end of each iteration).
• Story Decomposition: Ensures product requirements are at the
correct level of detail and align to delivering a valuable business
objective.
Techniques

• Story Mapping: A technique for creating a visual representation of

the sequence of activities to be supported by a product. Story
Mapping can be used to decompose stories and determine the
minimum viable product.

Story Mapping
Source: Agile Extension to
the BABOK Guide

The Agile Perspective 27

11.1.3 APPROACHES AND TECHNIQUES
• Storyboarding: Provides information visually and textually related
to the sequence of activities that represent user interactions with a
system or product.
• Value Stream Mapping: Provides a fact-­based, time-­series
representation of the stream of activities needed to deliver a
product or service to the customer.
Techniques

Value Stream Mapping

Source: Agile Extension to
the BABOK Guide

The Agile Perspective 28

11.1.4 UNDERLYING COMPETENCIES
• By embodying the values and principles of the Agile
Manifesto, business analysts develop competencies in:
• Communication and collaboration: Communicate vision and
needs, influence others to support the vision, negotiate priorities,
and facilitate collaborative agreement on solutions.
Competencies

• Patience and tolerance: Maintain self-­control under pressure and

keep an open mind when interacting with others.
• Flexibility and adaptability: Develop cross-­functional skills that
allow the business analyst to support other team members.
• Ability to handle change: Quickly assess impact of change,
determine business value, and assist in reprioritization of work.
• Ability to recognize business value: Understand how changes
and new features can deliver value and support the vision.
• Continuous Improvement: Periodically review and reflect with the
agile team and make changes to become more effective.
The Agile Perspective 29
11.1.5 IMPACT ON KNOWLEDGE AREAS
• This section explains how business analysis practices
within agile are mapped to business analysis tasks and
practices as defined by the BABOK® Guide
• How each knowledge area is applied or modified within the context
of an agile approach.
Introduction

• Some of the additional BA techniques needed to fulfil the work of

the agile perspective.

The Agile Perspective 30

11.1.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• With agile approaches, detailed business analysis planning
can be deferred until work on an activity is ready to begin
rather than planning everything upfront.
• Initial, high level plan of business analysis activities is
developed at the beginning of the project and then updated
prior to the start of each cycle to ensure the plan is up to date.
Business Analysis
Planning and
Monitoring

The Agile Perspective 31

11.1.5 Impact on Knowledge Areas
• Introduction
• Progressive elaboration and elicitation take place
throughout an agile initiative.
• In every cycle, more detailed elicitation takes place for
backlog items to be developed in the next cycle.
• The goal is to minimize the time between the elaboration
of customer needs and solution delivery.
Elicitation and

Collaboration

• Requires a focus on collaborative elicitation approaches.

The Agile Perspective 32

11.1.5 Impact on Knowledge Areas
• Introduction
• Scope of the initiative is defined with increasing specificity
as the initiative progresses.
• We expect customer needs to change and solution design
will evolve over time.
• Review and validation of the evolving solution with
Cycle Management

stakeholders occurs at the end of every iteration, taking

Requirements Life

the place of a formal requirements approval process.

• Business value and development priority drives the work to
be done in the next cycle.

The Agile Perspective 33

11.1.5 Impact on Knowledge Areas
• Introduction
• Strategy analysis is used to ensure that the solution
being delivered continues to provide value to
stakeholders.
• For each cycle, the proposed solution is reevaluated in
the current business context to ensure it will meet
business goals.
Strategy Analysis

• Strategy Analysis helps agile teams:

• Define and understand product vision
• Create and modify the development roadmap
• Assess risks

The Agile Perspective 34

11.1.5 Impact on Knowledge Areas
• Introduction
• Analysis and design are performed on a just-­in-­time basis,
either just before or during the iteration in which the
solution component will be developed.
• Analysis performed just before the iteration is to provide
the team with enough information to estimate the planned
work.
Analysis and Design

• Analysis performed during the iteration is to provide the

Requirements

Definition

team with enough information to develop or deliver the

planned work.
• Analysis and design approach used should support
progressive elaboration, be adaptable to change based on
learning, and not cause the team to select solutions
prematurely.

The Agile Perspective 35

11.1.5 Impact on Knowledge Areas
• Introduction
• Stakeholders and agile team continually reassess and
evaluate the solution as it is incrementally built and
refined throughout the project.
• Evaluation of the evolving solution with the
stakeholders occurs at the end of every development
cycle to ensure the deliverable meets their needs and
satisfies their expectations.
• The business analyst ensures that the product meets
Solution
Evaluatio

expectations before it is released and identifies new

opportunities that will add value to the business.
n

The Agile Perspective 36

 11.2 The Business
Intelligence Perspectives
INTRODUCTION – THE BUSINESS
INTELLIGENCE PERSPECTIVE
• Business Intelligence definition -­The transformation of
data into value-­added information:
• Where to source it
• How to integrate it
• How to enhance it
• How to deliver it

The Business Intelligence Perspective 38

INTRODUCTION – THE BUSINESS
INTELLIGENCE PERSPECTIVE
• Business Intelligence definition -­The transformation of data
into value-­added information

• Business Intelligence Perspective: in the context of delivering

reliable, consistent, high-­quality information that enables
stakeholders to better manage strategic, tactical and operational
performance.
Data

• The focus of business intelligence From

is the transformation of data into Information
Insight
to
valued-­added information to deliver Impact

analytic insight.
Knowledge

Action

The Business Intelligence Perspective 39

11.2.1 CHANGE SCOPE
Business Intelligence Solution – Conceptual Framework
Introduction

The Business Intelligence Perspective 40

11.2.1 CHANGE SCOPE
• Key objectives of a business intelligence system
• Provide a ‘Single version of the truth’.
• Provide effective Information delivery methods and tools.
Objectives and Values

• Promote an enterprise-­view of the information management.

• Integrate multiple data sources .
• Integrate different types of data .
• Support Infrastructure services.

• Value of a Business Intelligence Initiative: provides timely,

accurate, and actionable information

• Drives better informed decision making

The Business Intelligence Perspective 41

11.2.1 CHANGE SCOPE
• Business Intelligence initiatives focus on the information
needed to support decision making at, or across
different levels within the organization.
Depth of Change

Executive
Strategic decisions
Level

Management Level Tactical decisions

Process Level Operational decisions

The Business Intelligence Perspective 42

11.2.2 BUSINESS ANALYSIS SCOPE
• The change sponsor is the business executive from the
impacted area:
Change Sponsor and Targets

• Understand the value of business intelligence

• Champion and promote the projects
• Influence other executives
• Approve the budget

• Targets are the business decisions that are made:

• People
• Process
• Technology

The Business Intelligence Perspective 43

11.2.2 BUSINESS ANALYSIS SCOPE
• Business Analyst role working on BI initiatives
• Business analyst who is competent in the definition of business
Business Analyst Position

requirements and the assessment of potential solutions.

• Business intelligence functional analyst who has an understanding
of data mining and predictive analytic techniques, as well as skills
in developing visualizations.
• Data analyst who is experienced at defining source systems data
to be used for the required analytical purposes.
• Data Modeler/architect who is skilled in defining the source and
target data structures in logical data models.

The Business Intelligence Perspective 44

11.2.2 BUSINESS ANALYSIS SCOPE

The specification of
Business Analysis Outcomes

business decisions to The collection of data

be influenced or from source systems
changed

Major
components

The integration of The provision of

divergent sources into a targeted information and
convergent enterprise analytic insight to
framework business stakeholders

The Business Intelligence Perspective 45

11.2.2 BUSINESS ANALYSIS SCOPE

Decision
Business Analysis Outcomes

Models Business
Business Process
Analytics
Coverage
requirements

Solution Architecture

Source logical Transformation

data model and Rules Target logical
data dictionary Source data data model and
quality data dictionary
assessment

The Business Intelligence Perspective 46

11.2.3 METHODOLOGIES AND APPROACHES
• Descriptive Analytics – what happened?
• Understand and analyze past business performance.
• Requirements for standard reporting and dashboards, ad hoc
reporting, and query functionality.
Types of Analytics

• Predictive Analytics – What will happen?

• Identify patterns and relationships to predict future events.
• Requirements for pattern recognition through data mining,
predictive modeling, forecasting and condition-­driven alert.

• Prescriptive Analytics – What will improve?

• Identify decisions and initiate actions to improve business
performance.
• Requirements for business objectives, constraints criteria and
business rules for decision-­making process.
The Business Intelligence Perspective 47
11.2.3 METHODOLOGIES AND APPROACHES
Structured & Unstructured data

Structured
Data
Unstructured
Data

Business Analysis focus Business Analysis focus

• Data models • Metadata definitions
• Data dictionaries • Data matching algorithms
• Business rules

The Business Intelligence Perspective 48

11.2.4 UNDERLYING COMPETENCIES
• The Business Analyst needs to be effective in liaising
with both business stakeholders and technical solution
providers:
• Business data and functional usage
Competencies

• Analyze complex data structures

• Understand business processes including KPIs
• Decision modeling
• Data analysis techniques
• Data warehouse and intelligence
• Logical & physical data models
• ETL (Extract, Transform, Load) best practices

The Business Intelligence Perspective 49

11.2.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Consider the level of stakeholders’ and business
analysts’ expertise on the planned approach.
• How experienced the stakeholders are expressing their business
needs in the business intelligence context
• How skilled the business analysts are in interpreting those
requirements into business intelligence technical specifications
business
Business Analysis

• Business Analysts should be aware that Business

Planning and

Intelligence solutions.
Monitoring

• Typically engage many stakeholders with overlapping

requirements
• Individual requirements need to be synthetized in a set without
conflicts and redundancies between stakeholders
• Deliver longer-­term strategic value that goes beyond short-­term
operational benefits

The Business Intelligence Perspective 50

11.2.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Employ specialized documentation tools and
techniques to elicit particular requirements from
stakeholders, both business and technical.
• Work closely with individual stakeholders that might
only posses partial knowledge and expertise on
business decisions, data elements, data sourcing,
business rules and information delivery.
Elicitation and

Collaboration

• Interview individual stakeholders to identify their

information needs to support their decision making.
• Elicit workshops with stakeholders to detect common,
overlapping information requirements.
• Use data models, process models and decision models
to identify data sources, data analytic requirements and
business rules for decisions.

The Business Intelligence Perspective 51

11.2.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Will need to establish the infrastructure capabilities of the
required solution, so this will drive requirements-­related
work.
• Consider the structural dependencies within the solution
that might affect the prioritization of individual business
needs.
Cycle Management
Requirements Life

• Achieve efficiencies by implementing related requirements

at the same time.

The Business Intelligence Perspective 52

11.2.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Use high-­level conceptual data models to map the current
state of corporate information, to identify information silos
and to assess their related problems and opportunities.
• Use high-­level models to map the BI architecture.
• Logical data models -­> Solution architecture
• Data flow diagrams -­> Dynamic data-­in motion
Strategy Analysis

• Decision models -­> Business decisions & Data Analytics

• Physical data models -­> Data Warehouse & Data Marts
• Deliver incremental implementations across different
functional areas of the business based on business needs,
business impact and priorities.

The Business Intelligence Perspective 53

11.2.5 IMPACT ON KNOWLEDGE AREAS
• Model back-­end solution
• Source data / Transformations & Business rules / Target data
• Define Data availability & Data quality
• Illustrate the management of data latency and accessibility

• Model From-­End solution

Analysis and Design

• Analyze existing reports gaps and identify improvements

Requirements

• Design content & format of new/update outputs

Definition

• Asses the capability of the proposed solution

Functional requirements Non-­functional requirements
• Self-­serve facilities • Data quality
• Data analytics tools • Data latency
• Data presentation tools • Query performance
• Drill-­down capabilities

The Business Intelligence Perspective 54

11.2.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Deliver longer-­term strategic value that goes beyond
short-­term operational benefits.
• Educate the organization on the Business Intelligence
functionalities and benefits.
• Guide & consult stakeholders on the business
requirements that will add value to their decision making
process.
Solution

• Do not simply replace or repair existing information

Evaluatio

outputs.
• Explore and evaluate opportunities for additional value
that are enabled by a business intelligence solution.
n

The Business Intelligence Perspective 55

 11.3 The Information
Technology Perspective
THE INFORMATION TECHNOLOGY PERSPECTIVE

• Business analysts articulate/translates business vision and

needs to technology stakeholders

• Key Factors to consider:

• Solution impact: value and risks to the business
• Organizational maturity: formality and flexibility
• Change scope: breath, depth, complexity and context for the
proposed change

The Information Technology Perspective 57

11.3.1 CHANGE SCOPE
• Reasons for initiating changes to IT System:
• Creating a new organizational capability
• Achieving an organizational objective by enhancing an existing
capability
• Facilitating an operational improvement
Introduction

• Maintaining an existing information technology system

• Repairing a broken information technology system

The Information Technology Perspective 58

11.3.1 CHANGE SCOPE
• Different scenarios for IT systems requiring different
Business analysis approach
Breadth and Depth of Change

• Nature of Business analysis activity depends on factors

impacting solutions

• Details required to be defined to assess if the

documentation are relevant to delivering value.
• Technical details
• Integration effort
• How IT supports the organization operations

The Information Technology Perspective 59

11.3.1 CHANGE SCOPE
• Organizational value added due to changes in IT systems
include:
Value and Solutions Delivered

• Reducing operating costs

• Decreasing wasted effort
• Increasing strategic alignment
• Increasing reliability and stability
• Automating error-­prone or manual processes,
• Repairing problems,
• Making it possible to scale up, enhance, or make more readily
available a business capability
• Implementing new functionality and new capabilities.

The Information Technology Perspective 60

11.3.2 BUSINESS ANALYSIS SCOPE
• Personnel who can be assigned Business analysis task
• BA who works specifically with the business users of an IT system.
Business Analyst Position

• IT business analyst who is the designated liaison between the

technical team and the business group which uses the application.
• SME experienced with the current software implementation.
• Software user experienced with the daily activity of how the software
is used and can focus on usability.
• Systems analyst who has experience within the business domain,
but does not have experience with the specific application.
• Business process owner who has a depth of experience with the
business capabilities or processes, but may not have IT experience.
• Technical person with a depth of technical experience.
• COTS representative who leverages vendor package knowledge and
past implementation experience to customize packaged solution
implementations.
The Information Technology Perspective 61
11.3.2 BUSINESS ANALYSIS SCOPE
• Deliverables for Business Analyst
• Defined complete testable prioritized and verified requirements
Business Analysis Outcomes

• Analysis of alternatives
• Business rules
• Gap analysis
• Functional decomposition
• Use cases and scenarios and/or user stories as appropriate
• Interface analysis
• Prototypes
• Process analysis, Process models, or State models
• Decision models
• Context models or scope models
• Data models
The Information Technology Perspective 62
11.3.3 METHODOLOGIES
• Organizational approaches for solution development
• Predictive
-­> Structured processes which emphasize planning
-­> Formal documentation of the processes used for change
Methodologies

-­> Phases of processes are completed sequentially

• Adaptive
-­> It allows for reworking within process cycles
-­> It is both iterative and incremental
-­> The focus is on growing the product in both breadth & depth
• Hybrid
-­> It may include an overall vision for the whole initiative.
-­> It defines details within individual cycles or iterations

The Information Technology Perspective 63

11.3.4 UNDERLYING COMPETENCIES
• Critical skills required to be successful as a Business
Analyst
• A strong understanding of the detail required within a requirements
package to support technical solutions
Competencies

• An understanding of what is technically feasible within the

constraints of an organization’s technical architecture.
• Influencing and facilitation skills for working with stakeholders.
• Negotiation skills for dealing with business and technical staff to
come to agreements and decisions on solution
• Systems thinking is a crucial competency for business analysts
practicing in an IT environment

The Information Technology Perspective 64

11.3.5 IMPACT ON KNOWLEDGE AREAS

• Introduction
• A well-­defined business analysis plan integrates into the overall
project plan and provides business analysts with the
opportunity to define and schedule.
• Some organizations may have some standards and processes
to identify analysis tasks and deliverables.
Business Analysis

• Business analyst needs to understand the context of analysis

Planning and

including inter-­operation of software systems, business

Monitoring

processes and data flow between them so that systems

impacted by change can be correctly assessed.
• COTS solutions introduction can involve major systems
integration efforts, customizations, and many unexpected
tasks. Hence relevant internal user and external stakeholders
with COTS expertise need to be engaged during planning.

The Information Technology Perspective 65

11.3.5 IMPACT ON KNOWLEDGE AREAS

• Introduction
• It is beneficial to have at least one elicitation session with all
stakeholders to build on their expertise and perspectives.
• Business analysts practicing in an IT environment may utilize
techniques like investigation, simulations, experimentation.
• Information technology changes can be seen as a distraction or
cost by business stakeholders if the change is not perceived as
Elicitation and

Collaboration

mission critical or if the stakeholder is experiencing negative

value from the change.
• IT business analysts can decrease the risk of rework by
engaging information technology and business in collaboration
activities.

The Information Technology Perspective 66

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• While creating change, through exploration the business
analyst discovers the implications of the new functionality
provided by the solution.
• It is the role of the business analyst to work with stakeholders
to develop a consistent method for reviewing evolving
requirements to ensure alignment with the business objectives
Cycle Management
Requirements Life

for the initiative.

• As the complexity of an information technology environment
grows, it becomes increasingly important to track each change
to each requirement or between requirements and other
information. Traceability that includes dependencies and
relationships among requirements makes it easier for
stakeholders to understand what is changing about the IT
system and predict impacts of additional changes.
• Traceability also helps in understanding why some functionality
is dropped. 67
The Information Technology Perspective
11.3.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Within IT organization, Strategy analysis focuses on the
technologies and systems, business units, business processes,
and business strategies impacted by a proposed change.
• Business analysts plan for a thorough understanding of the
current state and a large context of the enterprise at first, with
the understanding that the scope will narrow as the future state
Strategy Analysis

is identified.
• Future state description may be process or capability related
and usually includes how current system functionality is
required to change in order to support the future vision and
meet the objectives of both individual stakeholders and the
enterprise.
• Once the aspects of the change scope and desired future state
are understood, business analysts assess uncertainty and risk.

The Information Technology Perspective 68

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• The term design is viewed more broadly from the business
analyst’s point of view. Designs are usable representations
that focus on the solution and understanding how value
might be realized by a solution if it is built.
• Business analysts define requirements to a level of technical
detail that will be used as part of solution design and input
Analysis and Design

into technical designs. This elaboration will include both

Requirements

functional requirements and non-­functional requirements.

Definition

• For some change initiatives, the definition of non-­functional

requirements could define all business goals for the change
effort.
• As part of requirements analysis, an IT business analyst
may partner with another business analyst with a different
focus, such as an enterprise business analyst or business
architect, to ensure that the IT requirements align to
business or organizational strategy.
The Information Technology Perspective 69
11.3.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Solution evaluation focuses on solution components and the
value they provide. Within an IT context, this includes a focus
on the interactions between multiple systems within the change
and the surrounding environment.
• Testing or quality assurance, as part of solution evaluation,
ensures that the solution performs as anticipated or designed,
and that it meets the needs of the business or stakeholders
who requested the change effort.
Solution
Evaluatio

• The value realization for IT solution is commonly associated

with better support for business processes and procedures.
• Business and technical objectives are associated with benefits
and value realization which are measured against defined
n

metrics used to evaluate success. Requirements should trace

back to the objectives, and this traceability provides a
foundation for solution evaluation.
The Information Technology Perspective

70
 11.3 The Business
Architecture Perspective
INTRODUCTION – THE BUSINESS
ARCHITECTURE PERSPECTIVE

Provide
Common
Understan
-­ding

Business
architecture

Support
Align to Ongoing
Strategic
Transform
Objectives
-­ation

The Business Architecture Perspective 72

INTRODUCTION – THE BUSINESS
ARCHITECTURE PERSPECTIVE
• Business Architecture principles
• Scope – the entire enterprise.
• Separation of concerns and scenario driven – different blueprints
• What
• How
• Who
• Where
• Why
• How well
• Knowledge based

The Business Architecture Perspective 73

11.4.1 CHANGE SCOPE
• Entire enterprise and may be performed
• Across enterprise as a whole
• Across a single line of business
Breadth and Depth

• Across a single functional division

• Executive or management level

The Business Architecture Perspective 74

11.4.1 CHANGE SCOPE
• Capabilities

• Value

• Processes

• Information and data

Elements

• Organization

• Reporting and management

• Stakeholders

• Security strategies

• Outcomes

The Business Architecture Perspective 75

11.4.1 CHANGE SCOPE
• Strategic planning

• Business remodeling
Types of Initiatives

• Organizational redesign

• Stream-­lining business operations

• Cost reduction

• Formalization of institutional knowledge

• Transformation initiatives

• Improve customer retention.

The Business Architecture Perspective 76

11.4.2 BUSINESS ANALYSIS SCOPE
• The goal is to:
• Understand the entire enterprise context
Business Analyst Position

• Provide balanced insight into all the architecture elements and their
relationships
• Provide a holistic view of all the specialties within the organisation

• Required insights, skills and knowledge:

• Business strategy and goals
• Conceptual business information
• Enterprise IT architecture
• Process architecture
• Business performance and intelligence architecture

The Business Architecture Perspective 77

11.4.2 BUSINESS ANALYSIS SCOPE
• The general outcomes:
• Alignment of the organization to its strategy
Business Analysis Outcomes

• The planning of change in the execution of strategy

• Ensuring that as change is implemented, it remains aligned

• Key deliverables include:

• Business capability maps
• Value stream maps
• Organization maps
• Business information concepts
• High-­level process architecture
• Business motivation models

The Business Architecture Perspective 78

11.4.3 REFERENCE MODELS AND TECHNIQUES
• Reference models are predefined architectural templates
that provide one or more viewpoints for a particular
industry or function
• Considered the default architecture ontology (industry or function).
Reference Models

• Provide a baseline architecture starting point.

ACORD Insurance and financial industry

BMM Generic
COBIT IT governance and management
eTOM & Telecommunications
FRAMEWORX
FEA SRM Government (US)
ITIL IT service management
SCOR Supply chain management

The Business Architecture Perspective 79

11.4.3 REFERENCE MODELS AND TECHNIQUES
• Common architecture techniques not included in the BABOK
Archimate® Open standard Modeling language
Business Motivation Formalization of the business motivation: mission, vision,
Model (BMM) strategies, tactics, goals, objectives, policies, rules, and
influencers
Techniques

Business Process Modeling of processes and interface points, identifies

Architecture core, supporting and management processes
Customer journey Customer journey through various touch points and
map stakeholders across the organisation. Used to analyze
customer experiences
Capability map Hierarchical catalogue of business capabilities (what the
business does)
Enterprise core Models integration and standardizations of the
diagram organisation
Information map Catalogue of business entities associated with business
capabilities and value delivery
The Business Architecture Perspective 80
11.4.3 REFERENCE MODELS AND TECHNIQUES
• Common architecture techniques not included in the BABOK

Organizational map Model showing relationships of business units, external

parties, capabilities & information
Project portfolio Model of programs, projects and portfolios to provide
analysis holistic view of change initiatives
Techniques

Roadmap Models actions, dependencies, responsibilities to move

from current state to future state
Service oriented Provides a holistic view of the IT infrastructure of the
architecture (SOA) organization
TOGAF A method to develop an enterprise architecture
Value mapping Holistic representation of the stream of activities required
to deliver value
Zachman framework Provides an ontology of enterprise concepts based on
matrix of six interrogatives and six levels of abstraction

The Business Architecture Perspective 81

11.4.4 UNDERLYING COMPETENCIES
• High tolerance for ambiguity and uncertainty

• A great deal of political acumen

• Ability to:
Competencies

• Put things into a broader context

• Transform requirements and context into a concept
• Suppress details and provide higher level views
• Think in long term time frames
• Deliver tactical outcomes
• Interact with people at the executive level
• Consider multiple scenarios and outcomes
• Lead and direct change

The Business Architecture Perspective 82

11.4.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• BA’s are required to understand enterprise level context:
• Strategy and direction, operating model and value proposition,
current business and operational capabilities, stakeholders and
their points of engagement, plans for growth, governance, and
planning processes, culture and environment, and capacity for
change
Business Analysis

• Governance planning and monitoring focuses on:

Planning and
Monitoring

• Selecting which initiatives will provide the most benefit in achieving

the business strategies and outcomes
• Determining which frameworks or models exist or are utilized
within the organization

The Business Architecture Perspective 83

11.4.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• BAs need to deal with a great deal of ambiguity & uncertainty.
• Communicate with and understand a diverse range of
stakeholders.
• Elicit inputs such as strategy, value, existing
and performance metrics to develop deep understanding.
architectures,
• Advocate for the organization’s strategy working to ensure
Elicitation and

Collaboration

alignment of individual initiatives to the strategy.

• Play a role to bridge the needs of individual stakeholders,
projects and operational groups to optimize the enterprises
goals and strategy.
• Optimize organization’s goals and strategies, discouraging
activities that achieve a narrow goal.

The Business Architecture Perspective 84

11.4.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• BA’s need to understand how projects impact the business
architecture on an ongoing basis and work to expand, correct
or improve the architecture.
• Essential BA’s have executive level support and agreement.
• Engage with architecture review board to review and assess
Cycle Management

changes to the architecture.

Requirements Life

• Identify possible emerging changes both internal and

external.
• Decide how to incorporate changes into the business
architecture of the organization.

The Business Architecture Perspective 85

11.4.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• Play a significant role in strategy analysis.
• Business architecture provides views on current state,
transitional state and future state of the organization.
• Develop roadmaps based on the organization’s change
strategy to ensure the organization continues to deliver value
and remain competitive throughout the change.
Strategy Analysis

• Analyze factors such as:

• Market conditions
• Which markets to move into
• How to compete in the transition state
• How to best position the organization’s brand proposition

The Business Architecture Perspective 86

11.4.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• BA’s select a variety of architectural models or views for
various stakeholders to provide context and information..
• These models result in better requirement analysis and
design, as they:
• Remove need to make assumptions
Analysis and Design

• Minimise risk of duplicating already existing capabilities, systems or

Requirements

sub-­optimizing the whole enterprise

Definition

• Synthesize knowledge and insights from multiple architectural

views to determine if proposed changes work towards or
conflict with organizations goals.

The Business Architecture Perspective 87

11.4.5 IMPACT ON KNOWLEDGE AREAS
• Introduction
• BA’s need to understand how well the business is performing
and investigate these measures against the expected
outcomes and initiatives.
• Must be able to collect capability and process performance
data collected by business owners, operational or IT
managers.
• BA’s analyze the results of measurements and use these to
evaluate solution impact and factor these into subsequent
Solution
Evaluatio

planning.
n

The Business Architecture Perspective 88

11.5 The Business Process
Management Perspective
INTRODUCTION – BUSINESS PROCESS
MANAGEMENT PERSPECTIVE
• Business Process Management (BPM) is a management
discipline and a set of enabling technologies that:
• Focuses on how the organization performs work to deliver value
across multiple functional areas to customers and stakeholders
• Aims for a view of value delivery that spans the entire
organization
• Views the organization through a process-­centric lens

• BPM initiative delivers value by implementing improvements to

the way work is performed in an organization.
• BPM determines how manual and automated processes are:
• Created
• Modified
• Cancelled
The Business Process Management Perspective 90
• Governed
CHANGE SCOPE
• Business analysts working within the BPM discipline may
address:
• A single process with limited scope
• All of the processes in the organization
Introduction

• Focus is on how the processes of an organization can be

changed in order to improve and meet the objectives of the
organization.

The Business Process Management Perspective 91

BPM LIFE CYCLE

Designing
Introduction

Optimizing Modeling

Execution and
Monitoring

The Business Process Management Perspective 92

BPM LIFE CYCLE
• Designing
• Identification of processes.
• Definition of current state (as-­is).
• Determining how we get to the future state (to-­be) by taking in
consideration stakeholders’ expectations of how the business
Introduction

should be run.

• Modeling
• Graphical representation of the process that documents the
process as well as comparing current and future state.
• Provides input to requirements and solution design specification as
well as analyzing their potential value.
• Simulation may use quantitative data so that the potential value of
variations on the process can be analyzed and compared.

The Business Process Management Perspective 93

BPM LIFE CYCLE
• Execution and Monitoring
• Provides the same type of input as Modeling but in terms of the
actual execution of processes.
• Data collected as a result of the actual business process flow is
reliable and objective.
Introduction

• Collected data is used in analyzing value and recommending

alternatives for design improvement.

• Optimizing
• Ongoing repetition or iteration of the previous phases.
• May be a source of requirements and solution design definitions
that comes directly from stakeholders and the user community.
• Demonstrates the value of a suggested solution modification and
justifies process and product improvement initiatives.

The Business Process Management Perspective 94

CHANGE SCOPE
• The goal of BPM is to ensure that value delivery is optimized
across end-­to-­end processes.

• BPM frameworks are sets or descriptions of processes for:

Breadth and Depth

• Generic organization
• Specific industry
• Professional area, or
• Type of value stream

• BPM frameworks define particular levels of processes

throughout the organization's process architecture.

• Business analysts involved with BPM are frequently engaged

in continuous improvement activities as a part of it.
The Business Process Management Perspective 95
BPM ACHIEVMENTS
• BPM achievements could be evaluated by reducing cost/risks
or by operational performance improvement.
Value and Solutions Delivered

• Effectiveness
• Efficiency
• Adaptability
• Quality

• Transparency into processes and operations is a common

core value of BPM initiatives, providing decision makers a
clear view of the operational consequences of process-­related
decisions.

• Starting point – identification of the business need of the

customers.
The Business Process Management Perspective 96
BPM DRIVERS
• Cost reduction initiatives
Value and Solutions Delivered

• Increase in quality

• Increase in productivity

• Emerging competition

• Risk management

• Compliance initiatives

• Next generation process automation

• Core system implementation

The Business Process Management Perspective 97
BPM DRIVERS
• Innovation and growth
Value and Solutions Delivered

• Post merger and acquisition rationalization

• Standardization initiatives

• Major transformation programs

• Establishment of a BPM Centre of Excellence

• Increased agility

• Speed or faster processes

The Business Process Management Perspective 98

BUSINESS ANALYST ROLES
Business Analysis Position

The Business Process Management Perspective 99

PROCESS ARCHITECT
• Responsible for:
• Modeling, analyzing, deploying, monitoring, and continuously
Business Analysis Position

improving business processes.

• Developing and maintaining standards and the repository of
reference models for products/services, business processes, key
performance indicators (KPIs), and critical success factors (CSF).

• Knows how to design business processes & enhance them.

• Enhances & transforms business processes into technically
enhanced and executable process templates.
• Focuses on managing business performance or on mapping
technology to business operations.

• Addresses & guides the decisions about process

knowledge, methodology, and technology.

The Business Process Management Perspective 100

PROCESS ANALYST/DESIGNER
• Has detailed process knowledge, skills, and interest
Business Analysis Position

• Expert in documenting and understanding process design

along with performance trends

• Has an interest in business process optimization to increase

overall business performance

• Understands the detailed process and performs the

necessary analysis for process optimization
• Performs analysis and assessment of as-­is processes
• Evaluates alternate process design options
• Makes recommendations for change based on various
frameworks

The Business Process Management Perspective 101

PROCESS MODELER
• Captures & documents business processes:
• Current (as-­is)
Business Analysis Position

• Future/target (to-­be)

• Documents a process for implementation or support by an

information technology system.

• The process analyst/designer and the process modeler

functions frequently reside within a single position.

The Business Process Management Perspective 102

OUTCOMES WITHIN THE DISCIPLINE OF BPM
• Business process models
Business Analysis Outcomes

• Business rules

• Process performance measures

• Business decisions

• Process performance assessment

The Business Process Management Perspective 103

COMMONLY USED METHODOLOGIES
• Adaptive Case Management (ACM)
• Used when processes are not fixed or static in nature, and have a
lot of human interaction.

• Business Process Re-­engineering (BPR)

Methodologies

• Fundamental rethinking and redesigning of business processes to

generate improvements in critical performance measures.

• Continuous Improvement (CI)

• Ongoing monitoring and adjustment of existing processes to bring
them closer to goals or performance targets.

• Six Sigma
• Continuous improvement methodology that focuses on the
elimination of variations in the outcome of a process.

The Business Process Management Perspective 104

COMMONLY USED METHODOLOGIES
• Lean
• Continuous improvement methodology that focuses on the
elimination of waste in a process.

• Total Quality Management (TQM)

Methodologies

• Processes of the organization should provide the customer and

stakeholders with the highest quality products and services.
• Products/services meet or exceed the expectations.

• Theory Of Constraints (TOC)

• Performance of a process is dominated by one key constraint at
any given time, and the process can only be optimized by
improving the performance of that constraint.
• Performance can be optimized by managing three variables:
throughput of a process, operational expense to produce it and
inventory of products.
The Business Process Management Perspective 105
BASIC SKILLS
• Challenge the status quo.

• Dig to understand the root causes of a problem.

• Assess why things are being done in a particular way.

Competencies

• Encourage subject matter experts (SMEs) to consider new

ideas and approaches to make their processes more efficient
and effective.
• Analyze internal and external views of the processes.
• Understand
• Articulate
• Move back and forth between views

The Business Process Management Perspective 106

BASIC SKILLS
• Due to the effects that changes to processes have on the
working habits of individuals, interaction skills are valuable.

• Negotiate and arbitrate between individuals with different

opinions.
Competencies

• Expose and resolve conflicts between different groups

within the organization.

• The business analyst is a neutral and independent

facilitator of the change.

• Communicate across organizational boundaries as well as

outside the organization.

The Business Process Management Perspective 107

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Progressive elaboration is used due to the amount of
information available for full planning may be limited in
the initial stages.

• Common cause of failure of BPM initiatives is the failure

to plan for ongoing monitoring of the effect of changes to
the process.
Business Analysis
Planning and
Monitoring

• Initial focus of business analysis work is on:

• Analyzing and improving the business process before
considering:
• Technology used to support the process
• Any changes that might be required to software applications or
work procedures

The Business Process Management Perspective 108

11.3.5 IMPACT ON KNOWLEDGE AREAS
• The scope of the initiative and the scope of the affected
process must be defined and understood.
• Process Modeling and stakeholder analysis are
generally utilized during the elicitation phase of a
BPM initiative.
• Process maps are an important tool to drive elicitation in
Elicitation and

BPM initiatives and stakeholders are frequently

Collaboration

consulted during their development.

• Process changes can have significant impacts across

the organization, so managing stakeholders and their
expectations is critical.

The Business Process Management Perspective 109

11.3.5 IMPACT ON KNOWLEDGE AREAS
• BPM is a set of approaches that focus on ways to deliver
value across multiple functional areas through a process-­
centric lens.
• BPM activities can drive out business requirements
resulting in new design, coding, implementation, and
post-­implementation changes.
Cycle Management
Requirements Life

• Business analyst ensures that communication is

effectively conducted with stakeholders and process
owners.
• Business processes documentation is available to all
stakeholders as it is to be used in the daily operation of
the business.

The Business Process Management Perspective 110

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Strategy analysis involves understanding the role the
process plays in an enterprise value chain.
• Any process that interacts with the processes affected by
the BPM initiative must be considered.
• Both current and future states need to be described by
the value chain and performance measures for the
Strategy Analysis

business process.
• Continuous improvement methods focus on the
performance measures to determine the strategy.
• The change strategy will involve the identification of
possible process changes.

The Business Process Management Perspective 111

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Focus on defining the to-­be process model.

• The requirements architecture includes:

• The process model
• Associated business rules and decisions
• Information requirements
Analysis and Design

• Organizational structure
Requirements

Definition

• Solution options include:

• Changes to IT needed to support the process
• Outsourcing of aspects of the process

The Business Process Management Perspective 112

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Solution evaluation occurs repeatedly during BPM
initiatives to assess the business process
performance.

• As processes are evaluated for different scenarios, they

can be refined and the results are monitored.

• Solution evaluation assists in understanding of the impact

and value delivered by business process change.
Solution
Evaluatio
n

The Business Process Management Perspective 113

11.3.5 IMPACT ON KNOWLEDGE AREAS
• Analyze solution performance task
• Understanding the differences between potential & actual
value.
• Determining if a solution can perform better/realize more
value.

• The evaluation examines:

• Opportunities or constraints of the implemented solution
Solution
Evaluatio

• How it satisfies needs

• How it could be improved
n

• Solution evaluation result:

• Triggers further optimization of the process
• Can lead to repeating of the BPM life cycle
The Business Process Management Perspective 114