Development Governance for Mashups

“Mashups” (and all the rest of the “Web 2.0” buzzwords) make up one of the more exciting trends to emerge recently. They promise to give the Enterprise a different view of its data assets, treating both structured relational database data and less-formally-structured operational business data as one resource—which can be combined with web data resources. This may help reduce the application backlog, increase business and IT agility—and also help to integrate IT with the business, as required by ITIL v3. The focus of mashups is very much on innovation; for instance, read Rene Bonvanie, senior vice president of marketing at Serena: “I think innovation is what’s more at stake here than governance. The thing is, how can we get enough people to do mashups and make them more innovative? We’ve overestimated the need for governance and underestimated the need for innovation”

However, there is possibly a dark side to this, the possibility of “standards-based chaos” and the basing of decisions on out-of-date data or, more worryingly, up-to-date data of doubtful provenance and reliability. The facilities provided by platforms such as Denodo are necessary to ensure that there’s an adequate level of governance applied to mashups (through automatic maintenance if the underlying resources change, for example) without compromising the agility which drove the use of Mashups in the first place.

First, we should define the term “mashup”, although defining terms isn’t a very “web 2.0” sort of activity. Mashup is used to describe a web application that integrates data from several sources, internal and external, in pursuit of some business benefit, often without the knowledge or agreement of the owners of the resources being “mashed”.

Mashups differ from portals largely in that they use newer technology with new, evolving standards (that is, in practice today, with few formal standards). Mashups are based on XML Data Interchange standards with REST semantics and commonly use RSS and Atom technologies.for integration.

Web 2.0 itself isn’t clearly defined—the Wikipedia definition is as good as any (another, rather unkindly, is that “Web 2.0 is all about running your business on beta software”). However, mashups and other Web 2.0 technologies are clearly enabling technologies for a new style of agile user-oriented web application with a rich graphical interface (the availability of geographical feedback on maps seems typical).

Mashups should be all about integrating business processes in order to deliver business benefits. Nevertheless, integrating business processes only makes business sense if the underlying business data can be relied on. However modern the mashup UI, successful data integration involves understanding the meaning (business semantics) of the data and its provenance, not just its physical format—and this implies the use of good old-fashioned data analysis. A governance issue arises from the fact that ubiquitous adoption of web services standards means that “mashing up” (integrating) data sources is trivial but sometimes the results might not mean much at the buiness level. Consider these scenarios:

• You combine 2 sources of customer data—but one source is all validated real customers with verified credit ratings and the other source is not validated and includes prospective customers with doubtful credit ratings. How much confidence can you have in the integrated data? Well, it depends whether you included a ‘quality metric’ in the mashup and on what you’re doing with it.
• You mashup near real-time data from your production systems with several internet resources—but the internet sources change while you’re doing your analysis. How up to date is your analysis? Well, it depends on how you build the mashup.
• You build a mashup application in the IT group, but several power users in different parts of the organisation have access to the Web 2.0 toolset (from the web) and produce custom versions of the app. Then the IT group produces v2 of its mashup, addressing several security and regulatory issues. Does Mashup v2 include some, none or all of the power user customisations? Which version is actually in use throughout the enterprise? When the auditors ask about the regulatory issues v2 addresses, can you convince them that everyone uses v2?

Other questions you should be considering include:

1. When you build a mashup from resources outside your control, do you have a service level contract with the owners of the resources? If Google Maps becomes critical to your customer’s interaction experience, with your sales system, for example, do you have any comeback if Google decides to stop providing Google Maps or to charge huge fees for its use?
2. Is everything in your mashup ‘industrial strength’? How do you know this; and if you have Web 2.0 coding standards how do you enforce them? And is the idea of having Web 2.0 Standards a silly one?
3. And, finally, if you address all the above issues, have you set Web 2.0 in concrete and destroyed the agility which made Web 2.0 mashups attractive in the first place?

There are several vendors with tools that can help you to exploit mashups without losing control of governance, and I’ve talked about some of here before: Compuware’s Uniface View 9.2, for example, now supports “enterprise mashups” and the use of the Uniface framework may help you address any governance issues. You can probably expect every vendor to add support for mashups and associated technologies over time—at Microsoft’s 2008 Heroes launch, to give another example, it demonstrated several mashup-like applications and it was very proud of its new support for php (after years of pushing C++ and C#). BEA is yet another company (or, possibly, division of Oracle) taking governance in the new Web 2.0 world very seriously. BEA AquaLogic Ensemble provides a role-based provisioning system for new mashups and can track usage; analysing both mashup activity and resource delivery. This could help make it easier to demonstrate the ROI from a mashup initiative.

More specialist vendors also have a strong story in the mashup space. One particularly successful example is Denodo, with its Data Mashup Architecture. This is a rich platform, which, for example, supports real time update of the mashup screen whenever one of its remote source components (possibly one outside of your control), changes. Less well known outside of Japan, JustSystems also provides a pure XML standards-based integration framework (not really a conventional mashup approach but one that delivers equivalent benefits) that should make building-in governance easy. And, don’t overlook the importance of something as conventional as change and configuration management for business-oriented mashups—for example, Serena Business Mashups (you can download a free copy of its Mashup Composer from the Serena website) claim to empower lines of business to build their own mashups while still maintaining IT governance by offering mashup versioning and full auditing.

However, always remember that, although tools and frameworks can make implementing good governance easier, governance is primarily a people and management thing. We remember the widespread creation of ungovernable legacies in the 1980s—not mainframe legacy, but the explosion of mission critical spreadsheet applications which turned out to be unmaintainable. At one stage we had every release of Lotus 123 in operation because no-one dared upgrade these spreadsheets in case a macro behaved differently afterwards (and no-one had any idea of how to regression test them anyway). Similarly, mashups could lead to “REST-based chaos”—so let’s learn from the past and do mashups properly.

And, to that end, would our readers be interested in a Bloor Spotlight Paper on the emerging issues around mashup governance? If so, please write in and let us know.