Two IBM’s Distinguished Engineers, Kyle Brown and Rachel Reinitz, start their new article with a quick discussion of the current Web 2.0 approach:
A new technology comes along and then suddenly everything we've ever done with any older technologies is obsolete and will go away. At first glance, the new Web 2.0 technologies appear to follow this pattern. Hardcore proponents of these technologies will tell you that you need to throw out all of your SOAP services; not only will building with SOAP and WSDL make your project take longer, they won’t convey any benefits... While REST makes it easier to build some types of services - particularly those that face outwards to the Internet or to Ajax clients - there are still lots of services that will benefit from applying SOAP, WSDL, and the WS-* specifications. And, depending on the type of SOAP services you have, you might be able to embrace Web 2.0 by transforming your services into REST services; this is particularly true for data-oriented services.
They also describe how several major enterprise SOA lessons can be leveraged for REST implementations.
Enabling new business models is one of the main SOA selling qualities, typically achieved through increased flexibility of enterprise business processes, which allow enterprise to reach new markets or regions. Similarly, Web 2.0 technologies provide new ways to reach out to, communicate with, and collaborate with customers and business partners:
Web 2.0 concepts can be used to drive new business models in several ways. Businesses can build communities, empower users as producers of key data, build ecosystems around users, find new ways of communicating to users, and enable the "mashing up" of information into new forms or views... This is, of course, a simplification, but if you view Web 2.0 only as cool technology focused on rich UIs, Atom feeds, and RESTful services, you can miss how Web 2.0 can be used to enable fundamental business change.
Reaching out to the business. One of the main prerequisites for successful SOA implementation is business-IT alignment through concise communication of both investments required for implementation and return on investment (ROI).
..you need to be as concrete as possible on business value, and - even better - provide projected return on investment (ROI) for adoption of Web 2.0...: the business community doesn't necessarily get jazzed by new technology the same way that developers do. Therefore, you need to be able to reach out to the business community on their terms (as you probably do already for developers) in order for Web 2.0 to take off.
Driving adoption from a firm methodological basis. Another key success factor for SOA has been the practices, procedures, and rules that form the basis of SOA methodologies. The authors cite Service Oriented Modeling and Architecture (SOMA) and Component Business Modeling (CBM) as the ways to engage business users and help them understand the alignment of business and IT. In order for it to succeed, Web 2.0 will also need a firm methodological basis that will be an evolution of existing SOA and object-oriented design methods:
...there need to be ways to identify the communities that are the targets of Web 2.0 applications, and also ways to identify their communication styles... there also need to be ways of defining the business value that result from leveraging these communities to help you evaluate services. Likewise, there should be modifications or extensions to the SOMA services identification mechanisms and services litmus tests to identify the difference between services that are appropriate for application integration and those appropriate for supporting rich Internet applications
Having vision, establishing a roadmap, and executing projects. Yet another prerequisite for SOA success is to have an overall vision and execute projects towards that vision:
If you focus only on the vision and roadmap for Web 2.0 (which includes implementing infrastructure and framework projects) in the absence of "real" projects (which go into production and deliver business value), then you run a high risk of achieving an infrastructure and procedure that do not meet project needs, making it even harder to get project teams to adhere to the roadmap/architecture/frameworks. If you start running individual Web 2.0 projects without a vision and roadmap, and without a common infrastructure, you risk delivering less value, re-learning lessons already learned, not reusing code across projects, and not building common infrastructure and procedures... Early projects do not need to be large to deliver value, but they always offer the opportunity to gain experience with the new technology and business models.
Not overlooking governance. There are plenty of publications emphasizing the importance of SOA governance:
What we have seen from early applications built using Web 2.0 principles is that governance for Web 2.0 will be even more challenging, given that key aspects of Web 2.0 adoption is free communication and collaboration in a community and the sharing of information. As we expose RESTful and Atom services, the question becomes: how do we control but not limit the use of those services and the development of assets by users? If the sociological aspects of building a community are limited by a too-restrictive governance process, then the community will not thrive. However, too often we've seen online communities poisoned by insufficient or improper governance; it's too easy to get buried in "junk" and not be able to highlight the valuable content that exists.
Similarly to enterprise SOA, impactful Web 2.0 implementations are aimed at the enterprise as a whole. As a result, lessons learned from both successful and failed SOA implementations can be applied to many Web 2.0 projects.