Hinchcliffe and Chappell Predictions for 2008 Part 2 - Mashup Governance

Welcome to Part 2 of my series on 2008 mashup predictions made by Dave Chappell and Dion Hinchcliffe. In Part 1 I discussed how both are predicting the end of Big SOA. If you are interested, read the original posts and circle back to my comments. If you aren’t interested in the death of Big SOA, but are interested in mashup governance, read on.

Both Chappell and Hinchcliffe note that organizations will start pushing for mashup governance in 2008. We all cringe at the G-word, linking it with over-governance as mandated by legalistic process Nazis. Too much governance and you bring innovation to a standstill. Not enough and you have chaos. Light-handed governance can be a great help, insuring that security is in place, that there are recovery procedures, that everyone knows the lines of responsibility.

I’ve written before about how IT and business need to work together to make sure mashers have a secure and reliable mashup platform. Now let’s take a look at what Chappell and Hinchcliffe have to say along the same lines.

Chappell believes it's only a matter of time until a business-critical mashup fails. Some feed you didn’t even know you used will go away, some 3rd party service will change endpoints, somebody will change the mashup on Friday evening and then leave to hike the Inca Trail for two weeks. What happens? As Chappell says, “…many will be scrambling to figure out who is supposed to fix it, and who to point the finger at.”

He goes on to say that by the end of the year, driven by these mashup failures, mashers and IT alike will understand that mashup governance has to be put in place. Does it need to be as rigorous as the rules and processes surrounding making changes to the SAP ERP Financial system? Probably not. But neither can it be ignored completely.

Hinchcliffe makes similar predictions, but believes the demand for governance won’t happen because of a catastrophe, but because IT will start voicing loud concerns. "...it will likely be widespread grassroots behavior outside of IT that will drive the need for these solutions within IT departments." Security will become an issue as mashers pull data from many sources behind the firewall, from SaaS applications, and even from the web-at-large leveraging Web-oriented Architecture. (WOA) Mashers should ask questions about these data. Are the data reliable? Are the data available? Are the data to be used appropriate for the audience? After all, you don't want sensitive financial data leaked to the wild by a clueless masher.

While mashers should ask these quesions, it is likely that IT will be the one doing the asking. IT will make noises to govern access to mashable data within the enterprise. Additionally, IT will demand a SOA governance infrastructure that will provide security, policy enforcement and scalability across both on premises and SaaS mashup platforms and data sources.

Unfortunately, I’m just not sure whether any SOA governance solution can put the necessary controls in place without unduly interfering with masher innovation. Let’s take it as given that in a SOA world IT will be able to control access to services. Will these same controls work in a WOA world? I doubt it, at least not without cutting off access to uncontrolled services and data. Frankly, I doubt if the business would stand for these tight restrictions.

As I've asked before, what's to be done?

While IT may not be able to enforce governance outside the firewall and known SaaS applications, it can act as an advisor, explaining to mashers why reliable data sources are important. Why it might not be a good idea to use the Unreliable News RSS feed as input to a mashup for the CEO. Why scraping content from a random web site may land him in trouble. In the end the masher will mash, but IT can at least help the masher understand the risks.

Besides the SOA Governance infrastructure Hinchcliffe believes will be put in place by IT, I believe there are some actions that IT and the business can take together to implement safe mashing in the enterprise.

• Agree up-front who owns the mashup and who is responsible for maintenance, updates and enhancement requests. Who is backup in case the responsible masher goes on holiday? The lines of responsibility should be documented before you have to send a helicopter down to the Andes to airlift your masher back to NY so he can fix the mashup.


• Define the deployment and rollback plan and rules of engagement. What is IT's involvement in a mashup deployment? What is the masher's involvement? What is the rollback plan in case a deployment fails?


• Give the masher access to a version control system. Mashers will be generating code, XML, a model, or some other artifact that defines the mashup. That code, model, etc. has to be saved so when the production copy needs to be modified or recovered, the masher doesn’t have to start from scratch. Hint to mashers: a copy sitting on your machine isn’t reliable version control.


• Work with IT to make sure your mashup platform is scalable, reliable and secure. IT should put a registry and a repository in place so mashers know what services are available, the SLAs for the services, and any security, scalability and reliability concerns for their use.


• Require the masher document the data sources before allowing mashups into production. I know, documentation sucks, but so does getting pulled back from your vacation to explain why you've been getting market sizing information from astrology.com

These recommendations won't cover all the bases, but they will provide a framework for governance, even in a world where there is, in Hinchcliffe's words, "...still too much steering committee and not enough operating governance infrastructure." And most importantly, they will help mashers understand that when they mashup a business application, it isn't just a cool science project. It's serious business.