Welcome Back Serena!

So, Serena seems to be making useful noises again, after a time when it sent out some very odd messages implying that it had reinvented itself as a mashups company and was no longer interested in its core competencies. This wasn’t true, of course, and although it had quite a good mashups story it still made its money from enterprise-level cross-platform tools like Dimensions.

However, back then I heard disturbing tales from people saying that “Serena is getting out of Configuration Management” (easily refuted if you bothered to talk to people like Serena’s evangelist Kevin Parker) and I suspect some competitors took advantage of Serena’s somewhat flawed messaging to spread ‘fear uncertainty and doubt’ about its future.

Now, the messaging is different—and better—as I found out while talking to Kevin Parker a week or so ago. It’s about orchestrating commodity tools from anyone around a process—which is a damn fine story.

But I’m just an analyst, and I wonder how this story is going down with potential customers and users of Serena’s technology. So I asked Robert Cowham, a consultant for VIZIM Worldwide and Chair of the BCS CMSG (Specialist Group for Change, Configuration and Release Management):

“I have chatted to several Serena employees who were all pleased with the change of CEO and the resulting return to the company’s traditional roots,” Cowham says; and he also notes, “a focus on things that have a good customer base and actually make money (e.g. Dimensions) as opposed to the diversion into ‘all things Web 2.0’ which resulted in TeamTrack being renamed Business Mashups and being about to take over the world”.

Cowham continues: “I was not convinced by the story of how Business Mashups was going to allow users to do everything themselves and do away with application development, even though it is a very capable and flexible tool. With the Mashups name quietly morphing to SBM, the new pitch around orchestration seems much more real and consistent with a company focussed around tools and solutions for managing application lifecycles”.

SBM (the name is derived from Serena Business Manager these days) is a process management tool and, according to David Hurwitz, Serena’s Senior Vice President of Worldwide Marketing, Serena is now engaged with Orchestrated Application Delivery, to “deliver apps faster and at lower cost by managing application demand, development and delivery as an end to end process”.

And he has some useful insights, including the need for process creditability, using automation to deliver key performance indicators (KPIs) and required documentation. With process-oriented metrics, the “demand to deploy” development process he envisages can be improved, and I think that process improvement is a key characteristic of next generation development.

I suspect Serena is onto a winner here—but I doubt if its competition is standing still. Its messages seem rather familiar to me from some of the ‘software econometrics’ presentations from IBM—including the use of Focal Point for demand management.

It is interesting that Kevin is scathing about IBM’s Jazz platform, it’s real openness in practice and its take-up outside of IBM—which perhaps means that Serena does see IBM products on the Jazz initiative as very real competition (although the jury is probably still out on the take-up of the Jazz ‘philosophy’ outside of IBM). However, there’s no point in arguing about marketing messages when the real proof will be in mass adoption customer case studies when (or if) they appear.

Personally, I think there’s room for both Serena and IBM in the development of the software behind automated business services (or applications, if you like) and that IBM really wants Jazz to be an open initiative. However, as Kevin Parker himself pointed out at a CMSG conference some years ago, all vendors [possibly even Serena, it occurs to me] have a “dirty little secret”; they quite like customer lock-in, albeit (these days) using velvet covered chains.

And, to be frank, if you are locked in by tools that are easier or cheaper to use, or more effective, than the competition supplies, even though there’s a risk to manage (the cost of moving off a platform or technology may allow vendors to charge you more in the longer term), it’s hard to see why you shouldn’t take advantage of them, with reasonable care and foresight.

David Norfolk is Practice Leader Development and Governance (Development/Governance) at Bloor Research. David first became interested in computers and programming quality in the 1970s, working in the Research School of Chemistry at the Australian National University. Here he discovered that computers could deliver misleading answers, even when programmed by very clever people, and was taught to program in FORTRAN. His ongoing interest in all things related to development has culminated in his joining Bloor in 2007 and taking on the development brief. Development here refers especially to automated systems development. This covers technology including acronym-driven tools such as: Application Lifecycle Management (ALM), Integrated Development Environments (IDE), Model Driven Architecture (MDA), automated data analysis tools and metadata repositories, requirements modelling tools and so on.

  • Great post.

    You captured the story succinctly and you nailed the main points.

    Your last point is key. The consistent message from customers is that they are tired of vendors trying to get them to rip-and-replace existing tools. The tools are adequate for their needs. The burning issue affecting app. dev. is how do we increase the velocity of app. delivery, strengthen quality and deliver greater value? The answer, customers tell me, is … "it's the process".

    It’s time to bridge the connections between IT silos and automate from inbound Demand, through the Development right on into Deployment.

    Once we automate, we optimize, we get data about IT and manage instead of react and we get auditability.

    As Serena's futurist, my prediction is that the next decade will be about IT lifecycle automation.

  • Business Mashups was a great tool – but the problem is it was only focused on one very specific kind of mashup, namely those with a key workflow component.

    Serena easily had the most extensive marketing campaign of any of the major mashup products (Kapow, IBM, JackBe, Connotate, etc). But unfortunately this created some confusion as they naturally sought to define mashups largely by the niche they excelled at.

    The "Mashup Story" was never about abolishing IT, but about creating a partnership where IT provides the services and "mere mortals" assemble them with simple tools. It's the "do-it-yourself" model of big home stores applied to the software world.

    Alas, Business Mashups didnt fit this meme, so Serena muddied the picture a bit to fit in. I think the takeaway here is that re-branding and extensive marketing are not a viable business strategy. Serena's return to its core competencies would indicate this lesson has been learned.