Visualising How a Business Analyst Delivers Value

http://brettarthur.hubpages.com/hub/Visualising-How-a-Business-Analyst-Delivers-Value

Summary

The first article in this series described the concept of Business Architecture, and went on to
introduce two powerful models used to build sound, robust architectural views, being the
Capability Model, and the Value Stream. This second article seeks to solidify these models in the
context of Business Analysis.

The International Institute of Business Analysis (IIBA) have identified a set of competencies they
consider necessary for a practicing business analyst to be effective at their job. This article
builds a capability view using these competencies as a foundation, and then considers the value
streams that a business analyst uses to co-ordinate these competencies to perform their job.

Two distinct value streams emerge, one showing how a business analyst realizes value on a
project, and one showing how a business analyst realizes value at an enterprise level.

What Do You Do?

As a business analyst, have you ever been asked to explain what you do for the organization?
The question may have come from a co-worker, but more likely you were asked by one of the
more senior members of staff. The question can be quite a daunting one.

Since the field of IT business analysis is still relatively young, false impressions of what exactly
a competent business analyst is, and more importantly what value they bring to their
organisation generally, and their projects specifically, are rife. It is therefore important that the
answer given to the question is clear and accurate.

Competency or Capability?

Before moving forward, we must first understand the difference between a capability and a
competency.

Although often used interchangeably, "capability" and "competency" are quite different. Ulrich
and Smallwood[1] make the distinction that individuals build competencies, while
organisations exhibit capabilities.

The intention article is to produce a strategic view of the business analyst, describing their
competencies using a capability model and value stream maps. In doing so, the aim is to
provide a concrete example showing how to construct these two models using concepts that are
familiar to analysts.
For the remainder of this article we are going to treat the individual BA competencies as
analogous to organizational capabilities, whilst understanding the key difference highlighted
above.

The BABOK, and the IIBA’s Competency Model

Let’s get back to the question that we posed to start with: “What Do You Do?”. The Business
Analysis Body of Knowledge[2] (BABOK) is an excellent place to look to begin in formulating an
answer.

The BABOK, and its supporting Competency Model [3], describes the knowledge, skills, abilities
and other personal characteristics that an effective analyst perfects in time. Also laid out is a
roadmap for an analyst to plan their career trajectory from junior to master analyst.

In addition to underlying competencies expected from a professional knowledge worker, the IIBA
has identified 6 core knowledge areas that a business analyst must hone in order to progress
from beginner to competent to master in the practice of Business Analysis.

The competencies that we will use to build our model come from these 6 knowledge areas.

Strategic Modelling Step 1: The Business Analyst Competency Model

Let us start our example by considering the analyst to be an enterprise, and the competencies
presented in the BABOK to be our Analyst-Enterprise’s capabilities. Our first step is to build
a capability model that represents ‘what’ the Analyst-Enterprise is doing to create value.

This example is built using the Business Architecture Guild’s Level-1 Capability Model as a
foundation for categorizing each competency. For the sake of clarity, the Underlying
Competencies are presented separately.

Since we are considering the ‘what’ and not the ‘how’, we must exclude all of the techniques that
the BABOK list. Techniques are very much a ‘how’, and a senior analyst will use several
techniques interchangeably, according to the needs of the project at hand.

The model is shown in Figure 1.

Figure 1: Business Analyst Competency Model

You will immediately notice two things in the model:

 first, the competencies, named as capabilities, have been renamed, and;

 second, ‘Transition Requirements Definition’ is highlighted in red.

Naming Capabilities

The reason for the name-change is that capabilities are named using nouns [4]. Remember that
capabilities are an external, ‘black box’ view of a business function that encapsulates the
people (stakeholders in our case), process (think of the techniques described in the BABOK),
and platforms (in our case this includes such things as CASE tools or document repositories).

To assembling our capability model we are defining what is being done, not how. By using nouns
we build in a cross-check that we are not including processes or value streams into the
capability model.

During analysis, it is quite easy to get tangled in naming capabilities that you are identifying in
the business. If you find yourself questioning whether you have identified a capability correctly,
remember that you are working towards building a view of ‘what’, and not ‘how’. Take a step
back and ask: “Does my capability encapsulate people, process and platform, or have I fallen
into the ‘how-trap’ by describing process?”
Identifying Duplication

The reason that ‘Transition Requirements Definition’ is highlighted in red is that capabilities are
unique, and must occur only once on the capability model. Let’s analyse ‘Transition
Requirements Definition’ by refering to the BABOK definition:

Purpose: To define requirements for capabilities needed to transition from an existing solution
to a new solution.

So, this competency talks to requirements definition, but with the narrow focus of transitioning a
solution into the organisation. Therefore, it is comprised several of existing requirements-centric
capabilities already on our map; it is in essence a specialisation that combines existing
competencies.

This composite capability must thus be eliminated from the capability model.
Benefits of the Capability Model

Now that we have produced the model, let us consider the benefits of having produced a
capability model for our hypothetical Analyst-Enterprise.

1. The model provides us with a talking point. We can refer to it during discussions, and
importantly it drives a common vocabulary into those discussions. Moreover, it is easy to
discuss individual elements of the role, whilst not losing sight of the whole.
2. We can quickly see, on a single page, the competencies that make a business analyst.
Using this view an analyst can quickly focus on weak areas, and they can take steps to
address these weaknesses.
3. Further, the model can aid the planning that the analyst may do by allowingobjective
prioritisation of actions to address their areas of weakness.
The capability model is our blueprint. The model is a stable reference point throughout our
career. We may need to change a great deal, through learning and experience, to cultivate
mastery in the role, but the model remains the blueprint against which we will plan to develop
ourselves further.

Strategic Modelling Step 2: The Business Analyst Value Streams

When considering how an analyst delivers value to an organisation, it emerges that there are
two distinct levels that the analyst engages at.

The first emergent focus is bounded by a project, and the analyst works within the ambit of the
project. Working at the project level, the analyst’s deliverables address the specific needs of
their project.
The second focus is at an enterprise level, where the analyst is working with business leaders,
and key decision makers. At this level the analyst is working to distil strategy into clear
objectives. They work to understand the current state of the business, and to formulate the
actions needed to achieve the desired future state. This analyst will often be responsible for the
business plans that give rise to the projects mentioned above.

Junior and intermediate analysts will tend to have a project focus, while senior analyst will likely
be found bringing their depth of experience to bear at the enterprise level.
Value Stream: Plan-to-Solution

Using the competencies identified by the IIBA, the value stream that expresses value delivery in
the project context is presented below.

In the interests of simplicity, the ‘Transition Requirements Definition’ competency has not been
decomposed into its discrete elements.

Since value streams are designed with improvement in mind, we can start to leverage our view
of Plan-to-Solution for the purpose of improvement. Our goal may be to reduce cost by
eliminating waste (maybe arising from poor upfront planning), or to produce the solution in time
with customer expectation (by better managing scope and communication). Our goal is likely to
vary from project to project.
Value Stream: Vision-to-Plan

Next up, let us examine how an enterprise analyst delivers value while conducting their duties.
Figure 3: Vision-to-Plan Value Stream

In this example we can see that the enterprise analyst is using many of the same value stream
stages as the project analyst. This makes sense, as in both cases the analyst must plan, they
must engage with identified stakeholders to elicit requirements, the must communicate and they
validate outcomes. The main difference is the scope of the initiative, and the desired outcome.

Looking at both of the examples I am sure that you get a sense that the value stream presents a
dynamic view of value delivery.
Key Principles of Value Streams to Remember[5]

The value stream is customer-focused. Our customer in either instance above is the Project
Sponsor, and ultimately the business itself. You may choose to represent the customer in a
number of ways, whether in the map directly, or in your supporting documentation.

Keep in mind that the value stream is value centric. At each value stream stage we should be
able to identify at least one customer for whom we have created value. If we are not delivering
value then we are wasting time and money. It is sometimes helpful to include a purpose and
value statement below each value stream.

The value streams are a business-centric view of value creation. They are aimed at strategic
decision-makers, and are intended to be simple to understand and interpret. Avoid making overly
complex value streams that are more process-centric than is necessary. Getting back to the
initial question posed in this article: Think how quickly you could answer the question with a
value stream. The high-level nature of the steam does not put off senior members of staff, and
they are able to quickly understand the value delivery mechanism.

Value streams are holistic, end-to-end views of value creation. They are by nature cross-
cutting, and inclusive of external parties. This allows decision-makers to formulate a common
approach that can be rolled out across the organisation without needing to be tailored for
individual divisions, departments or sites.

Moreover, the value streams aggregate the underlying processes from across organisational
silos, and even organisational boundaries. This allows similar processes to be rationalised and
consolidated. Decision-makers are empowered by the holistic view to recognise redundant or
duplicate process, and to implement common solutions in these identified areas. The business
as a whole becomes more streamlined and efficient.

We can decompose the value streams. This allows the value stream to be tailored to meet the
specific needs of an individual product line, or business unit in the context of the value delivery
highlighted by the value stream.

Lastly, we can quickly understand how the value creation process leverages business
capabilities. Resources can be brought to bear, in an objective way, on capabilities that are
underperforming. For instance, we may quickly realise that we are not planning our activities well
enough as we are weak in the ‘Business Analysis Activities Planning’ competency. We could
then plan to work at improving this competency in upcoming projects.

Conclusion

By using our capability model and value streams we can lay down a blueprint that lets us
envision ourselves in terms of what we do, they facilitate planning of a successful approach to
improving our skill, and then guiding our development of these skills.

Crucially, we are able to express complex ideas simply, and effectively. The models tend to drive
out a common language, and by allowing discussions to revolve around the models we can
avoid ambiguity. Armed with these models it should be easy for an analyst to clearly answer the
question ‘What do you do?’.

Exactly the same principles apply when you view the enterprise through these two lenses. The
opportunities for improvement become quickly obvious. Business Architecture is becoming ever
more important in linking the business strategy to explicit, achievable results. As this field
matures it is going to become ever more important pillar that supports the overall Enterprise
Architecture.

References

[1] Dave Ulrich and Norm Smallwood. “Capitalizing on

Capabilities”.http://kwork.org/stars/Ulrich/Capabilities.pdf

[2] Business Analysis Body of Knowledge, version 2. 2009. Available from the International
Institute of Business Analysis.

[3] International Institute of Business Analysis. “Business Analysis Competency Model Version
3.0”. 2010.
[4] William Ulrich & Michael Rosen. “The Business Capability Map - Rosetta Stone of Business-
IT Alignment”. Enterprise Architecture Vol. 14, No. 2, 8 March 2011, available from Cutter
Consortium.

[5] “The Business Architecture Body of Knowledge Handbook”. 2011. Available from The
Business Architecture Guild.

------------------------

Business Architecture Visualising Value Delivery

http://brettarthur.hubpages.com/hub/Business-Architecture-Visualising-Value-Delivery

Summary

This article discusses the concept of Business Architecture, a new and fast-maturing disciple
whose purpose is to improve the strategic alignment of IT investment with business drivers.

Two models, the Capability Model, and the Value Stream, are emerging as powerful tools that
are essential for building robust strategic views of the business. These architectural views speak
to decision-makers in their simplicity, and empower these senior business stakeholders to make
objective planning decisions. Success is measured by evaluating outcomes against clear
performance objectives, which are agreed before any investment is made in building IT Assets.

Aimed at the practicing business analyst, this article presents the Capability Model and the Value
Stream Map in easy-to-understand language, and uses an example of each to further clarify the
discussed ideas.

A follow up article will use these two models to understand the competencies identified by the
IIBA in a personal context, and then to build value stream models that describe how a Business
Analyst delivers value to their customer.
Why Business Architecture?

Enterprise Architecture takes a strategic view the organisation in terms of the business functions
being executed to create shareholder value, and the IT capabilities that support those business
functions.

Business Architecture applies a set of tools and techniques to create a business-centric view of
the enterprise that supports the technical views of the enterprise derived from the Software,
Infrastructure and Information Architectures. It is a discipline that is maturing to support the
overall strategic understanding of the enterprise.

The practice of Business Architecture brings focus to improving enterprise agility, while at the
same time reducing costs. An enterprise can leverage its Business Architecture is to increase
market share (in increasingly competitive marketplaces), and to reduce unnecessary waste,
especially waste arising from the misalignment of Business and IT.
Reality Check: Achieving these lofty ambitions is a tall order.

To assist the Business Architect achieve these goals two essential business models have
emerged whose main purpose is to allow decision-makers to both visualise, and importantly to
share, their strategic view, both with each other and also the organisation at large.

Discussions that revolve around a common business model drives out a shared vocabulary. This
agreed vocabulary will, in time, address the problem of ambiguity that is so common in
organisations. Overall, we can expect that this will lead to objective decision-making that can
ultimately guide the enterprise to greater heights.

If the mission statement, vision, and specific business goals chart communicate why the
enterprise exists in the first place, then Business Architecture models describe what (“What the
Business Does”) and how (“How the Business Does It”) in the context of this strategy.

Business Architecture Defined

To start, let’s understand the definition of Business Architecture.

The OMG’s Business Architecture Special Interest Group[1] uses this definition:

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization

And Is Used To Align Strategic Objectives And Tactical Demands.

Ralph Whittle and Conrad Myrick, in their paper Enterprise Business Architecture: The Formal
Link between Strategy and Results[2], are more specific with their definition:

The [Enterprise Business Architecture] defines the enterprise value streams, their relationships
to all external entities and other enterprise value streams, and the events that trigger
instantiation. It is a definition of what the enterprise must produce to satisfy its customers,
compete in a market, deal with its suppliers, sustain operations and care for its employees. It is
composed of architectures, workflows and events.

The remainder of this article discusses capability modelling, which is the enterprise blueprint,
and value stream mapping, which describes how the business satisfies customers.

Capabilities

A business capability is an abstraction of a business function that describeswhat is being done

by the business to achieve a specific purpose or outcome.

Conceptually, a capability is a “black box” view of a business function[2], and each capability
encapsulates the people, processes and IT platforms that are needed to realise the desired
outcome, and accomplish the stated purpose.

By observing the capability as a black box we can evaluate the performance in terms of known
inputs and expected outputs, and we can make an assessment of how effective the capability is
in terms of its stated purpose.
The description of a business function, or capability, brought into view by examining its externally
visible behaviour, is tremendously stable. In contrast, observing how a business function is
delivered, seen by taking an internal view of the enterprise reveals the heady pace of change in
most businesses today.

The analysis of business function, leading to the identification of capability, must ensure that
each identified capability is unique. Discovering similar capabilities is a signal for further
investigation. Quite likely, your analysis has uncovered duplication and redundancy.

Leveraging the stability of capabilities, we organise the capabilities our analysis has revealed
into a change-resilient model of the enterprise; our enterprise blueprint. When necessary,
further analysis to decompose complex capabilities into simpler, smaller, and more purpose-
specific capabilities can be performed. Only decompose when necessary, and no sooner.

Using the model we can also investigate how the identified capabilities relate to each other. The
connections between capabilities are defined by the relationships that the capabilities have
with one and other. Capabilities that are heavily interconnected with other capabilities may prove
difficult to change, and the business architect can use this to highlight areas that pose a high risk
in the face of change.

The Business Architect uses the capability model as their blueprint for understanding
the business-at-rest.

Using the Capability Model

The diagram below presents a generic, level-1 capability model that the Business Architecture
Body of Knowledge[4] uses as an example to support its discussion on capabilities. The
capabilities have been organised into three categories according to the intent of the capability.
These categories are:

 Strategic or Direction Setting;

 Core or Customer Facing;
 Supporting.
By stratifying the capabilities according to their intent we are better able to communicate with our
stakeholders. The concepts we wish to convey using the model are simply stated, and require
little additional explanation. Meaningful discussions can be initiated quickly.

During our analysis, while we are building the model, we will decompose these level-1
capabilities into their constituent elements. We will only decompose capabilities as necessary,
and when necessary. There is a danger of getting bogged down with unnecessary over-
analysing.
Figure 1: Example Level-1 Business Capability Model

Once we have built our capability model we can mine it for information using heat mapping, and
other techniques. These methods allow us to clearly identify and better prioritise IT initiatives
(and will be the subject of a subsequent article). Breaking free of the how-trap[5] takes
practitioners beyond mere process improvement and refinement, and the what-centric view
encourages decision-makers to focus resources on those areas of their business that create the
most value.

For example, analysis can highlight capabilities that hold high-value, but are performing poorly.
These underperformers will naturally attract resources and investment over better performing, or
less valuable capabilities.

In this way the capability model becomes pivotal to achieving strong alignment between
Business and IT.

Value Streams

James Martin[6] defines the value stream as:

A value stream is an end-to-end collection of activities that create a result for a “customer” who
may be the ultimate customer or an internal “end user” of the value stream. The value stream
has a clear goal: to satisfy (or, better, to delight) the customer.
Where the capability model provides a view of the enterprise at rest, the value stream
demonstrates how business capabilities are orchestrated to deliver customer value, and value
streams[7] allow you to visualise your business in motion[8].

Customers have three basic requirements: on-time delivery of a product or service at the
right price to the expected level of quality. Value streams span the enterprise, and take a cross-
functional, birds-eye, process-centric view of how the enterprise acts to deliver on the customer
requirement. A value stream can even include external participants such as suppliers and
channel partners.

Each value-stream must align with at least one business goal, and its associated business
objectives. In this way, the business value of each stream to be objectively assessed and
prioritised during planning, and returns on the investment can be measured once the project
has delivered an IT asset.

A value stream stage is enabled by a set of capabilities. Each unique capability can be used
multiple times when doing value stream mapping, and capabilities are reused across any
number of value stream stages and appear on multiple value stream maps.

The value stream therefore acts to tie what an enterprise does to create customer value (and by
extension to grow shareholder profits) to how the enterprise actually delivers this value.

The diagram below simplistically describes a hypothetical value stream for processing a permit
application.

Figure 2: Example Value Stream

Conclusion

Building the business architecture consists of constructing strategic views of both the current
and the desired future state across all aspects of the enterprise for the purpose of planning the
transition to the desired future state.
Because the architecture models are sufficiently abstract, there is a natural inclination to focus
on the ‘big picture’, and discussions do not become mired in tactical details during the planning
sessions.

The business architecture underpins a common language for sharing strategy, and
communication amongst team members is unambiguous. There is tremendous opportunity to
drive this common language down to line managers and team leads to ensure a consistent view
of the enterprise at all operational levels.

A transparency will emerge that encourages collaboration and cooperation. The business
architecture will highlight duplication and redundancy, brings sharp focus to improvement areas,
and informs the tactical decisions necessary to improve co-operation and cohesion across all
business units.

Effectively executed, the business architecture will directly lead to enterprise agility and cost
reduction.

References
[1] OMG Business Architecture Special Interest Group. http://bawg.omg.org/

[2] Ralph Whittle, Conrad Myrick. 2004. Enterprise Business Architecture: The Formal Link between
Strategy and Results.

[3] Ulrich Homann. 2006. A Business-Oriented Foundation for Service Orientation. Microsoft
Corporation.

[4] Business Architecture Handbook version 2.0. 2012. Available from the Business Architecture
Guild. http://www.businessarchitectureguild.org/About

[5] Ric Merrifield. 2009. Rethink: A Business Manifesto for Cutting Costs and Boosting Innovation.

[6] James Martin. 1995. The Great Transition.

[7] Note: It is important to not confuse Value Streams with Value Chains. Although the terms are often
used interchangeably, they actually refer to different concepts.

[8] William Ulrich. 2011. Business Architecture-Why it Matters to Business Executives. Enterprise
Architecture Advisory Service. http://www.cutter.com