Extending Reuse to the Last Mile

While services make it easier to share your data and functionality, some developer still has to write the code to consume your service and present the results to the end user. In many cases, that code to consume and present a visualization of the service can be reused by other applications. This has already exploded on the Web with Facebook widgets, embeddable YouTube videos, blog traffic counters, etc., so what I'm talking about here is nothing new.

However, within the enterprise the use of shared UI widgets is still not very prevalent. This is problematic because it still leaves the creation of useful applications out of those shared enterprise services within the hands of IT. This really does not make the enterprise that much more agile at delivering useful capabilities to the end users. Real agility is achieved when end users can create those capabilities themselves by building lightweight micro-apps that are composed of various shared widgets for consuming and visualizing those enterprise services. These micro-apps can themselves be packaged up as widgets so that they can be reused within other apps.

So the next thing to do after you're done building those enterprise services is to start building some UI widgets for those services so that you end up with a portfolio of widgets that can be shared alongside your portfolio of services. This will extend the ability to share (or reuse) those services all the way to the end user, i.e. the last mile. You can think of this as sort of a "widgets-based architecture" that is built on top of your services-based architecture.

Woohoo! I Can Now Access Your Crap Data More Easily

With the growing popularity of enterprise mashups, more and more organizations are starting to service-enable their data sources, i.e. building web services on top of their data sources to enable access to their data. Unfortunately, most of them are not addressing their underlying data problems first before doing so. I've written about this before, talking about the need for an SOA data strategy. It still amazes me to see how many people out there still think that by slapping web services on top of their databases, amazing things will happen and their problems will be solved. All that will happen is that this will bring all their crappy data up front and center on some flashy AJAX-based mashup application. We've seen this before in the past with BI and reporting applications that used some of the more traditional data integration technologies. After the BI app is built, the end user realizes that she still can't do any real analysis because the data is crap.

soa, enterprise mashups, data strategy