Application transformation thoughts

For the second time, I was speaking with a friend in application support who was talking about their ‘run rate’ and how the business were complaining and he was thinking about virtualization of his servers to get of aged hardware on to ‘cheaper’ more ‘dynamic virtual machines’.

This got me thinking, is virtualization not stage one? A distraction step if you like, by that I mean ultimately I want my business to be leading edge to be agile and ahead of the competition, virtualization is a stage in which I abstract the application code from hardware, with stage 1.5 abstracting it from the operating system and the middleware bits that make it work.

Stage two would be application innovation and transformation.

Innovation in the respect that we look at our operating stack, the services, feeds and outcomes that the application delivers and consolidate these to reduce our operating costs and create opportunity. So we’re creating an asset report, how could we leverage that data in other lines of business and provide the relevant information or analytis for our decision making. Can that asset report data be merged with our server inventory to create a unified data set for support by our server teams, and decision making at the CIO and CEO level when it comes to data centers, platforms and strategies for how we use and derive benefit from our infrastructure. Our core objectives:

• Identify applications – what they deliver, what the upstream/downstream feeds are, what the outcome of the application is, who uses it and what we can derive from it, crucially is it needed – what happens if we switch it off?

Transformation in the respect of transforming out applications, our systems and our processes to identify our core business, our subsidiary businesses and the ones that we need to keep the lights on – email, intranet the bit that makes cnn.com work from my desktop. Our core objectives therefore would be:

• Consolidate applications – how many applications do we have vs what are needed, remove duplication, reduce complexity, identify and consolidate upstream and downstream feeds. In essence remove barriers to success, less things that can go wrong, with more transparent feeds so we can identify issues more quickly.
• Reduce range of application code platforms, fewer types of code cobolt, c sharp, xml, java, through to visual basic. Fewer types of developers requiring fewer and more diverse infrastructure plartforms to deliver what is in essence a commodity offering – it’s admirable that the code is concise, that it runs on a DEC Alpha, but how many downstream systems have I got to translate the text in that database into a html page on my iPhone?  How many different monitoring tools, database types and intermediary systems do we have to make application a speak to c and output to D
• Engineer for the future – whilst we fix the legacy systems, I need to be able to capitalize and deploy rapid next generation applications which are deployable across platform, this needs to be repeatable and customizeable so that we can deploy in one market, adapt and deploy in another, to whitelable our application to our clients, to someone else’s clients – whoever is paying.

When we refer to the ‘run rate’ the cost of running our application therefore we sometimes focus on the baby steps which absolutely we need to be doing, but doing so whilst understanding the cost of doing business, the cost of migration.  Baby steps are great, but we need to understand technically and operationally our IT infrastructure, our applications, from there we can make the right decisions:

• Core applications – typically in house unless economics dictate it
• Subsidiary applications – these might include white labelled applications (where I’m reselling my application to another customer a virtual mobile phone provider) – the hybrid cloud – I might use my in house standards but procure the service from the cloud
• Common applications  – the cloud, salesforce.com, whatever works and provides that function at a cost

In this space I am reminded of the example in a ‘core services’ of a global enterprise who’s manager once said to me, it’s $1million a year to run the entire solution end to end for the users, but $6million to re-write. We’d rather pay the $1 million a year. But why I asked, you yourself admit you could recognize the savings and you might get extra functionality. Yes replied the manager but:

• The application is a known and fixed cost – it’s factored into our business and IT running costs and needs no approval
• It’s due for decommission – since I’ve started here (3 years ago) we’ve been ‘decommissioning it’
• Incremental services and feeds can be added as a bau add on with little additional funding – we have the capacity
• Past experience has illustrated poor value dervied from large projects, the code, the middleware, the infrastructure is legacy. Switching to a newer standard of code, on new middleware and new infrastructure would mandate we comply with new standards which means procedure, operations and application level changes end to end.

This site uses Akismet to reduce spam. Learn how your comment data is processed.