We’re struggling to keep up. The pace of business seems to be constantly accelerating. Requirements don’t just slip anymore: they can change completely during the delivery of a solution. And the application we spent the last year nudging over the line into production became instant legacy before we’d even finished. We know intuitively that only a fraction of the benefits written into the business case will be realized. What do we need to do to get back on top of this situation?
We used to operate in a world where applications were delivered on time and on budget. One where the final solution provided a demonstrable competitive advantage to the business. Like SABER, and airline reservation system developed for American Airlines by IBM which was so successful that the rest of the industry was forced to deploy similar solutions (which IBM kindly offered to develop) in response. Or Walmart, who used a data warehouse to drive category leading supply chain excellence, which they leveraged to become the largest retailer in the world. Both of these solutions were billion dollar investments in todays money.
The applications we’ve delivered have revolutionized information distribution both within and between organizations. The wave of data warehouse deployments triggered by Walmart’s success formed the backbone for category management. By providing suppliers with a direct feed from the data warehouse—a view of supply chain state all the way from the factory through to the tills—retailers were able to hand responsibility for transport, shelf-stacking, pricing and even store layout for a product category to their suppliers, resulting in a double digit rises in sales figures.
This ability to rapidly see and act on information has accelerated the pulse of business. What used to take years now takes months. New tools such as Web 2.0 and pervasive mobile communications are starting to convert these months into week.
Take the movie industry for example. Back before the rise of the Internet even bad films could expect a fair run at the box-office, given a star billing and strong PR campaign too attract the punters. However, post Internet, SMS and Twitter, the bad reviews have started flying into punters hands moments after the first screening of a film has started, transmitted directly from the first audience. Where the studios could rely a month or of strong returns, now that run might only last hours.
To compensate, the studios are changing how they take films to market; running more intensive PR campaigns for their lesser offerings, clamping down on leaks, and hoping to make enough money to turn a small profit before word of mouth kicks in. Films are launched, distributed and released to DVD (or even iTunes) in weeks rather than months or years, and studios’ funding, operations and the distribution models are being reconfigured to support the accelerated pace of business.
While the pulse of business has accelerated, enterprise technology’s pulse rate seems to have barely moved. The significant gains we’ve made in technology and methodologies has been traded for the ability to build increasingly complex solutions, the latest being ERP (enterprise resource planning) whose installation in a business is often compared to open heart surgery.
This disconnect between the pulse rates of business and enterprise technology is the source of our struggle. John Boyd found his way to the crux of the problem with his work on fighter tactics.
John Boyd—also know as “40 second Boyd”—was a rather interesting bloke. He had a standing bet for 40 dollars that he beat any opponent within 40 seconds in a dog fight. Boyd never lost his bet.
The key to Boyd’s unblemished record was a single insight: that success in rapidly changing environment depends on your ability to orient yourself, decide on, and execute a course of action, faster than the environment (or your competition) is changing. He used his understanding of the current environment—the relative positions, speed and performance envelopes of both planes—to quickly orient himself then select and act on a tactic. By repeatedly taking decisive action faster than his opponent can react, John Boyd’s actions were confusing and unpredictable to his opponent.
We often find ourselves on the back foot, reacting to seemingly chaotic business environment. To overcome this we need to increase the pulse of IT so that we’re operating at a higher pace than the business we support. Tools like LEAN software development have provided us with a partial solution, accelerating the pulse of writing software, but if we want to overcome this challenge then we need to find a new approach to managing IT.
Business, however, doesn’t have a single pulse. Pulse rate varies by industry. It also varies within a business. Back office compliance runs at a slow rate, changing over years as reporting and regulation requirements slowly evolve. Process improvement and operational excellence programs evolve business processes over months or quarters to drive cost out of the business. While customer or knowledge worker facing functionality changes rapidly, possibly even weekly, in response to consumer, marketing or workforce demands.
We can manage each of these pulses separately. Rather than using a single approach to managing technology and treating all business drivers as equals, we can segment the business and select management strategies to match the pulse rate and amplitude of each.
Sales, for example, is often victim of an over zealous CRM (customer relationship management) deployment. In an effort to improve sales performance we’ll decide to role out the latest-greatest CRM solution. The one with the Web 2.0 features and funky cross-sell, up-sell module.
Only of a fraction of the functionality in the new CRM solution is actually new though—the remainder being no different to the existing solution. The need to support 100% of the investment on the benefits provided by a small fraction of the solution’s features dilutes the business case. Soon we find ourselves on the same old roller-coaster ride, with delivery running late, scope creeping up, the promised benefits becoming more intangible every minute, and we’re struggling to keep up.
There might be an easier way. Take the drugs industry for example. Sales are based on relationships and made via personal calls on doctors. Sales performance is driven by the number of sales calls a representative can manage in a week, and the ability to answer all of a doctor’s questions during a visit (and avoid the need for a follow-up visit to close the sale). It’s not uncommon for tasks unrelated to CRM—simple tasks such as returning to the office to process expenses or find an answer to a question—to consume a disproportionate amount of time. Time that would be better spent closing sales.
One company came up with an interesting approach. To support the sales reps in the field they provided them with the ability to query the team back in the office, answering a clients question without the need to return to head office and then try to get back in their calendar. The solution was to deploy a corporate version of Twitter, connecting the sales rep into the with the call center and all staff using the company portal via a simple text message.
By separating concerns in this way—by managing each appropriately—we can ensure that we are working at a faster pace than the business driver we supporting. By allocating our resources wisely we can set the amplitude of each pulse. Careful management of the cycles will enable us to bring business and technology into alignment.
Great post Peter, in many ways
We did automate it all, on an ever growing scale. Then, we found out we had to govern it all as well. Maintain, change, retest, re-release, OMG
CRM and ERP were the next answers: one big carpet for all, amen. Well, that didn't work either. And, in the meantime, not only did the degree of automation explode within the company, but also the size of the IT department
Well, that didn't help either, creating one big elephant and still having to tweak and tune bits of that, that's where the conflicting cycles really start to hurt
Agile fixes some of these problems, although most Agile evangelists think documentation is evil period. I think reverse documentation during / after the go-live can be very cost efficient. Applications / federations without documentation, now that's evil
Turning your organisation into a network, business and IT-wise, will help too. I complained in a blog post about the size of IBM (no shares myself indeed), can anyone tell me how to move a 400K people company in any direction?
Integration will help glue the parts back together, make them sourceable, shoreable, cloudable, buyable and sellable
And, last but not least, we always always all of us make the mistake to “fix” an organisational or business problem by wheeling a flashy, techy solution. Preferrably by a third party…
Completely agree. There was this bloke who wrote some book about the inefficacy of silver bullets…
Your comment reminds me of a comment by Gordon Murray, better known for designing the McLaren Formula 1 cars. He pointed out that fuel efficient cars that are fun to drive are easy to make: they just need to be small and light. There's no magic bullet that will endow Hummers (or other over inflated SUVs) with a small carbon footprint; technology can only chip away at the edges.
If enterprise IT were a Formula 1 car, then it would be something like the Mercedes-Benz W196, good in its day but heavy and slow based on what is possible today. Bolting a supercharger onto the W196 will not make it competitive with an MP4-24. It might accelerate a bit better, but the cornering and breaks will still be somewhat lacking.
You need to rethink the architecture of your business. It might still have four wheels and one driver, but everything else should be up for grabs. New, lighter and stiffer, materials (such as SaaS and Web 2.0) let us strip weight out of our business, creating something which the W196 will be unable to compete against.
Just another argument for the Business-Technology story 🙂
I guess you like cars 😉
Silver bullet, it just reminded me of this other “new” thing: ESB and SOA. Again, right about now, I'm reading about a national government agency that wants an enterprise-wide Service Bus “to glue it all together” (my own words) and create an agile, flexible service oriented architecture (yawn)
Now, how well have they thought about the different departments, each dealing with different business pieces, consumer sub-markets, various government (other parts of the government of course) regulations, different timings (8/5, 12/6, 24/7) etc?
The ESB must support SOAP over JMS outside, and SOAP over HTTP inside. Described in WSDL. Now I know exactly what they mean, but they don't have a clue themselves
Where's the business agreements going through? How do we get from nothing to perfect by just agreeing on the fact that we'll speak English. I mean, which English? British? Welsh? Scottish? Irish? Which dialect? Australian, American, Kiwi-an? Is Dunglish and Frenglish allowed as well?
Not a word about how to collect enterprise-wide services (= interfaces). How to describe them. How to maintain them. How to version them. How to have them fit-for-purpose for applications, consumers and businesses
It's going to be a long, heavy, dirty and political fight, and my company will seriously miss out on throwing consultants at this by the dozen, but I'm going to go all the way in order to stop this madness before they even try to detail design it
I am blaming the rise of architecture as a profession and institution for this. 10 Years ago people would just get fired or figuratively shot for silly ideas like these, and rightfully so
Now, these ideas are pinballed by and through CIO offices and Chief Enterprise Architects and Boards for months and years, and whatever factor of 100 pages rolls out because the money ran dry, it's become a fact of life, no matter how unpragmatic, inefficient, unflexible and guaranteed-to-not-ROI it is, and their will must be done
Yes, I do get excited every now and then. I'm an Enterprise Integration Architect, and I loathe the current way decisions are rolled down from the top through impermeable layers of management
We don't do IAD, RAD, RUP or Agile. We still LAD through our architectural and CIO departments. And that's just dead wrong
Sorry for this long comment, but thanks for the inspiration 😉
Business-IT Nirvana does not exist. If it ever did, now is further away than ever.
I would kindly invite you to read my post about it at
http://align4survival.pleyad.es/it-business-nir…
Business-IT Nirvana does not exist. If it ever did, now is further away than ever.
I would kindly invite you to read my post about it at
http://align4survival.pleyad.es/it-business-nir…
[…] my colleague PEG discusses in his “Why we can’t keep up” post business and IT cycles have become misaligned. IT departments are typically geared to […]
[…] colleague PEG discusses in his post Why we can’t keep up, we’re not a in a period where business cycles are reasonably static. We’re in a period […]