Tag Archives: The rules of IT

Some new rules for IT

The other week I had a go at capturing the rules of enterprise IT{{1}}. The starting point was a few of those beery discussions we all have after work, where we came to wonder how the game of enterprise IT was changing. It’s the common refrain of big-to-small, the Sieble to Saleforce.com transition which sees the need for IT services (internal or external) change dramatically. The rules of IT are definitely changing. Now that I’ve had a go at old rules, I thought I’d have a go at seeing what the new rules might be.

As I mentioned before, enterprise IT has historically been seen as an asset management function, a production line for delivering large IT assets into the IT estate and then maintaining them. The rules are the therefore rules of business operations. My attempt at capturing 4 ± 2 rules (with friends) produced the following (in no particular order):

[[1]]The rules of Enterprise IT @ PEG[[1]]

  • Keep the lights on. Much like being a trucker, the trick is to keep the truck rolling (and avoid spending money on tyres). Otherwise known as smooth running applications are the ticket to the strategy table.
  • Save money. Business IT was born as a cost saving exercise (out with the rooms full of people, in with the punch card machines), and most IT business cases are little different.
  • Build what you need. I wouldn’t be surprised if the team building LEO{{2}} blew their own valve tubes. You couldn’t buy parts of the shelf so you had to make everything. This is still with us in some organisations’ strong desire to build – or at least heavily customise – solutions.
  • Keep the outside outside. We trust whatever’s inside our four walls, while deploying security measures to keep the evil outside. This creates an us (employees) and them (customers, partners, and everyone else) mentality.

[[2]]LEO: Lyons Electronic Office. The first business computer. @ Wikipedia[[2]]

Things have changed since these rules were first laid down. From another post of mine on a similar topic{{3}} (somewhat trimmed and edited):

[[3]]The IT department we have today is not the IT department we’ll need tomorrow @ PEG[[3]]

The recent global financial criss has fundamentally changed the business landscape, with many are even talking about the emergence of a new normal{{4}}. We’ve also seen the emergence of outsource, offshore, cloud computing, SaaS, Enterprise 2.0 and so much more.

Companies are becoming more focused, while leaning more heavily on partners and services companies (BPO, out-sourcers, consultants, and so on) to cover those areas of the business they don’t want to focus on. We can see this from the global companies who have effectively moved to a franchise model, though to the small end of town where startups are using on-line services such as Amazon S3, rather than building their own internal capabilities.

We’re also seeing more rapid business change: what used to take years now takes months, or even weeks. The constant value-chain optimisation we’ve been working on since the 70s has finally cumulated in product and regulatory life-cycles that change faster than we can keep up.

Money is also becoming (or has become) more expensive, causing companies and deals to operate with less leverage. This means that there is less capital available for major projects, pushing companies to favour renting over buying, as well as creating a preference for smaller, incremental change over the major business transformation of the past.

And finally, companies are starting to take a truly global outlook and operate as one cohesive business across the globe, rather than as a family of cloned business who operate more-or-less independently in each region.

[[4]]The new normal @ McKinsey Quarterly[[4]]

So what are the new 4 ± 2 rules? They’re not the old rules of asset management. We could argue that they’re the rules of modern manoeuvre warfare{{5}} (which would allow me to sneak in one of my regular John Boyd references{{6}}), but that would be have the tail wagging the dog as it’s business, and not IT that has that responsibility.

[[5]]Maneuver warfare @ Wikipedia[[5]]
[[6]]John Boyd @ Wikipedia[[6]]

I think that the new rules cast IT as something like that of a pit crew. IT doesn’t make the parts (though we might lash together something when in a pinch), nor do we steer the car. Our job is to swap the tyres, pump the fuel, and straighten the fender, all in that sliver of time available to us, so that the driver can focus on their race strategy and get back out on track as quickly as possible.

With that in mind, the following seems to be a fair (4 ± 2) minimum set to start with.

  • Timeliness. A late solution is often worse than no solution at all, as you’ve spent the money without realising any benefit. Or, as a wise sage once told me, management is the art of making a timely decision, and then making it work. Where before we could take the time to get it right (after all, the solution will be in the field for a long time and needs to support a lot of people, so better to discover problems early rather than later), now we just need to make sure the solution is good enough in the time available, and has the potential to grow to meet future demand. The large “productionisation” efforts of the past need to be broken into a series of incremental improvements (à la Gmail and the land of perpeputal beta), aligning investment with both opportunity and realised value.
  • Availability. Not just up time, but ensuring that all stakeholders (both in and outside the company, including partners and clients) can get access to the solutions and data they need. There’s little value in a sophisticated knowledge base solution if the sales team can’t use it in the field to answer customer questions in real time. Once they’ve had to fire up the laptop, and the 3G card, and the VPN, the moment has passed and the sale lost. Or worse, forcing them to head back to the bricks and mortar office. As I pointed out the other week, decisions are more important than data{{7}}, and success in this environment means empowering stakeholders to make the best possible decisions by ensuring that the have the data and functions they need, where they need, when they need it, and in a format that make it easy to consume.
  • Agility. Agility means creating an IT estate that meet the challenges we can see coming down the road. It doesn’t mean creating an infinitely flexible IT estate. Every bit of flexibility we create, every flex point we add, comes at a cost. Too much flexibility is a bad thing{{8}}, as it weighs us down. Think of formula one cars: they’re fast and they’re agile (which is why driving them tends to be a young mans game), and they’re very stiff. Agility comes from keeping the weight down and being prepared to act quickly. This means keeping things simple, ensuring that we have minimum set of moving parts required. The F1 crowd might have an eye for detail, such as putting nitrogen{{9}} in the tyres, but unnecessary moving parts that might reduce reliability or performance are eliminated. Agility is the cross product of weight, speed, reliability and flexibility, and we need to work to get them all into balance.
  • Sustainability. Business is not a sprint (ideally), and this means that cost and reliability remain important factors, but not the only factors. While timeliness, availability and agility might be what drive us forward, we need still need to ensure that IT is still a smooth running operation. The old rules saw cost and reliability as absolutes, and we strived to keep costs as low, and reliability as high, as possible. The new rules see us balancing sustainability with need, accepting (slightly) higher costs or lower reliability to provide a more timely, available or agile solution while still meeting business requirements. (I wonder if I should have called this one “balance”.)

[[7]]Decisions are more important than data @ PEG[[7]]
[[8]]Having too much SOA is a bad thing (and what we might do about it) @ PEG[[8]]
[[9]]Understanding the sport: Tyres @ formula1.com[[9]]

While by no mean complete or definitive, I think that’s a fair set of rules to start the discussion.

The rules of enterprise IT

As I’ve pointed out before (possibly as I’m quite fond of games{{1}}) the game of enterprise IT has a long an proud history. I’ve also pointed out that the rules of this game need to change if enterprise IT — as we know it — is to remain relevant in the future{{2}}. This is triggered a few interesting conversations at the pub on just what are the old rules of IT.

[[1]]Capitalise: A game for the whole company to play![[1]]
[[2]]People don’t like change. (Or do they?)[[2]]

Enterprise IT, as we know it today, is an asset management business, the bastard son of Henry Ford’s moving production line. Enterprise IT takes the raw material of business processes and technology and turns them into automated solutions. From those first card tabulators through to today’s enterprise applications, the focus has been on delivering large IT solutions into the business.

The rules of enterprise IT are the therefore rules of business operations. After a fair amount of coffee and beer with friends, the following 4 ± 2 rules seems to be a fair minimum set (in no particular order).

Keep the lights on. Or, put more gently, the ticket to the strategy table is a smooth running business. Business has become totally reliant on IT, while at the same time IT is still seen as something of a black art run by a collection of unapproachable high priests. The board might complain about the cost and pain of an ERP upgrade, but they know they have to find the money if they want to successfully close the books at the end of the financial year. While this means that the money will usually be found, it also means that the number one rule of being a CIO is to keep the transactions flowing. Orders must be taken, products shipped (or services provided), invoices sent and cash collected. IT is an operational essential, and any CIO who can’t be trusted to keep the lights on won’t even have time to warm up their seat.

Save money. IT started as a cost saving exercise: automatic tabulation machines to replace rooms full of people shuffling papers, networks to eliminate the need to truck paper from one place to another. From those first few systems through to today’s modern enterprise solutions, applications have been seen as a tool to save time and money. Understand what the business processes or problem is, and then support the heavy information lifting with technology to drive cost savings and reduce cycle time. Business cases are driven by ideas like ROI, capturing these savings over time. Keep pushing the bottom line down. These incremental savings can add up to significant changes, such as Dell’s make-to-order solution{{3}} which enabled the company to operate with negative working capital (ie. they took your cash before they needed to pay their suppliers), but the overall approach is still based on using IT to drive cost savings through the automation of predefined business processes.

[[3]]Dell’s make to order solution leaves competitors in the dust.[[3]]

Build what you need. When applications are rare, then building them is an engineering challenge. You can’t just go to the store and by the parts you need, you need to create a lot of the parts yourself in your own machine shop. I remember the large teams (compared to today) from the start of my career. A CORBA project didn’t just need a team to implement the business logic, it needed a large infrastructure team (security guy, transaction guy …) as well. Many organisations (and their strong desire to build – or at least heavily customise – solutions) still work under this assumption. IT was the department to marshal large engineering teams who deliver the industrial grade solutions which can form the backbone of a business.

Ferrero Rocher
Crunch on the outside, soft and chewy in the middle.

Keep the outside outside. It’s common to have what is called a Ferrero Rocher{{4}} approach to IT: crunchy on the outside while soft and chewy in the middle. This applies to both security and data management. We visualise a strong distinction between inside and outside the enterprise. Inside we have our data, processes and people. Outside is everyone else (including our customers and partners). We harvest data from our operations and inject it into business intelligence solutions to create insight (and drive operational savings). We trust whatever’s inside our four walls, while deploying significant security measures to keep the evil outside.

[[4]]Ferrero[[4]]

It’s a separate question of whether or not these rules are still relevant in an age when business cycles are measured in weeks rather than years, and SaaS and cloud computing are emerging as the dominate modes of software delivery.

People don’t like change. (Or do they?)

I seem to be having a lot of conversations at the moment around whether people (you, me and everyone else) like and embrace change, or whether they resist it. The same question arises for companies. Like a lot of these questions, I think it depends. As individuals we don’t mind change, given appropriate circumstances. Organisations also want to change (and in today’s business environment it seems to be a question of changing or becoming irrelevant). However, people in organisations are usually strongly incentivised to dislike change, especially if they want to make that next repayment on their new mortgage. Fixing this, and creating a culture that embraces change, means changing the way we think about and structure our organisations and our careers. It means rethinking the rules of enterprise IT.

Every time a conversation comes around to the topic of change, I’m always reminded of a visit I made to a Toyota factory something like a decade ago. It’s so long ago now that I can’t even remember the reason for the visit, but that’s not the point of this missive.

Toyota, like most businesses, loves change. (Many large companies reorganise so often that change seems to be the only constant.) Change, embodied in the development of the Toyota Production System, was what took Toyota from the bottom of the global car industry to the top. Change is also why many of us have moved companies, following jobs as our employers reorganise their operations. For some of us, change is an opportunity. For many though, change is the tool of the man as he tries to disrupt our lives. Change means unwanted relocations, pay cuts, career stalls, or the need to shift jobs when we don’t want to. Change is something to be resisted.

What was interesting about my visit to Toyota though, was the attitude of the workers on the shop floor had to change. They didn’t hate it. They didn’t even resist it. They actually arrived at work each day eager to see how work practices had been changed since the end of their last shift.

A Toyota assembly line circa 2000.
A Toyota assembly line circa 2000

The concrete example I saw of this was the pre-sorting of seatbelt parts into coloured tubs. Apparently only a few weeks earlier the parts had been arranged on a wall. All hooks and dangling parts, like your Dad’s tools in the shed. When a car came down the assembly line a worker would select the parts appropriate for the car model, and then attach them to the car. Each seat belt had roughly four parts, so that meant there was three unnecessary decisions. Unnecessary decisions usually mean mistakes, mistakes waste time and money, and there were a number of mistakes made.

One day a member of the shop floor team had had the bright idea of pre-sorting the seat belts to avoid these mistakes. Some coloured tubs were sourced (some of the shop floor team drove to the local Walmart with a little petty cash), parts were sorted into tubs, and they gave the idea a trial run. Selecting seatbelt parts for a car now only required one decision: which tub?

The idea was a huge success; error rates went down dramatically. I hear that it was even taken global, and implemented in most Toyota factories around the world. (Though being around ten years ago, and with today’s rapid pace of change, I expect that the tubs have been superseded by now.)

What’s interesting about this story is that the change originated on the shop floor, from the assembly line worker who were actively looking to improve operations, rather than from head office as part of a reorganisation. Some of the improvements I heard about even resulted in the elimination of jobs, with the workers redeployed elsewhere in the factory. Workers weren’t just changing how they did something, they were also changing what they did. Change was what made the work interesting and engaging for the workers, rather than being seen as an oppressive tool used by the man.

I think we can safely set aside the idea that works don’t like change, as this story is not an isolated incident. Why then, do so many people resist change? Why, for every Toyota factory, there is a story like the UK newspaper industry, where workers (and unions) resisted change for decades, until Rupert Murdoch came along.

Rupert Murdoch, destroyer of unions, and good Melbourne boy
Rupert Murdoch, destroyer of unions, and good Melbourne boy

The problem is not people or organisations, but people in organisations.

People are funny things; they tend to do what you incentivise them to do. There’s an excellent article over at the NY Times, The no-stars all-star, which talks about measurement and incentives in basketball. We often talk about “what gets measured determines what gets done” from an employee incentive point of view, but this article puts some real meat on the bones of that argument.

Shane Battier, the no-stars all-star
Shane Battier, the no-stars all-star

As the article says (on page two):

There is a tension, peculiar to basketball, between the interests of the team and the interests of the individual. The game continually tempts the people who play it to do things that are not in the interest of the group.

A little later it goes on to mention (on page three):

A point guard might selfishly give up an open shot for an assist. You can see it happen every night, when he’s racing down court for an open layup, and instead of taking it, he passes it back to a trailing teammate. The teammate usually finishes with some sensational dunk, but the likelihood of scoring nevertheless declined. “The marginal assist is worth more money to the point guard than the marginal point,” Morey says.

The point guard’s career is defined by the number of assists he makes (among other metrics), and he’ll try and increase the number of assets even if it’s not in the best interest of the team. After all, teams come and go, while he has a career to maintain.

Once you place a person into a role you have put them on a career path which will determine their attitude to change.

Usually we take an operational approach to defining roles, rewarding people for the volume of work they are responsible for. Career progression then means increasing the amount of work they are responsible for, regardless of what this means for the company.

Measuring a project manager in terms of head count or revenue under management will give them a strong preference for creating ever bigger projects. It doesn’t matter if the right thing to do is create more, smaller projects, rather than run a programme of a few major projects as we have in the past. Your project manager’s career path is to increase their head count and revenue under management. And they do have those private school fees due soon.

Just like the point guard, change that will prevent career progression will be resisted (remember those kids in private school), even if it is counter to the company’s best interests. Which makes the current transformation we’re seeing in IT all the more important, because if we set the wrong incentives in place then we just might be our own worst enemies.

We can’t force a square peg into a round hole; nor can we force our existing employees to take their current roles and careers into a new organisational model. They just don’t fit. Take IT for example. We can’t expect many modern IT departments to spontaneously modernise themselves, transforming into agile business-technology engines under their own volition. It’s not that the departments don’t want to change: they do. Nor are most of the employees, as individuals, opposed (remember the Toyota example). But the combination of people and organisation will repel all but the most destructive boarders.

It’s interesting how other games, games other than basketball that is, have structural solutions to this problem. One solution is the line-up in baseball. From the NY Times article (page two, again):

“There is no way to selfishly get across home plate,” as Morey puts it. “If instead of there being a lineup, I could muscle my way to the plate and hit every single time and damage the efficiency of the team — that would be the analogy.”

Solving this problem in IT means rethinking the rules of IT.

The game of IT has, for the last few decades, been determined by the need to deliver large, enterprise applications into the IT estate. Keep the lights on, don’t lose orders, and automate anything that hasn’t yet been automated. Oh — and I’d like my reports accurate and on time. IT as the game of operational engineering. It was these rules that drove the creation of most of the roles we have in enterprise IT today.

However, this has changed. Decisions are now more important than data, and the global credit crunch is driving us to reconsider the roles we need in IT. We’re trying to reinvent our IT departments for the modern era – I even posted about how this was driving the need the need to manage technology, and not applications – but we haven’t changed the rules to suit.

If we want out people to embrace change, as the people on the shop floor at Toyota did, then we need to provide them with roles and careers that support them in the new normal. And this means changing the rules. Out with the more – more applications, larger projects, more people – and in with the new.

So what are the new rules for IT?