This post originally appeared as at ITSMportal.com
Let’s start by looking at the supply chain in its simplest imaginable form, even simpler than the supply chain at a manufacturing company. Think of a transport company – like a Federal Express, DHL or TNT – that transports packages from location A to location B. There are processes, people and resources needed to get the package from A to B within the supply chain.
The reality today is that many of these distribution companies do not actually come to your door themselves – at least not in every region or town; they use subcontractors and local partners at various points. It would be far too expensive for the delivery firm to have their own trucks and employ their own drivers in every remote country, city and village around the world. (Bear with me, we will get to cloud computing in a minute). This way, they can still offer you end to-end-service and keep you up to day of minute by minute parcel movements around the globe. They provide customers with tracking numbers - or “meta“-information (01001011). They know exactly which trucks are where, and with which packages; as a result they can “outsource” almost every logistical process (the outside arrows in our animated diagram).
But IT does not transport packages from A to B (at least I hope that is not what you do all day!). IT meets the demands of the business by providing a steady supply of services. IT does not have trucks or warehouses, but departments such as development, operations and support that work within their supply chain. What an IT supply chain essentially does, is take IT resources - like applications, infrastructure and people - and use these to create and deliver services.
Some IT shops have decided not to react to demand, but to actively help the users - work with the business – figure out what they should want or need (shown by the arrow marked “innovation” in the diagram). A more recent trend is the introduction of DevOps, a way to closely connect and integrate the demand side with the supply side. This is often done in conjunction with the introduction of agile development processes.
Users typically care about speed, cost and reliability, not about whether IT used its own trucks or someone else’s. Speed - like in many supply chains - is one of the main criteria. Responding faster to customer or user demands reduces cycle time and time-to-market and makes organizations more agile and more competitive. The use of cloud computing in all its incarnations, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS), can play an important role in further increasing this speed.
With IaaS, the IT department can significantly speed up the procurement, installation and provisioning of required hardware. Because of its OPEX model, no capital expenditure requests need to be raised, no boxes with hardware need to be unpacked, no servers need to be installed. Just as in the above distribution example, the organization can rapidly respond to heavily fluctuating demand, extreme growth or demand for new services by using external capacity if and when needed.
With SaaS the route from determining demand to getting a service up and running is even shorter, because the whole thing is already a service the minute we start looking at it. There is no buying, installing, or configuring of the software. It all runs already at the provider’s website. If you are implementing a solution for ten thousand users across hundreds of departments, the time you save by not having to install a CD is not that significant. Large SaaS implementations go live much quicker than traditional on premises implementations, in many cases for psychological or even emotional reasons.Once the solution is already running, users are much more willing to start using it on the spot. Many SaaS providers reinforce this further by specifically designing their software to enable simple “quick starts.”
In those cases where there is no readymade solution available, PaaS (Platform as a Service) can deliver significant time savings. As soon as the developer has defined the solution, it can be used in production. The PaaS provider – through its PaaS platform – takes care of all the next steps such as provisioning the servers, loading the databases, granting the users access etc. Comparing PaaS with IaaS, the big difference s that with PaaS, the provider continues to manage the infrastructure, including tuning, scaling, securing, and so forth.IT operations does not have to worry about allocating capacity, about moving it from test to production or about all the other things operations normally takes care off. And because the PaaS provider has already done this many, many times, it can be done immediately and automatically.
Sound too good to be true?
Well,actually it might be, because - although the above can be faster – it also can mean IT loses control and can no longer assure the other two aspects that users care about: reliability and cost. So, how can these concerns be addressed? In the same way as in the distribution example: by making sure that at all times, IT has all the information (010011001) about “where everything is,” or better, “where everything is running.”
This management system –call it a “cloud connected management suite” if you like – needs to not only give insight about where things are running and how well they are running, but also allow you to orchestrate the process, move workloads from one provider to another, and help you decide whether to take SaaS or PaaS applications back in house (or move them to a more trusted provider). Ideally it will allow you to dynamically optimize your environment based on the criteria –such as speed, cost reliability – and constraints – such as compliance, capacity, contracts - that are applicable at that moment in time to your specific business.
Clearly this dynamic approach is a long way from the more traditional “If it ain’t broke, don’t change it,” but IT will have to get used to this. Or - even better - embrace this new way of doing things, just like planners at industrial companies did. Today’s global manufacturing would not be as efficient and such a driver for the world’s prosperity if they had not started to optimize their global processes a long time ago.
There are, however, a number of prerequisites to be able to implement such a supply chain approach in IT. First, we need to achieve fluidity or movability of IT. IT needs to be able to take fairly sizable IT chunks and move them somewhere else with relative ease. On the infrastructure side, virtualization is a major enabler of this. Virtualization containerizes and decouples from the underlying hardware, thus acting as a dire needed “lubricant”. But to enable true movability, more is needed.
Many of today’s applications are as intertwined as the proverbial plate of spaghetti. This makes the average datacenter a house of cards, where removing one thing may cause everything else to come crashing down. On the functional side, the use of Service Oriented Architectures can help, but we will also need to apply this thinking on the operational side.A virtual machine model is in many cases too low level for managing the movement of complete services; management needs to take place at a higher level of abstraction, ideally based on a model of the service.
The second hurdle is security. I don’t mean that the security at the external providers may be insufficient for the needs of our organization. In fact, the security measures implemented at external providers are often much more advanced and reliable than those inside most enterprises (fear for lack of security is consistently listed as top concern by organizations before they use cloud computing, but it rapidly moves down the list of concerns once organizations have hands-on experience with cloud computing). The real security inhibitor for the dynamic IT supply chain is that most organizations are not yet able to dynamically grant or block access to a constantly-changing set of users, across a fast moving and changing portfolio of applications running at a varying array of providers. This requires us to rethink how security is approached, where it is seen more as along the lines of “Security as a Service”, an enabler instead of an inhibitor.
The third consideration is that any optimization will have to work across the whole supply chain, meaning across all of the different departments and silos that the average large IT organization consists of. For example, it has to look at the total cost of a service, including running, supporting, fixing, upgrading, assuring, and securing it. Likewise, it also has to optimize the speed and the reliability - or at least give visibility into these - across the whole chain.
To prevent sub-optimization (the arch enemy of real optimization) one needs to understand and connect to many of the existing information and systems in these departments. Systems in diverse areas such as helpdesk, project management, security, performance, costing, demand management, data management, etc. IT supply-chain optimization is in its infancy and many start-ups are gearing up to offer some form of cloud management, but it will be clear that offering optimization requires quite a broad and integrated view of IT.
The end result of adopting a Supply Chain approach is that IT becomes more an orchestrator of a supply chain - a broker of services - than a traditional supplier of services. Demand and Supply are two sides of the same coin which occur (almost recursively) throughout the chain. Once we close the loop, the supply chain becomes a cycle that constantly improves and becomes more efficient and agile in delivering on the promises the organization makes to its customers, just like an industrial supply chain but also very much in the spirit of Deming and the original ideas around Service Management.