Web 2.0 is one of those marketing words I don’t like to use that often, but unlike SOA 2.0, the Web 2.0 is a reality. It’s really a change in platform at its essence, but there are also many social issues there as well…information sharing, collaboration, and social networking to name a few. But can your enterprise see the emerging Web?
What’s important to remember is that there is a huge resource that is being created on the Web these days. This includes access to SaaS applications, such as Salesforce.com, that are better than their enterprise bound counterparts, service marketplaces, such as StrikeIron, and even mash-able applications that you can mix and match with other Web 2.0 applications or enterprise applications to solve business problem quickly.
However, having such a resource available for the price of a broad-band connection does not mean you’ll be able to leverage it properly. Indeed, it’s going to take some time before your enterprise is prepared to leverage the emerging Web beyond the browser. The best way is to design and deploy the first generation SOA with the Web 2.0 in mind, or in other words making your enterprises systems “exposable” to services or applications outside of your firewall, or “able to consume” the same services or applications. This is harder than it sounds, and chances are your current systems can’t see outside of their own operating systems.
Truth-be-told most SOAs will have the side benefit of being able to leverage the Web 2.0 stuff as a resource, services for example, but I assert that you need to design for that in order to make your infrastructure most effective. This means cataloging and testing services you don’t own, attempting to mashup systems inside and outside of your firewalls, and making sure your security planning considers this notion as well. Many who don’t plan for this will be stuck with an enterprise that can’t see the new Web, and I think those enterprises will have a huge strategic disadvantage in the years to come.
Mashing Stuff Up
With the advent of rich client and extensible interfaces such as AJAX, we now have the ability to quickly create mashups to solve specific business problems using standard dynamic interfaces that front services. Mashups are powerful ways of taking existing applications and services, and creating something even more useful for business.
However, I think that there are really two types of mashups emerging: visual and non-visual.
Visual mashups, are mashups we are more than aware of today as we mash Google Maps with a sex offender database, or a real time stock ticker with a portfolio manager. The value is there, we take two different interfaces and create something that is more useful than the two separate applications, kind of a 1+1=3 thing. Clearly, this is the “sex on the screen” aspect of SOA and mashups. We’re bound to so a ton of these in the near future, if not already.
Non-visual mashups are the mashing up of two or more services to create a combined application, or integration point, to service a business process. What’s unique here is that they may not externalize anything to a user interface. For instance, mashing up a stream of customer addresses with an address validation service, or mashing up a stream of social security numbers with a credit check service. Each non-visual mashup, perhaps, is sending exceptions off to another stream or queue for processing later or perhaps to other mashups. This is very simple, and I bet you can think of even more complex and valuable non-visual mashups for your own enterprise.
Truth-be-told, while visual mashups are cool and useful, I think that non-visual mashups will be more valuable to business as time goes on. So, if you’re mashing stuff up remember to consider the non-visual with the visual, as well as how this all works in the context of your SOA, and how your SOA works with the emerging Web.
