2004: A Leap Year for Service-Oriented Architectures
The standards are maturing, the products are on the market, and the architects have figured out what Service-Oriented Architectures (SOAs) are all about. Now that it’s 2004, it’s time for the rubber to hit the road. ZapThink has even seen several significant, albeit frequently tentative, implementations of SOAs that have already realized return for the companies that implemented them. Even more companies have architecture teams actively planning out their SOAs. Yet, while 2003 showed tentative steps in SOA adoption by end-users, 2004 will prove to be the break-out year for the technology. For end-users, this means a certain set of action items to make SOA a reality. For vendors, this means that 2004 will be a do-or-die year for their products.
Beyond the pilot project and on to the incremental project
One of the steps companies took in 2003 towards SOAs was to implement focused Web Services and/or SOA implementations targeted at solving specific integration problems. Most companies limited these pilot projects in scope both financially as well as the number of systems that they integrated. In addition, teams focused on integration, portal, or other specific tasks implemented most of the pilots on a departmental level, and as a result paid little, if anything, for the SOA part of their solutions. As a result, many of these departments experienced significant ROI from their efforts.
Enterprise-wide, big-bang SOA efforts are still few and far between, but a substantial number of companies have completed departmental SOA implementations. Now that many departments have an SOA implementation or two under their belt, vendors of Web Services and SOA products and services should start to see an increase in additional incremental SOA projects.
In fact, the incremental approach to SOA adoption is specifically the direction that ZapThink recommends companies should go with respect to SOA implementation. Rather than trying to rip out existing integration infrastructure or middleware and implement an enterprise-wide SOA that aims to replace all proprietary interfaces in the company with Web Services-based ones, and then compose those into enterprise-wide business processes, companies should solve their most pressing integration problems first by applying Service interfaces and then gradually increasing the scope of these projects to encapsulate more Service-oriented processes. As a result, ZapThink expects repositories, asset management libraries, Service-oriented management applications, and Service-oriented process tools to gain significant traction in 2004. Therefore, those products must be ready now for enterprises to purchase and use.
Establishing the enterprise architecture team
Enterprise architecture, and by extension Service-oriented architecture, is special in that requirements cross IT and business domains. While IT executives could delegate portal projects, CRM and ERP implementations, and Web site projects to small, focused, and relatively isolated groups within the IT department, the same cannot be said for any SOA implementation that addresses a business need. Rather, SOA projects demand expertise from across the organization, including business users who can define needs and process definition, application developers that interact with integration middleware and legacy systems, data center administrators, portal developers and administrators, folks that deal with security, and IT staff that manage and monitor the back-office systems.
Indeed, pulling off a successful SOA implementation requires discipline and teamwork across the IT and business organization. Such enterprise architecture teams must operate as the cohesive backbone for realizing early SOA success. While 2003 saw just a few architecture teams at Fortune 1000 firms, 2004 will see the rapid emergence of the enterprise architecture team as the primary venue for defining, implementing, and managing SOAs. So, firms must stop thinking of Web Services as a point-solution for a point-problem, but rather more holistically as a cross-organizational architectural approach to solving an incrementally larger set of problems, using reusable architecture elements. Make no mistake, such changes are difficult, and require effective governance and broad discipline. Many companies will get it wrong.
Demand SOA from your suppliers
End users have been too passive in 2003 in demanding Web Services-enabled, Service-oriented products from their current IT suppliers. While the vendors have been doing an excellent job of defining and driving new standards initiatives, large industry participants have been all but invisible in this standards definition process. With the exception of the Liberty Alliance and WS-I.org groups, no organization involved in establishing or interpreting standards has made significant traction in getting end-users to join. If companies wish to have standards that they can use, they must either be part of the standards definition process or demand compliant solutions from their vendors.
Clearly, vendors are broadly implementing Web Services and SOAs in their products. Application server, Enterprise Service Bus, and Service-Oriented Integration vendors are converging on a set of functionality for producing secure, managed, process-driven SOA implementations that in turn address integration issues. ZapThink calls this converged market the SOA Implementation Framework market, and expects it to exceed $43 Billion by 2010. In fact, ZapThink predicts that this SOA Implementation framework will transform and subsume the markets of application security, security appliances, system management, application integration, data integration, and business process management as vendors in those markets Service-enable their products.
Yet, even though the march towards Service orientation is inexorably in progress, end-users must continue to demand standards-compliant solutions from their technology suppliers. Specifications for security, management, and process have been out for a year or more in some cases. Yet, implementations of these same specifications by major vendors are still lacking. With sufficient end user demand, these vendors will accelerate their product delivery plans.
Learn from peers
Finally, it is vitally important for IT teams to learn from their peers the mistakes they are making, or the successes they are having, in their SOA implementations. There is a lot of great SOA implementation activity going on in a wide range of industries ranging from financial services and insurance to health care, manufacturing, and government sectors. Yet, there is little sharing of the lessons learned among companies in these industries. For firms build successful SOAs in 2004, they must find opportunities to share their experiences with others, as architecture is not a skill that people can easily and quickly acquire, but rather emerges over time as they learn best practices from others.
Do or die for vendors
On a final note, ZapThink believes that 2004 will be a make-or-break year for most startup firms that are producing innovative, emerging products for the various SOA markets. Vendors that gain traction this year with customer wins and partner relationships will significantly leap ahead of their competition, while those who lag behind may find it increasingly difficult to compete. Furthermore, the window of opportunity for new entrants to these markets is rapidly closing. Basically, if you’re not already in the market with working products, or coming to market in the next few months, then it will be too late.
The ZapThink take: time to get down to business
ZapThink has been touting the value propositions of SOAs for a few years now, and people are finally getting it. We’re beyond the hype (both the “best thing since sliced bread” type and the “nothing new under the sun” flavor), and SOAs are becoming a reality. For both end-users and vendors, 2004 promises to be the year of the SOA.