Enterprises are wrestling with the conflicting needs to chase competitiveness in a world of endlessly changing technology, whilst still remaining mindful and careful. In IT we are caught in the same bind. I have written about this squeeze before in "To Protect and Serve".
This year I'm looking at solutions: how IT can deal with the dichotomy with Multi-Speed IT. By embracing Agile, DevOps, BYOD and other "liberation" approaches, and integrating them into our ITSM, risk, and governance practices, we can create an IT environment with a better chance of responding at the speed of business, whatever the business chooses that speed to be. This article proposes a nuanced approach to two-speed IT, where each lifecycle implementation is a blend of the two "speeds".
|This is a long post. Please take the time to read it.
Every year I seem to get one "Big Idea" that I feel is really important and at least slightly new or a fresh perspective.
This is 2015's.
This led me in 2013 to call for "Slow IT":
Slow IT is a provocative name. It doesn't mean IT on a go-slow. It means slowing down the pace of business demands on IT so as to focus better on what matters, and to reduce the risk to what already exists. The intent of Slow IT is to allow IT to deliver important results more quickly. It does this by concentrating on the interfaces between business executives and CIOs. Slow IT highlights the importance of Governance of IT and of Service Portfolio in order to make the right decisions to do the right things in the right way at the right time, to maximise benefit and minimise risk. Slow IT challenges the hysterias and fads of IT to ensure that these results are really needed as quickly as we think they are. Slow IT is about trying to introduce more measured responses, to bring some sanity to the current dangerous madness that is organisational IT.
That went down like a lead balloon, even though i offered the Meet-in-the-Middle quid pro quo of "Fast IT" in return:
Here then is a strategy for IT to address the issue, to make a value proposition for the parent organisation about how Slow IT will deliver benefit, will allow IT to be more response, will enable Fast IT.
Fast IT is all those things you have heard about, from CSI to Agile, Lean, and DevOps. You will struggle to get them in place in a legacy environment without some Slow IT.
We need to meet in the middle:
If we can just improve the governance of IT so that a reasonable conversation can be had about the priorities and impacts of new services, and we can slow down the currently unrealistic deluge of demands on IT;
...then we can buy enough breathing space, enough headroom, to make improvements in IT, to adopt new approaches, "Fast IT", which allow us to deliver faster, such as:
- good old ITSM standard change
- lean IT
...and so on. They are all great ideas for making IT more nimble and responsive, but they ALL require time and energy and resources to implement.
Well, I thought it was a compelling argument. I still do.
Somehow, with or without "Slow IT" running interference for you, you need to claw yourself into some of these new approaches such as Agile and DevOps in order to meet the needs of the business.
Don't argue - as I used to - that the core legacy systems and processes will never withstand such volatile approaches. They don't need to. Here's the answer:
Adopt two approaches to change in your organisation:
- Conservative: traditional, probably waterfall, change management and operations
- Nimble: some variant of DevOps
The business, specifically the governors of IT, are to determine which organisational changes are to use which approach for their IT changes, driven by the appetite for risk in that change.
Possibly the choice will be made at an even lower granularity: some IT changes go through a traditional cycle and others get agile treatment.
- the marketing department get the OK to engage an Agile development company to build their new website for a sales campaign,
- but the project to achieve PCI compliance will use a tightly controlled release and deployment of changes to the financial systems
- and the sales department must use a conservative lifecycle approach to moving to SalesForce, with exemptions for updates to the affected intranet pages which will use the existing funky methodology of the intranet team
As another example, an internet banking system uses DevOps to maintain content and functionality of the user interfaces, but you can bet a conservative lifecycle is used for changes to the underlying web services that actually move money.
As many of you will realise, this is not my idea.
Gartner speaks of a "bi-modal" approach (original research here), and I think they may have been the first to crystalise the concept completely.
Some systems are legacy ones to be handled with legacy methods, with an emphasis on risk and control. Other systems are new and innovative, and can be managed with new techniques and a higher risk profile.
Gartner also talk about a tri-modal "pace layered" model of IT, with
- Systems of Innovation: bleeding edge stuff
Systems of Differentiation: stuff that gives your business an edge
Systems of Record: boring stuff
Has anyone seen Gartner's bi-modal and pace-layered models married up?
the map of a business contains many components organised into a chain of needs (the value chain) with the components at differing states of evolution. As components evolve, their properties change (from uncharted to industrialised) and different methods of management become appropriate. Hence components in the uncharted space use in-house, agile techniques, quick release cycles, highly iterative etc. Whereas those more industrialised components tend to be six sigma, ITIL, long release cycles, heavily standardised etc.
When it comes to organising then each component not only needs different aptitudes (e.g. engineering + design) but also different attitudes (i.e. engineering in genesis is not the same as engineering in industrialised). To solve this, you end up implementing a trimodal structure known as pioneers, settlers and town planners...
The problem with bimodal (e.g. pioneers and town planners) is it lacks the middle component (the settlers) which performs an essential function in ensuring that work is taken from the pioneers and turned into mature products before the town planners can turn this into industrialised commodities or utility services. Without this middle component then yes you cover the two extremes (e.g. agile vs six sigma) but new things built never progress or evolve. You have nothing managing the 'flow' from one extreme to another.
[an] organization is delivering new mobile solutions through lightweight apps that are rolled out on a continual basis. The accelerated app delivery program is on a different cadence from their traditional solutions. The solutions have longer development cycles and higher reputational risk in the case of failure, and in some instances compliance requirements must be satisfied.
Different change cadences require different approaches. This financial organization’s approach is quite simple. They have what is described internally as systems of innovation – change that leverages a DevOps approach, where their systems of record, such as their SAP implementation, follow a more traditional waterfall approach.
API-based XaaS adoption will continue at a torrid pace, and yet ITIL-based managed services buying will continue as well, albeit at a slower pace. The two will co-exist for many years to come. The key is having a framework to determine which delivery model is appropriate for which business process or application.
Large enterprises may never be able to do one hundred deploys a day like Amazon, but they probably don’t need to anyway. There is no reason why they can’t tune their ITIL processes to get to the point of delivering daily. They also may decide that certain applications fit a high-risk profile and are not allowed to be released every day. After all, not all applications are web apps. Use a hammer when you have nails; use a screwdriver when you have screws. Tighten controls when the applications are high risk; loosen the controls when they are not.
Cohen also challenged the view that enterprise technology is broken. “There are certain analysts and media companies that say it is broken because it sells good copy. There is not a two speed IT, as some analysts suggest. I have multi-speed IT and I’m sure that is the same for all of us. Different markets operate at different speeds."
Many will say that you cannot perpetuate ‘unique snowflakes’, so you must standardize environments. This dogma is easy to preach – and in principle is a best practice – but in reality it is too simplistic for most enterprises. Disparate environments often exist for good reasons (e.g. to accommodate cost, skillset, throughput, integration, or other technical requirements). In any case, you cannot simply run roughshod over established architectures. So standardize if and when you can, but realize that this path is unlikely to solve the problem.
Gartner urges CIOs to craft a more nuanced IT strategy that is both highly standardized and highly flexible
The next-generation of business technology solutions have a short time-to-market, are created and delivered in an agile way, and are developed and owned in the closest proximity to the business. These solutions are like ‘scooters and cars’, whereas the current application landscape typically contains ‘trains and buses’. Think about when to apply the right rhythm; build the platforms to support multi-speed IT
If an organization can embrace the shift to allowing systems manage systems, then they can capitalize on this foundation of stability that ITSM practices has established. Enabling the values fostered by DevOps to create a fluid release stream that is scalable will thus position the business value streams to test new market opportunities faster and with less risk.
Operational Excellence + Speed of Innovation = Business Agility
Good useful advice from Mirco Hering
The smaller gear moves much faster than the larger one, but where the two gears interlock they gearsremain aligned to not stop the motion. But what does this mean in reality? Think about a banking app on your mobile. Your bank might update the app on a weekly basis with new functionality like reporting and/or improved user interface. That is a reasonable fast release cycle. The mainframe system that sits in the background and provides the mobile app with your account balance and transaction details does not have to change at the same speed. In fact it might only have to provide a new service for the mobile app once every quarter. Nonetheless the changes between those two systems need to align when new functionality is rolled out. However, it doesn’t mean both systems need to release at the same speed. In general, the customer facing systems are the fast applications (Systems of Engagement, Digital) and the slower ones are the Systems of Record or backend systems. The release cycles should take this into consideration.
or this skeptical view from Jason Bloomberg
Fundamentally, Bimodal IT recommends maintaining your organizational silos, which is contrary to the entire notion of business transformation. True, I advise executives to know when to optimize, and know when to disrupt – but not in separate silos! There are roles both for optimization as well as disruption-driven innovation in both agile/innovative IT as well as slow/traditional IT, even though the specific optimization and innovation activities will largely be different across the larger organization.
I always welcome a brother skeptic but I wasn't wild about this post. For an article that criticises the Gartner straw man, it is riddled with them. It actually ends up at the same conclusion as Gartner and this post, only with more huffing (that's a bit rich coming from me I know). I may do a post critiquing it one day. Anyone want to see that?
And of course some silly ones, like this one from ComputerWorld
Businesses that sell goods and services to consumers need at least two CIOs and multi-speed IT departments if they are to keep up with the competition.
Long-established businesses based on traditional bricks and mortar customer service will need more than one IT leader when they move to multi-channel models.
Introducing DevOps to the organisation
A Nimble, "Mode Two", high speed approach probably means DevOps (my definition here).
Most of the DevOps poster-children are greenfield: Netflix, Etsy, Amazon, Google... But we are now hearing names of older enterprises: Barclays, GE, Disney, Macy's, Nordstrom, Telstra...
Now this is interesting: what are they doing with DevOps?
I suspect much of the adoption of DevOps in enterprise is in [Gartner-speak:] Systems of Innovation / Mode 2, which nearly always equates to web/mobile and nearly always equates to standalone greenfield systems. Lets beware the over-enthusiasts who think DevOps can and should be rolled out through Systems of Record. This is a harder ask, reverse engineering DevOps ideas and tools into legacy environments. Is it proven? Have we arrived at generally accepted DevOps Enterprise practices? These are systems with a low appetite for risk. We want to see the evidence before we do anything radical with them.
And so we come to the point of this post. Its not about a two-speed, black and white, DevOps-or-ITIL model. We need to have two approaches, Conservative and Nimble, as models that we use in or organisation. But I think any one project or development team can have some nuanced mix of the two depending on the business's needs. We may end up with three or more lifecycle structures in the organisation, as needed.
DevOps is not an all-or-nothing thing. Just like ITIL, we shouldn't "do" all of it. We adopt and adapt ideas as they deliver value. There are ideas in DevOps which we could potentially apply in all areas of IT, not just Systems of Innovation.
So we need to monitor what the DevOps Enterprise pioneers are doing, to see where they are applying DevOps, which parts of DevOps work where, and what practices are becoming generally accepted. That's why I went to San Francisco, to the DevOps Enterprise conference last year (my reflections on it here). I wish I could afford to go again; I recommend you do if you can.
Different teams will have different needs, different system structures, different culture especially acceptance of DevOps, different customers with different risk appetites. Any attempt to impose an A-or-B choice of lifecycle methodology on them is not much more helpful than trying to shoe-horn them all into one approach.
It is time we accepted flexibility in lifecycle design for IT changes. Instead of dictating how changes and releases must happen, we should set policy for the bounds in which they happen and the business rules that must be obeyed, and leave them to it.
No wait! Come back. Let me expand on that.
Types of change
Not every team and not every type of change gets carte blanche. Most (all?) changes that we choose to be controlled by a Conservative lifecycle will follow a standardised process across the organisation: do it this way. Only some types of changes will be given the flexibility that the team owning hem can design a lifecycle to suit.
Let me be clear here; when i talk about change A being lifecycle X and change B being lifecycle Y, I'm talking about types of changes, categories of change. I'm not suggesting that for each individual instance of change, someone gets to choose the process to follow (though that would be interesting, wouldn't it?). For example:
- All changes to the SAP General ledger use change lifecycle A1 a centralised controlled waterfall workflow. Risk assessment is done by centrally by Change Management.
Changes to the public main internet website content done via the Content Management System can be done using lifecycle M3, which requires a couple of signoffs and thats it.
Unless they are changes rated as business impact 1, in which case they must use lifecycle M2, which requires the change to be scheduled centrally by Change Management and notified to a range of stakeholders from the sales teams to support, so that everybody knows it is coming. But otherwise there are few controls.
Changes to the HTML or code of the public main internet website must be done using lifecycle M1, which is an automated DevOps process with two business signoffs and a peer review. Developers do their own risk assessment. No central change scheduling required unless the risk is assessed as High.
Eventually Operations ends up with everything
There is One Lifecycle That Rules Them All.
- A system starts life as new, unusual, experimental. the team have special circumstances that justify doing change in some new way. The business has a high appetite for risk, because they want agility as they explore a new space, probing it to learn what works and responding quickly when they do. Trusted and senior staff develop the lifecycle they require, with a free hand so long as they stay within the policy. The lifecycle is a highly nimble one with rapid unconstrained changes. The team operate and support the system.
After an initial period, the system stabilises and settles down to known kinds of changes. These get standardised so they can be automated, and a regular cadence of change is adopted after the users get change fatigue from the wild early days. The team find support too distracting from development, and Level 1 is transferred to the central Service Desk. The team becomes a Level 2 and 3 resolver group, as well as iterative developers.
The team goes through a cost-cutting event and a number of staff are moved out. They no longer have the resources to operate the infrastructure and databases themselves, even though the servers are in the cloud. They persuade central IT Operations to take them on. the servers are moved off Amazon into the private corporate cloud and the central database team start doing maintenance.
After a year or two, the system is stable, it has become part of business as usual, is changing much less. The business loses interest in funding it, the development team is disbanded except for one developer, and it needs to be operated and supported. The code then goes through all the stages of a traditional waterfall release to production and is handed over the the core Applications Maintenance team as just another system to support. They change it when needed using their conventional conservative change cycle.
That's four different change lifecycles through the lifetime of the system.
Ultimately all systems trickle down to central IT to own as "legacy".
One or two who follow what I write may have spotted where I am going with this.
I came up with a concept several years ago called "Standard+Case". It says:
Here is an exciting new approach to categorising and resolving any sort of response "tickets", such as requests or incidents on a service desk, problems, or changes.
The world refuses to be standardised: there is other incoming stuff that we haven't seen before, that we don't already have a defined response for, that has to be handled as a case.
You can only industrialise that which you can standardise, i.e. make known: described, predictable, and repeatable. Only some of the world can be standardised.
Whether you are talking development, transition, or response to situations, some of the world will always be unfamiliar due to change, or unpredictable due to complexity.
Standard+Case is a synthesis of our conventional "Standard" process-centric approach to responding, with Case management, a discipline well-known in industry sectors such as health, social work, law and policing.
Standard+Case is intended for response management: responding to situations. In this discussion here, we are looking at responding to the requirements of a development or project team for a change lifecycle. But the Standard+Case model still applies. Some teams will work within a standard lifecycle and other teams will be empowered to create their own (in collaboration with necessary experts and within the bounds of change and risk policies).
Be clear: this is not saying Conservative=Standard and Nimble=Case. They cut across each other. We need to take a Standard+Case approach to deciding how we will allow a team to determine their change lifecycle, which will be a mix of Conservative and Nimble attributes. If we recognise their requirement, we can send them to a known, predefined, standardised lifecycle. If we don't recognise their requirement, if we don't already have a standardised response for them, then we will treat it as a new case, and assign an experienced person to work out a custom lifecycle for them (or to learn enough about their requirements to find a standard fit after all).
Multi-Speed IT Capability
There you have my summary of the multi-speed ideas I've seen in the industry. I hope I have brought a fresh perspective to them by (a) bringing in the concept of Standard+Case and (b) by suggesting its not a two-speed or three-speed model we need but rather an infinitely-variable Multi-Speed IT Capability model: a more nuanced approach where we create a calibrated lifecycle model for a team introducing a mix of these elements to meet their business need (at the business's chosen level of risk).
This post is part of my Kamu project to reconcile DevOps and ITSM.