A few weeks ago I visited a customer that laughed about how they were 5 years into their 2 year IT transformation program. Sounds like a familiar story. I can’t count on my two hands the number of customers that have shared the same story, always with that funny smirk of “what were we thinking” or “this was never going to work”.
Then I visit the small number of customers who tell me their transformation journey has worked, that IT is seen as a valued business enabler, and that agility and innovation is a key outcome that they have been able to provide to the business. In some cases I hear this from the business. One large business owner in a top 4 bank said to me “IT is a differentiator when we sell banking solutions to business customers”. It’s not every day that you hear about business owners talking about their IT capabilities like that.
So what’s going on that separates the success stories from the failures?
Usually a new CIO enters an organization and is faced with the challenge of legacy IT, slow processes and a poor reputation within the business. Eager to succeed, these CIOs usually quickly conclude that people, culture and processes need to change. They present a vision of embracing agile practices, building a DevOps culture, transforming teams towards Cloud architecture and often head down the path of BiModal (reference Gartner) IT.
And things don’t work. Why not? Well here’s an interesting analogy.
For anyone over the age of 40, if you were to fly on a plane as child (usually a Boeing 747) if you were lucky you may have gotten the chance to enter the cockpit during a long-haul flight. What you would have seen is 3 people flying the plane. The Pilot who leads the team, the Co-pilot and the Engineer. While the first two people were flying the plan, the role of the engineer was to tune the plan and fix problems in real time through a series of dials and buttons.
Jump forward to the 1990s and through to today and what would you notice? Typically aircraft, even large 747s are flown by two people – the pilot and the co-pilot.
So what happened? What was the transformation that occurred? Did airlines come in and say we need to embrace new methodologies, change our processes to be leaner and optimize our teams, while still running legacy aircraft? What would happen if we transformed the team to just a pilot and co-pilot while they tried to run a traditional, non-automated plane. Clearly this approach would not have worked. Overworked pilots would be complaining about risk, stress and an ability to do their job. Their capability to learn everything and manage all they needed to do would have been seriously challenged.
Or did airlines modernize their aircraft, enable automation and then transform their teams around the new systems and tools?
It seems natural to most people that the second approach makes sense. Only once you have a modern plane with automation systems can you then transform your teams.
Unfortunately too many IT executives in Australia are trying to fix IT by transforming teams without first modernizing their platforms.
Here’s an example. In one case I saw a large financial institution who is struggling after many years to achieve any improvement as a result of their IT transformation program. In many cases the business views IT as having gone backwards over the last 5 years in terms of their capabilities. When we discussed further, this organization had a heavy adoption of outsourcing. Their complex systems range from mainframe, to Unix to a vast array of non-converged x86 platforms. Their processes to provision and allocate resources involved one team calling another. Their tools were all manual and efficiencies were trying to be had be moving manual processes in Australia to manual processes in India.
In another example, a large telecommunications company was trying to build in automation to their IT infrastructure. After 4 years they are just winding their second attempt to automate IT into a service catalogue. Twice this organization had procured automation software to run over legacy systems. The goal was to turn legacy siloed technology into pools of resources with rapid provisioning and automated operations. The challenge they faced was that while automation might work day 1, as soon as a driver needed to change, or a system was updated to a new OS, or a new version of ESX needed to be installed, the whole automation system collapsed and they would spend many manual hours fixing issues that caused these operations to break. The vision of automation and transformation has been getting nowhere.
So where should CIOs start to transform successfully?
My view is that we should look at the organizations that have been successful and understand what they did differently. Here’s what I see as the common approach.
For those successful organizations, the first step in the process is to begin by modernizing the core data centre infrastructure platforms and technology. As a CIO, there are some great questions to ask the Infrastructure team to help understand how they are going about this.
Firstly ask them how many standard infrastructure patterns they have for compute, storage, network and virtualization? Many IT organizations will answer with something like “we have hundreds of variations of everything” or “we build custom, tailored platforms based on what the business wants”. It could be that one compute system has 64GBs of RAM, and another has 128GBs. It could be that storage configurations vary greatly. It might be different flavours of Unix or other operating systems that warrant different hardware. When you look at mega scale data centres, and there are well publicised examples of companies like Amazon, Facebook and Google, typically these organizations will have no more than 8-10 patterns for everything they do. These organizations may be 10x larger than yours, and have vastly more complex systems to support, and yet they always reduce IT down to a few basic building blocks.
These organizations have realized that variation creates complexity while standardization leads to efficiency and agility. If your team tells you they have more than 8 patterns, then ask them why they think they need to be more complex than google. The challenge will be having to say no the business A LOT. Can I have iSeries platform for my new database? No. Can you tailor my HANA environment with 10s or TBs of RAM? No. Can you implement a rare flavour of Linux that is completely different to anything else we run? No. While this
Secondly, have they embraced the core tenants of the modern data centre. Is the technology architecture and systems that they are deploying converged (meaning does compute, storage and network get built and operate as one)? Have they standardized around hyperconverged nodes which are the modern building block for IT? Are they embracing a move to the all flash data centre which is highly efficient and enables 10x increases in application performance with fewer administrators doing crazy tasks like balancing I/O? Are they leveraging software defined scale out technologies, which allows data centres to start small, scale big, operate in a programmable (automated) cloud like fashion and adapt to new business demands that may warrant both growth and decline of services? Do they have a strategy to connect infrastructure to external cloud services, particularly for services like backup, archive, disaster recovery and unique services not currently offered by IT? At the end of all this infrastructure modernization, if you ask your Infrastructure team how many standard patterns they have based on these modern data centre trends, if the answer is less than 10 then they are on the right track.
Once the foundation is laid and the core data centre modernized, then the organization can begin building out automation capabilities. These capabilities come from laying converged and software driven architectures that are controlled through APIs and building a suite of automation software that automates key functions. These functions would include infrastructure provisioning, systems lifecycle management, predictive fault detection with analytics and correction. In addition most organizations will now introduce at this point a service catalogue with a set of automated workflows, the ability to provide charge-back, self-service to the business (ie the tools and systems are based on policy) and elastic scale of infrastructure. Because the underlying infrastructure is converged, the automation workflows will have a much simpler time driving these traditionally manual functions. Tying automation to converged systems means that the issue I spoke about earlier where a company was struggling with their automation roll-out will be mitigated.
The shift from CapEx to Utility
One of the biggest challenges in enterprise IT is wasted infrastructure. Too many times we see organizations invest capital into large infrastructure solutions, only to find that a quarter of what they expected to use was actually consumed. Littered with waste, IT gets a bad reputation for unused infrastructure and inefficiencies.
This point in the transformational journey is the perfect time to start asking your infrastructure suppliers how they can change the way they work with you. Why should you own all the risk when it is their technology? Most innovative IT vendors will structure true utility consumption models where they own the asset and you pay as you consume. The risk shifts to them. A sale no longer occurs. As a customer, once you sign a contract it is up to the vendor to help you consume the services. This traditional vendor of model of “call me in 5 years when you want to refresh something” goes away and the vendor is now as accountable for adoption of modern data centre services as you are.
In many cases IT might want to look at a shared risk model. Some vendors refer to this as a “flex” utility consumption model. Under this model the infrastructure is consumed on demand with some level of commitment. Whether you adopt a true utility model, or a flex style strategy, this discussion with vendors and change in which you buy and deploy systems is a way to reduce wastage and increase IT utilization.
Tip: Many CIOs usually hit this point in a discussion and say “but I only have a CapEx budget. My business will never move to OpEx.” I have heard this from a great number of IT leaders and CIOs. It is often something holding them back from shifting to cloud and sharing risk with suppliers. Our organization had the same challenge when shifting towards a utility models. The business wasn’t ready for a transformation to full utility charge-back models, so we began with what’s known as “show back”. Under this model, each application owner and business unit knows the cost to run every application or device (e.g. what a virtual machine costs per user, or what my SAP landscape cost me) through a monthly reporting cycle showing the bill for that month. At this point the business still provides IT with a CapEx budget, but the business unit and application owners see their costs as a utility consumption model through the show back reports. Eventually what happened in our organization is that the business started identifying systems that were costing a lot, but not adding value, while other new applications were being held back due to lack of funds. Once the business was able to talk in consumption economic terms, they began wanting to take control of decisions of what project to fund and what services to switch off. Through empowering the business and making them accountable for the overall operating spend they began to want to shift to having more ownership. This then drove the move to true utility charge-back models. The whole change took 1-2 years.
Think of “show back” as an interim step towards full charge-back models that warms the business to the change.
Here’s the best part. Every year prior to our consumption transformation, IT was seen as a large monopolistic cost centre that the CFO would drive cost savings through by annually lowering CapEx and expense goals. Once the model shifted to Opex and Utilty, it was now the business units’ decision as to whether they would hire more people, or invest more in IT and applications that would drive new business models and increase revenue. With the business making those trade-off decisions, the overall spend on IT has increased rather than reduce. IT’s role is now to focus on lowering unit cost and increasing adoption of services, while the business works out what services they will pay for that will deliver new business outcomes.
Last Phase: Transformation
So we built a modern data centre and enabled automation, what now? This is where it gets interesting. Remember all those people that were building systems, allocating storage volumes, updating drivers and configuring networks? Suddenly they have a lot more time on their hands. Now it is time to begin the true IT transformation journey that the CIO wanted to so eagerly implement.
Most organizations at this point carry out a number of changes:
– Restructure and realign the traditional server, storage, network, backup and virtualization teams into one team of “cloud architects”. This team should be trained on how to build service catalogues, how to implement and manage consumption models, ensuring standardization and optimization of operations and how to automate any manual process in the data centre.
– Shift developers to agile development methodologies, train them on cloud native applications (here’s some great reading: http://bit.ly/1Fwy4c7 and http://12factor.net/) and have them understand the emerging world of containers and commoditized web scale and open source systems. Ironically 5 years ago developers did not need to care so much about the infrastructure as usually the infrastructure team would build custom solutions to suit the service level needed by an application. Today the developer needs to understand that in a cloud native, standardized world, they as developers are now responsible for application availability.
– Ensure all new off the shelf applications are deployed only if they meet the same set of principles and requirements of the cloud native world. Legacy applications that require heavy infrastructure architecture and development should be reduced in order to build towards the new leaner set of infrastructure services and agile application methodologies.
– Finally think about IT’s role in having the business consume services. As an IT organization, external cloud services (particularly SaaS models) may be your ally or your competitor. The difference is those external cloud service provides probably have sales teams. If they do, and they are your competition, then why shouldn’t you think about having your own internal sales team? Many of our customers have taken the traditional role of the business analyst and transformed this to a business development manager who earns commission for internal sales and is responsible to increasing the consumption of IT services. One customer told me they were even hiring Presales Engineers from vendors who knew how to do solution selling to drive consumption back to the business. Many customers say to me that they have great IT services, but struggle to get the business to adopt them. This is a way to solve that problem. Our IT team spends a lot of time with internal business units showing the internal IT roadmap and using a consultative approach to help apply technology solutions to different business needs. Ultimately the idea is to not assume that your business will consume your services just because those services are there, but to educate, sell and help the business through a new approach.
Throughout this process, one service to be mindful of is the external cloud and shadow IT. These services can bring awesome agility that many IT teams find hard to replicate. One customer showed me an example of where they had built an amazing analytic and big data project, leveraging machine learning for customer insight. They rolled out the entire project in just 12 weeks in the public cloud. Internally they estimated the same project would have taken 2 years to develop. Public cloud meant this innovation was brought to market much more quickly.
However in another customer example the business had moved a mission critical application into the public cloud without consulting IT. After a number of months the operations for this application was moved over to internal IT to run, at which point the team discovered that there was no backup or disaster recovery plan for this application. The business had assumed this was something natively provided by cloud models. The organization had been exposed to a huge level of risk, which is something that IT could have helped avoid if they were brought into the conversation earlier.
The reason for these two examples is they help to explain why IT organizations should allow and embrace external cloud services as part of their model for IT architecture. By helping the business consume the right cloud service, whether that is on premise private cloud or externally in the public cloud, the CIO and their team can become an enabler for business agility, while managing risk and delivering an efficient set of services.
Bringing it all together
I may not have every answer, but in my role of CTO in Australia I have seen the many different ways organizations are going about trying to achieve the same transformational outcome. What I do know is that trying to transform people and processes first while running a legacy IT infrastructure is like trying to fly a 1980s Boeing 747 without an engineer. The transformation just does not work.
If transformations in Australian IT are to become successful, then the process needs to start with modernizing the core data centre technologies. Once this is done, IT automation can be introduced and the process of removing manual tasks can begin. Finally this gives the IT organization the ability to conduct the much needed people and process transformation that delivers the outcome many businesses so desperately need.
I would love to hear your thoughts on this. Do you agree or disagree? Are there companies that have transformed IT while still using legacy infrastructure and siloed platforms? Tweet me @mattzwol