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…
