I am excited that “service mash-ups” has been selected as the theme for this year’s GTEC conference. In fact, there is a lot about mashups to be excited about. They extend the capabilities of an organization and provide a platform for productivity which challenges traditional roles, responsibilities, and boundaries. Mashups fill a need that is not met: if the current application portfolio did everything that was needed, we wouldn’t need mashups. Mashups shake things up and fill this gap. And what’s not to like about a good shake-up? Mashups symbolize a shift in the landscape for productivity within an organization.
Mashups have a lot more to do with enterprise architecture than might immediately meet the eye. They are all about reusing existing IT assets, optimizing service capabilities of the organization, aligning IT with business, and delivering control of creating solutions directly into the hands of the users of these solutions. In this way, mashups can play a key role in the enterprise architecture of an organization.
There are two striking ways in which mashups change the landscape for productivity: ease of assembly of software solutions, and change of responsibilities for software development. Mashups provide an environment for rapidly building new solutions by leveraging existing data sources, processes, and user interface gadgets. These assets can be quickly and easily orchestrated to form a new solution, often used in a context beyond their original intent. This greatly extends the capabilities of the organization and provides a platform for a level of productivity previously unseen. These solutions can be created by anyone – not just the IT department – and do not follow the same protracted lifecycle for the delivery of “official” applications. This type of opportunistic programming is a new concept for most organizations.
Mashups also represent a change in the way IT is viewed within an organization. Given this shift, it is important to recognize the role that traditional IT plays in enabling a mashup platform in the first place. You can only mash what you have at your disposal. Items to be mashed must first be defined and wrapped with a formal interface. Someone, somewhere, will have to do this work. For now, this work remains firmly within the IT department. It is the job of architects and developers to build the underlying building blocks of the mashup platform. These building blocks, or services, are then exposed in the “formal” environment for use in mashups. If this sounds to you like a service-oriented architecture (SOA), you are bang on the money. We can greatly improve our efforts in the mashup arena by taking clues from the world of SOA. After all, if we are shaking things up, let’s do it right.
Apr 9th, 2009 |
