An Object Lesson In BT

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:

  1. Major business processes would be implemented on a single, modern, flexible platform.

  2. The platform would employ SOA to ensure that it could adapt to unforeseen needs.

  3. 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? 



Inherent differentiation in BP title

The actual stereotype of business people not knowing or understanding IT, and IT people not knowing or understanding business, is the actual cause of the gap, IMHO.

IT is not a separated thing, it should be part of the enterprise as a business department, just like sales, marketing and human resources. So, the analogy is clear:
1. To work on sales, I need to understand the business to communicate with clients, and also know my stuff to create convincing speeches.
2. To work on IT, I need to understand the business to generate supporting IT resources, and also know my stuff to create best of breed technology.

So, now, any business people must know about IT, since it is part of the business. But should know about possibilities, trade-offs, quality properties, evaluations, shadow architectures, strategic IT planning, etc. I see no need for business people to read code, understand what a protocol for communication is, or what threads and race conditions are.

I see enterprise architects running the role in that gap, but not the regular ones (focused on IT), but the ones that work on the enterprise strategy, not the IT one, and the ones that see IT as part of that strategy itself.

Technology is the driver, not strategy!

John, thanks for a truly insightful post. A number of points can be gathered from it.

1) There is a lot of sense in a consolidated approach.
2) It has to be based on a business architecture model.
3) To use orthodox programming is expensive and complex.
4) Analysing needs to be encoded by IT leaves the business outside.
5) The business must be empowered without needing IT knowledge.
6) Neither SOA not OO-Java make it any easier or cheaper.
7) Outsourcing it does not make it cheaper either.

Finally, the path to innovation is not from strategy to IT, but IT must provide innovative technology that REAL-WORLD enables new strategic initiatives for business and not just delivers the latest technology buzzwords. Clearly supports my position that businesses do need a consolidated application platform that does not require a programming approach, but uses a BT model-preserving concept and support and iterative, adaptive implementation cycles in small focuses projects.

Thanks, Max J. Pucher
Chief Architect ISIS Papyrus