WHITE P APER Architected to Last: The Expanding Relevance of Service-Oriented Architecture

Sponsored by: IBM Stephen D. Hendrick April 2011

www.idc.com

IDC OPINION
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 that SOA 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.

Global Headquarters: 5 Speen Street Framingham, MA 01701 USA

P.508.872.8200

F.508.935.4015

IN THIS WHITE P APER

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. Recent survey-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.

SITUATION OVERVIEW
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.

From Silos to Services

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 serviceoriented 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-level coding 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

#227837

2011 IDC

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.

2011 IDC

#227837

FIGURE 1
From Silo to Service: The Transformation of IT

Style Code Higher Configure Deployment

Abstraction SOA

Structure

4GL Lower 2GL Past 3GL

Cloud Development Future Time

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.

Key SOA Constructs and Attributes

SOA in itself was an evolution of industry thinking around distributed computing and componentization. The key principles that guided the development of SOA include service 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.

#227837

2011 IDC

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.

The Role of SOA in the Enterprise

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 addressing interoperability 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.

2011 IDC

#227837

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.

FIGURE 2
The Leading Ways in Which Organizations Plan to Be More Competitive
Q. What usage plans does your organization have for each of the following ways to be more competitive?

Application integration Risk management and compliance Mobility solutions Business intelligence Collaboration Application modernization 0% Using 20% 40% 60% 80% 100%

Will use 20112013

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.

#227837

2011 IDC

FIGURE 3
Reliance on SOA in Organizations That Are Using Application Integration to Increase Their Competitive Position

SOAEnabled Data Integration

No plans to use Don't know Using

SOAEnabled Application Integration

No plans to use Don't know Using

Evaluating Will use 20112013

Evaluating Will use 20112013

n = 300
Source: IDC's 2010 SOA and Cloud Survey

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 and the benefits of using SOA as a key architectural principle for guiding new application and system design.

2011 IDC

#227837

Observed SOA Benefits and Challenges

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. 2. 3. 4. 5. Improved business agility Faster response time to change requests Reduced cost of application integration More flexibility in application development 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.

#227837

2011 IDC

SOA Challenges
Material SOA challenges in order of importance were as follows: 1. 2. 3. SOA requires a sizable investment in tools. SOA is slow to show value. 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.

The Business Value of SOA

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.

2011 IDC

#227837

FIGURE 4
The Business Value of SOA
Q. Can you quantify the business value of establishing SOA within your company?

Don't know

Little or no business value

Some or significant business value

Unable to measure value

n = 220
Source: IDC's 2010 SOA and Cloud Survey

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 SOA users 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.

10

#227837

2011 IDC

FUTURE OUTLOOK
SOA's Transformative Role in IT and Business
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.

FIGURE 5
Technologies Necessary for Success of AD&D Cloud Services
Q. Which of the following technologies are necessary for success in using AD&D tools in the cloud?

Web services SOA Multitenant architecture SCA XML Messaging and ESB Registry and repository SOAP and REST WS* standards WS Security standards Other Don't know or not sure No cloud familiarity 0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%

n = 300 Note: Multiple responses were allowed.

Source: IDC's 2010 SOA and Cloud Survey

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

2011 IDC

#227837

11

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.

SOA and Platform Computing

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 the packaged 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 ondemand 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

12

#227837

2011 IDC

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.

SOA Growth Drivers and Forecast

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 SOA revenue 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-tomarket 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.

2011 IDC

#227837

13

! 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.

FIGURE 6
Worldwide 20062015 SOA Revenue Forecast by Primary Market

30 25
($B)

20 15 10 5 0 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

System infrastructure software

AD&D

Applications

Source: IDC, 2011

14

#227837

2011 IDC

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.

CHALLENGES/OPPORTUNITIES
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 private cloud 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.

CONCLUSION
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

2011 IDC

#227837

15

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.

Copyright Notice
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.

16

#227837

2011 IDC