whitepaper-bpm-soa

8/7/2019 whitepaper-bpm-soa

http://slidepdf.com/reader/full/whitepaper-bpm-soa 1/12

Modernize Existing Enterprise Architecture and

Infrastructure Into a Service-Oriented Architecture

Business Process Modeling

Optimization, or Automation

Consolidate Process and Activities toStreamline Operations and Business Performance

Balance Scorecard or Similar

Performance Management Programs

Six Sigma or Similar

Quality Management Programs

Identify and Prioritize Legacy Systems and

Applications with Open Source Software

Continuous Process Improvement Initiative(s)

Rationalize and Consolidate Existing

Systems, Applications and Infrastructure

IT Govenance and Risk Management Initiatives

(not Related to Regulatory Compliance)

Programs for Ensuring and MaintainingRegulatory Compliance (e.g., Sarbanes-Oxley)

Source: Delphi Group

During the second quarter of 2005 Delphi

Group surveyed 110 firms across a broad set

of industries on their anticipated spending

for 2006. Respondents were asked to prioritize

activities from a list of approximately two

dozen categories relative to general IT

improvement, business process activities,

and compliance and governance issues. The

clear favorites, ranking above such issues as

Sarbanes-Oxley compliance, were the

modernization of existing IT infrastructure

around a service-orientated architecture and

the application of BPM.

B P M & S O A :N E X T G E N E R A T I O N B U S I N E S S

P E R F O R M A N C E I M P R O V E M E N T

A W H I T E P A P E R B Y D E L P H I G R O U P A N D S I N G U L A R I T Y

O C T O B E R 2 0 0 5

In Q2 2005, Delphi Group surveyed 110

firms about their 2006 investment priorities.

The top three responses were related to

Service Oriented Architectures (SOA) and

Business Process Management (BPM).

This whi te paper explains why.

Performance improvement of a business, at every

level of operation, has been a desirable goal

for every management team. For some

organisations, it is now becoming a very real and

tangible part of everyday routine. Today’s

generation of business leaders concentrates

unprecedented energy on performance

improvement, from transformational change

programs through to small-scale incremental

tweaks in the production cycle.

Evidence abounds – in the last decade alone,

massive transformations have been initiated.

Services - way beyond manufacturing - have

been moved halfway across the world. We are

now extending our marketing reach to buyers

and markets in countries we have never visited

and in unimaginable numbers, and those buyers

are being courted by a vast and ever-changing

0% 20%

24%

24%

24%

25%

26%

28%

30%

31%

31%

32%

36%

40%



universe of competitors. We are refreshing our

products and services, and the way in which we

package and deliver them, at unprecedented

speed – and all these trends are accelerating.

The chain of events leading from an innovative

idea to production availability is being shortened

dramatically. Two communities who need to

acquire that kind of flexibility (scalability and

adaptability) are the technical infrastructure

owners, and those responsible for the process

of building, shipping and supporting their end

product, in whatever form that is to take.

The infrastructure owners have discovered

Services-Oriented Architecture as the answer to

their need. Independently, business managers

are discovering Business Process Management

(BPM) to be their tool of choice, allowing them

to take ownership of their own flexibility

challenges.

The combination of SOA and BPM is becoming

the transformational technology platform of the

decade – apart from the inherent benefits of each

technology on its own, the combination

addresses one of the fundamental problems of

technologically-supported change programs.

W H A T I S T H E P R O B L E M

T H A T B P M & S O A S O L V E S ?

For several decades, it has been widely, if

reluctantly, accepted that newly-installed IT

systems will probably fall short of serving the

purpose for which they have been bought or

built. Every system that is developed experiences

diminishing returns over time, as the original

requirements evolve and the challenge to maintain

and update the IT system becomes more

burdensome. Business processes increasingly

evolve away from the systems that are built to

support them and the processes themselves fail

to evolve quickly enough as customer needs

change. This relentlessly growing disconnect

between business requirements and the

processes and systems deployed to meet them

is widely accepted as a truism by technology and

business leaders alike. We will call it the

“Requirements Gap Syndrome” (see Fig. 1).

Business Process Management (BPM) and

Services Oriented Architecture (SOA) are two

technologies that in combination have the

potential to not merely treat the symptoms of the

Syndrome but to eradicate it altogether.

The existence of a disorder such as

“Requirements Gap Syndrome” is not surprising

when the perpetuating mechanisms are

considered. Although both business and IT staffs

work to bring new and improved processes to

bear for the benefit of their customers, the two

professional disciplines are divided by the nature

of their functions. This division exists to some

degree in nearly every sizeable enterprise.

Bridging this divide has become an industry in

itself as the gap hinders efforts to build integrated

TraditionalProcesses &Systems

Evolving BusinessNeeds

Time

Fig. 1 - The Requirements Gap Syndrome

BPM+SOA-basedProcesses &Systems

Size ofRequirements Gap

B u s i n e s s F i t

P A G E 2



The first major shift in software evolution

resulted from the introduction of the PC

and the client/server architecture. As has

occurred with every major change in

architecture, the result was the emergence

of new market leaders and the eventual

disappearance of most of the dominant

players of the previous era.

The next significant shift in software

architecture is from n-tier client/server

to the inherently multi-tiered SOA. Just

as has been seen with each generational

change in software evolution, this shift

will no doubt result in the re-drawing of

the competitive landscape for commercial

software vendors.

P A G E 3

business systems capable of rapid response to

the ever-evolving need for change. At the initiation

stage of any major project, the in-house business

owners and IT staff usually delegate the task of

articulating the detailed business process

requirements to a hybrid person or team, able

to understand and articulate problems by

negotiating between the two communities. Whilst

moderately effective, this approach often leads

to an unhealthy concentration of knowledge -

the revised business process is truly understood

only within the project team, which is a temporary

body, and the Requirements Gap Syndrome is

thus perpetuated.

The cure for the Syndrome is a combination of

treatments, which are claimed by some to be out

of the lab and well through their clinical trials.

The treatments are Service Oriented Architecture

(SOA) and Business Process Management

(BPM).

T H E B E G I N N I N G S O F A

C U R E :

T H E E V O L U T I O N O F S O A A N D

B P M

In the Q2 2005 Delphi Group survey in which

110 firms were asked about their 2006 investment

priorities, the top three responses were related

to Service Oriented Architectures (SOA) and

Business Process Management (BPM). In

contrast, investments to address regulatory

compliance and risk management topics rated

joint ninth in priority. This reflects the fact that

neither SOA nor BPM are still “in the lab”. Indeed

this interest indicates recognition of the potential

these technologies offer to resolve pressing

issues firms face today. A brief review of how

these two technologies have evolved will shed

light on why they, especially their use in

combination, hold such promise.

Focus: Service Oriented Architecture

While a relatively new phrase to some, “Service-

Oriented Architecture” or “SOA” has already

become well ingrained within the business

computing vernacular. It is nearly impossible

today to pick up any IT periodical without

encountering a reference to SOA. Recently it



has become the rallying cry of virtually every

enterprise software vendor, and many have taken

great liberties in its meaning and definition. It

would be easy to dismiss the current flurry of

“buzz” surrounding SOA as simply the result of

market ing hype

and/or the product of

inflated expectations.

To do so, however,

would be a grave

miscalculation.

SOA is the manifestation of the current economic

climate in which turbulent times have forced a

crisis of integration upon every organization. For

the last decade there has been a continuous

drive to deliver processes and systems that are

sufficiently integrated and flexible to provide

liquidity in an organization’s information and

process assets. It is only recently that IT platforms

such as .NET and J2EE, network interoperability,

and standardization have evolved to a point

where they can support the vision of these sorts

of distributed, component-based applications.

Based on recent Delphi Group research, the

transformation of existing IT systems and

infrastructure to a SOA basis is now viewed by

many as their top priority.

SOA recognizes that what is needed at the core

of an enterprise’s IT systems is something far

more flexible and dynamic that the monolithic,

set-in-stone solutions of recent decades. In the

same way that the foundations of a building

remain intact and immutable while the structure

erected on them may be rebuilt many times, SOA

lays foundations for information systems that willsupport an ever more malleable business

structure.

An important catalyst for change was the Internet

and the advent of Web-based computing that

combined the benefits of host-based computing

with client/server's richer functionality. The Internet

presented the need for delivering Web pages

and performing functions not possible within a

Web browser, as well as standard protocols to

access both. This necessitated pushing more

and more capabilities through application ("app")

servers. The migration of functions led to the

multi-tier or "n-tier" client/server architecture, and

resulted in increasingly decentralized applications

and business logic running on top of app servers.

Just as the abstraction of data management led

to an explosion of new client/server applications,

the availability of more and more capabilities to

app servers led to a new wave of Web-based

application development. The richer platform of

app servers allowed for "quick and dirty"

application development, and gave rise to an

increasing volume of “homebuilt” software. In the

short time since the late 1990s, when the

presence of app servers and Web-based

computing began to flourish, the typical desktop

environment has changed from a relatively static

and stable suite of core applications to a collection

of dynamic network-delivered applications. Many

of them were built internally for specific (and

often short-lived) purposes.

Application frameworks built around an SOA

environment allow the elements of business logic

to be broken out through the adoption of service-

oriented architecture and broken down into

individually callable function points. The result is

that the power to change business processescan be given to business staff without threatening

the integrity of business data and infrastructure,

“SOA lays foundations for

information systems that will

support an ever more

malleable business structure”

P A G E 4



P A G E 5

and without requiring IT involvement in process

changes.

The resulting approach is to build applications

as a collection of individual components,

connected and coordinated by a separate layer

of business logic. Although componentization

and its inherent benefits for software reuse has

been common within the world of object-oriented

programming, the emergence of open standards

for integration (most notably the core Web

services stack of SOAP, WSDL, XML and UDDI)

present a standard application-independent

means for components to be exposed as a library

of invocable services. This is the essence of

SOA. SOA can itself be “wrapped” around legacy

systems and components, which brings even

those systems into compliance with the structure

of reuse and flexibility, albeit purely from the

integration perspective.

SOA enables the segmentation of specific

appl icat ion services into independent

components, which then can be built

independently from the business processes

which use them. This allows development of

executable processes as a set of loosely-coupled

activities rather than explicitly coded steps, and

also permits software to be quickly customized

to meet immediate business requirements.

Thus, SOA provides a highly flexible integration

and process reuse structure, replicable across

an entire enterprise with clear and tangible

benefits measured in massively accelerated time-

to-market, and significant development and

maintenance cost savings.

Focus: Business Process Management

Two key evolutionary trends have advanced one

of the fundamental charters of BPM: putting the

management of business logic in the hands of

business managers without threatening the

integrity of the application logic (the infrastructure

that is rightfully managed and protected by IT

personnel).

The first trend concerns the ownership of process

change. BPM first emerged as an identifiable

software segment in 1999, and over the last five

years the focus of the technology has shifted

from automation and integration to orchestration

and coordination . In the early years (1999-2001),

BPM initiatives tended to be parochial and

integration-centric; early deployments were often

aimed at closing gaps in existing ERP

deployments. BPM solutions of this period were

differentiated by proprietary measures, such as

application adapters, data transformation

capabilities and product-specific process

definitions Firms then began building process-

centric applications with BPM frameworks, and

the technology had evolved from middleware

into development environments where the

business process owners were heavily involved

- even to the point of responsibility - in the change

management project itself.

In the absence of BPM, business logic exists

primarily in two places: 1) embedded inside of

applications and IT infrastructure where it is out

of reach to business users; or 2) in the minds of

business process owners and subject matter

experts, or written down in policies and

procedures, but otherwise separate from the

systems and applications used to support



operations. What BPM has introduced is the

ability to abstract business logic (e.g., processes,

business rules, user roles, task descriptions, etc)

and allow this to be managed and maintained

within a separate system by non-technical,

business-oriented users.

The second BPM-related trend is connected to

the evolution of complementary standards such

as Web Services. The pace at which advances

in the development and design tools within BPM

frameworks is accelerating is clear - and these

a r e a l l a b o u t

reducing the cost

and complexity of

application and data

integration.

Enabled by standards-based protocols (notably

the core Web Services stack of XML, SOAP,

UDDI, and WSDL plus specialized constituents

built in XML) and as result the emergence of

Service-Oriented Architectures (SOA), BPM

frameworks gained flexibility and agility in

resolving integration issues. This fact is critical

to taking advantage of the agility and adaptability

offered by BPM. What SOA provided BPM and

other software environments is a common means

for communicating between applications, such

that connections do not need to be programmed

in advance, as long as the BPM environment

knows where to find information and how to

access it. Again, this is critical to dynamic

processes where the specific information,

activities and roles involved with a process may

not be predetermined but identified as the process

progresses.

O R C H E S T R A T I O N :

M O B I L I Z I N G C O M P O N E N T S A N D

S E R V I C E S F O R B U S I N E S S

A D V A N T A G E

A key concept underlying SOA and BPM is that

of “orchestration” and it is of vital importance in

addressing the Requirements Gap Syndrome.

Systems built for a particular purpose are often

not applicable to other situations. Many processes

and systems currently in use need much greater

flexibility in order to adapt to business needs,

but change is difficult and slow to take hold within

the enterprise. Fortunately it is no longer

necessary to accept delivery of systems with

such limitations. When used together, BPM and

SOA provide a new capability to orchestrate

system components or services to meet new

business requirements as they surface.

When the early Model-T Fords rolled off theproduction line they represented a revolution.

The long and expensive process of building a

car had suddenly become short and inexpensive.

Fast assembly of pre-built components replaced

arduous fitting of individually crafted pieces.

Although components could be quickly and

economically assembled into a finished product

that met a need the resulting product was limited

to one style of car available in only one color.

Today the most modern automobile plants use

the same production line to produce several

different models of cars, and can adjust quickly

to switch between models and reuse componentry

intelligently. The shift of focus is toward the

effectiveness with which componentry can be

“orchestrated” in order to produce the specifically

desired car.

“BPM and SOA provide a new

capability to orchestrate

system components”

P A G E 6



B P M A N D O R C H E S T R A T I O N :

T H E E V O L U T I O N O F G O A L -

O R I E N T E D P R O C E S S E S

Orchestration has changed the role of BPM

frameworks from that of a transit system designed

to shuttle data from one point to another over

predefined routes, to that of a virtual power user

that “knows” how to locate, access and initiate

application services and information sources.

Orchestration-focused BPM frameworks tap this

capability to support business performance

through the application of goals, policies and

rules, while adjusting the flow of the process to

accommodate outcomes not easily identifiable

in advance.

Consider a practical example - the admission of

a patient for medical treatment. What is involved

is in fact a process, yet the specific sequence

and set of activities does not follow a specific

script, but rather is based on a diagnosticprocedure which likely involves applying a

combination of policies, procedures, other rules,

and the judgment of healthcare workers.

Information discovered in one step (e.g., the

assessment a given condition) can drastically

alter the next set of steps, and in the same way

a change in ‘patient state’ (e.g., patient goes into

heart failure) may completely alter the process

flow in other ways. This type of process, which

assembles itself as it executes, requires the

execution-time assembly of process components

which only BPM-centered orchestration can

provide.

This transition in computing orientation can be

described as the shift from Event-Driven to Goal-

Oriented. In event-driven computing, systems

respond to a specific event – a request for

information is received and the appropriate

information is sent, or a process step is complete

and so the results are recorded and the next step

is initiated. In most cases, the nature of event-

driven computing

requires explicit

s c r i p t i n g o r

programming of

outcomes. What

earlier workflow and

BPM systems provided was the ability to stitch

together a series of events into a process

sequence. These tools allow some variability of

process flows (such as ‘splits’ and ‘joins’) but the

majority of the process is predetermined.

The result of these systems that impose rigid

process models is often that only part of the

process is managed. For example, moving a task

from one individual to another may be automated,

but what happens when a step in the process is

in the hands of a given individual may occur

entirely outside of the process management

system. The goal-driven approach that defines

orchestration allows for processes to be defined

in terms of an end goal and milestones, but does

not require an exact path or process flow to be

programmed in advance.

The patient admission scenario described earlier

is an appropriate example. What really

differentiates this as a goal-driven system is the

ability to determine the sequence of a process

based on current context. A BPM system can

examine appropriate business rules and other

defined policies against the current status of a

process or activity to determine what step shouldoccur next and what information is required.

“Information discovered in

one step can drastically alter

the next set of steps”

P A G E 7



The benefits of orchestration to operations

managers are clear - especially if the resources

which those managers may wish to deploy as

part of a new or revised process orchestration

are themselves exposed as Services, obviating

the need for detailed knowledge of complex

legacy integration protocols and mechanisms.

Thus, SOA and BPM actually leverage each

other - a compelling combination.

B P M + S O A :

C O M B I N I N G P R O C E S S

M A N A G E M E N T W I T H S E R V I C E -

O R I E N T A T I O N

As explained above, the introduction of an

independent process tier is BPM’s major

contribution to business computing. It puts the

management of business logic in the hands of

business managers without threatening the

integrity of IT systems’

application logic. In

other words, the

introduction of an

independent process

management t ier

a l lows the core

elements of IT infrastructure to be managed by

IT personnel, while allowing business processes,

business, interaction models and application

behaviour (i.e., business logic) to be managed,

and safely improved, by those directly responsible

for them.

SOA provides orchestration of IT assets. BPM

provides orchestration of business process

assets. The two together provide a platform on

which flexible business operations can be built.

Recognizing the power of this combination of

SOA and BPM has led some to coin a term for

the combination itself - BPM+SOA results in a

flexible “Business Process Platform” that

orchestrates process and system components

to meet continually changing business needs.

Business process management allows processes

to be designed independently from any single IT

system and leveraged as shared business logic.

The breakthrough here is analogous to that made

when the definition of information was separated

from IT systems. In that revolutionary step in the

development of how enterprises manage their

data assets, data was defined in separate,

independent data structures. Data values were

stored in databases for access whenever needed

by whomsoever needed them. The terminology

that emerged for the technology that catered for

data in this way was “Relational Database

Management Systems” (RDBMS). Today an

analogous technology enabling the extraction of

business process into a separately manageable

tier in an enterprise is being called Business

Process Management Systems (BPMS).

By themselves, Web services and other

components in an SOA-based IT infrastructure

are simply smaller islands of automation.

However, process orchestration allows these to

be coordinated within business processes. The

understanding and manipulation of Service

Oriented Architectures and IT systems built upon

them today requires a high level of skill in

technology, but BPM technology is specifically

designed as a tool that staff who are not

technology professionals can use with ease.

What SOA and BPM have in common is theirfocus on pragmatic and fast reusability of

“What SOA and BPM have incommon is their focus on

pragmatic and fast

reusability”

P A G E 8



P A G E 9

components. In combination, SOA + BPM allow

both business and IT staff to quickly create, and

subsequently evolve, business processes and

supporting IT systems which closely meet and

follow business needs. The result is that the

Requirements Gap Syndrome is no longer an

inevitable factor in the makeup of an enterprise.

The Business/IT divide, if not obliterated, is much

more effectively bridged than at any time before.

SOA and BPM have thus far been viewed as

distinct technologies, evolving along their own

paths in response to different drivers. Yet the

natural synergies between BPM and SOA are

apparent. To realize the “on-demand” process

and system environments that businesses need

requires that these two technologies be leveraged

together. Simply put, the combination offers:

an IT infrastructure that is SOA-enabled,

allowing the fast and simple assembly of IT

systems to meet business needs as they

arise

a process infrastructure that is likewise

“service oriented”, allowing business

processes to be quickly and easily built and

optimized.

Under the hood, so to speak, the core constituent

pieces of SOA and BPM that make this possible

are:

a registry and discovery process to identify

and access the suitability of available process

and IT components;

a component-based framework for

constructing processes and applications on-

demand using metadata and process models

(often described as “codeless development”);

a platform capable of orchestrating

componentized services within registry or

through third party interfaces; and,

an ability to orchestrate SOA-enabled IT

systems for the purpose of executing abusiness process

The transformational impact of SOA and BPM is

largely about making what is in place more usable

and much more adaptable. It is about gaining

greater leverage of existing assets, rather than

simply making new software investments.

One of the core advantages of this service-

oriented approach is that it allows processes and

applications to access other systems on a just-

in-time basis, instead of having to build all

integration points in advance. This ‘”loosely-

coupled”’ approach is distinct from previous

business and system architectures. Rather than

binding all functions and activities into a tight ball

of closely defined processes and compiled

software, a service-oriented approach allows the

development of adaptable, living processes and

applications where capability is governed by

business process models that include rules,

process and roles.

The process-driven and service-oriented

architecture presented by the combination of

SOA and BPM provides an ideal environment for

building adaptable, model driven composite

applications or “composite apps” from existing IT

assets and infrastructure.

Composite Apps are process-driven, typically

Web-based applications built from virtualized

application components and abstracted services.



P A G E 1 0

Composite apps leverage processes and

interaction models to manage screen-flows,

presenting a unified and personalized desktop

(whether Web or Windows) where multiple

screens across multiple systems would otherwise

be required to access the same information.

Process and Rule Management engines

orchestrate the sequencing of process steps,

the flow of information, and triggering of individual

activities, such as introducing a specific offer

based on customer circumstances. These

engines represent the ‘”heart”’ of solutions built

within a customer-centric architecture. Process

engines provide the ability for business logic to

be defined and managed separately from

application logic, allowing changes to rules and

process to be made without affecting underlying

systems or interaction channels.

Where prior generations of technology and

previous methods of technology development

came with the debilitating Requirements Gap

Syndrome as part of their very makeup, the

BPM+SOA combination is free of the disorder.

Businesses that use the combination of

BPM+SOA will find that the flexibility required

for competitive advantage in their business

operations is mirrored by an equal flexibility in

the systems which support the business.



T H E N E X T S T A G E O F B P M

A N D S O A E V O L U T I O N

Every 10 years or so a catalyst materializes that

is capable of shifting the software market axis

enough to displace incumbent leaders to allow

new players and products to quickly rise in

prominence. Who was the leading independent

software vendor 30 or 25 years ago? It was not

Oracle or Microsoft or any other brand name

many might guess, but one since long lost in the

annals of software history. It was Cullinane (later

Cullinet), the first software company to be listed

on the New York Stock Exchange, whose

mainframe-based products were among the most

widely deployed software ever developed. At its

peak, Cullinet and its contemporaries on the

mainframe seemed unstoppable. Yet in the

predictable pattern of the software industry, the

axis shifted and these vendors (as well as the

mainframe platform) ceded to the client/server

"revolution" of the late 1980s and early 1990s.

While someone may argue that the emergence

of the PC was most responsible for these changes,

the more likely tipping point was the emergence

of SQL and the ability to centralize data

management separate from applications. By

allowing abstracted data management and

presenting a standardized means for reading it

SQL made inevitable the "two-tier" architecture.

By moving the database onto its own tier, it could

then be accessed by various applications running

on clients’ PCs. This ultimately paved the way

for an explosion of client/ server "Killer Apps"

(ERP, HRMS, etc.) and a new set of brand leaders

who displaced forever the Cullinets of the previous

generation.

The direction of all systems and IT

i n f r a s t r u c t u r e

today is becoming

i n c r e a s i n g l y

service-oriented.

This has led many

to recognize the

need to transform systems and operations

around an SOA model, leveraging BPM to

build adaptable, composite applications

capable of supporting today’s constantly

changing business environments. At the heart

of these solutions are process engines,

enabling the separation of business logic and

application logic, and allowing changes to

rules and processes to be made without

affecting underlying systems or interaction

channels.

With SOA providing orchestration of IT assets

and BPM providing orchestration of business

process assets, enterprises now have the

option to build a platform that will support

truly f lexible business operat ions.

Recognizing the power of this combination,

and accepting or not the label “Business

Process Platform” for the flexible operational

infrastructure that results, the potential

benefits are immense. The Requirements Gap

Syndrome can be treated and, ultimately,

eradicated – and for the first time in many

industries’ history, those responsible for

business operations can be fully enabled to

take charge of business operations

performance.

“Every 10 years or so a

catalyst materializes that is

capable of shifting the

software market axis”

P A G E 1 1



Cable House54-62 New Broad Street

London EC2M 1JJ

United Kingdom

TEL: +44 20 7826 4470

EMAIL: [email protected]

711 Third Avenue

Suite 900

New York

NY 10017

USA

TEL: +1 212 203 9360


32 Maxwell Road

#03-13

Whitehouse

Singapore 069115

TEL: +65 9616 7732


Headquarters

100 Patrick Street

Derry BT48 7EL

Northern Ireland

TEL: +44 28 7126 7767



WEB: www.profit-thru-process.com

Founded in 1994, Singularity is a leading provider of Business

Process Management (BPM) solutions to world-class

organizations such as JPMorgan, BT, Raymond James,

Wyeth Pharmaceutical and UBS.

Using our award-winning BPM solution, the Singularity

Process Platform, customers build, execute, monitor and

optimize high-performing business processes that deliver

tangible results. Through offices in London, New York and

Singapore, and development centres in Ireland and India,

Singularity offers market-leading process technology combined

with extensive consulting and project delivery expertise.

Delphi Group delivers strategic advantage at the intersection

of business and IT. Our thought leadership advisory services

have assisted more than 20,000 professionals in the Global

2000.

PEROT SYSTEMS, DELPHI and the DELPHI logo are

registered or unregistered trademarks of the Perot Systems

or its subsidiaries in the United States and other countries.

Delphi Group

111 Huntington Ave

Suite 2750

Boston, MA 02199

TOLL FREE: + 1 800-335-7440

TEL: + 1 617-247-1511

FAX: + 1 617-247-4957

EMAIL: [email protected]: www.delphigroup.com

whitepaper-bpm-soa

Documents