Find the thread

This post is the follow-up to the earlier post Caveat Vendor.

It’s not easy being an enterprise IT buyer these days. Time was, the IBM sales rep would show up once a year, you would cover your eyes and sign the cheque, and that would be it for another year. Then things got complicated.

Nowadays there are dozens of vendors at each level of your stack, and more every day. Any hope of controlling the Cambrian explosion of technologies in the enterprise went out of the window with the advent of cloud computing. Large companies used to maintain an Office of Vendor Relations, or words to that effect. Their job was to try to keep the number of vendors the company dealt with to a minimum. The rationale was simple: if we have an existing enterprise licensing agreement with BigCo, introducing PluckyStartupCo just adds risk, not to mention complicating our contract negotiations. It doesn’t matter if PluckyStartupCo has better tech than BigCo, we get good enough tech from BigCo as part of our Enterprise Licensing Agreement (all hail the ELA!). On top of that we are pretty sure BigCo is going to be around for the long haul, while PluckyStartupCo is untested and will either go bust or get bought by someone else, either BigCo or one of their competitors. Job done, knock off at five on the dot.

The dependency of business on technology is too close for that approach to work any longer. The performance of IT is the performance of the business, to all intents and purposes. If you don’t believe me, try visiting an office when the power is down or the net connection has gone out. Not much business gets done without IT.

If companies effectively hobble themselves with antiquated approaches to procurement, they leave themselves wide open to being outmanoeuvred by their competitors. When the first non-tech companies built websites, plenty of their competitors thought it was a fad, but those early adopters stole a march on their slow-moving erstwhile peers.

All of this does not even count shadow IT. Famously, Gartner predicted that "By 2015, 35 percent of enterprise IT expenditures for most organizations will be managed outside the IT department's budget." People are bringing their own services, not just the techie example of devs¹ spinning up servers in AWS, but business users - Muggles - using Dropbox, Basecamp, Google Hangouts and Docs, Slideshare, Prezi, and so on and on.

What is a CIO or CTO to do?

First of all, don’t try to stop the train - you’ll just get run down. The only thing you can do is to jump on board and help drive it. Note that I said help: IT can no longer lead from high up an ivory tower. IT leaders need to engage with their business counterparts, or those business users will vote with their feet and go elsewhere for their IT services.

IT leaders can help the business by building a policy framework to encompass all of these various technologies. Most importantly, this framework has to be flexible and assume that new technologies will appear and gain adoption. Users won’t listen if you say "we’ll review doing a pilot of that cool new tech in six months, and if that goes well we can maybe roll it out a year from now". By the time you’ve finished speaking, they’ve already signed up online and invited all their team-mates.

Fortunately, there is a technique that can be used to build these frameworks. It’s called pace layering, and was introduced by Gartner in 2012.

Pace Layering

Pace layering divides IT into three layers:

• Systems of Record — Established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low, because the processes are well-established and common to most organizations, and often are subject to regulatory requirements.

• Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium life cycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements.

• Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies.

The idea is that there are parts of the business where the emphasis is on absolute stability, reliability and predictability - the Systems of Record, which are basically the boring stuff that has to work but isn’t particularly interesting. Other areas need to move fast and respond with agility to changing conditions - the Systems of Innovation, the cool high-tech leading-edge stuff. In between there are the Systems of Differentiation, which are about what the company actually does. They need to move fast enough to be relevant, but still be reliable enough to use - often a tough balancing act. The layering looks like this:

If we overlay two common IT methodologies, we start to understand many of the ongoing arguments of the last few years, where it seems that practitioners are talking past each other:

DevOps, Agile, and so on are approaches that work well for Systems of Innovation. Here it is appropriate to "move fast and break stuff", to fail fast, to A/B test things on the live environment. Run with what works; the goal is speed and quickly figuring out the Next Big Thing.

ITIL is the opposite: it’s designed for a cautious approach to mature and predictable systems, with the ultimate goal of maintaining stability. Here, the absolute goal is not breaking stuff; the whole moving fast part is completely subordinate to that goal.

I hear a lot of complaints along the lines of "ITIL is a bottleneck on IT", "ITIL is the anti-Agile", and so on. In the same vein, ITIL sages throw up their hands in horror at some of what the new crowd are getting up to. The thing is, they’re both right.

Use ITIL where it’s appropriate, and be agile where that is appropriate. Try to figure out the demarcation points, the hand-offs, and where you can, by all means take the best of both worlds. You don’t want to have to wait for the weekly Change Advisory Board meeting to make a minor website change, but when something goes wrong, you’ll be thankful for having some sort of an audit trail in place.

From operations to planning

So much for operations - but the same applies to planning. The Systems of Record might have a roadmap planned out years in advance, with little reason to deviate from it. The motto here is "if it ain’t broke, DON’T TOUCH IT!". This is the part of the company where mainframes still lurk. Why? Because they work. It’s as simple as that.

On the other hand, the Systems of Innovation are where you want to let a thousand clouds bloom (to coin a phrase). Let people try all those wonderful services I mentioned earlier. The ones that are useful and safe will gradually get adopted further back from the bleeding edge. If something doesn’t make the cut, no matter - you didn’t bet the company on it.

To return to one of my pet arguments, the Systems of Record are virtualised, the Systems of Differentiation are on a private cloud, and the Systems of Innovation are in the public cloud. This way, the strengths of each model fit nicely with each layer’s requirements.

The problems arise if get your layers mixed up - but that’s outside the scope of this post.

The world of IT is changing fast, and the rate of change is itself increasing. This insight is almost a tautology by now, I admit, but what I want to explore here is what this means for enterprise software customers and vendors.

A recent newsletter from Ben Kepes, of Diversity fame, includes this aside in the introduction (emphasis mine):

One theme that I kept coming back to was the risk that IT vendors run in continuing to communicate under the false expectation that enterprises are all at the same level of adoption. It's easy to sit in a conference room and think that everyone "gets it", but the reality is that organizations are complex beasts and sometimes it's hard for IT practitioners to look beyond simply "keeping the lights on". IT vendors have a responsibility to articulate their solutions in a way that helps them plot a progressive journey from where they are today to a better future.

This is basically a reformulation of Clayton Christensen’s Innovator’s Dilemma. If you innovate beyond your customers’ needs, your position is at risk of being undermined by less sophisticated offerings that match your customers’ current needs. The insidious part is that for a while this feels good. Those are the customers which are a stretch for your product, and the ones where the return on investment is weakest. Dropping those raises the average among your remaining customers - for a while.

The really insidious part is what Ben Kepes points out: not all customers are at the same point along that journey. Vendors have to strike a balance between the Scylla of out-innovating their less sophisticated customers and the Charybdis of not keeping up with their more sophisticated customers’ requirements. This dilemma has been articulated already by Massimo Re Ferré, so I will just point to his blog for the full treatment.

For vendors, the trick is finding that sweet spot in the market. You don’t want to chase every will o’ the wisp promising technology - nobody has the development dollars to do that. You also can’t afford to get left behind by your customers’ adoption rate. You have to surf that wave constantly, and never fall off.

Sticking with the surfing metaphor for a moment, surfers like smooth, predictable waves. The worst thing for surfers is chop - but chop is exactly what we have in the enterprise software market. The pace of technology churn is accelerating.

It used to take years, sometimes even decades, for new technologies to be widely adopted in the enterprise. Sure, there might be testbeds experimenting with crazy notions such as relational databases or object-oriented programming, but they remained isolated.

This gave vendors the time to adapt their own offerings, whether that meant using the New Hotness themselves, integrating with it, or managing it - or buying a smaller player who had worked it out faster. Once they had built an offering, they could also count on getting revenue from it for a good few years, as their customers kept on using the now mature and widely adopted tech.

So what changed? The pace of adoption of new technologies in the enterprise has accelerated enormously, and indeed is still accelerating. The plateau of productivity has also shortened, since there is a new technology wave coming right behind the current one, and another one even closer behind that.

Meanwhile, vendors have not been able to accelerate the pace of development, distribution and adoption of their offerings to match this heightened tempo. In other words, the rate of churn within the enterprise is now, or will soon be, inside vendors' OODA loops.

What does this mean? Is it the end of the commercial software vendors, as some argue?

I don't think so, but it is the end of what has been business as usual, and some vendors will not survive the transition. To survive and prosper, vendors need to let go of their old engagement models.

Agile is not just a development buzzword, it needs to be adopted as part of the DNA of vendors. Multi-year product roadmaps are as out of date as the Soviet Union’s infamous Five-Year Plans. By the time the roadmap reaches its first milestone, it’s already obsolete. If vendors - or customer architects¹ - try to stick to their roadmaps, they will find themselves wildly out of step with their customers after a few rounds, which is hardly a recipe for long-term success.

So, both customers and vendors need to build flexibility into their plans. No more huge monolithic projects that will show return on investment only after twelve, eighteen or even twenty-four months. Instead, modular projects with loosely-coupled milestones, with each milestone able to stand alone in terms of its own RoI. In this model, milestones can be rearranged, cancelled or replaced with others as the project develops and its goals and usage evolve.

This new model also requires a different type of sales process.

Traditionally, vendors start engaging with customers only once a sales process begins, with activity really ramping in the delivery phase. Once implementation is complete, the vendor generally disengages, handing the implemented solution over to the customer's IT team to manage in production. As I posted yesterday, customers don’t see a huge amount of value in this approach, especially nowadays.

The New Normal requires a much more constant engagement between vendors and users. This contact begins long before an official sales or procurement cycle, as part of what is known as the Zero Moment Of Truth or ZMOT. The ZMOT requires a constant exchange between vendor and user. This conversation will cover topics such as:

• New technology developments

• Changing user requirements

• Level of satisfaction with existing technologies

• Constraints on adoption of new technologies

• Expected benefits from new technologies

This conversation has obvious benefits for the vendor in enabling them to prepare their solution for the user, reducing the lag time between when users want to adopt a new technology and the vendor being able to support it. The benefit is also for the user, because the resulting solution will be much more closely matched to their actual requirements, rather than to the vendor's theory of what those requirements might be at some point in the future.

The gap between the user's requirements and the vendor's projections is often large, and the reason is that lag time. Vendors must not simply divine what users want today, but what they will want a year from now, when their solution will actually be ready - a much more difficult task.

Vendors talk about building a "trusted advisor" relationship with customers. Sometimes this is no more than a code for "persuading customers to buy whatever we are selling, sight unseen", but when it is done right, this relationship is a two-way one. The vendor-adviser needs to understand the customer's needs in depth to provide good advice.

Good advisers do not hand out their advice and then disappear, they stick around for the long haul and are available to give advice at any juncture. The rapid churn of technologies means that advice is needed regularly, not just every twelve months or so, when it’s time to set the budget for next year or renew the maintenance contract.

Next up: what can customers do in this brave new world? Follow Mum’s advice: Tech in Layers.

Serendipity: Seth Godin’s post for today has an example of a company failing to engage in this way. His example is more consumer-oriented - an inkjet printer - but the general point about continuous engagement holds. Vendors that sell something, then disappear until it’s time for them to sell something again, are actively pushing customers away. What do you call a vendor who doesn’t vend?