MBIT Thesis

GRADUATE PROJECT ON
TECHNOLOGY MANAGEMENT
by
Dimitris Kosmidis
A thesis submitted in partial
fulfillment of the requirements
for the degree of
MSc in Management of
Business, Innovation and
Technology (MBIT)
Athens Information Technology
(AIT)
Sep. 30, 2008
Approved by Gregory S. Yovanof
Chairperson 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 BUSINESS
PROCESS INNOVATION
by Dimitris Kosmidis
Chairperson of the Supervisory Committee: Professor
Gregory 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..........................................................................1
End-2-End Business Process & Business Process
Workflow.......................................................................................
Innovation.....................................................................................
From strategy to execution......................................................
Business Process Expert...............................................................
Business Process Management (BPM)..........................................
Business Process Modeling Notation (BPMN).........................
Business Process Modeling Suite (BPMS)................................
Description..................................................................13
Innovation and Process Change..................................................
Enterprise Architecture (EA)......................................................
Process Classification Framework (PCF): a
framework for process improvement.....................................
Capability Maturity Model®
Integration (CMM®
I).................
Zachman Framework.............................................................
Definition....................................................................21
Service 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 Management
Database (CMDB)..................................................................
Market.........................................................................31
The Technology Adoption Curve.................................................
Hype Cycles...........................................................................
The SOA Maturity Model............................................................
Organizational Maps...................................................................
i

The ITIL v3 Application Example......................................
Strategy.......................................................................37
Innovation, Optimization, Agility.....................................37
The Imperative to Evolve.......................................................
Organizational Analysis vs. Organizational
Transformation...........................................................................
The Liquid Enterprise: Unlocking the Value of ERP
Systems..................................................................................
Business Integration, -a good place to start
innovating over ERP systems.................................................
The Object Management Group (OMG)......................................
Business Process Ontology.....................................................
Innovation vs. Complexity...........................................................
Proposition..................................................................45
Tight 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...............................................................54
The IT – BM “Bipolar”.................................................................
The Business Process Maturity Model........................................
Financials....................................................................58
Research 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...................................................................64
Concluding Remarks........................................................64
ii

LIST OF FIGURES
Number
Figure 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 an
Application-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), “Theory
of 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, Workflow
and 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 Process
Management 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 and
Exploratory 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 Reference
Model.
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: newScale
Inc.).
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 Six
Sigma’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

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 a
Process-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
Current
business
system
Current
business
system
Model T:
zero-
complexity
baseline
Model T:
zero-
complexity
baseline
Innovation
fulcrum
Innovation
fulcrum
Cost out the
new
one-product
process and
estimated
impact
on quality
Add options
back in to meet
true customer
demand
Understand
how processes
change as
complexity is
layered 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-driven
Clients.
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 and
Value 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 Chains
and 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 Key
to 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 Thomas
Manes, Enterprise
Service Bus: A Definition,
October 05, 2007.
Business Week, Six Sigma
undermined Innovation
at 3M, Special Innovation
Section, June 11, 2007.
Competitive Focus, Leslie
Martinich, An Innovation
Framework: The
Foundation for Two
Complementary
Approaches to Innovation
Management.
Compuware White Paper,
Bryce Dunn, Linh Ho,
Enabling Business and IT
Integration, 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 Success
by Creating a Modeling
Environment for
Everyone, Version 1,
August, 2007.
Versata, Understanding
Service-Oriented
Architecture, An
Introductory Overview,
2004.
Workpoint, Next-Generation
BPM: Creating the
Strategic Enterprise,
2007.
Dan Woods, Thomas
Mattern, O’Reilly,
Enterprise SOA,
Designing IT for Business
Innovation, 1st
ed., April,
2006.
Leslie Martinich,
Competitive Focus, An
Innovation Framework:
The Foundation for Two
Complementary
Approaches to Innovation
Management, 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.com
http://www.wikipedia.org
iv

MBIT Thesis

Recommandé

Recommandé

Contenu connexe

Similaire à MBIT Thesis

Similaire à MBIT Thesis (20)

MBIT Thesis