Forrester has long advocated adoption of a “business technology” approach to replace traditional IT. “BT” recognizes the fundamental role information technology plays in all aspects of business – and the need for business decision-makers to be deeply involved in setting technology strategy, priorities, and even delivering solutions. But how does this tight coupling of business and technology decision-making actually work?
My colleague Alexander Peters and I have just witnessed a situation that illustrates that having the right organizational structure and technology-savvy businesspeople is crucial to a BT transition.
The organization developed an IT strategy 10 years ago based on three best practices:
Major business processes would be implemented on a single, modern, flexible platform.
The platform would employ SOA to ensure that it could adapt to unforeseen needs.
- The platform would run in the consolidated, scalable, and efficient data center of a service provider.
Today, the organization has not yet achieved its top goal of a single platform for all of its major processes. It has a new SOA/Java environment, but it processes a little more than half of the required workload. Older systems do the rest. Most disturbing:
The development investment has been many times greater than expected at the outset.
The annual cost of IT operations doubled versus the baseline.
- System reliability went down with the new environment.
Several things went wrong. Most importantly, external technical architects drove many of the new system’s innovative concepts from inside the project while learning the company’s core processes. It was very difficult for business decision-makers to do anything but submit requirements in the usual way because they didn’t understand the underlying technology at all. This is not the deeper involvement in strategy and delivery that BT aspires to. It is traditional requirements management, SOA-style.
Worse, while senior executives supervised investments in projects, no one was responsible for understanding the impact of individual project decisions on end-to-end service and operating costs – until the support-desk incidents and big bills started arriving.
The organization has now pushed the reset button on its strategy and is putting people in place who will properly guide future investments. A critical question is how much the new managers must know about the technology they guide. These businesspeople are not developers but must be smart enough to engage with the technical staff they work with on creation of new processes and understand the larger cost implications of project investments. I think the development staff has a big interest in helping them learn.
What do you think? How IT savvy do your business representatives to technology teams need to be?