Jeremy Burton has followed a circuitous path to his current role as president and CEO of Serena Software. Having served executive roles at the likes of Oracle and Veritas, a good part of his career has had to do with the controlling role the IT department plays in keeping an organization's bits flowing towards profitability. Now at Serena where such control is the antithesis to his company's strategy, Burton probably realizes the role he played in the IT departments' taking back of what it thought belonged to it in the first place.
Burton came to my home office for both a podcast interview and a demonstration of Serena Software's business mashup development environment that's designed for non-programmers. We captured the demo on video so you can judge its ease of use for yourself. But it was during the podcast where I captured Burton's philosophical approach to Serena's business. For those of you who were around in the 80's perhaps you remember how PCs and local area networks (LANs) represented the rebel movements inside corporate America. Loathe to wait for the IT departments to respond to their needs, department heads were taking IT matters into their own hands, first buying PCs and using them to automate certain tasks and then, God forbid, networking them together to yield an additional gain of productivity and efficiency.
As Burton and I talked, I couldn't help but agree that some how, some way, that ability for departmental managers and innovative thinkers to act on their automation instincts (some might call this a threat to the IT department) is a bygone. Back in the 80's, not only did we have LANs, we also had dozens of relatively approachable programming tools that allowed slightly advanced (if not ordinary) PC users to automate certain tasks. What started with macros in word processors and spreadsheets lead to lightweight yet programmable databases and forms tools like dBase, Foxpro, and Paradox. But today, while some friendly tools do exist, if they can't get it done in an Excel or Word macro, most people end up calling the IT department where projects can disappear into the ether (if they're lucky enough to get approved). Considering where we once were, how the hell did we end up here?
Instead of answering the question, Burton just seems hell bent on getting Serena Software to pick up where things left off. Given the role that services oriented architectures (SOAs) now play in retrieving data and functionality, Serena's Holy Grail is less about the sort of scripts we used to write at dBase's dot prompt and more about the rapid development of mashups: browser-based software that draws upon one or more SOA-driven sources of data and functionality. Today, there's really a dearth of turnkey mashup development environments. BEA has a tool under its Aqualogic brand and IBM's QEDWiki-driven mashup development environment is in beta. But, whereas both of those probably require input from the IT department to get up and running, Serena's solution involves the downloading of a Windows-based tool that can publish mashups to a Serena-hosted infrastructure. As with many commercial software development tools, it costs nothing to download and build mashups using Serena's tools. But the minute you put those mashups into production for your company, the toll starts to ring.
In the podcast, which you can manually download, stream (just hit the play button on the podcast player above) or have automatically delivered to your PC or MP3 player (see how), Burton answers all sorts of questions about how a 20-something year old mainframe computing company is suddenly working the bleeding edge of software development, the company's business model, and what the options are for those who are interested but don't want to publish their mashups outside the corporate firewall. Then, in the attached video, he gives a quick demo of how it all works.