Developer Product Briefs
Harness and SOA/Web Services Strategy
Implementing SOAs will increase ROI, but first you must determine how to pool existing assets and adopt procedures incrementally. Learn how you can up do this with minimal effort.
Harness an SOA/Web Services Strategy
SOA will improve technology investment ROI only if each business unit has a stake in the process and if you adopt procedures incrementally.
by John Deeb and Dave Berry
September 15, 2005
Organizations that have implemented service-oriented architectures (SOAs) recognize SOA as a paradigm shift that illustrates how to bridge the gap between fast-changing business requirements and what the supporting IT infrastructure can deliver. SOA also promotes the reuse and leveraging of existing IT assets, using a "service" metaphor. Web services complement the SOA vision, providing service access by using standardized query and other loosely coupled interfaces. Reaping the full benefit of an SOA/Web services strategy requires consideration of some essential factors, including these criteria:
- Planning and creation of service portfolios across organizational boundaries
- Centralized orchestration of distributed data and processes
- Integration of technology components to increase productivity and business value
- Deployment and management of services to demonstrate business ROI
Let's see how even minimal planning can a go a long way to improve the ROI from your SOA/Web service investment drastically (see Figure 1).
How We Got Here
Knowing your organization's past before planning its future adds important perspective as well as a knowledge base you can build on that enables you to evolve your plans. SOA itself evolved from technologies such as RPC and XML to deliver a new way to build applications by using a distributed application framework. Whereas traditional programmers have built interfaces around logical programming groupings such as classes or packages to deliver business applications, SOA encourages and even enforces practices that steer the development process toward decoupling the business rules from the process logic. With separate levels of functionality, your programming environment has the flexibility to change logic at the business-component level. This is harder to accomplish and enforce in C or COBOL programs, which mix process logic, data interfaces, business rules, and presentation panels. Early developments in the distributed programming model moved away from this tightly coupled execution framework (see Figure 2).
If you look at a simple example of a legacy approach to order processing, you'll see that one program has many subroutines that handle overlapping functionality such as data interfaces, business rules, and presentation and process logic. In addition, the code might also cross organizational boundaries representing order handling, credit, fulfillment, and billing. The same order process implemented in a service environment decouples business and architectural functionality into separate deployable units, allowing them to be changed independently, which makes your processes less rigid and simplifies meeting diverse business requirements. This means if you need to implement new credit-term rules, you have the flexibility to make these changes with few or no alterations to the other services in the system.
Build a Service-Oriented Business
Among the core benefits of SOA are that it enables IT agility and allows reuse of technology investment to solve problems such as integrating back-end systems to build a connected enterprise. This can be something simple, such as sharing common customer information across help desk and fulfillment centers, or something more complicated, such as an HR system that holds sensitive information and must publish appropriate content securely to all external systems. The integration design patterns for this type of solution are well known and do not present a huge technical challenge, but satisfying the often conflicting needs of the business units and their respective infrastructure is much more difficult.
To take advantage of SOA, matching the business infrastructure to the distributed nature of the technology is best. For example, an SLA typically is used to define a business contract across organizations. Similarly, a WSDL file is used by IT to enforce the contract between the provider and consumer of a service. This is even more pronounced in the case of a business-to-business application that must provide non-repudiation to meet the legal contracts between two companies. It is the binding of these business and IT agreements that is a fundamental requirement for implementing and successfully exploiting SOA. If managed effectively to meet the organization's needs for security, high availability, and quality of service, SOA can help you build a distributed business architecture that will provide a competitive advantage for your business (see Figure 3).
New Framework Presents IT Challenges
Absorbing new technologies has always been a major IT requirement, and SOA is not much different. Regardless of where your IT staff's primary skill sets lie, it is management's responsibility to ensure that personnel are prepared to work and deliver value in new and changing technology landscapes. To help address changes in dynamic business cycles, projects should be staffed with a healthy mix of technological expertise. This will facilitate mentorship and training of IT staff to ensure long-term viability. Management should also build a relationship with business partners and end users, and it should use this relationship to communicate the advantages of staffing for SOA.
IT managers should not underestimate the difficulty of simultaneously consuming new technologies and internally selling the benefits of a service-enabled enterprise. The involvement of a senior system architect who understands and internalizes the needs of the business will go a long way toward ensuring IT can deliver on the promise of SOA. Strategic vendor relationships are important and should be included in the process to make sure the vendors can work with you during this evolutionary stage. Whether you are going through a vendor selection process or using products from current vendors, make sure the vendors are prepared to pitch in and help you define your SOA strategy and demonstrate how their products are reliable and flexible enough to meet your business needs.
Finally, if necessary, you might consider hiring outside the organization to build the IT infrastructure in a way that will help you meet short-term requirements and construct a self-sustaining organization. The cost of this sometimes can be difficult depending on your environment, but external staffing can become crucial for delivering business value in a services environment.
Tool Your Business-Oriented Architecture
Regardless of the industry, adequate tooling is required to satisfy customer requirements. Technology and SOA projects are no exception, and a process must be built and implemented to be successful. Luckily, SOA tools for this purpose are rich and abundant, and finding the best one to meet your particular needs is important.
These days, virtually every technology is billed as a Web service enabler. This might sound great, but prudent managers must peek under the covers to discover where the true value lies. The word service has become so overused that it is virtually meaningless, so establishing a good definition of it within the context of your organization is an excellent starting point. A simple definition of a Web service might be a technology that uses XML, WSDL, and SOAP to implement a distributed or loosely coupled interface that meets performance requirements and is easy to configure and manage from a thin-client browser. An SOA could then be defined as a framework of products that interoperate to enable the delivery of Web services to meet the business requirements of end users.
From this simple definition, you can start to break down the requirements of the tools and separate them into groups, such as those that support Web services natively and those that are simply a veneer on top of legacy technologies. Although a Web services façade strategy might meet the requirements for wrapping legacy applications, it is hardly sufficient for the core components of your SOA platform because it limits your ability to expose them on demand. Configuration and manageability are critical pieces of your infrastructure that enable IT to stay focused on solving core business problems. Make sure the tools satisfy your organization's lifecycle management needs and are flexible enough to enable rules configuration, thus avoiding costly redeployments. Look for tools that both support and extend existing standards; this will help you simultaneously protect your investment and bridge technology gaps.
Technologies such as Business Process Execution Language (BPEL), Java Messaging Service (JMS), and Business Activity Monitoring (BAM) are critical to SOA and can be used to extend the promise of SOA into a more process- and event-driven enterprise. BPEL lets you implement business processes such as cell phone provisioning, using native Web services that meet your organization's orchestration, integration, and workflow requirements in a secure, transactional, and fault-tolerant environment. JMS enables delivery of publish/subscribe messaging to synchronize back-end systems such as CRM and ERP, and it is a core asset of a newer class of software: Enterprise Service Bus (ESB). BAM lets you model and monitor key performance indicators for gold or platinum customer service packages, ensuring that you are meeting their Service Level Agreements (SLAs). The tight integration of these technologies is what will increase the payback of both SOA and existing technology assets (see Figure 4).
Feed the Corporate Knowledgebase
From an SOA viewpoint, few major changes to your project management competencies are required. For SOA, as with any other IT project, starting simple and building from there is important because as you develop Web services expertise, you can spread that knowledge across your organization. The distributed nature of Web services is a notable adjustment to existing technology practices, so building a core team to deliver initial proof of concepts will enable you to get a handle on the tools and trumpet early successes. Gaining proficiency in using SOA during process creation and deployment, exception handling, debugging, and lifecycle management is important in the early phases.
As always, including IT business partners early in this process serves as a basis of their understanding of the inherent difficulties of working with and getting the most out of the SOA "distributed" environment. Picking the right project that properly matches your available staffing and aligning it to the business's needs might be your earliest critical decision point. Identify an appropriate business opportunity for which you have a good technological understanding and relationship with the business users. Ideally, the project solution should illustrate an innovative use of technology to solve a key business problem that will maximize management visibility and demonstrate the IT department's ability to deliver on the promise of SOA.
Measure SOA ROI
The ability of senior management to measure the benefits of the SOA project will determine its long-term viability within your organization. Reusing previous business metric procedures and applying them to the SOA environment is particularly helpful if you can illustrate both cost and people savings. Automating manual processes with orchestration technologies such as BPEL is a great way to do this. Measuring customer response time or time improvements of previously resource-intensive processes such as provisioning is something business managers respond to.
Using BAM technology is another effective way to measure productivity gains in the organization. Building SLAs and integrating existing applications with BAM will provide adequate information for gauging the success of your SOA. Finally, a non-intrusive way to gather performance information for gauging ROI is to use a Web services management gateway. This can work like a proxy, whereby the gateway can feed service execution data to BAM so it can correlate response times and computation of an organization's SLAs. This is another instance in which your integrated SOA infrastructure will increase productivity and help deliver business ROI.
Success = Having a Stake
SOA presents unique organizational challenges, and it can be successful at improving technology investment ROI only if each affected business unit has a voice and a stake in appropriate phases of the process. To best exploit distributed technologies such as SOA, extend your traditional methodologies by creating a "distributed" organization with buy-in and participation at all levels. Improved business efficiencies are a result of a well-defined process-modeling approach that implements process orchestration as a key component of an SOA.
From a technology perspective, using incremental adoption practices is your best opportunity to achieve early measurable ROI with SOA. Building small working groups with a limited number of business users, architects, and vendors can reduce project complexity. Distribute staff expertise across legacy, database, and Internet technologies to increase SOA cross-training and project productivity. Ultimately, to harness the most out of your SOA, you should strive to reduce risk by reusing existing methodologies and technology practices, but you should adapt them to the distributed aspect of the SOA.
About the Authors
John Deeb is a member of the product management team for Oracle Application Server 10g, a component of Oracle Fusion Middleware. He focuses on enterprise integration, business process management, and BAM technologies.
Dave Berry has more than 25 years of technology experience ranging from mainframes, integration, and SOA technologies in financial services, government, and vendor environments. He works in the Oracle Server Technologies Group where he leads product management activities for Oracle's ESB technology.