IDC-paper

8/3/2019 IDC-paper

1/16

W H I T E P A P E R

A r c h i t e c t e d t o L a s t :T h e E x p a n d i n g R e l e v a n c e o f S e r v i c e - O r i e n t e d A r c h i t e c t u r e

Sponsored by: IBM

Stephen D. Hendrick

April 2011

I D C O P I N I O N

The term service-oriented architecture (SOA) invokes differing responses depending

upon whom you talk to. Some members of the analyst community feel that SOA is in

need of a "makeover." C-level business managers sometimes grow nervous because

of the "A" word in the term SOA. Developers are generally supportive of what SOA

represents, and vendors would like to see a higher level of adoption and leverage of

SOA products.

What's missing from these stereotypes is a perspective on what is really happening in

the industry. The reality is that IT is in the midst of a very significant transition from

software to services. This transition is occurring because of architectural, technological,

and business model changes that are designed to expand and enhance the role of IT

within the enterprise. This transition from software to services is the next step in the

evolution of SOA and provides confirmation that the principles behind SOA are sound

and remain relevant in light of the changes that are occurring in IT.

The architectural bent of SOA creates some challenges for vendors in bringing SOA

products to market. However, modern application development, which is now largely

based on SOA principles, is proof that SOA's influence is expanding. The fact is thatSOA represents a change in software design that came about in the wake of the

distributed computing movement. As newer devices including tablets,

smartphones, and cloud services gain traction, SOA will become the de facto

standard for how the industry supports the growing appetite for software services.

I N T H I S W H I T E P A P E R

This white paper explores SOA's relationship with and relevance to IT and business.

The evolving software marketplace, which is transitioning from software to services,

provides a context for better understanding the role of SOA in application

development and deployment (AD&D) today and over the next five years. Recentsurvey-based research and IDC's top-line forecast for SOA are presented in this

paper and help communicate the value, opportunities, and challenges associated

with SOA.GlobalHead

quarters:5SpeenStreetFramingham,

MA

01701USA

P.5

08.8

72.8

200

F.5

08.9

35.4

015

www.i

dc.com

8/3/2019 IDC-paper

2/16

2 #227837 2011 IDC

S I T U A T I O N O V E R V I E W

Although SOA has been with us in a formal way for a decade, the roots of SOA go

back to the beginnings of distributed computing. These roots run deep and have been

cultivated to yield an architecture that is abstract enough to ensure lasting relevance,

extensible enough to enable evolution and refinement, and focused enough to drive

value beyond the boundaries of IT and into the business of the enterprise.

F r o m S i l o s t o S e r v i c e s

The evolution of software over the past 20 years has involved a number of key

transitions. These transitions help explain how IT has evolved from its monolithic

origins into the siloed instantiation of IT today and to a more rationalized service-

oriented environment beyond.

One of the most important trends in application development is the transition from

coding all aspects of an application to developing applications that leverage runtime

componentry, typically in the form of a platform for application development and

deployment. This transition is very pronounced in the AD&D markets, which provide

the tools and technologies that professional developers use to build and deploy

applications. If we look at the spending on AD&D tools, we find that in 1990, 66% was

focused on tools to code applications and 34% was dedicated to tools to deploy

applications. In 1990, the majority of deployment spending was aligned with database

engines and transaction processing monitors. By 2010, spending on AD&D tools had

reversed. Only 23% was focused on tools to code applications and 77% was for tools

to deploy applications. However, by 2010, the array of deployment tools had grown

considerably from database engines and transaction processing (TP) monitors to

include products such as data services, application servers, integration servers,

business process management systems, business rule management systems,

browsers, and portal servers. Platforms allow vendors to bring many of these core

deployment products together to provide a more complete environment for both

building and deploying applications. This transition from development to deployment

by itself has facilitated an immense change in how we build applications.

One of the most obvious implications of this transition from development to

deployment is the change from coding to configuration. Modern deployment platforms

provide numerous runtime capabilities that speed application development while

simultaneously improving the quality of the application, leveraging well-vetted and

more highly abstracted platform components. Deployment platforms today provide

immense value and represent something akin to a "destination resort" for professional

developers because of the many capabilities that they now provide. These runtime

capabilities help simplify software development by abstracting away the lower-levelcoding that otherwise would be necessary. While we have not yet reached a point

where application development is completely configuration based, business process

management systems show that it is possible to come quite close to this objective.

Another implication of this transition from development to deployment is the support

that is provided for multitier application development. Deployment products are

designed with clear interfaces that enable them to receive, process, and deliver

content. Interfaces are required to leverage the runtime capabilities of the deployment

8/3/2019 IDC-paper

3/16

2011 IDC #227837 3

product. Consequently, as deployment products were developed around the key

constructs for application development (data management, hosting, messaging,

processing, decisioning, and user interaction), support expanded from one-tier, to

two-tier, to three-tier and n-tier application development. The advantages that come

from loosely coupled components are well documented but are really possible only by

standardizing how components interface with each other.

A more recent implication of this transition from development to deployment is cloud

computing. The most compelling characteristics of cloud computing are its shared

service and self-service models. The shared service model picks up where

virtualization leaves off. Virtualization abstracts away the complexity of managing a

heterogeneous collection of servers while simultaneously driving utilization rates

higher. A shared service model similarly provides increased efficiency by driving

higher utilization of active application instances, which reduces the number of

instances and helps consolidate resources and reduce system complexity. A shared

service model also places a premium on the separation of concerns principle because

a higher level of autonomy must be introduced to isolate users, data, and process.

Likewise, vendors that offer cloud services must build their products to a higher

standard to ensure that they can reliably meet the service-level agreements (SLAs)

that they define with their customers. Consequently, these cloud services must have

a very explicit interface and a well-defined usage model to ensure their successful

use in a public cloud, private cloud, or hybrid cloud.

Figure 1 brings many of these transformative characteristics together in one diagram.

The differing approaches to application development in Figure 1 have a long life span

and are both additive and cumulative. In other words, with each new generational

approach to application development, new technologies and techniques are

introduced that provide more effective ways to build or integrate applications. These

new technologies and techniques usually don't replace existing tools, but they do

provide better ways to address business needs.

8/3/2019 IDC-paper

4/16

4 #227837 2011 IDC

F I G U R E 1

F r o m S i l o t o S e r v i c e : T h e T r a n s f o r m a t i o n o f I T

Source: IDC, 2011

This description of key changes that have occurred in application development and

deployment over the past 20 years is intended to provide a context for better

understanding the contributions of SOA.

Figure 1 mixes approaches to service development (2GL, 3GL, 4GL, SOA) with

service delivery (cloud). This is one of the reasons why cloud services, which can

conceptually support any method of service development, have such expansive reach

across abstraction, style, and structure.

K e y S O A C o n s t r u c t s a n d A t t r i b u t e s

SOA in itself was an evolution of industry thinking around distributed computing and

componentization. The key principles that guided the development of SOA includeservice modularity, interoperability, standardization, identification, and provisioning.

These principles remain operative today because they reflect an elegant balance

between being specific enough to drive adoption yet abstract enough to be

extensible.

The transition from development to deployment that began 20 years ago occurred

because the software industry was engaged, as it is today, in a quest for better

capabilities that translate into economic value for customers and vendors alike.

2GL3GL

4GL

SOA

Higher

Lower

Abstraction

Code Configure

Past Future

Time

Development

Deployment

Style

Structure

Cloud

8/3/2019 IDC-paper

5/16

2011 IDC #227837 5

The path of this evolution represents the collective thinking of the world's most

talented technology officers and exists for a reason. The path we are on from silo to

service represents an extraordinarily well-conceived approach to building applications

that encompasses most of what we know about software architecture and design.

SOA itself was built on decades of accumulated experience in how to build and how not

to build applications and systems. Subroutines, remote procedure calls (RPCs), the

Component Object Model (COM), the Common Object Request Broker Architecture

(CORBA), the PC, client/server, the distributed computing environment (DCE), and

many other industry efforts influenced what SOA is today. It's important to recognize

that SOA is well into its first decade of use and has outlived many of its predecessors.

The path that we are on for the near term will stress services more heavily as will the

variety of new delivery models for these services. Consequently, as we transition from

software to software as a service, more mature SOA principles will be increasingly

needed to ensure efficiency and manageability in the face of added complexity.

SOA enables us to define services, which are collections of tasks that are made

accessible through an interface. Service contracts control how services can be

accessed, and flexibility around service implementation ensures wide-ranging

environmental support. The message-based architecture of SOA is what enables

services to be loosely coupled and developed in granular ways that facilitate reuse.

However, for SOA services to communicate effectively, services must be accessible.

Accessibility is accomplished by two additional constructs: a registry that oversees

service access and an enterprise service bus (ESB) that enables the movement of

messages between services. The design of SOA makes it effective at establishing a

wide range of services that can be sourced from existing legacy systems or built from

scratch and connected together to facilitate interoperability or reengineered to

facilitate integration.

T h e R o l e o f S O A i n t h e E n t e r p r i s e

SOA is interesting in that it provides value to both IT and the business. The architectural

focus of SOA provides IT with a framework to address both tactical and strategic

development tasks. The service orientation of SOA is aligned with the needs of the

business because business services are the building blocks of business processes,

which uniquely identify and position the business relative to its competitors.

In practical terms, SOA is seeing use in businesses to address integration tasks. The

siloed characteristic of most organizations makes it difficult to define business

processes that span silos. Point-to-point connectivity is one way to address

interoperability needs but fails to meet requirements pertaining to maintainability,

scalability, and extensibility. SOA provides a generalized framework for addressinginteroperability and integration.

The real benefit of SOA is that it is able to appeal to organizations on any level. There

is value for both IT and the business, the architecture of SOA allows it to relate

effectively to both legacy and modern applications, and SOA can support a wide array

of activities ranging from simple system-to-system interoperability to being the

underlying architecture for new system design with high levels of component reuse.

8/3/2019 IDC-paper

6/16

6 #227837 2011 IDC

Organizations today are using IT in many different ways to improve their competitive

position. A 2010 IDC survey of 300 organizations in North America found that

application integration was the leading IT approach and was used by 62% of

respondents to advance their competitive position, as shown in Figure 2. Risk

management and compliance ran a close second at 61%, followed by mobility

solutions (58%), business intelligence (56%), collaboration (54%), and application

modernization (51%). SOA has applicability to all of these activities, although how

SOA is leveraged differs by organization size.

F I G U R E 2

T h e L e a d i n g W a y s i n W h i c h O r g a n i z a t i o n s P l a n t o B e M o r e

C o m p e t i t i v e

Q. What usage plans does your organization have for each of the following ways to be more

competitive?

n = 300

Note: Multiple responses were allowed.

Source: IDC's 2010 SOA and Cloud Survey

We then looked at the organizations focused on application integration and examined

the extent to which they used SOA to support various types of integration efforts.

Figure 3 shows that where application integration is a primary way in which

organizations planned to be more competitive, SOA was used by 50% of

organizations to address data integration needs and 44% of organizations to address

application integration needs. This indicates that where integration is a priority, SOA

is a short-listed technology for addressing integration needs.

0% 20% 40% 60% 80% 100%

Application modernization

Collaboration

Business intelligence

Mobility solutions

Risk management and

compliance

Application integration

Using Will use 20112013

8/3/2019 IDC-paper

7/16

2011 IDC #227837 7

F I G U R E 3

R e l i a n c e o n S O A i n O r g a n i z a t i o n s T h a t A r e U s i n g A p p l i c a t i o n

I n t e g r a t i o n t o I n c r e a s e T h e i r C o m p e t i t i v e P o s i t i o n

n = 300


When we look at the use of SOA by company size, the results are even more

interesting. Small organizations (5099 employees) rely on SOA primarily to address

current business challenges. Despite the limited IT resources of small organizations,

SOA is understood to be an effective way for IT to respond to acute business needs

in an efficient way. Medium-sized organizations (1001,499 employees) rely on SOA

primarily to address data integration tasks. While data integration is clearly a tactical

use of SOA, it is an effective way to break down the silos that can exist in

organizations and begin to make progress on master data management needs. Large

organizations (1,500 or more employees) rely on SOA primarily to address application

modernization needs. It is no surprise that application modernization is a key

objective for large organizations given the size and diversity of their IT portfolio andthe benefits of using SOA as a key architectural principle for guiding new application

and system design.

Using

Will use

20112013

Evaluating

Don't know

No plans to

use

SOAEnabled

Data Integration

Using

Will use

20112013

Evaluating

Don't know

No plans to

use

SOAEnabled

Application Integration

8/3/2019 IDC-paper

8/16

8 #227837 2011 IDC

O b s e r v e d S O A B e n e f i t s a n d C h a l l e n g e s

SOA Benefits

As part of the 2010 North American survey cited earlier, we asked organizations

about the benefits they were experiencing from using SOA as well as the challenges

they faced in using SOA.

SOA benefits in order of importance were as follows:

1. Improved business agility

2. Faster response time to change requests

3. Reduced cost of application integration

4. More flexibility in application development

5. Reduced cost of data integration

Improved business agility, which was the leading benefit cited in this survey, is a

frequently cited benefit of SOA. The ability to expose content through services and

move data between applications provides organizations with tremendous flexibility in

leveraging existing data and business processes. This ability to establish new

business processes by leveraging existing assets where possible makes application

development more efficient and more consistent.

Faster response time to change requests is a related benefit to improved business

agility in that technologies that make organizations more agile typically do so because

they are more efficient and consequently allow many types of changes to be

accomplished faster.

Reduced costs associated with application integration stem from a much higher

degree of custom code and unique point-to-point integrations that would otherwise be

necessary. We would also infer that these benefits would extend not only to

development activities but also to maintenance.

More flexibility in application development can follow from SOA involvement of

additional application infrastructure, including an ESB, a registry, and a repository, but

is clearly rooted in SOA's ability to support the development of loosely coupled

systems with a potentially high degree of component reuse.

The reduced cost of data integration was cited as another SOA benefit. We expect

that this is the case because of the ease with which SOA can facilitate interoperability

between data sources and provide an in-context capability when integrating and

unifying data.

8/3/2019 IDC-paper

9/16

2011 IDC #227837 9

SOA Challenges

Material SOA challenges in order of importance were as follows:

1. SOA requires a sizable investment in tools.

2. SOA is slow to show value.

3. Gaining business buy-in for SOA is difficult.

SOA requires a degree of investment to show value. Deployment products such as an

ESB, a registry, and a repository are incremental investments necessary to extract

the full value from SOA. However, these products typically have a fast time to value

for organizations that commit to SOA due to the core capabilities that these

foundational technologies provide.

SOA can be slow to show value depending upon the mix of pending requirements in

queue. Early SOA projects have a learning curve, and the benefits of SOA increase

geometrically as organizations build out their inventory of SOA services. So while it is

a fair criticism of SOA, being slow to show value does not mean that SOA is

challenged to show immense value.

Gaining business buy-in for SOA can be a challenge. SOA is an architectural

approach that is supported by a degree of runtime infrastructure and standards.

Business executives looking for an overt and significant quid pro quo when being

pitched an initial SOA project may find it difficult to understand why new technology is

necessary to address what could be a simple task. This is a legitimate challenge that

faces SOA and requires a response built around a firm commitment to SOA so that

time to value is kept short and the value gathers momentum and increases as

additional SOA projects are addressed.

T h e B u s i n e s s V a l u e o f S O A

Another question that we asked as part of our 2010 North American survey was

directly focused on the business value of SOA. Figure 4 displays the results to the

following question: Can you quantify the business value of establishing SOA within

your company? The results reflect the beliefs of SOA users from the survey sample.

8/3/2019 IDC-paper

10/16

10 #227837 2011 IDC

F I G U R E 4

T h e B u s i n e s s V a l u e o f S O A

Q. Can you quantify the business value of establishing SOA within your company?

n = 220


A total of 49% of SOA users reported that SOA shows some or significant business

value that would justify continued investment in SOA. About 18% of SOA users said

that they lacked information that would allow them to measure the value that SOA is

providing them. A surprising 14% experienced little or no business value from SOA,

and 19% either didn't know or were unsure how much business value was provided

by SOA.

It is encouraging that about half of SOA users are seeing material business value

from SOA. For those users who are unable to measure the business value of SOA,

we would estimate that about half of them would see value in SOA if it was

measurable or they did know. Therefore, we would expect that the majority of SOAusers see real value from SOA. Given the benefits and challenges observed in this

survey, these results are consistent with and characteristic of a technology that offers

significant value but requires organizational commitment.

Some or

significant

business value

Unable to

measure value

Little or no

business value

Don't know

8/3/2019 IDC-paper

11/16

2011 IDC #227837 11

F U T U R E O U T L O O K

S O A ' s T r a n s f o r m a t i v e R o l e i n I T a n d B u s i n e s s

If we elect to use the cloud as a benchmark for important transformative trends

occurring in IT, it would be interesting to see how important SOA and SOA-supported

technologies are in helping the cloud be successful. We asked respondents to identify

the technologies that are necessary for success in using AD&D tools in the cloud.

Figure 5 shows their responses.

F I G U R E 5

T e c h n o l o g i e s N e c e s s a r y f o r S u c c e s s o f A D & D C l o u d S e r v i c e s

Q. Which of the following technologies are necessary for success in using AD&D tools in the

cloud?

n = 300

Note: Multiple responses were allowed.


Topping the list of key technologies to make AD&D tools in the cloud successful is

Web services, which was identified by 46% of respondents. Given the important role

of the Internet in the delivery of cloud services, we would expect Web services to rank

highly. Web services follow an interaction pattern that is becoming aligned with SOA.

The evolution of Web Services Description Language (WSDL) has moved away from

its RPC, Simple Object Access Protocol (SOAP), and port orientation to a more

0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%

No cloud familiarity

Don't know or not sure

Other

WS Security standards

WS* standards

SOAP and REST

Registry and repository

Messaging and ESB

XML

SCA

Multitenant architecture

SOA

Web services

8/3/2019 IDC-paper

12/16

12 #227837 2011 IDC

flexible and abstracted definition supporting Representational State Transfer (REST)

and interface-oriented specifications. This evolution indicates an increasing alignment

between Web services and SOA. This alignment will be enhanced as Web services

borrow SOA infrastructural capabilities to enable better scalability, maintainability, and

governance.

Second on the list of key technologies to support AD&D cloud services is SOA, which

was identified by 38% of respondents. This confirms the critical role of SOA in

facilitating the design and access of cloud services. Given the flexibility,

configurability, scalability, extensibility, and maintainability required of cloud services,

SOA is currently the best architecture for ensuring that these needs are met. These

attributes are equally important to ISVs looking to build cloud services and to end

users who want a high degree of configurability and interoperability when using public

or private cloud services. The primary difference between services and cloud services

is that cloud services have to be built to a higher standard to meet availability and

reliability requirements. The architectural, infrastructural, and standardized

characteristics of SOA make it a good match as a foundational technology for AD&D

cloud services.

Multitenancy is followed by four technologies that are ranked closely in terms of

importance: Service Component Architecture (SCA) at 23%, Extensible Markup

Language (XML) at 23%, messaging and ESB at 22%, and registry and repository at

21%. These technologies are core to SOA, and together they account for much of the

runtime and design time value of SOA. The strong support for SCA was especially

interesting because SCA brings specificity to service composition, which helps ensure

the value-add of SOA. SCA and the related Service Data Object (SDO) standards are

important SOA drivers, and their high relative ranking in this survey question suggests

that principles and mechanics of addressing SOA are understood.

S O A a n d P l a t f o r m C o m p u t i n g

Earlier in this paper we discussed the transition from development to deployment.

Given the many advantages of platform-based application development, it is useful to

consider what this means. Although the SOA specification leaves plenty of room for

interpretation when it comes to implementation, all of the leading platform providers

provide infrastructural support for the key constructs of SOA, including ESB and

registry and repository. This degree of support from platform providers is designed to

help accelerate the adoption of SOA, speed application development, and improve

application quality and reliability. The transition to platform-based development and

deployment is for developers who are building custom applications and is becoming

the foundation for more and more packaged applications. The qualities that make

SOA desirable for custom application development carry over just as easily into thepackaged application realm.

The transition from silos to services also gave birth to the idea of on-demand

capabilities. A key characteristic of services is their interface, which enables a service

to be provided and consumed. This service orientation made it much easier for

application functionality to be decomposed and consumed on demand. Key to this on-

demand style of computing is the messaging that enables the consumer to issue a

request and the provider to serve the consumer content. This on-demand style of

8/3/2019 IDC-paper

13/16

2011 IDC #227837 13

computing is characteristic of a person-to-system (P2S) interaction pattern. The next

evolutionary step in computing styles, which is starting to occur, is support for the

system-to-person (S2P) interaction pattern. The S2P interaction pattern will enable

devices (and the people who carry them) to be contacted in real time when a

recognizable opportunity or concern occurs. Given that many devices like

smartphones have geospatial awareness, the potential of the S2P interaction pattern

is immense. The purpose of highlighting these interaction patterns is that the

message-based metaphor for communicating is just as well suited for P2S as it is for

S2P or system-to-system (S2S) interactions. Consequently, the messaging-based

orientation of SOA that is becoming common in supporting P2S interactions will be

equally effective at supporting these newer S2P and S2S interaction patterns.

S O A G r o w t h D r i v e r s a n d F o r e c a s t

The worldwide SOA market consists of license, maintenance, and subscription

revenues of products that provide or leverage SOA capabilities. A degree of SOA

revenue therefore exists in almost every software market that IDC follows. IDC sizes

the SOA market using a revenue allocation model and then forecasts future SOArevenue based on assumptions regarding what is likely to drive or inhibit SOA growth.

Growth Drivers and Inhibitors

IDC has identified a variety of key drivers and inhibitors that largely account for the

overall growth of the SOA market. The leading drivers and inhibitors are described as

follows:

! Market momentum. The service- and standards-oriented principles of SOA ensure

continued strong adoption of SOA. The current low level of market penetration also

ensures plenty of enterprises with compelling use cases. SOA is a key go-to-

market message for most leading ISVs that are seeking to promote applications,

platforms, and systems with broad-based extensibility and scalability. Overall

momentum as measured in growth will remain robust because there are no other

meaningful alternatives from the standpoint of technology choices.

! Agility. The componentized approach to application development supported by

SOA enables a level of flexibility and reuse that over time improves time to

market and application quality. The combination of these characteristics is what

best defines agility.

! Application and data integration use cases. SOA excels in addressing

integration needs given its service and message-oriented architecture. These

use cases will continue to drive revenue growth despite their limited ability to

improve IT operations through reuse or reengineering.

! IT governance. Governance is a key issue for large enterprises and will help

drive SOA growth due to the explicit monitoring and management provided by

SOA runtime technologies, including ESB, registry, and repository.

! Software as a service. The transition from software to services helps reinforce

SOA messaging and promotes SOA principles.

8/3/2019 IDC-paper

14/16

14 #227837 2011 IDC

! Complexity. SOA requires investment in development and runtime tooling.

Tactical SOA integration projects are easy to implement but may not be short on

financial return and will initially add to system complexity. Consequently, we see

the complexity of SOA as an inhibitor until an organization leverages the

technology enough to begin seeing engineering and operational benefits from

scale and reuse.

SOA Forecast

The outlook for SOA is consistent with the perspectives from our recent cloud and

SOA survey. IDC research estimates that revenue for SOA in 2010 totaled about

$8.1 billion, reflecting an increase of 37% over 2009. The outlook for SOA over the

20112015 forecast period is positive due to the moderate overall penetration of SOA

to date combined with strong cloud services trends that are aligned with and will help

emphasize SOA principles and products.

Figure 6 shows the worldwide 20062015 SOA revenue forecast segmented by

primary market.

F I G U R E 6

W o r l d w i d e 2 0 0 6 2 0 1 5 S O A R e v e n u e F o r e c a s t b y P r i m a r y M a r k e t

Source: IDC, 2011

0

5

10

15

20

25

30

2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

($B)

System infrastructure software AD&D Applications

8/3/2019 IDC-paper

15/16

2011 IDC #227837 15

Revenue in the AD&D segment accounted for over 52% of total SOA revenue in 2010

due to the large number of SOA tools, including ESB, registry, repository, SOA

connectors and adapters, and SOA development environments that reside in the

AD&D market. The overall SOA market is expected to have a compound annual

growth rate (CAGR) of just over 24%, which will drive revenue from $8.1 billion in

2010 to $24.4 billion in 2015. Overall growth for SOA is expected to reach 37% in

2011 and decline over the forecast period, as adoption continues, to 19% by 2015.

The AD&D market segment will see the highest growth, followed by applications and

then system infrastructure software.

C H A L L E N G E S / O P P O R T U N I T I E S

As outlined in this white paper, the opportunities clearly outnumber the challenges

that SOA faces. A tactical emphasis on data and application integration is often what

brings organizations to SOA but the real value of SOA is realized as organizations

standardize their approach to application development and adopt modern application

development techniques that share a services and business process focus and never

lose sight of the architectural discipline that SOA brings to IT activities.

If there is one challenge for SOA, it is the complexity of moving beyond the tactical

tasks associated with interoperability and data or application integration. While

integration tasks provide a logical SOA entry point, the challenge is recognizing the

potential of SOA to move beyond simplistic veneer-like interoperability tasks akin to

integration on the glass. SOA offers the capability to develop new applications as

services as well as reengineer existing applications in a variety of ways, ranging from

top-down wrappering of legacy code logic to bottom-up redevelopment using modern

platform-centric application development techniques.

Today's focus on application development is closely linked to software delivery as a

service. Consequently, this increased emphasis by the industry on public and privatecloud services means that the focus of SOA will begin to shift from top-down

interfaces and interoperability to bottom-up implementation. Although SOA today is

capable of supporting this bottom-up reengineering of applications, these types of

development activities can be difficult because they leverage new platform

infrastructure and require a higher degree of foresight regarding application and

system design to ensure the right level of service granularity and reuse. While such

reengineering and rehosting tasks are clearly challenging, the software industry could

and should do more to reduce task complexity. One example of how this issue could

be addressed is to build a higher degree of SOA support into architectural tools.

Another example would be to embed ESB and messaging capabilities in the

operating system to provide pervasive SOA service availability.

C O N C L U S I O N

SOA's relevance is now stronger than ever, although the software industry's fondness

for new terminology and messaging seems to suggest that SOA is showing its age.

However, SOA's tenure in the industry is its best attribute, and the industry's current

intense focus on services means that SOA's contribution to the industry is now larger

than ever. Survey data that we have presented, while falling short of a wholesale

8/3/2019 IDC-paper

16/16

16 #227837 2011 IDC

endorsement of SOA, speaks to its expanding adoption and significant role in

supporting application development today. Vendor revenues for SOA continue to

expand as well due to the pervasive transition from software to services that adhere

to SOA principles. While it is clear that SOA provides very tangible support for data

and application integration activities, the role of SOA is expanding to include IT

governance and application modernization.

The industry could and should do more to ease the process of SOA-based application

modernization. Some progress is being made on this today, as evidenced by the BPMN

2.0 specification that now supports a new variant on messaging (events) and extending

the service model to better support business rule processing. Added industry efforts

around domain-specific solution accelerators and process compositions, which

comprise upgradable data models, process models, business rules, and UIs, are an

effective way to deliver SOA-based componentry that combines the best that SOA and

modern application development and deployment have to offer.

The net of this is that SOA continues to exert a high degree of influence as the

architectural foundation for modern application development and deployment tooling.

This virtually ensures the lasting relevance of SOA and implies wider adoption of and

reliance on SOA as a foundational technology for all applications.

C o p y r i g h t N o t i c e

External Publication of IDC Information and Data Any IDC information that is to be

used in advertising, press releases, or promotional materials requires prior written

approval from the appropriate IDC Vice President or Country Manager. A draft of the

proposed document should accompany any such request. IDC reserves the right to

deny approval of external usage for any reason.

Copyright 2011 IDC. Reproduction without written permission is completely forbidden.

Documents

IDC-paper