Innovative Business Process Design

April 2011

Editorial . . . . . . . . . . . . . . . . . . . . . . 2 The Parallel Universe Syndrome Practice Guide . . . . . . . . . . . . . . . . .3 Beware the New Silos! There are six primary disciplines involved in business

improvement – Business Architecture, Enterprise

Architecture, Business Process Management, Business

Capability Management, Service Oriented Application

Modernization and IT Service Management. In many

enterprises the level of coordination between the

disciplines is inadequate resulting in silos which deliver

suboptimal results for the enterprise. In this report we

explore the issues and propose a governance based

approach to balancing responsibilities, accountabilities

and managing conflicts and maturity.

By David Sprott

Practice Guide . . . . . . . . . . . . . . . .18 Innovative Business Process Design In previous reports we have advised on approaches for

modeling for business improvement and the adaptable

enterprise. In this report we return to this topic and

show by example how enterprises are innovating in

their process design to deliver significant improvements

in customer experience. They do this by going beyond

basic process modeling with capability models for

organizational intelligence. We show by example how

this model provides an integrating framework for

implementing a broad range of organizational and

technological initiatives.

By Richard Veryard

Independent Guidance for Service Architecture and Engineering

CBDI Journal © Everware-CBDI Inc. April 2011

Editorial –The Parallel Universe

Syndrome

I have become increasingly concerned that in the typical enterprise the major business

improvement disciplines operate to some extent as silos. EA is often disconnected from

Business Architecture. BPM is frequently not well connected with EA and Application

Modernization. Governance is commonly applied at discipline level rather than being

coordinated across discipline.

The term Parallel Universe comes to mind in which a hypothetical self-contained

separate reality coexists with one's own. Although strictly we should refer to this as a

Multiverse, let’s not get too technical. Think about it for a moment; disciplines are

inward looking, they have their own language, industry standards, specialists,

champions, culture and sponsors. In fact they have a significant critical mass of their

own. Furthermore we can observe standards bodies for the various disciplines

expanding their scope to encroach on the natural space of other disciplines, instead of

establishing agreed boundaries and coordination mechanisms.

Figure 1 – Example BPM Framework (Source BP Trends)

In the BPM world there appears to be a profusion of frameworks, all of which cover

similar ground, but no real convergence. I particularly liked the framework recently

published by BP Trends shown below as Figure 1. This illustrates the point perfectly –

this is centered on the BPM discipline, with a nod towards Business Architecture, and

various IT and HR stuff along the way.

Disciplines are inward looking, they have their own language, industry

standards, specialists, champions, culture and sponsors. What’s needed is

a cross discipline governance system that allows these parallel universes to

continue in splendid isolation but with minimum necessary dependencies

between disciplines defined and governed.


Other disciplines have equivalent frameworks, and they are similarly discipline centric.

No surprise here. They all use different perspectives to manage dimensions of a

common business objective. The issue is that all these frameworks need to work in a

coordinated, networked manner. But in addition to the culture, language and other areas

of difference mentioned above, they operate on different life cycles and timescales in a

concurrent but often conflicting manner frequently with very fragmentary coordination.

I don’t believe we need yet another framework to address this question. There are a

huge number of possible dependencies and interfaces, and given the heterogeneous

nature of the overall business improvement environment, it seems preferable to

encourage outcomes not techniques. What I propose is that because governance is

typically exerted for each discipline, what’s required is a set of governance review

criteria for each discipline that raises the key questions that allows the organization to

monitor and govern across discipline.

In this month’s Journal I have introduced such a cross discipline governance system. I

have suggested a simple approach which extends the widely used COBIT governance

framework. There’s no attempt to say “how” the disciplines should work together;

simply to focus attention on the outcome for the collaboration to ensure that

appropriate coordination is considered.

In this way the parallel universes can continue in relative isolation but with minimum

necessary dependencies.

David Sprott, Everware-CBDI, April 2011

Everware-CBDI – Specialists in Service Oriented Application Modernization

As specialists in service oriented application modernization, we offer a range

of consulting services and knowledge-based products to help organizations

successfully transition to a business driven, service-oriented

information technology portfolio.

Checkout the Everware-CBDI web site at:

www.everware-cbdi.com

http://www.everware-cbdi.com/


Beware the New Silos! A governance approach to coordinating the disciplines involved in business improvement There are six primary disciplines involved in business improvement – Business Architecture, Enterprise

Architecture, Business Process Management, Business Capability Management, Service Oriented

Application Modernization and IT Service Management. In many enterprises the level of coordination

between the disciplines is inadequate resulting in silos which deliver suboptimal results for the

enterprise. In this report we explore the issues and propose a governance based approach to ensuring

managed outcomes for the wider enterprise.

By David Sprott

Introduction Many enterprises are now embracing the BPM discipline. After many years in the

doldrums, the BPM market is clearly maturing rapidly. But does “market maturity”

necessarily equate to capability maturity?

Recently I was speaking with a business process analyst who briefed me on how his

company, a medium sized financial services organization, is using a leading BPMS

together with a collaboration based tool. He described how they are doing amazing

work in the business process layer, but appear to be oblivious to everything else.

They have no information architecture, no services or service architecture, no

applications and no interest from business or IT management in anything other than

delivering business processes. Everything is managed in the one platform and

organized in business process silos. He commented, “this is a major train wreck

waiting to happen!”

Perhaps this is an extreme case, but it serves to highlight a very common problem in

the BPM space. But don’t imagine that BPM is unique. After many years of strategic

commitment to SOA without effective governance, it is clear that SOA is now

mainstream for many enterprises, a mandatory architecture pattern and technology

for all projects and programs. But interpretations of SOA vary widely and it’s

extremely common to see services implemented as next generation enterprise

application integration, with minimal business based service architecture.

Similarly many enterprises struggle to find the right role for Enterprise Architecture.

The continuing debate about “what is the purpose of EA?” demonstrates that there is

profound lack of understanding or agreement throughout industry. One well known

bank set up an EA responsibility, but after a few months it was clear that business

pressure for solution delivery programs simply overwhelmed the EA effort which in

the end was reduced to a bit part player on the governance board. Is this atypical? I

think not. The core issue is that EA as practiced and as articulated in standards is too

technology focused and too procedural. And whilst enlightened EA practitioners

have promoted the idea of Business Architecture or Business Design as a parallel

discipline to EA, in most enterprises the reality is that business architecture and

design gets done in business delivery programs.

The issue is that each of these primary disciplines is required, but they need to be

coordinated to some degree. Most enterprises have business transformation and

CBDI Journal © Everware-CBDI Inc. April 2011 5

modernization tasks in process and these require the involvement of all the

disciplines if the outcome is going to be materially improved over the status quo.

There’s no sense that we require an umbrella “framework”. I suspect we have

sufficient frameworks already. Rather in this report we explore a governance based

approach to coordination in which the responsibilities for policy creation and

compliance plus inter discipline dependencies form a minimum necessary structure

for ensuring the right questions are asked, and there is clear understanding on a case

by case basis of the risk and lost opportunity which may result from isolationist

strategies.

Landscape View

Figure 1: Disciplines in the Landscape

If you have just one, isolated business process to improve or a single legacy

application to modernize, you don’t need to read further. But, if like most enterprises

you have a hugely complex landscape of business processes, services and

applications you almost certainly require some coordination across the various

disciplines involved.

Almost all business improvement and solution delivery is modernization of some

existing artifacts. Green field developments in business or IT are extremely rare. Yet

the modernization topic doesn’t seem to be a core area of interest even though in

most enterprises the existing processes and systems are the only reliable source of

knowledge about what the business does.

We advise that a modernization context saves time and money because:

It enables a reliable baseline against which improvements can be

justified and planned

IT MODERNIZATION

BUSINESS MODERNIZATION

ARCHITECTURE

Application Modernization (AM)

Enterprise

Architecture (EA)

Business

Capability

Management

(BCM)

Business

Process

Management

(BPM)

Business

Architecture

IT Service Management (ITSM)


It facilitates incremental, progressive delivery of smaller components

that reduce risk and shorten time to market for critical business

capabilities

It reduces the reinvention of core business knowledge that is central to

the way the business operates and thereby reduces risk

So, perhaps controversially, we recognize three primary tracks of distinct activity as

shown in Figure 1.

Architecture – planning, architecting IT and business, coordinating

portfolios and transition

Business Improvement – improving business processes, creating

common business capabilities

IT Modernization – rationalizing the existing application estate as a set

of IT services which offer appropriate SLAs for operation and change

Tracks Discipline Short Description

Architecture Business Architecture

(BA)

A blueprint of the enterprise that provides a common

understanding of the organization and is used to align

strategic objectives and tactical demands (OMG)

Enterprise Architecture

(EA)

A formal description of a system, or a detailed plan of the

system at component level to guide its implementation.

The structure of components, their inter-relationships,

and the principles and guidelines governing their design

and evolution over time. For a collection of organizations

that have common goals. (Open Group)

Business

Improvement

Business Capability

Management BCM)

A systematic approach to managing stable, shareable

business capabilities that enable common behaviors

across many business processes. (CBDI)

Business Process

Management (BPM)

A systematic approach to managing an organization's

business processes and workflow that enables separation

of business process and application behaviors and

increases business agility. (CBDI)

IT

Modernization

Application

Modernization (AM)

A business driven, architecture led, agile process

approach to modernizing one or more applications or a

portfolio to deliver service oriented solutions and

components that can be evolved on a continuous basis in

response to changing business needs. (CBDI)

IT Service Management

(ISTM)

The implementation and management of Quality IT

Services that meet the needs of the Business. IT Service

Management is performed by IT Service Providers

through an appropriate mix of people, Process and

Information Technology. (ITIL V3)

Table 1 – Defining Disciplines


Some comments on this landscape perspective:

This should not be viewed as a hierarchical, top down arrangement of

disciplines. The reality for most enterprises is that increasingly BPM

projects drive business modernization. The other disciplines try to

respond.

Readers will quickly spot that SOA is missing. Of course SOA is not a

discipline in its own right. SOA is an architecture style and pattern and

View. So it will be an integral perspective of the Business Architecture,

and the Enterprise Architecture. Similarly SOA will guide the efforts of

BCM and BPM. And SOA will be the underlying structure for AM and

ITSM. Figure 2 below illustrates.

Figure 2 – Disciplines in the Service Life Cycle

We recommend that Business Architecture and Enterprise Architecture

should be separate disciplines. Whilst it is perfectly reasonable for the

EA structure to include business process models the EA (at least) as

defined in the TOGAF standard is insufficiently rich to articulate the

business context to inform the other disciplines.

BCM is one of the most important aspects of modernization planning

that facilitates cross cutting capabilities which can provide

standardization of business process behaviors across multiple value

chains and business processes. Arguably BCM will kick in at higher

levels of BPM maturity, but our recommendation is that BPM efforts

will deliver far more value to enterprises if they embrace coordination

and collaboration as early as possible in their capability maturity model.

The term AM is widely used but frequently refers to conventional

legacy reengineering; often a technology centric activity. At CBDI we

use Service Oriented Application Modernization (SOAM) to better

describe business driven AM.

The overwhelming majority of BPM projects require service enablement

BA EA BCM BPM AM ITSM

Planned

Specified

Certified

Published

Operational

Retired

Being Provisioned

Provisioned

Archived


of legacy and other back end applications which frequently generate

demand for minimalist, façade based application modernization for

specific BPM projects. But the façade approach is almost certainly not a

long term solution.

The objective of the AM discipline should be to facilitate service

enablement of applications that separates business process behaviors

from applications in an architected manner that enables the application

portfolio to support common, consistent service support to all BPM

projects and to be able to continuously evolve to support the inevitable

demand for change from the business process layer. If you are still

persisting with conventional legacy reengineering it’s time to look at

AM.

Information Technology Service Management and ITIL are de facto

practices across the industry. The ITSM discipline is well placed to

effect modernization of the provided IT service. Today the industry

solution is typically Cloud deployment, and it would be easy to say that

all we need is a Cloud deployment modernization discipline. But as

most larger enterprises are discovering the reality of future deployment

architectures will be multi dimensional.

A Governance Based approach

In most organizations the relationships between the various disciplines in general, let

alone individual project instances, are commonly tenuous. The IBM Red Book

exploring just the relationships between EA and BPM1 refers to tribes! That

summarizes the problem rather well. The Red Book pursues the relatively simple

relationship between EA and BPM in a conventional manner defining all the various

deliverables that link modeling systems. I am however more than a little skeptical

that it will solve the primary issues between the two disciplines because it is

narrowly focused and mechanistic.

Figure 3 – Interrelationships Between COBIT Components

(Source IT Governance Institute)


In my report on the COBIT Framework2 last year I outlined how the highly generic

COBIT framework could be used to govern SOA based solution architecture and

delivery, and provided extensions to the meta model and classification system. One

aspect of COBIT that I found very useful was the relationships between Business

Goals and Control Objectives shown in Figure 3 below.

To coordinate the various disciplines involved in business architecture and

modernization I recommend a governance approach in which the key Control

Objectives for each discipline that support integrity of inter discipline relationships

are the basis for ensuring integrity of the overall coordination.

The Control Objective is a governance review criteria. In project practice this will be

supported by detailed deliverables, but we don’t need to itemize these in order to

show all the dependencies between the disciplines. This provides us with a

meaningful and communicable view of cross discipline interrelationships.

To manage the governance process the incremental Control Objectives can be added

to existing Control Objectives and managed through existing governance practice.

The governance reviews need to be executed on a discipline by discipline basis

triggered by discipline / phase activity.

Using and extending the COBIT framework for our purposes will, in many

enterprises, be seen as very supportive of existing governance practices and reduce

friction in the areas of adopting new governance criteria.

Control Objectives In this section I set out Control Objectives for each of the Disciplines discussed

above. For each discipline I outline business goals that should drive inter discipline

relationships. I then map key Control Objectives that govern inter discipline

relationships and show examples, plus coordination requirements. I don’t pretend this

is exhaustive, but hopefully it’s a good template and starting point.

The interrelationship aspect is crucial to governance across the disciplines. The intent

is that the Control Objectives form key governance criteria for each discipline that,

together with the identified coordination with other discipline(s) provides a coherent

approach that should optimize the enterprise view in the most efficient manner.

Discipline: Business Architecture

Control Objectives that can be utilized regardless of how the disciplines are

organized, with BA as part of EA or standalone.

Business goals relevant to BA cross discipline control might address:

Adequacy of business strategy

Business standardization – goals that rely on consistent business process

and information such as customer satisfaction, cross channel behaviors,

competitive business intelligence and so forth. And conversely . . .

Business diversity – goals that rely upon freedom of action in innovation

areas, loosely coupled parts of the business that are perhaps candidates

for divestiture as well as cash cows where business improvement is low

priority.


Business morphology – goals that influence the structure and shape of

business. Strongly linked to business loose coupling, these goals may

relate to business components that may be more easily outsourced, or

capabilities that deliver cross division, LoB and geography to achieve

goals such as regulatory compliance or centralization to achieve

reduction in headcount or costs.

Control Objective Type Examples Coordination required

Business strategy is articulated

sufficient to guide primary

delivery projects and programs

Context business components

will be outsourced

Core business components will

be enterprise standard

Architectural response by EA

Project goals, scope and strategy

response by BPM and AM

projects

ITSM response on scope of IT

services

Standardized business model

components modeled and

defined

Consistent behaviors for certain

business types

Policy governing

implementation approach

defined in EA and complied with

by BPM, AM and ITSM

Standalone business

capabilities identified

Candidate for outsourcing and or

offshoring

Candidate for replication for

scalability or risk reduction

Policy governing

implementation approach

defined in EA and complied with

by BCM and BPM implemented

in AM and ITSM

Compliance requirements

defined for (industry standard)

semantics

Support for partner ecosystem

and or channel strategy

Business process standardization

EA defines information and or

transformation architecture

Compliance with defined aspects

of Information Architecture by

BPM, BCM, AM

Key KPIs defined for major

processes (value chains)

Number of complaints

Average <claim, trade, . .>

handling cost

% add-on business

Architecture and design response

from BCM, BPM

Service architecture and design

response from AM including

schema support

SLA response from ITSM

Table 2 – Example BA Control Objectives

Discipline: Enterprise Architecture

In most enterprises EA is responsible for determining the enterprise context for

solution and BPM delivery projects and managing the portfolio view. This means

setting policies for architecture work, establishing reference architecture and

identifying those elements of all architecture views that are enterprise standards such

as capability and core business services, technology and deployment components and

so forth.


Whilst EA will typically establish requirements for architecture governance, in a

cross discipline environment it is also important that the other disciplines accept the

enterprise policies and architecture as relevant to discipline delivery. A governance

forum is an appropriate mechanism to improve coordination between EA and the

other disciplines.

The business goals relevant to cross discipline EA Control Objectives may include:

Prioritized focus on principles that support key business strategies

Loose coupled business

Alignment of IT services with strategic business context

Establishing architecture that enables continuous evolution of business

capability with appropriate response time to defined classes of change

by domain

Business sourcing strategy

Conformance with specific business governance requirements, such as

business security and threat containment, regulatory requirements,

knowledge and intellectual property management, management of third

party relationships etc.


Architecture principles reflect

business strategy needs

Services and components will

map to key business concepts

that support consistent behaviors

for mission critical, core

business processes across all

channels, LoB and geographies.

Common enterprise data and

information architecture

supporting above.

Evolutionary architecture in

support of innovating business

processes.

Alignment between BA and EA

Compliance by all disciplines

Reference model and

architecture establishes

consistency of approach and

reusability of standard

components relative to

a) strategic business context

b) type of sourcing

Component types by layer for

logical, implementation,

technology and deployment

architecture mapped to strategic

grid

Reference business process

architecture mapped to strategic

grid

Contract formats for services,

components and IT services.

Development of EA overlays to

support specific business and

sourcing contexts as requested

by BA/BPM/AM

Compliance by BPM, BCM, AM

and ITSM



Key planning and architecture

policies approved

Architecture layer patterns

Commoditization patterns

Sourcing Type by layer and

component


and ITSM

Architecture governance

process defined

Architecture and delivery phase

end deliverable templates


and ITSM

Common enterprise service

architecture contracts mirror

business contracts

Orders Capability Service is a

business service and a technical

interface

Alignment with BA, BCM and

BPM

Conformance by AM and ITSM

Common enterprise

component architecture meets

objectives for loose coupled

Business Types

Information and Semantic

Architecture

Common application platform

architecture for various layers

Service exception architecture

Common Technology

Architecture

Common Security Architecture

Alignment with BA, BCM and

BPM

Compliance by BPM and BCM

Implementation and compliance

by AM and ITSM

Enterprise portfolio and

transition plan supports

business priorities for

continuous business evolution

Service Portfolio Plan

Transition Engineering Plan

Aligned with BA priorities

In conjunction with ITSM

Change SLAs

Continuous feedback of portfolio

asset status from BPM, BCM,

AM, ITSM

Table 3 – Example EA Control Objectives

Discipline: Business Process Management

As discussed, whilst BPM projects are generally the primary drivers for business

improvement, they need to be coordinated with all other disciplines.

The business goals relevant to cross discipline BPM Control Objectives may include:

End to end business processes or cross ecosystem business processes

Support for radical changes in business model(s) and new KPIs

Process improvement including increased productivity and quality of

service, lower operating costs and faster cycle times

Improve ongoing flexibility of business processes



Business process explicitly

supports business strategy

Business process supports new

business model with new KPIs

Alignment with BA

Business process is part of a

coherent process portfolio

Business processes not

confined to existing

organization structure

BPM projects collaborate in

delivering consistent end to

end business process support

Between BPM projects to establish

interaction and interfacing

With BA for cross functional

perspective

With EA to ensure use of common

reference architecture and

components

Business process reuses

standard elements – business

process components and

business capabilities as

appropriate

Common Ordering Process

capability used across many

lines of business and

geographies

With EA to signal demand for

common components and to

feedback asset reuse

With ITSM to reuse standard IT

services

Business process is designed

to continuously evolve to meet

demands of changing business

Managed dependencies limit

horizon of change

Componentized business

process design

Strict enforcement of BPM

architecture layering

Generic designs where

appropriate

With BA to drive out future

perspectives

With EA to develop agile

architecture, generic components,

customizing platforms etc

With EA to minimize

dependencies

With AM to commission

generalized, constantly evolving

services and to minimize change

cycle time

With ITSM to establish contracts

for IT Service change cycle time

Business process reuses

standard enterprise services

Common customer service

enforces common behaviors

across all customer contacts

throughout all business

processes

With BA to understand strategy for

consistent business process

behaviors

With EA to signal demand for

standard service or feedback asset

reuse

With EA to develop platform

strategies for embedding consistent

behaviors into processes and

concurrently enabling localization

With AM to enable reuse and

potentially to evolve standard

service and or introduce

localization



Business process uses

common reference process

architecture and template.

Enterprise standard BPMS

practices, technology,

templates, components

With BA to understand

requirements for enterprise

consistency or innovation

With EA to adopt standard

reference process architecture

With ITSM for standard SLAs

implicit in standard reference

architecture

Table 4 – Example BPM Control Objectives

Discipline: Business Capability Management

Business capabilities are generally intended to implement standard behaviors across

an enterprise, although it is perfectly possible that certain capabilities may be limited

to specific domains, divisions or product groups.

There is a natural tension between BCM and BPM insofar as business capabilities

will usually encapsulate business process components as well as application

functionality. This will require coordination right from the outset in development of

the BA such that the embedded processes are clearly demarcated from other free

standing business processes.

The business goals relevant to cross discipline BCM Control Objectives may include:

Segregating context behaviors for use of a standard COTS package

Segregating context behaviors for use of a BPO

Segregating core or context behaviors with standalone deployment for

outsourcing and or cloud deployment

Standard capability behavior is mandatory

Standard capability behavior is mandatory but localization by extension

is encouraged to meet situation specific behavior needs.


Business capabilities are

designed to be extended for

local behaviors whilst

maintaining the integrity of

standard enterprise behaviors.

Customer support capability

facilitates extension for

varying product group

requirements

Compliance with common

capability behaviors defined in the

BA

Coordination with EA policy on

capability extension platform stack

Business Capabilities are

enterprise standards

Customer, Risk, Regulatory

Compliance, Customer

Support, Authentication . . .

Embedded business process

components defined in the BA to

ensure separation from free

standing business processes

Architecture defined in EA

AM provides standard interface

contract

Standard ITSM SLA



Business Capabilities are

genuinely standalone

Manufacturing capability

encapsulates all layers of stack

including business process,

application and technology.

Deployment architecture is to

Cloud with explicit

agreements that facilitate

rehosting

Coordination with AM and ITSM

to ensure minimum necessary

dependencies

Capability behavior is

encapsulated.

Communications with offered

capability services are entirely

through the capability service

interface. All physical

attributes and behaviors are

hidden from consumer.

ITSM to cover technology and

manual activities and resources

Capabilities are single

business functions (or

components) that may be

assembled into composite

applications or business

processes.

Shipment capability may be

composed into Orders to Cash.

Defined in EA

Coordination with BPM for

business process design.

Coordination with AM for

composite delivery

Coordination with ITSM for

composite SLA

Table 5 – Example BCM Control Objectives

Discipline: Application Modernization

The key feature of AM is the transformation of the application portfolio to a set of

components and services that will facilitate continuous evolution. Smaller units of

deployment that map well onto the service architecture and by inference business

components.

The business goals relevant to cross discipline AM Control Objectives may include:

Reduce unit cost of delivery

Ensure service can meets business needs for response to change by

continuous evolution

Retention of business knowledge


Solutions deliver services for

specific solution(s) but within

enterprise framework

Retail channel specific

Customer service is designed

to be evolved over several

iterations to support multiple

channel behaviors.

Coordination with EA and BA for

vision of endpoint goal for generic,

differentiated service.

Coordination with ITSM for

version availability

Leverage and protect existing Where relevant ensure

stability of business model by

With BA to understand where



business knowledge reusing existing knowledge

Deliver comprehensive

knowledge together with

solution and services

business model is changing

With EA to align with new

information architecture

With BA to align with business

process rules

With ITSM to include knowledge

as a key deliverable

Modular, portable, cloud ready

services and components

Solutions, services and

components designed to

minimize dependencies,

reduce deployment horizon

where appropriate

Enable minimum effort to

rehost

With EA to align with enterprise

technology and deployment

architecture

With ITSM to establish operational

and change SLAs

Integrated into service and

component portfolio

Twin track approach to AM

separates out service from

solution delivery. Service

delivery is usually evolving

the Service Portfolio Plan

(SPP)

With EA to align with SPP,

implementation architecture and

feedback asset status

With ITSM to provide SLAs

Deliverables include services,

components and solution(s)

plus designs and processes for

continuous evolution

Designed for low horizon of

change to enable narrow focus

units of deployment.

Work Breakdown Structure

common to Deliver and

Evolve Phases

Aligned with BA business

components and heat maps for

areas of volatility

Aligned with Change SLA in

ITSM

Business capabilities

implemented as standalone

components and encapsulated

services

Private stack Coordinated with ITSM for

separate deployment and

virtualization

Table 6 – Example AM Control Objectives

Discipline: IT Service Management

Service architecture is by definition a contract based environment. A key business

goal is generally to establish high levels of separation between component, services

and layers of the stack. The AM discipline delivers the technical interfaces; the ITSM

manages the usage and life cycle contracts for composite IT services that ensure the

goals of separation are achieved at realistic cost.

The business goals relevant to cross discipline ITSM Control Objectives may

include:

Dynamic reporting of business performance data

Faster response to business change


Reduced lock-in to suppliers at all levels of the stack


SLA reports support KPI

requirements

Average time and cost to

handle claim

Alignment between SLA reports

and BA, BPM, BCM KPI reporting

requirements

Delivered IT Services have

functional change SLA for

relevant granularity

components

Services classified for

functional change (upgrade)

response time

Change SLAs agreed with

consuming BPM, BCM projects

Delivered IT Services have

non functional change SLA

Services classified for non

functional change response

time. E.g

- scalability

- change of host

Change SLAs agreed with

consuming BPM, BCM projects

SLA reports support KPI

requirements

Average time and cost to

handle claim

Alignment between SLA reports

and BA, BPM KPI reporting

requirements

Table 7 – Example ITSM Control Objectives

Summary and Conclusions

Each of the primary disciplines involved in business improvement have a high

internal critical mass which may encourage isolationism. Interrelationships may be

competently established on a one to one basis. But if this is done in a tactical manner,

the communications will be narrowly focused on deliverable and data exchange, and

may ignore the bigger picture.

The governance approach outlined in this report, particularly in conjunction with

some form of cross discipline governance body, can provide assurance that due

diligence has been carried out in delivering optimum outcomes for the wider

enterprise. Further this is a lightweight process, with low overheads placed on the

disciplines, that can shine spotlights on areas where more attention needs to be given

to particular issues.

From my observation of numerous corporations and government departments, a cross

discipline governance system is badly needed, and in many situations could be

rapidly demonstrated as bringing considerable benefit.

1 Reference IBM Red Book – Combining BPM and EA

http://www.redbooks.ibm.com/abstracts/sg247947.html?Open

2 Using the COBIT Framework for SOA Governance, CBDI Journal, May 2010

http://www.redbooks.ibm.com/abstracts/sg247947.html?Open


Best Practice Report:

Innovative Business Process Design

Going beyond basic process modeling for enhanced customer experience In previous reports we have advised on approaches for modeling for business improvement and the

adaptable enterprise. In this report we return to this topic and show by example how enterprises are

innovating in their process design to deliver significant improvements in customer experience. They do

this by going beyond basic process modeling with capability models for organizational intelligence. We

show by example how this model provides an integrating framework for implementing a broad range of

organizational and technological initiatives.

By Richard Veryard

Introduction

As transaction-oriented IT becomes increasingly commoditized and virtualized, any

competitive advantage from IT must come from its support for business innovation and

organizational intelligence. In this article, we shall explore how business improvement

in today’s world demands innovative business process design.

Strategic Advantage and Differentiation

There are two important differentiation questions for any organization with critical

relationship with external stakeholders (such as customers): how do They differentiate

Us, and how do We differentiate Them.

Firstly how do They differentiate Us. In other words what differences in our products

and services or organization are (a) going to be noticed by external stakeholders such

as customers and (b) going to affect the behaviour and attitudes of these stakeholders.

Sophisticated marketing organizations pay a lot of attention to this kind of thing. Does

it make a difference if we put this in a blue envelope? Does it make a difference if we

have a female voice here? Sometimes you have to experiment with differences that

don't matter, in order to have a refined view of what differences do matter. So

intelligence involves an important feedback loop through Decisions and Learning.

Secondly, how do We differentiate Them. What are the strong signals in the

environment that we must respond to, and what are the weak signals we might respond

to? An organization that responded to every weak signal would be impossibly unstable,

so most organizations have operational processes that respond to strong signals, and

We explore examples of how complexity can be managed and show

how to give the organization more power to operate effectively in a

complex demand environment.


some form of business intelligence that scans the environment for weak signals and

identifies a subset of these signals demanding some kind of response.

Differentiation and Context

The CBDI Forum identified Differentiated Services as a key pattern of advanced SOA

as long ago as 2002. We have looked at a number of dimensions of differentiation,

including identity, presence and context, and discussed how businesses in such sectors

as retail have created value for themselves and their customers by progressive

differentiation.

An enterprise may differentiate its customers (and their behavior and intentions)

according to a number of factors, with greater or lesser granularity.

Zero variation. No differentiation between customers. One size fits all.

Fixed segmentation. The enterprise identifies a number of (fixed) market

segments, and assigns each customer to the appropriate segment.

Dynamic deconstruction. Differentiation based on the detailed actions and

inferred intentions and context of customers.

Each degree of differentiation increases the range and scope of supported behaviors,

and therefore affects the overall complexity of the process1. Under the right conditions,

increased differentiation may produce better outcomes for the enterprise and its

customers. Under the wrong conditions, differentiation merely adds complication,

increases cost and risk, and may produce worse outcomes.

From a business process design point of view, we are searching for different contexts.

Understanding the range of contexts is critical for business agility – because each new

context introduces some degree of variation (differentiation) that adds value to the

process for that context2.

Business Intelligence and Differentiation

With business intelligence, we have the opportunity to select the most relevant forms of

differentiation, based on statistical analysis of characteristic features. In many

situations, what the business really wants is to use the past to predict the future. We

only want to differentiate customers based on their past buying patterns if this provides

a good predictor of their future buying patterns.

When I lived in Central London, I sometimes used to visit a hairdresser on the King’s

Road in Chelsea, The King’s Road is full of hairdressers, and the staff would stand in

the street handing out leaflets to likely customers. When I was walking towards my

hairdresser, I would walk past several of these touts, but I wouldn’t be recognized as a

potential customer because I didn’t have a smart haircut. After my hair was cut, I

would be given loads of leaflets because I then fitted their preconception of what a

customer looked like – but of course I didn’t then need a second haircut. This is the

kind of stupidity trap that many backward looking sales operations fall into – trying to

sell lawnmowers to people that already have lawnmowers.

Business intelligence helps us find alternative differentiators. What are the

characteristic features of someone who needs a haircut, or might buy a lawnmower?

We can then differentiate the services based not on a fixed set of differentiators, but on

a current (and periodically updated) set of differentiators, and we constantly review the


predictive power of these differentiators. (This means that the underlying business type

model now needs to be constructed at the meta level, with DIFFERENTIATOR and

CHARACTERISTIC FEATURE as business types.)

Retail Example – Amazon

In our articles about business modelling, we have described the progressive

differentiation that can be observed in certain industries. For example, over the past

decade or so, retailers have progressively increased their ability to differentiate

customers according to buying history and other contextual information.

The introduction of the loyalty card represented a radical strategic shift for the large

retail chains. Stores now had a formal basis for recognizing a customer as the same

again. They can identify customers, and collect and analyze data about the behavior of

specific customers. And they can use this analysis to differentiate the response to

different customers. For example, different customers may receive different special

offers.

Obviously if the retailer can identify the customer as she enters the store, then this

differentiation can be done as the customer browses, rather than only when the

customer comes to pay. This is relatively easy to implement with online shopping (for

example through the use of cookies); and there are various mechanisms (smartphone,

face-recognition software, RFID) that might achieve the same result in a physical store

if the obvious privacy concerns can be allayed.

For example, if there are RFID chips on the goods and RFID scanners on the shelves

and in the shopping trolley, then the customer can be presented with information based

on the stuff that is already in the shopping basket. This capability is very easy to

implement for online shopping, and this stimulates retailers to build an equivalent

capability for physical shopping.

The service we get from supermarkets is fairly simple, so perhaps there isn't much

scope for variation. But each customer may get a different set of special offers, and this

can be generated dynamically, according to the contents of the shopping basket or the

path through the store. A customer with a known taste for raw eggs, or a history of

returning stale products, may get a warning that a selected product is close to expiry.

Amazon is of course well-known for its pioneering work in providing targeted

information and deals based on a customer’s browsing and buying history, and creating

new forms of associative information which may be reflected back to the customer. But

even Amazon could possibly go further in differentiating all aspects of the supply

chain, in order to maximize value for the customer and for itself. For example, we

recently heard a complaint from an Amazon customer about the delivery process that

required the customer to pick-up the parcel after failure to deliver, for an item that was

actually small enough to slip through the letter-box. In this particular instance, in other

words, Amazon seems to have failed to have built sufficient differentiation into its

delivery process. (Perhaps we have higher expectations of companies like Amazon: the

appalling lack of differentiation we experience from most other service companies is

quite scandalous.3)

Library Example


Some business people think of differentiation purely in terms of targeted advertising.

But it is also important to think of ways that an organization can serve its customers

better (not just target them better) through an awareness of their context. This is

intrinsic differentiation - in other words, differentiation that is relevant to the service in

hand.

Let us consider libraries. A few years ago, my son did a school project on a

mathematician of his choice. He chose Florence Nightingale (the inventor of the pie

chart). If he had gone into a library for help, would he have been offered a scholarly

history of the Crimean War or an academic thesis about mortality statistics and their

graphical representation? Maybe that depends whether he talks to a human librarian or

uses the computer.

Can a computerized system offer anything approaching the sensitivity and common

sense that we still expect from a human librarian? At one extreme, there are

standardized search systems, which will give you exactly the same answer whether you

are a schoolchild or a BBC researcher or an LSE postgraduate. At the other extreme,

there may be inflexible classification systems, which assume that a child is only

interested in reading books that are designated suitable for that age group.

One of the most important aspects of context is how the service fits into what the

consumer (the customer, the library reader) is trying to do. Do I have an essay or

article or thesis to write, and when is it due? Am I reading Nietzsche because I am

learning German, or because I am learning existentialism (or both)? Am I reading

Bede because I am studying history or historians (or both)? Does it make sense to read

Locke without also reading Hume? What stage of my learning have I reached? Do I

need an edition with glossary, with scholarly notes, with English translation facing?

What is my preferred style of learning, my preferred style of researching a topic?

Surely questions like these are relevant to improving the service offered by a library to

a particular reader?

Ultimately, context-awareness takes us down a path of embracing user diversity. Not

just user semantics, but user pragmatics. How much of the reader's context can the

library possibly deal with, and what other service providers might the library

collaborate with? There are some seriously complex models here.

Context-awareness introduces some significant challenges to many organizations -

introducing modes of complexity that they have never dealt with before - but with the

potential reward of offering massive improvements to the experienced quality of

service.

Coordination and Intelligence

Effective differentiation is a function of the intelligence embedded within the customer

management capability. The greater the “quantity” of intelligence, the greater the

capacity to differentiate effectively. See Box below.

Success Factors of Effective Differentiation

Focus on the most relevant differentiators.

Sufficient range of responses to differentiators.

Coordination between variety of perceived differentiation and variety of

response.


Feedback loops to improve relevance and accuracy of differentiation.

Feedback loops to refine responses.

Progressive elimination of unnecessary or irrelevant complication, along with

exploration of new opportunities.

Retail Example – Supermarkets

Many organizations are increasingly facing multi-sided markets, and the need to create

indirect value as well as direct value. They must differentiate and innovate in a number

of different process areas simultaneously. The critical capability here is the

coordination between these process areas. Let’s explore this using a retail example.

Let’s start by dividing a retail operation into a number of discrete capability areas, each

focusing on a discrete domain of interest. Each capability area can then be managed

semi-autonomously.

Figure 1 – Example Capability Areas in Retail Operations

(We may compare alternative ways of decomposing the retail operation according to

the independence of each chunk, and how much coordination is required. Any given

decomposition leaves some cross-cutting concerns. Many architects skip this step, and

base their models uncritically on the most obvious decomposition, without exploring

alternatives.)

Within each capability area, we have a potential trade-off between the economics of

scale and the economics of scope. For example, simple economics of scale within

product management suggest stocking large quantities of a very small number of

products from a small number of suppliers to obtain maximum discounts and minimum

transport costs. However, this conflicts with the need within product management to

offer a broad range of products (economics of scope).

There are also trade-offs between capability areas. For example, a simplistic approach

to the economics of scale within product management will conflict with a simplistic


approach to the economics of scale within store management. In practice, it is

impossible to optimize all these economic factors simultaneously. So we need a

coordination mechanism that allows for a reasonable accommodation between these

semi-autonomous areas, illustrated in Figure 2, as well as a sense of the economic and

organizational cost of this coordination.

For example, suppose a supply-side manager negotiates a deal with a key supplier,

which specifies a favourable display position for that supplier’s products. This deal

may then inhibit our ability to vary the display arrangements, even if this variation

could improve the customer experience and increase total spending. Most importantly,

if we fail to experiment regularly with alternative display arrangements, we won’t have

enough data to calculate the true value of a given display arrangement, and therefore to

estimate whether a given supply-side deal carries an unacceptable opportunity cost (in

terms of lost sales for other products).

Figure 2 – Coordinating Semi Autonomous Capability Areas

Design Questions

What are the events and information flows that help to join up the retail

operation as a whole?

Where is the strategic knowledge of the enterprise located, and how is it

continuously developed and effectively used?

What are the mechanisms to support innovation and organizational learning?

There are many different pathways for joining-up the business. Think for example how

a supermarket manages a single product – a jar of organic baby food. This product has

many different associations, each of which has some coordination and integration

implications as shown in the Table below.

Coordination with other jars

(pasta sauce)

Often supplied by the same manufacturers.

Similar patterns of shelf life and shelf management.

Similar handling requirements.


Coordination with other baby goods Bought by the same customers.

Coordination with other organic produce Bought by the same customer demographic.

Table 1 – Example Product Associations Requiring Coordination

How are these different associations managed? The traditional approach is to regard

one of these associations as primary, and to construct processes and hierarchical

organization structures around the primary association – for example, product line

management. Some organizations complicate this approach by attempting various

forms of matrix management, but this is typically an unsatisfactory compromise that

still fails to deal with all the associations and pathways properly. Furthermore, when

these associations are hard-coded into the organization structure, even tactical change

in product management necessitates major organizational change – and there are some

organizations that undergo this kind of reorganization alarmingly frequently.

An adaptable enterprise needs to have a more dynamic way of managing a broad range

of these associations and pathways. Each of these pathways may be associated with a

different capability area, and mobilizes a different kind of intelligence.

Systems, Services and Technology

There are several technologies that help to support the intelligent real-time enterprise,

including business intelligence, complex event processing, business process

management, knowledge management and enterprise social networking (“Enterprise

2.0”). Within the enterprise, these technologies are typically at different stages of

adoption and maturity, and there are interesting developments within each area. The

key question for us here is how these technologies and tools can be combined to solve

more interesting and complex business problems.

In our work on service-oriented business intelligence, we have talked about closed-loop

business intelligence – management feedback loops that operate at real-time or near-

real-time. We are already seeing an interesting convergence between business

intelligence and complex event processing.

Figure 3 – Closed Loop Business Intelligence Model


Much of the experience with Complex Event Processing (CEP) tools has been in

tracking real-time operations. For example, telecommunications companies such as

Vodafone can use complex event processing to monitor and control service disruptions.

This is a critical business concern for these companies, as service disruptions have a

strong influence on customer satisfaction and churn. CEP is also used for autodetecting

various kinds of process anomalies, from manufacturing defects to fraud.

When coordinating between different business processes, each process may operate on

a completely different tempo. With customer complaints, for example, replying to the

customer is either instant or within hours/days (and a product recall for safety reasons

would probably operate on a similar tempo), whereas the feedback loop into product

design probably takes weeks or months - in other words, a much slower tempo.

Business Process Management itself has several nested feedback loops, each operating

at a different tempo.

A modeling and discovery tempo, in which the essential and variable

elements of the process are worked out. Oftentimes, full discovery of a

complex process involves a degree of trial and error.

An optimization and fine-tuning tempo, using business intelligence and

analytics and simulation tools to refine decisions and actions, and improve

business outcomes.

An execution tempo, which applies (and possibly customizes) the process

to specific cases.

The events detected by CEP can then be passed into the BPM arena, where they are

used to trigger various workflows and manual processes. This is one of the ways in

which CEP and BPM can be integrated.

Social software and Enterprise 2.0 can also operate at different tempi - from a rapid and

goal-directed navigation of the social network within the organization to a free-ranging

and unplanned exploration of business opportunities and threats. Social networking

platforms (such as TIBCO's new product tibbr®4) can be organized around topics,

allowing and encouraging people to develop and share clusters of ideas and knowledge

and experience.

The organization of Enterprise 2.0 around topics appears to provide one possible way

of linking with CEP and BPM. A particularly difficult or puzzling event (for example,

a recurrent manufacturing problem) can become a topic for open discussion (involving

many different kinds of knowledge), leading to a coordinated response. The discussion

is then distilled into a resource for solving similar problems in future.

A critical success factor for organizational intelligence is "contextually relevant

information", and this provides a common theme across all of these technologies. It

helps to think about the different tempi here. In the short term, what counts as

"contextually relevant" is predetermined, enabling critical business processes and

automatic controls to be operated efficiently and effectively. In the longer term, we

expect a range of feedback loops capable of extending and refining what counts as

"contextually relevant".

On the one hand, weak signals can be detected and incorporated into

routine business processes. Wide-ranging discussion via Enterprise 2.0 can

help identify such weak signals.


On the other hand, statistical analysis of decisions can determine how

much of the available information is actually being used. Where a

particular item of information appears to have no influence on business

decisions, its contextual relevance might need to be reassessed.


Social Media (Systems of Engagement)

Recent work in the Content Management domain distinguishes between Systems of

Record (focused on transactions) and Systems of Engagement (focused on

interactions). In a recent white paper Systems of Engagement and The Future of

Enterprise IT : A Sea Change in Enterprise IT (AIIM 2011), Geoffrey Moore identifies

this as a major shift of emphasis in IT. According to Moore, this shift is necessary

because most organizations are dependent upon suppliers or distributors or partners to

deliver their fundamental value proposition to their customers.

(Of course, these challenges aren't just for commercial organizations. Public sector

organizations are under just as much pressure to deliver value, even if this pressure is

transmitted politically rather than commercially.)

They also raise key architectural issues, especially in managing the join between formal

systems and informal systems. For example, enterprise social media can be organized

around business topics. The particularly difficult or puzzling example event mentioned

above (the recurrent manufacturing problem) is a good example of this. The discussion

around the topic leading to the coordinated response may be distilled into a resource for

solving similar problems in future. A business topic can be modeled as a social object5-

efficient and effective integration between transaction systems (Systems of Record)

and intelligence systems (including Systems of Engagement) requires a simple and

flexible model of such social objects, and a clear understanding of the identification

and granularity of these objects.

Conclusion and Key Actions

In this article, we have explored how complexity is (can be) managed in a real

business. The agenda here is not to eliminate complexity but to respect and leverage it

– giving the organization more power to operate effectively in a complex demanding

environment. For improving organizational intelligence, there are several key actions

for architects, as shown in Table 2 below.

Aspect Purpose Artefact

Granularity Enabling the organization to identify more precisely and

respond more flexibly and appropriately to a finer level of detail

and differentiation.

Business Concept Model

Business Type Model

Sense and

Respond

Defining the set of events that the business processes can

respond to.

Event Model

Business Process Model

Feedback

Loops

Building a closed improvement and learning loop into each

business process.

Business Process Model

Coordination Establishing coordination and intelligence capabilities between

multiple strategic processes.

Business Capability Model

Platform Establishing a joined-up platform (including business

intelligence, business process management, knowledge

management and social networking) to enable managers across

the organization to collaborate and innovate effectively.

Technology Architecture

Table 2 – Key Actions for Architects


References

Some of the ideas presented in this article have been mentioned in previous articles.

Business Flexibility (CBDI Journal, June 2002)

Web Services to improve Business Intelligence (CBDI Journal, June 2003)

Service-Based Business – Insurance 2 (CBDI Journal, December 2004)

Service-Oriented Business Intelligence (CBDI Journal, October 2005)

Business Modeling for SOA (CBDI Journal, January 2006)

Towards the Agile Business Process (CBDI Journal, July 2007)

Web 2.0 and Enterprise Architecture (CBDI Journal, November 2007)

Event-Driven Service Architecture (CBDI Journal, February 2008)

1 Process complexity informally measures the difficulty of describing and executing a

process. See for example Howard, Rolland and Qusaibaty, Process Complexity, INFOS

2004. http://www.cs.rmit.edu.au/~jah/cats09/papers/cats2009_submission_41.pdf

2 The ability of a system to respond appropriately and flexibly to the variety in the demand

environment is known as requisite variety. The greater the complexity and turbulence of

the environment, the greater the value of this variety. The challenge for the enterprise is to

manage this variety efficiently, and to focus on those variables that have the greatest

potential contribution to business value.

3 See my review of the Support Economy, CBDI Journal July 2004. Also available at

http://rvsoapbox.blogspot.com/2005/01/support-economy.htm

4 Tibbr® http://www.tibbr.com/

5 The concept of social object was introduced by Jyri Engeström, and has been developed

by JP Rangaswami and others.

http://www.cs.rmit.edu.au/~jah/cats09/papers/cats2009_submission_41.pdf

http://rvsoapbox.blogspot.com/2005/01/support-economy.htm

http://www.tibbr.com/


About CBDI

CBDI Forum is the Everware-CBDI research capability and portal providing independent

guidance on best practice in service oriented architecture and application modernization.

Working with F5000 enterprises and governments the CBDI Research Team is

progressively developing structured methodology and reference architecture for all aspects

of SOA.

CBDI Products

The CBDI Journal is freely available to registered members. Published quarterly, it

provides in-depth treatment of key practice issues for all roles and disciplines involved in

planning, architecting, managing and delivering business solutions.

Visit www.cbdiforum.com to register.

Platinum subscription – A CBDI Forum subscription provides an enterprise or individual

with access to the CBDI-SAE Knowledgebase for SOA delivering ongoing practice

research, guidance materials, eLearning, tools, templates and other resources.

Everware-CBDI Services

At Everware-CBDI we enable large enterprises and governments to become more agile by

modernizing their business systems. We have repeatable processes, resources, tools and

knowledge-based products that enable enterprises to transform their current applications in

an efficient, low risk manner, into an optimized service-based solutions portfolio that

supports continuous, rapid and low cost evolution. Our consulting services range from

providing practices and independent governance to architecture development, solution

delivery and service engineering.

Contact

To find out more, and to discuss your requirements visit www.everware-cbdi.com or call

USA and Americas: 703-246-0000 or 888-383-7927 (USA)

Europe, Middle East, Africa, Asia, and Australasia: Telephone: +353 (0)28 38073

(Ireland)

www.everware-cbdi.com

IMPORTANT NOTICE: The information available in CBDI publications and services, irrespective of delivery channel

or media is given in good faith and is believed to be reliable. Everware-CBDI Inc. expressly excludes any representation or

warranty (express or implied) about the suitability of materials for any particular purpose and excludes to the fullest extent

possible any liability in contract, tort or howsoever for implementation of, or reliance upon, the information provided. All

trademarks and copyrights are recognized and acknowledged. The CBDI Journal may be distributed internally within

customer enterprises that have current corporate subscriptions. Otherwise CBDI Journals may not be copied or distributed

without written permission from Everware-CBDI.

http://www.cbdiforum.com/



Innovative Business Process Design

Documents

Transcript of Innovative Business Process Design