Pace Layering in Software: WebSphere Feature Packs vs Major Releases

One of the biggest challenges for any software organisation is how and when to deliver new functionality. Customers demand new features, yet they also don’t want to do anything to affect the stability of existing applications and services. This Hobson’s choice affects all software companies, as well of course in-house development – the app dev teams build software the ops guys don’t want to deploy.

Many of today’s key developer trends are attempts to bridge the functionality/stability gap – the public cloud largely took off as it did because it removed barriers to deployment. Developers could get apps up and running without having to ask permission or wait until someone was ready to deploy their code. DevOps is the new buzzword for shops that closely integrate development and operations processes – largely a web phenomenon so far, DevOps is gaining currency – but we need to be a little careful about assuming it will work for everyone – generally shops successfully using DevOps have hired the best technical talent to make it work. Another software approach designed to collapse the distinction between Dev and Ops is Continuous Deployment, an agile development practice, based on running a battery of tests during the development process using a continuous integration server such as Hudson, so the developer can be be confident they won’t break anything when they ship.

The new hotness is all very well and good, but for most shops traditional approaches will hold sway for a long time to come. So the question remains – how to get new functionality into the hands of developers, and so to end users?

Historically, IBM tracked innovations in the Java space with rapid iterations of WebSphere App Server (WAS). But customers found there were just too many releases to sensibly consume. WAS has therefore now formalised its delivery mechanisms with a stable core, every two years, with new functionality delivered through Feature Packs on an ongoing basis. Decoupling support for new APIs with core WAS Java and JEE support makes sense. The need for new services is only accelerating as web innovation is increasingly consumed by the enterprise – customers can’t wait years to take advantage of new technology, but they also demand stability. IBM can focus on fundamental architectural concerns such as rewriting the app server from the ground up to take advantage of OSGi, while new functionality is delivered at the edges. WAS tracks core Java specs, while Feature Packs allow IBM to support other stuff like OSGi, and dynamic languages:

• Feature Pack for Communications-Enabled Applications (CEA) – I have written before about CEA before – cool functionality – SIP calls in portals through Javascript, two users sharing one browser session – terrible name.
• Feature Pack for Web 2.0 – Cool functionality – all about AJAX goodness for more interactice UIs, even on iPhones, terrible name… (seems to be a theme emerging.) A good example of tech suitable for a Feature Pack, without the need for a major, or minor WAS release – support for the Apache Wink incubator project.
• Feature Pack for Dynamic Scripting – this time the name is spot on but the functionality is lacking. PHP and Grails… Come on IBM, sMash was nice and all, but I think we can safely file under- needs work if IBM wants to attract dynamic developers, and help its customers take advantage of their skills.

There are a few more to check out. But when it comes the new workloads, exciting functionality for developers and businesses WebSphere really needs a Feature Pack for NoSQL, helping enterprises consume some of the new data management hotness (largely) being standardised by the ASF. But then IBM has its own data grid software called eXtreme Scale.

I have written about Stewart Brand’s notion of Pace Layering before here and here, funnily enough both in the context of SAP, a company which more than most understands the tension of stable core vs innovation, and the pressure customers exert for both. SAP CTO Vishal Sikka has pace layering as a strategic concern under the rubric Timeless Software. One of the biggest pathologies in enterprise software is the pickup truck upgrade aka giving birth to a pumpkin– where it seems everything needs to be upgraded in order to upgrade anything. Stable core, innovate at the edges. IT needs to be more like building architecture, where it is accepted, even expected, that different elements of the infrastructure will evolve at different speeds. You don’t re-dig the foundations in order to modernise the wiring… But the problem of driving into a monolith remains a pathology – just see Windows Vista. So much for service-oriented architecture.

You see – SOA can underpin pace layering. Without the hard work of modularisation and componentisation over the few years, driven by SOA, IBM couldn’t be delivering Feature Packs as it is.

Its good to see IBM acknowledge and formalise pace laying in WebSphere: Feature Packs should make it easier for application developers to get what they need from IBM as they get out in front of the Java train. Indeed if you are a developer with a wish list item please let me know. If there is Java-based technology you’d like to be building apps to, but your ops folks say IBM doesn’t support it please let me know. I am happy to hassle IBM on your behalf.

And one last thing, for the purchaser-minded among you– the battle between new functionality vs operational stability maps pretty much directly to the ongoing License Fees vs Maintenance fees discussion in enterprise software. IBM has got this right with its Feature Packs- they are free to existing, version-current, WebSphere customers. One final advantage to IBM and customers of Feature Packs – delivering functionality becomes less about tracking formal JCP specs and more about implementing Java-functionality: IBM may be making nice with Oracle around Open-JDK but that doesn’t mean the Java innovation system isn’t multipolar.

disclosure: Yes IBM is a client. And yes I wrote a positive piece about them Friday. But I really want to up my posting frequency, and this was in the hopper. [update: got an interesting email from an ex IBMer saying the disclosure statement might be misconstrued. To clarify then – of course features vs stability is a relevant, indeed vital, industry issue, otherwise I wouldn’t post on it. That said- I do try and post on a range of topics, technologies and vendors. I don’t want to be, or appear, too IBM heavy, even in a month where I am taking so many briefings from the firm.]