Making the Transformation to SOA

Making the Transformation to
Service-Oriented Architecture
Capitalizing on the Next Revolution in IT

January 2005 TABLE OF CONTENTS
THE NEXT REVOLUTION IN INFORMATION TECHNOLOGY................................................ 3 GROWING MOMENTUM .......................................................................................................... 3 REAL BUSINESS BENEFITS .................................................................................................... 4 THE ROLE OF WEB SERVICES................................................................................................ 6 MAKING THE TRANSFORMATION TO SOA ........................................................................... 7 BUILDING-BLOCK SERVICES .................................................................................................. 7 SERVICE-ORIENTED ARCHITECTURE INFRASTRUCTURE .......................................................... 9 SERVICE-BASED BUSINESS SOLUTIONS ............................................................................... 10 CHOOSING A STRATEGIC SOLUTION PROVIDER.............................................................. 12
©2005 webMethods, Inc. All rights reserved. Page 2 THE NEXT REVOLUTION IN INFORMATION TECHNOLOGY Businesses are looking to service-oriented architectures (SOA) as the best way to leverage their Information Technology (IT) assets and to provide their organizations with the agility needed to be competitive in today's economy. This white paper explores why service-oriented architecture has emerged as one of the most significant developments in IT, and is followed by an overview of how businesses can make the transformation to service-orientation.
Growing Momentum There is a remarkable consensus on the importance of SOA. Customers, vendors and analysts are united in the conviction that SOA is the dominant theme in IT today. Consider that: „ In an April 2003 report, Service-Oriented Architecture: Mainstream Straight Ahead, Gartner, Inc. predicted that "by 2008, SOA will be the prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability)." „ An article in the October 2003 edition of CIO Magazine noted that over 50% of clients in a survey were already engaged in some form of SOA development. „ A report in the Wall Street Journal in November 2003 noted that 85% of large North American companies planned to use Web services in the coming year. „ A March 2004 survey of 100 CIOs by Smith Barney found that service-oriented architecture was their number one priority in the area of emerging technologies. „ Almost every software vendor on the market has claimed some association with service-oriented architecture (some more legitimately than others). But what exactly is "service-oriented architecture," and why has it generated such interest? Quite simply, SOA is an approach to software design ("architecture") where app-lications are assembled from reusable components ("services"). A service is a software building block that performs a distinct function - such as retrieving customer information from a database - through a well-defined interface (basically, an electronic description of how to call the service from other programs). SOA differs from other forms of computing in a few fundamental ways. First, software is organized into modular components. This is not a novel concept, but the difference with SOA is that the components, or services, are loosely coupled. Loose coupling is significant because it underlies the flexibility behind SOA. Loose coupling means services can be linked together dynamically at run-time, with few dependencies on how the services are actually implemented. For example, a company could create a "Customer Lookup" service to return information about a customer. With an SOA, any application needing customer information would be able to find, link to, and call the Customer Lookup service, regardless of whether the service was built using the same or different programming technologies as the calling application. Tight coupling, in contrast,
©2005 webMethods, Inc. All rights reserved. Page 3 results when there are dependencies between software modules that are designed, coded, or compiled into applicatio... [download for more]