Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly
more resources

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

ADVERTISEMENT

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

Back to top

Printer-Friendly Version









Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home