Guest post by Daniel Smithson Don’t incur technical debt with the cloud – employ a cloud abstraction product The arrival of cloud technologies has led to a gold rush of adoption. Cloud technologies appear to offer organisations the nirvana of rapid, on-demand elastic compute provision, be that through public, private or hybrid deployments. Having embraced the benefits of self-service infrastructure, organisations are now embarking on developing cloud-centric applications that harness the ability of the cloud to expand and contract infrastructure capacity based on application demand. However, to do so applications need to be coded to exploit the API of the chosen cloud platform. And this may have a sting in the tail - technical debt.
Have you stopped to think about how the leading cloud computing providers are able to provide enormous quantities of computing resources at the click of a button? Clearly, they have massive data centres around the world filled with racks of high performance IT. If you were their only customer that might be the end of the story but, of course, they serve huge numbers of customers, many with enormously volatile workloads, and are taking on more every minute. Now and again you might get a little reminder that this does not all come about through magic (have you noticed the occasional “our servers are busy” message when trying to use Twitter?). So how does it all work and what risks does this pose to your business? How confident can you be that your next ad-hoc request for a virtual machine will be satisfied? Even worse, how do you know that your existing cloud based services will not be constrained by your cloud provider’s next wave of new customers?
Recently I have been enjoying the “Pheonix ProjectThis is one of those novels of IT and, like a good Disney movie, you know it is just a story but it engages on many levels and includes strong messages. In the Pheonix Project the authors make much of the parallels between traditional manufacturing and IT operations. I am a big fan of this idea and something very similar is at the heart of the next chapter in our story about a service oriented operating model for IT.
It might seem odd, given I make my living helping organisations with their IT, that I am what marketing types call a “late adopter”. I was just about the last person I know to get a DVD player and even my mother got a high definition TV at home before me. I skipped the first 3 iPhones and I am only a month into my first tablet. But being a late adopter doesn’t mean being ignorant about the latest developments. I may be a late adopter but I am also an early monitor; trying to keep up with new ideas so that I can, hopefully, help others. Adopting new ways of working or technologies should be a well informed decision not a reflex. Here are a variety of areas that I am monitoring, as they may develop into useful tools in the future, together with some research topics which I think deserve more attention than they are currently receiving.
In this latest post on a service-oriented operating model for IT I will cover mapping out the IT value chain. There are quite a few steps which lead up to this point so start here if you want a reminder and don’t forget these warnings. So let’s get started with: what are IT value chains all about, why you need to take the time to map them and how do you use them.