As our discussion around the role of the application platform continues, a quick look back shows us that the Reg reader jury is still out when it comes to deciding on the capabilities which deserve or need to be included in one.
The other side of the coin to ‘what’, is perhaps unsurprisingly, ‘how’. If you are going to develop an application platform the natural thing to consider is not only what to include, but where you get the bits from. We already touched upon the build versus buy question, but when it comes to planning in earnest, we’re talking about more than just software, aren’t we?
If we’re serious about application platforms – and all the indications suggest that we are - then we need to be sure we’re covered before we set off. This means taking time to consider lifecycle support and services, in addition to the components that make up an application platform. For many organisations, the question of ‘services and support’ is one of the reasons why proprietary software already occupies the strong position it does. The trade-off between (assumed or real) vendor lock-in and ongoing support often outweighs the flexibility and freedom of developing things in-house using open source tools and components – but which can incorporate less, or no third party support in the traditional sense.
To frame this as a question then, do such longer-term considerations play a part in how you will proceed with the planning and development of an application platform? Given the spectrum of support services available throughout the industry, perhaps some organisations will simply default to the suppliers whose business models are focussed around post acquisition support, whether they supply proprietary or open source software. That could mean that ultimately, we might see very little change in the grand scheme of things when it comes to vendor representation in the application platforms of the majority of organisations.
Given the importance to the business of how the application stack evolves, perhaps it’s too big a risk just to take the plunge without a level of guaranteed service – and indeed controlled lock-in. Does all this dictate little in the way of change for the future, then, or does it simply mean that for business critical applications the status quo will remain, leaving areas such as testing and development open to broader ideas such as utilising open source tools and products without a service guarantee?
Tell us what you think, if you'd be so kind... ®