"Java or .Net?" was the question that seemed to dominate the initial coming of Web services. Ask most organizations that same question today and the likely response will be a quizzical look.
"Two years ago, choice of development tools choice was a very important issue -- but now the tools are not so critical and the attention is on service oriented architecture (SOA)," said Gordon Li, Borland's CTO for Greater China. "Developers will simply use whatever they are most familiar with-interoperability between different Web services is no longer an issue."
Li explained how development tools were crucial in initially developing Web services during a time when standards were less mature, resulting in a lack of interoperability between Web services created by different tools and development environments. But nowadays, more mature standards and the emergence of protocols and standard messaging have produced greater interoperability between the development camps.
Li stressed that the key for enterprises today is to construct the architecture for all services within the firm. "Firms now want to really focus on the value of Web services, developing them, changing them, and managing them effectively."
In the past, Web services were used to do a lot of point-to-point integration based on simple standards like Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal, Description, Discovery and Integration (UDDI). These standards were very specific to operating systems, interfaces and development languages. Enterprise customers used .Net or J2EE to extend their applications and services to other systems and parties.
But now, SOA is helping to create an additional layer on top of Web services providing a shared business services capability, and allows firms to build many applications and services with business logic and reuse capability.
SOA is a different approach to application development that supports loosely-coupled services to enable business flexibility in an interoperable, technology-agnostic manner. Through business rules and processes enabled with integration and messaging tools, SOA enables businesses to break down processes, applications and services into components which can be reused and recompiled for another service or application.
Such services can then be combined, given specific service levels and aligned to business needs to form composite services that encourage reuse but also allow much faster and more flexible changes to business systems and processes.
"As an interoperability architecture, SOA should be viewed as a new approach to system design, development and integration," said, Michael Barnes, vice president for technology research services at Meta Group.
He added that organizations are struggling to become more adaptive to change and are seeking ways to ensure that IT does not hinder this adaptability but instead helps enable it.
"SOA has the potential to help organizations deliver highly adaptable services connected via an easily changed model that parallels the business process," said Barnes. "And that can be related to the business process in a manner that is meaningful to a business user." When moving to an SOA world, it's no longer about solution development by programmers locked away in a single room -- it now involves the business level members.
"SOA forces the team to think of other factors like application lifecycle management, the architecture, business mapping through to design and onto deployment," said Anmar Alani, director, developer and platform group, Microsoft Hong Kong.
The immediate benefits of this process are reduced costs and investment required for application and service development and management.
Alani suggested the .Net /Java dilemma is still important when deciding on technology tools for your development environment. "You still need to assess what you know, your existing skills base, what training is needed, and overall cost and ROI," he added. "However this is not critical in the philosophy of SOA, as the first steps aren't concerned with technology."
Implementing SOA is not dependent on technology or particular products, note vendors Microsoft and BEA. Instead it involves process and mindset change.
"SOA is not a technology-driven thing, it's a process, approach and philosophy that drives SOA," noted Alani. Though the technology and tools are important when firms reach the physical layer of SOA, he added.
Yip Ly, senior director, business solutions group and presales operations at BEA, notes the .Net/Java debate is still an issue for some firms and is something which depends on the size and nature of the company.
"Many smaller firms will be using Microsoft environments so will likely pursue .Net as their development strategy and will expect to continue using .Net," said Ly. He added that larger enterprises and applications that require real scalability and high levels of complexity, will often utilize Java/J2EE.
At BEA Systems, a specific methodology is suggested for firms seeking to implement an SOA. According to BEA's Ly, the first step is to build a common infrastructure, have simple links to all applications and legacy systems, and identify and analyze existing processes. The second stage is building a shared applications framework, which involves consolidating backend applications and breaking down any traditional silo-type systems. The third stage is working on a shared business framework to allow building of composite applications for businesses to enable reusability of services.
Ly noted that identifying processes and breaking them down is a difficult exercise. Alani at Microsoft agreed that this could be an exhausting task. "Just taking a system like ERP and seeing how the processes are mapped between partners, suppliers and customers can prove to be challenging," Alani said.
Ly observed how firms often find it hard to define processes and some may require consultants to identify and break these down into specific components.
Alani however, disagreed on this point, stating while the business analysis is a difficult exercise, "you should not need a consultant to help you get a better understanding of your own business processes." Another key element to establishing an SOA is assigning someone to be the architect. "Firms need to create that position if not already existing, to empower someone in deciding how best to implement SOA," said Alani.
Core requirements for this position include experience with different technologies and best practices, and keen understanding of previous architectural projects. Alani notes that this person will serve as the critical bridge between the business team and the development team.
Once these initial steps are complete, the next decision is how best to start implementation. The general consensus is to start small and initiate pilot projects. New applications are often good cases for applying SOA, or old systems and applications that have been given new business requirements.
"If you get buy-in from business and from IT on specific projects, they are the best to try SOA on," said Alani. "You will be challenged on what skill sets you have, the tools you need, the cost and what return you can deliver."
Once underway, such projects should be evaluated for overall return over time, and whether development and deployment has proven more efficient compared to previous experience. "If it's all positive, you look to roll out SOA across other areas of the organization," noted Alani.
Ly stated that many firms face this critical problem of how to approach SOA, when to use it and when not to use it.
"SOA is ready for implementation, but it's not necessarily right for everyone to jump on board," said Ly. "Each firm will have a certain time which is right." He noted for standalone, non-distributed applications, there is not much need for SOA. "The scope is too limited with short-lived applications -- SOA here can complicate development."
Once a repository of Web services has been created, there also needs to be a committee to provide governance and management, Ly noted. Business managers under pressure could be tempted to veer from the principles and guidelines of the SOA by taking further short cuts in development and deployment. Service quality and performance can be affected in the long run if such practices occur.
Implementing SOA should not be a costly exercise. In fact, if organizations find it more costly than their existing application development process, that means: "You haven't defined the SOA clearly or you haven't understood or deployed it correctly," according to Ly.
Meta's Barnes stressed that "SOA as an approach to application design, development and integration is best-suited to projects where business processes must be very clearly defined, managed and modified."
Vendors have seen three sectors: finance, telecommunications and government taking active interest in SOA adoption. "All these sectors are very clear in their understanding of SOA and are beyond investigating the merits," said Ly. One such firm is investment bank CLSA who adopted SOA to help deliver straight through processing (STP) for trading operations).
Barnes notes that SOA represents a significant shift in the way organizations design business systems and the applications that support them. This shift will affect not only the applications, but also the roles and the responsibilities of the firm and the various tools and techniques that are used to build them.
He also cautioned that many vendors and the media currently talk about the end vision in a manner that makes it difficult for a typical firm to plan a road map.
"The changes associated with service orientation can seem daunting, and the vision of the future seems well beyond what existing systems and organizations are capable of," said Barnes.