Say I am a business manager at an insurance company and my job is to recruit insurance agents. These agents in turn meet the insurance needs of their customers and build their own customer base. If an agent does well, the company does well. With a finite amount of recruiting dollars available, I need to be able to make the best decisions on where to focus my recruiting efforts. Would I want to recruit more agents in California or in Arkansas?
To make these types of decisions, ideally I would like to visually map out the location of current agents, the location of their associated customers, and the population density of the country. That’ll give me a visual of the “gaps” in the geographic regions of the country where coverage could be improved. I could get the population distribution from the census bureau, the map data from an external provider, agents and their customer data from my own company. While the census and map data do not change on a daily basis, my agent and customer data does. As I recruit more agents, who in turn bring more customers, I would like to, on a daily basis, visually be able to see coverage gaps so I can spend my recruiting budget judiciously.
In a typical organization, once I have this business requirement, I would have to write a business case, get it approved for alignment and funding, create a business and IT project team to get the requirement implemented. Since this work also calls for access to data that’s owned by other departments I have to ensure that the business sponsor for the project is at a high enough level to facilitate data sharing and collaboration.
Again, typically the IT department will add this project to their queue. When they get around to this project, the may potentially use the requirements to drive changes in an existing architecture, and based on the current approaches, suggest a Service Oriented Architecture based approach to leverage existing applications. IT may get the census data and store that in a database, acquire a geographic information system for mapping, and then expose the data regarding agents and their customers through web services. All this may come together in a context of a business process, which will call for a Business Process Management System.
The question then is whether IT should use SOA or should it use mashups? What’s the difference?
While this long term approach to alignment and architecture is commendable, this project will likely run into the 12-18 month time frame. Do I have an alternative? Yes indeed, in a technology called “mashups” that’ll help to build this application relatively faster while leveraging the strengths of existing providers. For instance, one could create a quick application using a rich-client development tool such as AJAX and/or web framework tool such as Ruby on Rails and Google Map APIs for the map display.
First let’s be clear on one aspect. As a business manager, I do not have to care about whether IT uses SOA or mashups to implement my business requirements. However, let’s look at this from an IT perspective.
Let’s take a look at where SOA will be suitable and where mashups will be suitable. SOA has a lot more rigor, methodology, maturity and tools associated with it contrasted to mashups that primarily access information using JavaScripts, web-services, RSS, or even screen scraping. SOA provides a methodical paradigm for a robust long-term architecture based implementation. Contrast these to mashups that are easier to develop but are a challenge to manage due to the immaturity of tools. Currently most IT departments would agree to manage and deliver services, but would prefer to hand-off mashups to the consumer for management and maintenance. That’s because services have the potential of reuse, whereas mashups are one-off implementations.
So from the business perspective, am I willing to have it treated as a one-off solution? In the map application example, if I am the only consumer, a mashup may be fine. On the other hand if this could potentially be used across the enterprise, then SOA paradigm is appropriate. Mashups are typically suitable for low volume consumption, while SOA is typically suitable for high volume consumption. In some cases, it’s doesn’t have to be an either/or decision. A judicious combination of both may be appropriate.
In a complex business process, it is conceivable that different activities in the process may consume different services. These services may in turn have been architected using the SOA paradigm or using the mashup paradigm. The services would potentially be reused in other processes whereas the mashups would have been developed for quick one-off data access where interfaces are not guaranteed. If at some point in the future these mashups have a potential of wider usage, they should be converted to services for robustness and manageability.
