IT should be an almost-silent partner of the business masher

I'm taking a break reviewing QEDWiki to comment on Tony Baer's excellent posting about the history of application innovation and the mashup. With mashups, he says, app dev innovation history is repeating itself. I couldn't agree more. Sometimes we forget lessons of the past in the rush to embrace the new and innovative.

Did I say "sometimes?"

We always do. And that's actually OK because behind every innovation there are a bunch of insiders who declare that it can't be done, shouldn't be done, or has already been done and failed. These people have an important place in the innovation loop, providing valuable negative feedback that should stop out-of-control oscillation. As long as the negative feedback doesn't overwhelm the positive motion of innovation, it's useful. Without collective amnesia, however, negative feedback can stop innovation in its tracks.

If collective amnesia is necessary and not at all evil, that may be why so much innovation has happened outside of IT. IT can't afford to have collective amnesia. They are directly responsible for keeping the CEO and CFO out of jail, making sure books get closed, people get paid, products delivered and customers billed. Radical innovation in that environment carries unacceptably high risk. That's why laptops infiltrated the workplace with new light-weight applications long before IT caught on. Web applications came out of marketing departments and mashups, well they are oozing out of everywhere. Everywhere except IT that is.

Baer's point, however, is that after the rush to innovate, mundane concerns eventually do set in. Once you've built a mashup, once the enterprise has started to depend on the mashup, how will the data be kept accurate? Who will maintain it? When it starts to be used in ways that the original masher didn't intend, who will support it? These are the everyday concerns that are in the DNA of professional coders in IT. When Computer Science professionals start to build an application, they think about these issues up-front.

Not so for the innovative business masher. He or she can build an application quickly, deploy it easily and watch it grow virally throughout the organization. Right up to the time the CEO gets bad information because the mashup referenced old data.

Crash!

So am I saying that business mashers need to stop innovating? Regular readers of this blog will know that I wouldn't say anything like that. Business developers are going to drive innovation further and faster than IT exactly because they aren't hampered by such mundane considerations. They need to keep moving forward, but they need help from IT even if they don't know it or are unwilling to admit it.

What sort of help? IT can give good advice about the best way to access data so it remains up-to-date. IT should set up a secure infrastructure so the business masher doesn’t inadvertently release sensitive data into the world. IT can also give some gentle technical advice about best practices for assembling applications. They can help mashers set up a very light-weight process for getting feedback (AKA bugs or enhancement requests.) and help them work with version control before disaster strikes.

Before you in IT decide this isn’t your problem, here's the money quote from Baer: “At the end of the day, mashups that evolve to enterprise mashups are not like enterprise applications. They are enterprise apps. The only difference is that they piece together much much faster.”

Again, I couldn't agree more.