GRADUATE PROJECT ONTECHNOLOGY MANAGEMENT

by

Dimitris Kosmidis

A thesis submitted in partialfulfillment of the requirements

for the degree of

MSc in Management ofBusiness, Innovation and

Technology (MBIT)

Athens Information Technology(AIT)

Sep. 30, 2008

Approved by Gregory S. YovanofChairperson of Supervisory

Committee

___________________________________________________

___________________________________________________

Program Authorized to Offer Degree MSc in Management of Business, Innovation and Technology (MBIT)

Date _________________________________________________________

Athens Information

Technology (AIT)

Abstract

END-2-END BUSINESSPROCESS INNOVATION

by Dimitris Kosmidis

Chairperson of the Supervisory Committee: ProfessorGregory S. Yovanof

MBIT

Pure innovation always embraces new ways of thinking about

products, services, processes and solutions. Sole innovation

undoubtedly has value but it is questionable if it “makes or

breaks” companies in today’s diverse global environment and

segmented business ecosystems.

Adoption of widely accepted industry standards may well

lead organizations to a kind of holistic “business excellence”

through lean operations and streamlining of activities.

Sometimes this is seen as panacea to survive. Nevertheless,

it should be noted that business agility seems to be the

critical factor to facilitate business excellence in such a way;

so to serve the unspoken mission of a long-term strategic

advantage, while at the same time secures the obvious goal

of profitable growth.

This paper questions numerous aspects of today’s business

reality, in an industry wide and locality neutral way. We are

consciously concluding to acknowledge and actually praise

the “culture of innovation”, as it may be seen in many

respected “living organizations”. We eventually argue for the

nature, necessity and application of considerable business

aspects, leveling from the “Idea Capturing”, to Business

Architectures, Process Frameworks, Modeling Techniques,

Implementation Platforms, and down to Resource Utilization

& Management, Product Presentation & Promotion, and

Service Delivery & Support.

We are trying to realize and explain common characteristics

of various models and map them to a number of finite

business perspectives, in the need to move towards business

success and sustainable growth. We are finally trying to

present few of today’s trends and possibly provide guiding

advice to decision making, towards business success,

economic prosperity and welfare.

TABLE OF CONTENTS

Preface..........................................................................1End-2-End Business Process & Business ProcessWorkflow.......................................................................................Innovation.....................................................................................

From strategy to execution......................................................Business Process Expert...............................................................Business Process Management (BPM)..........................................

Business Process Modeling Notation (BPMN).........................Business Process Modeling Suite (BPMS)................................

Description..................................................................13Innovation and Process Change..................................................Enterprise Architecture (EA)......................................................

Process Classification Framework (PCF): aframework for process improvement.....................................Capability Maturity Model® Integration (CMM®I).................Zachman Framework.............................................................

Definition....................................................................21Service Oriented Architecture (SOA)..........................................

Web services..........................................................................Universal Description, Discovery and Integration(UDDI)....................................................................................Enterprise Service Bus (ESB)................................................

Web Services Description Language (WSDL)....................Business Process Execution Language (BPEL)..................

Information Technology Infrastructure Library (ITIL)...............................................................................................Service Catalogue & Configuration ManagementDatabase (CMDB)..................................................................

Market.........................................................................31The Technology Adoption Curve.................................................

Hype Cycles...........................................................................The SOA Maturity Model............................................................Organizational Maps...................................................................

i

The ITIL v3 Application Example......................................

Strategy.......................................................................37Innovation, Optimization, Agility.....................................37

The Imperative to Evolve.......................................................Organizational Analysis vs. OrganizationalTransformation...........................................................................

The Liquid Enterprise: Unlocking the Value of ERPSystems..................................................................................Business Integration, -a good place to startinnovating over ERP systems.................................................

The Object Management Group (OMG)......................................Business Process Ontology.....................................................

Innovation vs. Complexity...........................................................

Proposition..................................................................45Tight Integration and Efficiency vs. Flexibility...........................

Cultural Issues.......................................................................The Business Ecosystem.............................................................

Value Chains..........................................................................Value Nets..............................................................................

Component Business Model (CBM)............................................Business Maps............................................................................

Cross-Functional Process Maps.............................................Enterprise Unified Process (EUP)...............................................

Management...............................................................54The IT – BM “Bipolar”.................................................................The Business Process Maturity Model........................................

Financials....................................................................58Research Abstracts..........................................................58

Maximizing IT Investments.........................................................Service Level Management (SLM).........................................

Service Level Agreements (SLA).......................................Software as a Service (SaaS)......................................................

The Financial Case for a Service Catalogue...........................

Conclusion...................................................................64Concluding Remarks........................................................64

ii

iii

LIST OF FIGURES

NumberFigure 1: Moore’s Technology Adoption Curve, BPMS and

EAI, Workflow and Process Modeling...........................................Figure 2: SAP, BPX hourglass.................................................................Figure 3: BPM standards........................................................................Figure 4: BP General Architecture.........................................................Figure 5: Goeffrey A. Moore, “Living on the fault line,”

HarperBusiness, 2002...................................................................Figure 6: Tools used in BPMS.................................................................Figure 7: Generic Architecture of a BPMS Product..............................Figure 8: Market Analysis for Business Process Management

Suites, 2007................................................................................Figure 9: O’Reilly Tushman Innovation Continuum..............................Figure 10: O’Reilly Tushman Innovation Continuum............................Figure 11: Focus and Capabilities for both Ongoing

Operations and Exploratory Operations.....................................Figure 12: An Enterprise Architecture Performance

Reference Model.........................................................................Figure 13: APQC, the Process Classification Framework.....................Figure 14: Zachman Enterprise Architecture Framework...................Figure 15: SOA Stack, -the SAP example.............................................Figure 16: The ITIL v3 Lifecycle and its Supporting

Processes....................................................................................Figure 17: The ITIL Framework...........................................................Figure 18: The Value of Transitioning to Service

Management...............................................................................Figure 19: The IT Organization’s “Front Office” and “Back

Office” Processes (Source: newScale Inc.)..................................Figure 20: The Service Catalogue and the CMDB (Source:

newScale Inc.).............................................................................Figure 21: The BPMS Adoption Curve.................................................Figure 22: The SOA Maturity Model....................................................Figure 23: An Organization Map..........................................................Figure 24: ITIL’s seven-step of the CSI phase complements

Six Sigma’s DMAIC model..........................................................Figure 25: ERP application silos impede process execution.................

iv

Figure 26: The Liquid Enterprise Transforms from anApplication-centric to a Process-centric approach......................

Figure 27: BEA, -Enterprise 3600, Technology Portfolio.......................Figure 28: SOA-based Business Integration.........................................Figure 29: Finding your Model T: ref. HBR..........................................Figure 30: Business Processes and Service Level-driven

Clients.........................................................................................Figure 31: Michael Porter’s value chain...............................................Figure 32: Most Companies will want both value nets and

value chains................................................................................Figure 33: IBM’s Component Business Model (CBM)..........................Figure 34: Advantages and Disadvantages of Value Chains

and Value Nets............................................................................Figure 35: SAP ERP Business (Solution) Maps.....................................Figure 36: The Lifecycle for the Enterprise Unified Process

(EUP)..........................................................................................Figure 37: Improving Specific Business Processes..............................Figure 38: Maturity Model Typology....................................................Figure 39: Third-party Services in IT Organizations............................Figure 40: The Rational for Outsourcing..............................................Figure 41: SaaS vs. Owned / In-house Systems....................................Figure 42: The Financial Case for a Service Catalogue.......................

v

ACKNOWLEDGMENTS

The author wishes to acknowledge AIT staff and colleagues,

for their teaching methodologies, their guiding advice and

co-studying efforts as well as business associates of various

Intracom Group units, for their help and valuable input, in

enriching and composing the present work. I would like to

dedicate this work to my professor and good friend G. S.

Yovanof, for these 3 years of inspiring and joyful academic

pace.

Thank you._

vi

GLOSSARY

B2B. Business-to-business

BAM. Business Activity Monitoring

BI. Business Intelligence

BPA. Business Process Analysis

BPM. Business Process Management

BPMN. Business Process Modeling Notation

BPMS. Business Process Management Suite

BPO. Business Process Outsourcing

BPP. Business Process Platform

BRE. Business Rule Engine

CBM. Component Business Models

CMDB. Configuration Management Database

CMMI. Capability Maturity Model® Integration

CSI. Continual Service Improvement

EA. Enterprise Architecture

EAI. Enterprise Application Integration

ECM. Enterprise Content Management

ERP. Enterprise Resource Planning

vii

EUP. Enterprise Unified Process

H2H. Human-to-human

H2S. Human-to-system

IDE. Integrated Development Environment

ISE. Integrated Service Environment

ITIL. Information Technology Infrastructure Library

Java EE. Java Platform, Enterprise Edition

PCF. Process Classification Framework

S2S. System-to-system

SaaS. Software as a Service

SOA. Service Oriented Architecture

SCOR. Supply-Chain Operations Reference

TCO. Total Cost of Ownership

TRIZ. (Teoriya Resheniya Izobretatelskikh Zadatch), “Theoryof Inventive Problem Solving”

UDDI. Universal Description, Discovery and Integration

WSDL. Web Services Description Language

viii

C h a p t e r 1

PREFACE

Innovation is a very hot term and it seems that recently

replaced the terms Agile and Excellence as a buzzword of

choice, in business literature. Businesses have always tried to

be innovative:

1..............Entrepreneurs, with new ideas, -something new.

2..........Managers, with the introduction of new processes,

-methodologies.

3....................Marketing, through unique ads, -campaigns.

4.. R&D, through invention and the use of technology, -new

products or services.

End-2-End Business Process & Business Process

Workflow

End-2-End Business Process: is about addressing business

information and processes across organizational and

technological silos. In most business processes, the time

involved in the actual processing of the data is only a

fraction of the total time, from start to finish that it takes to

complete the transaction, -the interrelated tasks and

sequence of activities. Most of the processing time is

1

consumed by the movement of the data from person to

person especially if the routing is done manually, and in the

"waiting to be worked on" phase. Workflow actually takes

advantage of that and is a tool designed to facilitate and

automate standardized business processes in a manner that

(a) spans organizational and functional boundaries, (b)

secures information flow integrity.

Innovation

Innovation: involves introducing something new, which can

be an idea, a method or a device. We will not discuss “the

new concept” herein. Innovation in this paper will mostly

relate to the use (flow) of master-data, meta-data, etc., in

such a way, to enable visibility and availability –or other said

transparency of key information, across the enterprise.

From strategy to execution

Business processes can make money and save valuable

resources. Moreover they represent intellectual assets for the

enterprise, -as they contain knowledge that can be captured,

reused and improved. Workflow software doesn't create

business processes itself. By applying workflow to a business

process, the details of that process can be brought into focus,

as it lays out the business process and add the required

business rules definitions. A workflow can be thought of as

the implementation of the answers to the questions: Who,

What, When, in a business process.

2

Figure 1: Moore’s Technology Adoption Curve, BPMS and EAI, Workflowand Process Modeling.

Business Process Expert

A Business Process Expert is neither a traditional

developer nor a traditional business analyst, but is able to

apply the concepts, metrics, and performance objectives of

business in the analysis, design, and optimization of IT

implementations capable of executing and monitoring cross-

functional processes. Such a role demands a common

language that bridges the worlds of business and IT as well:

the Business Process Modeling Notation (BPMN), a standard

from Object Management Group (OMG).

3

Figure 2: SAP, BPX Hourglass.

Business process experts have the business knowledge and

IT savvy to make business process innovation happen in real

time by adapting, composing, and executing end-to-end

business processes, using composition software tools and

enterprise services. Business Process Expert, –is a role that

today is done partly by a business analyst, partly by an

application consultant, and partly by a process developer.

Business Process Management (BPM)

In today’s accelerated business cycles require managers to

manage operations in real time. Managing work activities by

using after-the-fact reports is no longer enough. Pressures

for information transparency, operational accountability and

compliance make it critical for managers to monitor

4

transactions by understanding operational processes and

being able to see work in progress to adjust as appropriate.

Increasingly, business managers, employees and potentially

even external constituents to the process want to proactively

adjust work in progress, not just to react to information about

completed business transactions.

Figure 3: BPM Standards.

Furthermore, in today's global business environment,

operational excellence is measured increasingly by process

responsiveness –that is, agility, rather than by efficiency. By

itself, efficiency is no longer enough. BPM is the newest

process management theory meant to address these new

business realities. BPM's disciplines are largely technology-

5

enabled to better address today's more-unpredictable market

dynamics by applying process management approaches. BPM

advocates process transparency and effectiveness in addition

to agility. Processes that are transparent, effective and agile

are more likely to be perceived as innovative by employees,

customers and partners.

Figure 4: BP General Architecture.

Business process management (BPM) is an emerging

discipline that looks at the enterprise in a radically new way.

Instead of trying to automate and optimize individual

functional units, like sales, supply chain, and customer

service, in isolation, BPM views the enterprise from the

perspective of end-to-end cross-functional processes, –exactly

the way customers and trading partners sees it. Emerging

BPM tools let model, automate, measure, and optimize the

6

business from such an end-to-end process perspective. These

tools straddle the traditional business / IT divide, and are

elevating the importance of a new role in the organization,

the Business Process Expert.

In most organizations, business processes are largely

embedded in applications and people's experiences. Parts of

processes may be carried out through informal work

practices, which are buried in the experiences of employees,

who may leave the company. Furthermore, informal work

practices contribute to the lack of process transparency.

When a process is automated by an application, it is, at best,

implied to the user; the actions of the application show that it

is operating by a defined process, but the process is achieved

by traditional programming logic and is not created using a

process model visible to business users or IT developers.

Gartner refers to this style of process management as

"implicit" process management. Clearly, a process is at work,

but the process is not isolated easily from the runtime

implementation expressed in the application; hence, the

process is real but implicit, the opposite of explicit.

In contrast to implicit process management, BPM advocates

that processes must be transparent to internal and external

users. When processes are visible, managers can better

manage them, participants can contribute to making the

process more effective and participants are more likely to

7

perceive the process as innovative and responsive. Gartner

refers to this as "explicit" process management.

A BPMS takes process management to the next level; in

addition to explicit process modelling, it makes the model

executable, while retaining the model as the central focus for

future process changes. The graphic model is actually

metadata that is dynamically interpreted and transformed

into the executed process. A BPMS supports the entire

process improvement cycle, from definition to

implementation, monitoring and analysis, and through

ongoing optimization. As a software infrastructure platform,

it enables business and IT professionals to work more

collaboratively on process design, development, execution

and enhancement, and to close the execution gap between IT

and the business.

8

Figure 5: Goeffrey A. Moore, “Living on the Fault Line,”HarperBusiness, 2002.

BPMSs deliver short-term benefits, such as cost and time

savings, and help in meeting compliance demands, and

longer-term advantages, including visibility across broad,

cross-functional processes and process agility to meet

changing market and constituent needs.

Business Process Modeling Notation (BPMN)

Business Process Modeling Notation (BPMN), is a

graphical notation for modeling business processes. A BPMN

9

model is essentially a diagram of the process flow, but a

process model is more than a drawing.

The architecture of the Business Processes (BP) of an

enterprise is defined as the type of processes it contains and

the relationships among them. We may define architecture

for the whole of an enterprise of for some portion thereof.

This idea is related to several proposals for frameworks that

enterprises have used to guide architecture design, such as

Zachman’s Framework, which is presented later on.

BPMN is simple enough to be readily understandable by

business, yet rich enough to support executable

implementation, – without changing the underlying

metamodel! As a result, it has become the de facto standard

or announced future direction of BPM Suite (BPMS) vendors

ranging from Lombardi, Savvion, and Appian, to TIBCO,

Oracle, IBM, and SAP. Thus, understanding how to model

processes effectively using BPMN is becoming a must-have

skill for a Business Process Expert.

Business Process Modeling Suite (BPMS)

A BPMS is an integrated collection of critical software

technologies that enables the control and management of

business processes. As compared with other model-oriented

development tools, such as integrated service environments

(ISEs) and integrated development environments (IDEs), a

BPMS emphasizes business user involvement in the entire

10

process improvement life cycle, from design through

implementation, deployment, monitoring and ongoing

optimization. Rather than reducing reliance on people

through automation, a BPMS emphasizes the value of

coordinating people and information, in addition to systems,

as central resources. This emphasis also distinguishes a

BPMS from other emerging model-driven application

infrastructure.

Figure 6: Tools used in BPMS.

11

BPMSs use explicit process models to coordinate the

interactions among people, systems and content as equally

important aspects of work. This model-driven approach

loosely couples the physical resources used at execution time

from the design of the process, enabling greater flexibility. At

runtime, the BPMS functions as a "superworkflow manager,"

coordinating end-to-end processes, including all resources

involved, human and machine, regardless of whether

software resources are created in the BPMS's design

environment. Workflow technologies often are incorrectly

assumed to be synonymous with a BPMS. However, workflow

is only one of many runtime capabilities required for a BPMS,

-per our definition below. Thus, a BPMS represents a holistic

technological approach to managing processes, from design

through implementation, to monitoring and ongoing

optimization.

12

Figure 7: Generic Architecture of a BPMS Product.

A BPMS is most appropriate for processes that have balanced

requirements for the coordination of people, systems and

information, and where management of the interactions and

interdependencies among all three aspects of work is critical

to work outcomes. The explicit process management

approach of a BPMS, -the "classic" use scenario, is most

valuable for processes that need to change frequently, extend

during hours and days, cross multiple physical boundaries

(such as organizational boundaries, boundaries among

facilities, system boundaries, information boundaries), thus

requiring a high degree of coordination of human activities,

information, business transactions and business rules. The

appropriate processes often exhibit the following

characteristics:

13

They are external-facing. This makes them highly

susceptible to disruption from external forces, such as

weather patterns, currency fluctuations, consumer

preferences, commoditization pressures, trading-

partner actions, competitive pricing, regulatory

changes, geopolitical events and skill availability.

Some critical aspects of the workflow are not yet well-

understood. The BPMS approach helps uncover more-

successful workflows by making their execution visible

and audited. Execution data history is used as input

into the next iteration of the design.

The process depends on human collaboration to have

an impact on outcomes (such as new-product designs,

problem diagnosis and case management-style problem

domains).

A BPMS enables its users to see and directly manipulate the

resources being coordinated. The explicit model of the BPMS,

used at design time and runtime, makes it far easier for

operational managers to change process execution by

altering the routing of work among people, and by altering

exposed rules and parameterized values that drive execution

flow. Explicit process models are far easier to change for

process designers and developers than traditional

applications, which use implicit approaches based on

programming code.

14

Figure 8: Market Analysis for Business ProcessManagement Suites, 2007.

15

C h a p t e r 2

DESCRIPTION

Innovation and Process Change

If we focus more narrowly on Innovation in the context of

process change, we can divide the recent literature, very

roughly, into three basic categories. One school stresses

creativity and focuses on brainstorming and a variety of

related techniques that can help teams of people think of

alternative ways of accomplishing a task. This school might

be summed up as the creative thinking school. A second

school derives from the work of Genrich Altshuller, a Russian

theorist who has created a systematic or “engineering”

approach – called TRIZ – which can be used to examine

problems and generate new possibilities. TRIZ is a Russian

acronym that means something like the theory of inventive

problem solving, and it was originally developed in

conjunction with work on patent analysis. TRIZ can be used

in conjunction with process redesign. The third major use of

the term innovation in conjunction with process change is

being driven by Michael Hammer, who has written on the

importance of innovation. A good example is Hammer’s

April 2004 Harvard Business Review article: “Deep Change:

How Operational Innovation Can Transform Your Company.”

16

Hammer contrasted innovation with improvement and

suggested that there are times when you simply want to

improve existing processes and then there are other times

when you want to innovate and completely change the way

you do business. In other words, the author uses innovation

as a synonym for reengineering.

Figure 9: O’Reilly Tushman Innovation Continuum.

Smart organizations seem to divide their organizational units

into two groups. One group of units, focuses on existing

business and the other focuses on emerging business, –one

seeks incremental innovations in all areas and one seeks

architectural or discontinuous innovations in more specific

areas. And one adjusts one’s approach as things change. If

we think of a large organization, it is easy to imagine that

different departments or business units would be changing at

different rates. Some would be mostly focused on

improvement while others might be focused more on

redesign. A few might be undertaking major reengineering

17

efforts. No company can be constantly locked in the throes of

reengineering or discontinuous innovation.

Figure 10: O’Reilly Tushman Innovation Continuum (b).

Sometimes radical change is necessary and at other times a

more restricted redesign effort is needed. Most of the time a

company will simply be engaged in ongoing process

improvement.

18

Figure 11: Focus and Capabilities for both Ongoing Operations andExploratory Operations.

Enterprise Architecture (EA)

Enterprise architecture as a term, it is used to describe the

practice of documenting the elements of business strategy,

business cases, business models and the supporting

technologies, policies and infrastructures that make up an

enterprise. Multiple architecture frameworks describe

Enterprise Architecture.

Enterprise Architecture can be described as: (a)

documentation describing the structure and behavior of an

enterprise and its information systems, usually in a number

19

of architecture domains, (b) a process for describing an

enterprise and its information systems and planning changes

to improve the integrity and flexibility of the enterprise.

Figure 12: An Enterprise Architecture Performance ReferenceModel.

The architecture process addresses documenting and

understanding the discrete enterprise structural components,

typically within the following four categories:

20

Business

Applications

Information

Technology

Enterprise architecture also involves developing an

architecture framework to describe a series of "current",

"intermediate" and "target" reference architectures and

applying them to align change within the enterprise.

21

Process Classification Framework (PCF): a framework

for process improvement

Figure 13: APQC, the Process Classification Framework.

The PCF provides the foundation for the Open Standards

Benchmarking CollaborativeSM (OSBC)1 database and the

work of its advisory council of global industry leaders. It is a

cross-industry framework, which has experienced more than

1 The PCF is continuously enhanced, as the OSBC database further develops definitions, processes, and

measures. The PCF and associated measures and benchmarking surveys are available for download and

completion at no charge from the Open Standards Benchmarking Collaborative Web site.

22

15 years of creative use by thousands of organizations

worldwide.

Capability Maturity Model® Integration (CMM®I)

A specialized methodology offered by the Software

Engineering Institute (SEI) at Carnegie-Mellon University.

Working for the US Department of Defense, SEI created

CMM, -the Capability Maturity Model. It was originally

designed to evaluate the maturity of software development

organizations. It has been extended to CMMI, which can be

used with any business process. CMMI believes that the most

effective way to evaluate the process maturity of

organizations is to study the skills possessed by managers.

Changing programs based on CMMI, define skills and

capabilities that process managers need to master. CMMI, as

a methodology or prescription for change, defines a training

program for people, -organization's managers. It doesn't

provide any direct help with specific process improvement

but assumes improvement of managers’ skills in managing

processes that will eventually result in improved processes

and better performance. Thus, CMMI, as a process change

methodology, is both a long-term and a niche-focused

approach. There are many books on CMMI and on various

specialized versions of CMM.

Zachman Framework

The Zachman Framework is a classification structure often

used by IT and the teams responsible for developing and

23

documenting Enterprise Architecture. The Framework is

used for organizing architectural "artifacts" in a way that

takes into account (a) who the artifact targets, -i.e. the

business owner and builder and (b) what particular issue,

-for example, data and functionality is being addressed.

These artifacts may include design documents, specifications,

and models.

The Zachman Framework is a schema, -the intersection

between two historical classifications that have been in use

for literally thousands of years, namely; What, How, When,

Who, Where, and Why. It is the integration of answers to

these questions that enables the comprehensive, composite

description of complex ideas. The second is derived from

reification, the transformation of an abstract idea into an

instantiation that it is labeled in the Framework, as:

Identification, Definition, Representation,

Specification, Configuration and Instantiation.

24

Figure 14: Zachman Enterprise Architecture Framework.

More specifically, the Zachman Framework is an ontology, -a

theory of the existence of a structured set of essential

components of an object for which explicit expressions is

necessary and perhaps even mandatory for creating,

operating, and changing the object, (the object may be the

enterprise, a department, a value chain, a project, a product,

a profession, etc.).

25

C h a p t e r 3

DEFINITION

Service Oriented Architecture (SOA)

Business today stands on the verge of widespread adoption of

service-oriented architecture (SOA), a development that

promises to change the dynamics of the software industry, as

much as the shift to client-server architecture did 15 years

ago. In essence, SOA defines the technical standards that

enable the various enterprise software applications used by

companies and their business partners to exchange data

effectively. Thus, SOA will help reduce the costs of creating

and maintaining data exchange interfaces, a factor that CIOs

and IT departments consistently cite as one of their top

challenges.

SOA as the architectural blueprint for the next wave of

distributed application development is according to Gartner’s

definition: a client-server / (N-tier) software design approach

in which an application consists of software service providers

and software service consumers (also known as client or

service requesters). SOA differs from the more general client-

server model in its definitive emphasis on loose coupling

between software components and in its use of separately

standing interfaces.

26

One tenet of SOA is the ability to re-use abstracted business

activities or events, which are modeled as Enterprise

Services. Reuse could be as simple as delivering the business

process or activity through a new channel such as the web,

-today when we say services, we really mean Web Services.

SOA also relies on a standard framework for defining and

designing services in order to facilitate re-use and business

agility. Because the full spectrum of potential uses for any

Enterprise Service is unknown at the point of design and

development, SOA requires a holistic approach to creating

that individual service. Traditional development focuses only

on the immediate tactical requirements for a given custom

program. SOA requires a focus on the bigger picture,

creating services that are well-defined, self-contained and

complete, Deloitte Development LLP, 2006, Service-Enabled

Enterprise Resource Planning: Challenging the boundaries of

traditional packaged applications to deliver business value.

27

Figure 15: SOA Stack, -the SAP Example

Web services

Web Services are a new breed of Web application and a

better way to realize SOA on a large scale. They are self-

contained, self-describing, modular applications that can be

published, located and invoked across the Web. They perform

functions from simple requests to complicated business

processes. Once a Web service is deployed, other applications

(and other Web services) can discover and invoke the

28

deployed service. The point to remember is that SOA is an

overarching architectural approach; Web services are the

enabling technologies.

Universal Description, Discovery and Integration

(UDDI)

Universal Description, Discovery and Integration (UDDI)

standard is used to publish, discover and manage Web

services in an UDDI registry. UDDI registry is like Yellow

Pages that list available Web services that can be discovered

by an application. Creation of a registry that contains

available services allows service consumers to discover and

invoke Web services that are published within the UDDI

registry.

Enterprise Service Bus (ESB)

An enterprise service bus (ESB) is a middleware solution that

enables interoperability among heterogeneous environments

using a service-oriented model. Although frequently

associated with concepts like “integration” and “mediation,”

an ESB also provides a service platform comparable to an

application server. In fact, ESBs represent the consolidation

of the integration and application server product categories.

An ESB's true breakthrough feature is its ability to virtualize

services. An ESB's service container abstracts a service and

insulates it from its protocols, invocation methods, method

exchange patterns, quality of service requirements, and other

infrastructure concerns.

29

Web Services Description Language (WSDL)

Web Services Description Language (WSDL) is an XML-based

standardized interface definition language used to describe

what a Web service can do, where it resides, and how it can

be invoked. A WSDL file associated with a Web service

contains important details about the Web-service interface

for client-service interaction. WSDL is used to provide

definition of a Web service and interface specification for it.

Business Process Execution Language (BPEL)

Many ESBs supply an orchestration engine that can execute

structured workflows representing a business process. The

Business Process Execution Language (BPEL) is an

orchestration language for defining these automated

business processes. A process definition specifies the precise

set of execution steps that govern runtime interactions

among applications, data sources, and other entities required

to complete the process. In particular, BPEL defines a syntax

for specifying an automatic workflow for invoking web

services, -services that are described by WSDL.

Orchestrations defined by BPEL are then in turn exposed as

web services.

Web Services Business Process Execution Language (WS-

BPEL) version 2.0 was ratified by OASIS in April 2007, and

the ESB vendors are strongly committed to this standard.

Currently, though, many ESB vendors implement support for

a previous nonstandard version known as Business Process

30

Execution Language for Web Services (BPEL4WS) version

1.1. In June 2007, a number of vendors, including Active

Endpoints, Adobe Systems, BEA, IBM, Oracle, and SAP,

published a set of specifications know as WS-BPEL Extension

for People (BPEL4People) that enable BPEL process

definitions to invoke human workflow activities in a standard

way. These specifications will address a glaring omission in

the current specification, -that of human participation but

they have not yet been submitted to a standards body.

Information Technology Infrastructure Library (ITIL)

The Information Technology Infrastructure Library (ITIL) is a

set of concepts and techniques for managing information

technology (IT) infrastructure, development, and operations.

Figure 16: The ITIL v3 Lifecycle and its Supporting Processes.

31

There are two concurrent and parallel waves of ITIL

implementation: (a) new adopters facing decisions about how

best to approach implementation, (b) organizations that are

mature in their ITIL initiative seeking to show value and

service-quality improvements to the business from the work

undertaken so far. The poor standing of IT with its business

users, is based on a lack of clarity about the services being

offered, sometimes simply due to an over-technical and

unfathomable presentation of what is available, coupled with

a lack of transparency on the costs and expected service-level

commitments. To re-align IT with its business users requires

a radical refocus on the needs of IT’s customers.

ITIL v3 introduces the Seven-step process to improvement:

1......................................Define what you should measure.

2...........................................Define what you can measure.

3.......................................................................Gather data.

4...............................................................Process the data.

5...............................................................Analyze the data.

6....................................................Present/assess the data.

7...........................................Implement corrective actions.

32

Figure 17: The ITIL Framework

While the benefits of ITIL are proven, the adoption is not a

trivial task. Whether starting out on that ITIL path or having

reached a level of ITIL maturity, there is strong evidence that

a Service Catalogue will either accelerate ITIL maturity or

provide a good basis to start. Someone can see little that

would prevent a strong recommendation of the early

adoption of a Service Catalogue and a great deal to support

the case for implementing one, -preferably as a starting point

that will integrate with and advance CDMB deployment.

More fundamentally there are demands on IT that are

unlikely to be met unless IT is firmly re-aligned with the

needs of its customers, compliant with regulatory

requirements, in control of its expenditure, and comparable

in quality and cost to external suppliers. All these issues

support the case for implementing a Service Catalogue. The

33

only remaining issue is how quickly the benefits are received

and the cost of implementation recovered.

Figure 18: The Value of Transitioning to Service Management.

Service Catalogue & Configuration Management

Database (CMDB)

The terms ‘Front Office’ and ‘Back Office’ originated in an

era when the typical company was bifurcated into two

disconnected sections: the ‘Front Office” roles like Sales and

Marketing had the primary interaction with customers, whilst

all the core operational tasks of running the business such as

manufacturing, transportation, and administration, were

handled out of sight in the ‘Back Office’. Clearly this

‘disconnect’ built a barrier to communicating the needs of

customers to the providers of core functions of the

organisation. This analogy is apt for the IT organisation in

34

large organizations today. Unfortunately, this barrier between

the customers of IT and the ‘Back Office’ of IT operations

remains a fundamental challenge, think of ERP and CRM

systems. The two central components of the ITIL framework

that we are considering here, -the CMDB and the Service

Catalogue, are at the crux of these different ‘Back Office’ and

‘Front Office’ perspectives and illustrate why there is the

need for a more customer-centric approach to IT Service

Management.

Figure 19: The IT Organization’s “Front Office” and “Back Office” Processes(Source: newScale Inc.).

The complexities present within IT infrastructures,

emphasise the need for automated Configuration

Management to assist in the creation and maintenance of the

map of the infrastructure. In many IT organisations, it is

35

impossible to even consider carrying out this task manually,

and those that do attempt it will find that it is labour-

intensive, expensive, and the resulting output is persistently

out-of-date. Of course, out-of-date information can be more

dangerous and damaging than no information, causing

severe problems when decisions are made on this false or

incorrect configuration data.

Figure 20: The Service Catalogue and the CMDB (Source: newScaleInc.).

CMDBs give (IT) organizations complete visibility into the

attributes, relationships, and dependencies of the

components in their enterprise computing environments.

Industry standards for federating and accessing IT

information integrate communication between IT

management tools. Organizations can use their CMDBs: (a)

36

to share and access configuration data and (b) to create a

more complete and accurate view of IT information spread

out across multiple data sources, using standard ways and

tools. This makes it easier to keep track of changes to an IT

environment, such as the last time an application was

updated or changes to critical configuration information. It

also helps organizations better understand the impact of

changes they make to the IT environment.

37

C h a p t e r 4

MARKET

The Technology Adoption Curve

BPM became a hot term in early 2003. BPMI was founded in

2002. Today, the number of vendors claiming to offer BPMS

products is probably over 100. Depending on whom you talk

with, BPM can mean Six Sigma, Balanced Scorecard, SCOR,

process redesign, or identifying business managers to

manage processes. And, of course, it can also mean using

ERP software to automate processes, or it can mean using a

BPMS software product to manage the runtime execution of

a business process.

Figure 21: The BPMS Adoption Curve.

38

If you talk with the leading BPMS vendors, they will tell you

that BPMS has crossed Moore's Chasm, -that BPMS has

moved beyond the Early Adopter phase and is being

embraced by major Early Majority companies. Perhaps it is

fair to say that the interest in BPMS has pushed the Workflow

and EAI markets into high gear.

Hype Cycles

A Hype Cycle is a graphic representation of the maturity,

adoption and business application of specific technologies.

Since 1995, Gartner has used Hype Cycles to characterize

the over-enthusiasm or "hype" and subsequent

disappointment that typically happens with the introduction

of new technologies. Hype Cycles also show how and when

technologies move beyond the hype, offer practical benefits

and become widely accepted.

What are the 5 phases of a Hype Cycle?

1. "Technology Trigger": The first phase of a Hype Cycle

is the "technology trigger" or breakthrough, product

launch or other event that generates significant press

and interest.

2. "Peak of Inflated Expectations": In the next phase, a

frenzy of publicity typically generates over-enthusiasm

and unrealistic expectations. There may be some

successful applications of a technology, but there are

typically more failures.

39

3. "Trough of Disillusionment": Technologies enter the

"trough of disillusionment" because they fail to meet

expectations and quickly become unfashionable.

Consequently, the press usually abandons the topic and

the technology.

4. "Slope of Enlightenment": Although the press may

have stopped covering the technology, some businesses

continue through the "slope of enlightenment" and

experiment to understand the benefits and practical

application of the technology.

5. "Plateau of Productivity": A technology reaches the

"plateau of productivity" as the benefits of it become

widely demonstrated and accepted. The technology

becomes increasingly stable and evolves in second and

third generations. The final height of the plateau varies

according to whether the technology is broadly

applicable or benefits only a niche market.

The SOA Maturity Model

Organizations that tread the SOA path often find it useful to

benchmark their current state of SOA maturity in order to

plan ahead, or to compare their products and processes with

those of similar organizations in the industry. It is often a

challenge to standardize on a generic maturity model for all

enterprises, as the SOA goals, objectives and requirements of

every enterprise vary based on the type and size of business,

40

market environment etc. It must not be forgotten the fact

that people, technology and architecture alone will not take

an enterprise through SOA journey successfully, unless they

are supported by key processes and activities. A maturity

model for SOA should therefore encompass both the

effectiveness of the architecture (product) as well as the

processes required to take it from the as-is state to the to-be

state.

Figure 22: The SOA Maturity Model.

This SOA maturity model provides a framework for

discussion between IT and business users about the

applicability and benefits of SOA in an organization across

five levels of adoption maturity.

41

Organizational Maps

Organization analysis refers to any effort that seeks to

capture, -more or less, objective information and then use it

to help decision makers. A good example involves the

development of a business model, e.g., the Organization

Map. In essence, an Organization Map conceptualizes an

organization as a system and defines the elements and the

flows that characterize the organization.

Figure 23: An Organization Map.

An Organization Map lists the organization inputs on the left,

outputs on the right, and external controls at the top.

Depending on the purpose, it can include value chains or

high-level business processes inside, and then show how

those processes interact with the environment outside the

42

organization. There are many other analytic enterprise level

diagrams. A hierarchy diagram showing how a value chain is

decomposed into levels of sub-processes is another example.

Similarly, a model of how scorecards can be cascaded from

an organization scorecard down to specific departmental, or

even workgroup scorecards, is still another.

The ITIL v3 Application Example

Figure 24: ITIL’s Seven-step of the CSI Phase Complements SixSigma’s DMAIC Model.

DMAIC (Define, Measure, Analyze, Improve, and Control).

Continual Service Improvement (CSI) is an important phase

in the IT service management life cycle; since business

demands evolve and change over time, the ability to

continually meet and exceed the business requirements

becomes critical.

43

44

C h a p t e r 5

STRATEGY

Innovation, Optimization, Agility

Organizations need three key capabilities to enable these

strategies for sustainable advantage:

1. Business innovation, -the ability to fundamentally

change the business landscape to their advantage.

2. Business optimization, -increasing overall efficiency in

delivering existing products and services, and the

ability to execute more reliably and with high quality,

even as operations scale.

3. Business and IT agility, -the ability to quickly recognize

and react to both predicted and unforeseen market

changes and make changes quickly.

All of these capabilities depend directly on the supporting

technologies. If IT systems duplicate data and functions,

creating inconsistencies and manual work-around, the

company will find it nearly impossible to optimize operations.

If applications have dictated the flow of business processes

and now constrain their evolution, the systems cannot

support the rapid change today’s businesses demand. Finally,

if a company has the same software infrastructure and the

45

same capabilities and constraints as all of its competitors, it

cannot hope to consistently differentiate itself, let alone

introducing continuous innovation into the market.

The Imperative to Evolve

Over the past two decades, organizations have invested in

ERP software to enjoy the efficiencies and cost savings

associated with a single, integrated suite of business

applications. ERP systems automate and manage processes

common to every company. These systems focus on

automation, not on enabling the unique business processes

that differentiate companies from one another. Most ERP

capabilities are so widely adopted today, that they have

become commoditized. ERP systems no longer offer the

competitive edge it once did. In fact, the “accidental

architectures” created by the deployment and evolution of

ERP systems are now roadblocks to continued innovation and

competitiveness. The business optimization accomplished

with ERP deployments came at the cost of agility and

sustainable innovation. Siloed ERP environments are poor

hosts to today’s cross-functional, geographically dispersed,

multi-channel processes. The customization and hard-wired

integration between these systems and the rest of the IT

environment make every successive change more complex

and expensive.

46

Figure 25: ERP application silos impede process execution.

Organizational Analysis vs. Organizational

Transformation

“Enterprises that aggressively begin their

organizational and cultural transformation for BPM

in 2007 will double their chances of becoming

industry leaders by 2010.”2 -Gartner

Business Process Management (BPM) is a strategy for

managing and improving the performance of a business

through continuous optimization and innovation of business

processes in a closed-loop cycle of modelling, execution, and

measurement.

2 Gartner, Predicts 2007: Align BPM and SOA Initiatives Now to Increase Chances of Becoming

a Leader by 2010, November 2006

47

“The value of SOA will be found in business

process management (BPM), which promises to

allow companies to create unique and

differentiating business processes on top of the

same software many of their competitors use.”3

-AMR Research

The Liquid Enterprise: Unlocking the Value of ERP

Systems

This new approach involves a transformation away from

functionally aligned systems and toward a process-driven

view of business operations and IT. Organizations must rid

themselves of rigid, functionally siloed connections that link

information, applications, and business processes, and

connect systems, people, and processes dynamically

whenever and wherever needed. Embracing heterogeneity is

the key to a Liquid Enterprise approach; large businesses

need to use the diverse IT assets they have and should not be

locked in to a single vendor or technology for future

innovation.

3 AMR Research, SOA and BPM for Enterprise Applications: A Dose of Reality, May 2007

48

Figure 26: The Liquid Enterprise Transforms from an Application-centric to aProcess-centric Approach.

The Liquid Enterprise bridges the gaps that exist between

legacy systems and organizations, and adopts the powerful,

collaborative Web 2.0 capabilities that have transformed the

consumer world for the enterprise, while ensuring security

and manageability for all.

49

Figure 27: BEA, -Enterprise 3600, Technology Portfolio.

Business Integration, -a good place to start innovating

over ERP systems

Many businesses begin their SOA and BPM projects with

business integration. Business integration connects data and

applications, accelerates IT response, and reduces non-

discretionary spend. According to AMR Research, 70 percent

of large enterprise IT groups view these three issues as their

biggest challenges.

There are typically three stages towards comprehensive SOA-

based business integration: (a) application integration, (b)

50

enterprise integration for SOA, and (c) business integration,

-using BPM. Projects in all three areas are likely to take place

simultaneously within an enterprise. As long as the

organization takes a unified infrastructure approach to all of

them, they will contribute to the enterprise transformation

and enhanced agility, innovation, and process optimization.

Figure 28: SOA-based Business Integration.

The Object Management Group (OMG)

Object Management Group (OMG) is a consortium, originally

aimed at setting standards for distributed object-oriented

systems, and is now focused on modeling (programs, systems

and business processes) and model-based standards.

Founded in 1989 by eleven companies (including Hewlett-

Packard, IBM, Sun Microsystems, Apple Computer, etc.),

51

OMG tried to create a heterogeneous distributed object

standard. The goal is a common portable and interoperable

object model with methods and data that work using all types

of development environments on all types of platforms.

Business Process Ontology

An ontology defines the terms and concepts (meaning) used

to describe and represent an area of knowledge, as well as

relations among them. Thus, an ontology includes: (a)

concepts (things) in the domains of interest, (b) relationships

between those things, (c) properties (and property values) of

those things, (d) the functions and processes involving those

things and (e) constraints on and rules about those things.

Ontologies are based on taxonomies which represent class

hierarchies in the object-oriented world and people are

generally used to designing taxonomies. For example, a

product catalogue is implicitly based on taxonomy.

Business information (content), and business processes and

applications, which use that content, need to be integrated so

that new business ecosystems can be created in a short time

span. High-level architecture enables metadata driven

development, deployment, execution and analysis of business

processes, applications and content. Ontologies provide a

clear separation of the “what” from the “how”, meaning that

business analysts can focus on the business aspects,

completely ignoring how declarative knowledge translates

52

into some kind of software system. Business analysts can

describe concepts in terms that stakeholders understand.

Innovation vs. Complexity

The continual launch of new products, services and line

extensions adds complexity throughout a company’s

operations and as the costs of managing that complexity

multiply, margins shrink.Finding a company's innovation

fulcrum is a two-step process. First, organizations need to

determine the zero complexity baseline, -the process costs of

selling an absolute minimum number of standard products.

In other words, what would be the company's equivalent of

Henry Ford's one size fits all Model T? Next, they need to add

variety back into the business system, -item by item, and

carefully forecast the resulting impact on customers’ sales as

well as the cost impact across the value chain. When costs

begin to overwhelm the added revenues, they have probably

found the innovation fulcrum.

53

Figure 29: Finding your Model T: ref. HBR.

54

Currentbusinesssystem

Currentbusinesssystem

Model T:zero-

complexity

baseline

Model T:zero-

complexity

baseline

Innovationfulcrum

Innovationfulcrum

Cost out the new

one-productprocess andestimated

impacton quality

Add optionsback in to meettrue customerdemand

Understandhow processeschange ascomplexity islayered back in

C h a p t e r 6

PROPOSITION

Tight Integration and Efficiency vs. Flexibility

A typical integration-centric approach to SOA is EAI 2.0. It's

a better form of EAI than in the past, but it's still

fundamentally focused on integrating application silos (EAI)

rather than dismantling the silos (SOA). The role of an ESB in

EAI 2.0 vs SOA, explain the fundamental difference between

SOA and integration. Service-oriented architecture (SOA) has

been increasingly adopted during the past five years, with its

promised benefits validated by early adopters. One of the

clearest lessons learned is that SOA is all about finding a

better approach, -rather than a better technology, for

enterprise application development. In 2008, we are

expecting to see a critical emphasis on establishing a new IT

culture, in which SOA-based projects have a better chance of

success.

SOA infrastructure technologies include solutions for service

enablement, messaging, orchestration, transformation,

enterprise integration patterns, management, and

registry/repository functionality. Because SOA is a better

approach to IT rather than a better technology, we will

continue to see in 2008 a proliferation of software products

55

aimed at satisfying the requirements of the SOA market. The

biggest influences on SOA projects during 2008 are likely to

come from enterprises addressing cultural changes related to

SOA adoption. New tools aimed at supporting SOA-based

designs, architectures and especially deployments will begin

to emerge.

Additional influences will be felt from three major technology

trends:

Commoditization, including open source and large data

centers;

Software abstractions, including modularity, inversion

of control and increasing use of patterns; and

Deployment options, including virtualization, grid,

multicores and other operational impact changes.

Trends for SOA in 2008 will be influenced by a combination

of cultural and technological issues.

Cultural Issues

Let's deal first with the changes related to IT cultural issues.

It's often said that SOA is an approach, not a technology. As

the number of enterprises with successful SOA-based

projects continues to grow in 2008, pressure on IT

professionals to investigate SOA as a potentially better way

to align IT spending with the bottom line will increase. In

other words, adoption rates for SOA are very likely to

56

continue to rise, pushing related cultural issues to the

forefront.

Organizations who have been working on SOA initiatives

from the past years advice to pay as much, -if not more,

attention to cultural issues such as architectural governance

programs, cross-departmental budgeting and keeping

reusable service developers insulated from application

project deadlines.

The right IT environment needs to be cultivated for SOA

success. This is virtually the opposite of the environment

found in a typical IT shop that focuses on bespoke application

development and maintenance. In a successful SOA

environment, resources, tasks, budgets and skills need to be

shared across projects instead of dedicated solely to a single

one of them. Every organization has to figure out its own

approach when tackling SOA-based projects, but cultural

issues definitely need to be considered. SOA governance is

not something you can buy, like software or tools, but if the

organization is not set-up right to begin with, all the

technology in the world isn't going to do any good. As SOA-

based projects continue to spread during 2008, this challenge

will become more and more apparent. So first and foremost

of the SOA trends for 2008 is an increased awareness of the

need to define an SOA culture and tie its significance to your

organization, and vigorously attack skill-set issues, budget

issues and corporate-level architectural issues in order to

57

ensure success with SOA initiatives. SOA tooling will evolve

to assist more aspects of the SOA project life cycle.

The Business Ecosystem

Figure 30: Business Processes and Service Level-drivenClients.

Value Chains

In order to be able to conceptualize any organization,

somebody needs a collection of the processes that it uses as

it generates its products and services. We cannot, however,

easily summarize all of the processes that make up a large

58

company. For the last twenty years the organizing principle

that most process analysts have relied upon has been the

value chain. The value chain concept originated by the

Harvard professor, Michael Porter. Michael Hammer relied

heavily on the concept in Reengineering the Corporation,

which he published in 1993. He urged companies to begin

their process work by identifying their value chains and then,

-as needed, to reengineer each value chain.

A value chain supports a product line, a market, and its

customers.

Figure 31: Michael Porter’s Value Chain.

Most of those who oppose the value chain approach support

an alternative model that is usually termed a value net.

59

Value Nets

Organizations are increasingly outsourcing processes and

need a model that let them represent value chains that are,

-in fact, orchestrated business processes provided by multiple

companies. Value nets enable organizations to tap into an

extended ecosystem of potential business partners to pursue

known opportunities and to learn about new opportunities

through inquiries from other organizations. Benefits can

include improving marketplace penetration, controlling costs,

compressing sales cycles, increasing margins and driving

innovation.

For example, an IBM value net consists of two or more

Business Partners who work together to create repeatable

solutions designed to meet customer needs. A successful

value net can help: (a) entering new markets, (b) creating

new business opportunities and (c) increasing revenues.

60

Figure 32: Most Companies will want both Value Nets andValue Chains.

Component Business Model (CBM)

Discussing of some more Complex Situations, IBM's Global

Services group has begun to urge companies to develop

Component Business Models (CBM), which they claim

derive from the value nets approach. IBM's Component

Business Models offer a very specific and practical approach

to organizing a Business Process Architecture, and thus they

move the discussion of whether one should emphasize a

value chain or a value net out as an issue that business

process architects and practitioners need to consider.

Figure 33: IBM’s Component Business Model (CBM).

61

A CBM starts by grouping processes into broad categories,

which it terms Business Competency Domains. The domains

vary from company to company and seem to be an informal

way to organize the specific company's large-scale processes.

Typical domains include Managing Customers, Supply Chain

and Administration. IBM subdivides these categories into

three fixed Accountability Levels: Strategy, Tactics, and

Operations, to form the basic CBM matrix. Both Strategy and

Tactics level processes tend to be management processes.

Operations level processes include both core and support

processes.

Figure 34: Advantages and Disadvantages of Value Chainsand Value Nets.

Business Maps

Business Process Mapping refers to activities involved in

defining exactly what a business entity does, who is

responsible, to what standard a process should be completed

62

and how the success of a business process can be

determined. Once this is done, there can be no uncertainty as

to the requirements of every internal business process. A

business process illustration is produced. The first step in

gaining control over an organization is to know and

understand the basic processes (Deming, 1982; Juran, 1988;

Taylor, 1911).

There is industry specific as well as cross-industry business

maps supporting service automation through today’s

Enterprise Resource Planning (ERP), Customer Relationship

Management (CRM), Business Intelligence (BI) & Data

Warehouse (DW) solutions, offered by many vendors. They

support standardization of processes, especially when

outsourcing services while they offer tools to secure the

competitive core functions of enterprises.

Figure 35: SAP ERP Business (Solution) Maps.

63

Cross-Functional Process Maps

Cross Functional Process Mapping improves process flow in

administrative areas, such as, (invoicing of customers' orders

or processing warranty claims). A Current State Map

allows seeing waste and problems that occur when

information travels across various departments or entire

functional areas. The participants may plan improvements,

-map the new process on a Future State Maps and create a

detailed action plan to implement proposed changes.

Enterprise Unified Process (EUP)

The Enterprise Unified Process (EUP) is an extension of the

Rational Unified Process. EUP shares and extends phases,

disciplines and best practices of RUP applied in software

development as well as modern project management

methodologies.

64

Figure 36: The Lifecycle for the Enterprise Unified Process(EUP)

65

C h a p t e r 7

MANAGEMENT

The IT – BM “Bipolar”

Almost everyone in the business community has, at one time

or another, complained of the IT obsession with new

technologies and their focus on implementation rather than

results. Too many business people have been subjected to an

IT enthusiasm for a new technology that seems to have little

to do with achieving key business objectives. Similarly, many

IT people have been frustrated by requests from business

managers to make changes that were vague, at best, and, in

the worst case, simply impossible.

Figure 37: Improving Specific Business Processes.

66

Too often, IT process people are focused on small-scale

processes that can be automated. While these processes are

important and need to be done effectively, they are well

below the level that business people are concerned with

when they speak of reorganizing a specific function area. So,

not only a common language is needed, but an agreement on

a common level of analysis. One might think that the right

approach would be to develop a business process

architecture that defines a hierarchy of business processes,

so each side could point to the processes they were

concerned with, and both sides could see how the processes

were related. Even this reasonable goal has often resulted in

frustration. Too often, the big picture is lost in an

overwhelming mass of details that are completely

incomprehensible to senior business managers.

The Business Process Maturity Model

An appropriate model for Business Process Maturity must be:

(a) multi-dimensional and (b) non-linear. Most organizations

consider (People, Process, and Technology) as main

dimensions but there are two other dimensions, just as

important in understanding the overall state and capabilities

of the organization (Controls & Strategy). The key seems to

be the ability to achieve consistent alignment across all

dimensions specified. When that is achieved, then the

organization is operating at a level where it can achieve

optimal results.

67

The five dimensions above provide the components about

which we can assess the capabilities of any particular

organization. As those capabilities advance, the company can

progress through the States of Process Maturity. These states

are as follows:

Siloed

Tactically Integrated

Process Driven

Optimized Enterprise

Intelligent Operating Network

As mentioned earlier, it is not a linear path to move from one

state to the next. In fact, the hurdles that must be overcome

vary considerably from one phase to the next, and while each

lever undergoes material change from state to state, different

levers play bigger roles in each of these progressive steps.

68

Figure 38: Maturity Model Typology.

The immaturity of business processes strictly limits the

value and success of IT systems.

The process maturity framework is a proven roadmap

for improving process capability and unlocking the full

value of IT systems.

The Business Process Maturity Model enables greater

fidelity between the actual performance of business

processes and their model-based representations.

In a BPTrends survey conducted in early 2006, respondents

defined BPM in four different ways, including:

69

A cost-saving initiative - 12%

A set of new software technologies - 16%

A systematic approach for process improvement - 26%

A new approach to organizing and managing

organizations using processes - 40%

70

C h a p t e r 8

FINANCIALS

Research Abstracts

Maximizing IT Investments

Organizations depend on the functionality provided by IT

even more when external economic factors make it difficult

to meet revenue goals. Businesses need to harvest all of the

value it can get from IT, so if IT organizations are late

deploying key applications such as ERP or CRM, -or if the

network suffers a significant outage, -the business is unlikely

to recover and still meet revenue goals.

71

Figure 39: Third-party Services in IT Organizations.

IT organizations need to change their processes to give other

business units more control over their part of the IT

environment. As part of this change, IT organizations should

implement role-based access controls that enable business

units to make changes to just their component of the IT

infrastructure. IT organizations should consider all

technologies existing in the marketplace to allow business

teams to implement corporate initiatives listed in the

chapters above.

Service Level Management (SLM)

Service Level Management is the primary management of IT

services, ensuring that agreed services are delivered when

and where they are supposed to be delivered. A Service Level

Manager is dependent upon all the other areas of Service

Delivery providing the necessary support that ensures the

agreed services are provided in a secure, efficient and cost

effective manner.

Service Level Agreements (SLA)

A Service Level Agreement, or SLA, is fundamental to service

provision, from the perspective of both the supplier and the

recipient. It essentially documents and defines the

parameters of the relationship itself. The quality of the

service level agreement is therefore a critical matter. It is not

72

an area that can be left to chance, and must command

careful attention. The SLA itself must be of sufficient detail

and scope for the service covered. Typical SLA sections

include: Introduction, Scope of Work, Performance, Tracking

and Reporting, Problem Management, Compensation,

Customer Duties and Responsibilities, Warranties and

Remedies, Security, Intellectual Property Rights and

Confidential Information, Legal Compliance and Resolution of

Disputes, Termination and Signatures. Other sections of

course may be applicable. Each of these sections must be

carefully crafted to ensure that the agreement properly

defines the service to be delivered.

Software as a Service (SaaS)

On-demand, Software-as-a-Service (SaaS) applications are

based on a recurring subscription fee and typically are a pay

as you go model. The cost may increase as the usage of the

application increases. In the SaaS model, costs are directly

aligned with usage (e.g. # named users, # transactions, etc.).

The biggest TCO factor of SaaS applications are the

subscription fees charged by the SaaS vendor. These fees are

all inclusive all include the monitoring, maintenance and

upgrades to the application as well as the training and

support of the end-user base. Compared with the ongoing

personnel costs of the traditional software application these

costs are quoted as part of the cost of deploying the SaaS

application. With traditional software, customers buy a

73

perpetual user license. This gives them the impression that

they “own” the software and can use it at will and in

perpetuity. With SaaS, instead of "owning" software,

customers pay for a subscription to software running on the

infrastructure owned by the SaaS provider. The customer’s

right to use the software goes away once they stop paying for

the subscription. They do not loose the rights and ownership

of data stored on the infrastructure of the SaaS vendor. The

dynamic between subscription and ownership is used as a

TCO argument in favour of buying traditional software. Why

rent when you can buy, especially when the plan is to use the

application for a long time. On the contrary, SaaS

applications offer many advantages over traditional software

including avoiding the huge hidden personnel cost in

deploying, running and maintaining traditional software.

Figure 40: The Rational for Outsourcing.

74

The Financial Case for a Service Catalogue

Figure 41: SaaS vs. Owned / In-house Systems.

Providing specific guarantees on the expected savings to be

made through the deployment of a Service Catalogue is

difficult because of the widely differing levels of maturity and

efficiency that exist before implementation. The following

table outlines example areas where potential financial

savings can be made through the use of a Service Catalogue.

The figures below represent conservative estimates of

savings through the introduction of an actionable Service

Catalogue for an IT organisation with 100 unique IT services

and 50,000 service requests annually:

75

Figure 42: The Financial Case for a Service Catalogue.

Return on investment calculations like the one above; provide

the basis for a serious debate about the potential value of

implementing the Service Catalogue. Even if all of the

savings promised are not delivered immediately, or if some

could be delivered through alternative means, the estimates

used in the above calculations are conservative and illustrate

the potential scope of possible savings. In reviewing these

figures we looked at evidence from other analysts, research

studies, and the direct experience of those working in this

field. The figures vary considerably between sources but the

weight of evidence based on those practitioners and clients

we interviewed, supports an overall level of expected savings

of a 30% reduction in the cost of delivering IT services and

76

up to 50% faster fulfilment cycle times in provisioning

services.

77

C h a p t e r 9

CONCLUSION

Concluding Remarks

A BPMS supports the model-driven manipulation of business

processes throughout the process life cycle, what we

describe in this paper, -an end-2-end business process.

Organizations should consider investing in BPMSs to

increase enterprise agility and encourage greater business

user involvement in the process improvement life cycle.

Documenting and implementing business processes of an

organization, forms a huge challenge, since there are many

issues to address, such as, agility, effectiveness, efficiency,

integrity of data and information, timeliness, scalability,

compatibility & openness, etc. The final deliverable should

address the expectations of sponsors and users, management

and workforce. It should answer with a persuasive manner

real case, -day to day scenarios. It should be resistant to

critique, -transparent and understandable, and at the same

time easily adaptable to a changing environment. It should be

able to accommodate additional and / or altered

requirements with the minimum cost, time and effort. This is

the purpose of the use of BPA (eEPC) Tools, BPMN Modelers

or MS-Office Applications: (a) faster and less expensive

process creation through process component reuse, (b)

78

business user engagement and (c) better context for process

monitoring. Agile BPM addresses more of these problems.

79

BIBLIOGRAPHY & SOURCES

BEA White Paper, Innovate over ERP with Service-Oriented Architecture, Business Process Management, and Enterprise Computing, 2007.

BMC Software, Warren Cook, BMC Service Request Management, Service Catalogs – The Heart of Service Request Management, 2007.

BMC Software, A Collection of Thought Leadership Articles on Issues, Best Practices, and Trends, Innovation: The Convergence of Information, Technology and Business, 2007.

BMC Software, Sharon Taylor, Ken Turbitt, ITIL Version 3: Support for the Growing Importance of Business Service Management, July, 2007.

BMC Software, Meeting the Challenge of Service Request Management, July, 2007.

BMC Software, Streamlining Service Request Processes: A Keyto Business Success, September, 2007.

BPMInstitute, Bruce Silver Associates, The BPMS

Report: BEA AquaLogic BPM 6.0, July, 2007.

BPMInstitute, Bruce Silver Associates, The BPMS Report: TIBCO iProcess Suite 10.6, July, 2007.

BPTrends, Volume 5, Number 11, Innovation &Process Change, June 19,2007.

BPTrends, Oscar Barros, IED,University of Chile, Business Process Architecture and Design, May, 2007.

BPTrends, A BPT Report, Curtls Hall, Paul HArmon, The 2006 BPTrends Report on Business Rules products, Version 1.0, April, 2006.

BPTrends, The 2007 EA, Process Modeling & Simulation Tools Report-2.1, Introduction, 2007.

BPTrends, The 2007 BPM Suites Report, An Introduction to BPM Suites, 2007.

Bruce Silver Associates, Industry Trend Reports, The BPMS Value Proposition, January, 2007.

Butler Group White Paper, Martin Gandar, The Service Catalogue and the CMDB, Front Office

i

and Back Office IT, July, 2006.

Burton Group, Anne ThomasManes, Enterprise Service Bus: A Definition,October 05, 2007.

Business Week, Six Sigma undermined Innovation at 3M, Special InnovationSection, June 11, 2007.

Competitive Focus, Leslie Martinich, An Innovation Framework: The Foundation for Two Complementary Approaches to InnovationManagement.

Compuware White Paper, Bryce Dunn, Linh Ho, Enabling Business and ITIntegration, March, 2007.

CSC White Paper, European Office of Technology and Innovation, Howard Smith, What Innovation Is, How Companies Develop Operating Systems for Innovation, 2008.

EMA Workbook, 5 Steps to Defining IT Services: A Hands-on Workbook, March, 2008.

Gartner RAS Core Research Note G00152906, Magic Quadrant for Business Process Management Suites, December 14, 2007.

Harvard Business School, Jim Heskett, What Is Management’s Role in

Innovation, November 30, 2007.

IBM, Global Business Services, Service-oriented Architecture, A Practical Guide to Measuring Return on that Investment, 2006.

IBM, DJ de Villiers, Mentor, Empulsys, Using the Zachman Framework to assess the Rational Unified Process, December 04, 2003.

Mayur R. Mehta, Sam Lee, Jaymeen R. Shah, Texas State University – San Marcos, Dept. of CIS & QMST, Service-Oriented Architecture: Concepts and Implementation, Nov.3, 2006.

Metastorm, Vendor Whitepaper, Bridging Business Models to System Implementation, November, 2007.

NewParadigm, Don Tapscott, Rethinking Enterprise Boundaries: Business Webs in the IT Industry, 2007.

Oracle, Ziff Davis Media, Shift from Tactical to Strategic Focus: Transforming IT through Convergence, Alignment and Good Governance, June, 2006.

SAP, Enterprise Service-Oriented Architecture

ii

from A Business Perspective, 2006.

SAP, Enterprise SOA Development Handbook, End-to-End Guide for Enterprise SOA Development, 2008.

Scheer, A. - W. ARIS – Business Process Modeling, 3rd ed. Springer, Berlin, 1999 – 2000.

Software & Information Industry Association White Paper, Software-as-a-Service; A Comprehensive Look at the Total Cost of Ownership of Software Applications, September, 2006.

Stefan Huttenrauch, Fundamentals of Service-Oriented Engineering – An Introduction -.

Telelogic, Achieve Business Process Analysis Successby Creating a Modeling Environment for Everyone, Version 1, August, 2007.

Versata, Understanding Service-Oriented Architecture, An Introductory Overview, 2004.

Workpoint, Next-GenerationBPM: Creating the Strategic Enterprise, 2007.

Dan Woods, Thomas Mattern, O’Reilly, Enterprise SOA, Designing IT for BusinessInnovation, 1st ed., April, 2006.

Leslie Martinich, Competitive Focus, An Innovation Framework: The Foundation for Two Complementary Approaches to InnovationManagement, November, 2004.

Justin J.P. Jansen, Frans A.J. Van Den Bosch, Henk W. Volberda, Rotterdam School of Management (ERIM), Exploratory Innovation, Exploitative Innovation and Ambidexterity, March, 2005.

Michael Tushman, Wendy K.Smith, Robert Chapman Wood, George Westerman, Charles O’Reilly, Harvard Business School, Organization Designs and Innovation Streams, September 8, 2006.

Peter F. Drucker, Harper Business, Innovation & Entrepreneurship, 1993.

iii

INDEX

http://www.apqc.org http://www.apqc.org/ OSBCdatabase http://www.bmc.com http://www.bpminstitute.org/topics/innovation.html?tac=105b http://www.bptrends.com http://www.businessweek.com/innovate http://www.cmdbf.org http://www.ecommercetimes.com http://www.enterprise-architecture.info/index-eu.htm http://www.enterpriseunifiedprocess.com http://www.ibm.com http://www.itbusinessedge.com http://en.wikipedia.org/wiki/ITIL http://www.oasis-open.org http://sdn.sap.comhttp://www.wikipedia.org

iv