Creating the Technology Strategy
So far so good, the business strategy is understood, the requirements are known with a reasonable degree of certainty and, by now, you have framed the relevant scope and priorities of your company (are you in a business that requires a view of technology as a competitive weapon or as a utility?). To boot, you have also apportioned how you will deal with complexity. It is finally time to develop the overall technology strategy that most clearly matches the technology plan of your business.
At its simplest, the technology strategy should provide a summary, a digest of the technical “Whats” and “Whens”, that translates in technical terms the key business needs. These are really the technical strategy answers to the business requirements, defined in terms that business folks can understand. Here are some examples:
What: “We will replace the entire system with new technology components via gradual investments.”
When: “Over a two-year period, starting with a Phase 1 deliverable that will support new customer analysis tools.”
What: “We will buy a new ERP from vendor XYZ and outsource all new development to India.”
When: “We will hold off until next year. In the meantime we will research outsourcing partners and develop an RFP.”
What: “We will continue to use the operating system ‘as is’, but we will use new technologies to develop any new business systems.”
When: “We will do so on an on-going basis as new business systems become approved.”
If you’ve ever watched a group of children playing a casual game of soccer, you may have been amused at the way they wildly chase after the ball as a pack (believe me, this happens whenever children are let loose with a soccer ball!) There is no structure to the way they play and, as a result, their efforts are usually wasted as they comically interfere with each other. The children know the “What”: to play soccer; they also know the “When”: right-now, but what they lack is knowledge of the “How”.
Just as the “What” and the “When” should have emerged from the definition of the agreed transformation previously discussed, the “How” is the essence, the secret-sauce, of the technology strategy. The “Whats”, the “Whens”, and the comprehensive explanation of the “Hows”, represent the detailed strategy that is to serve as the blueprint for the multi-year IT transformation plan. This technology strategy blueprint is depicted in the diagram below: the core technical solution, including the overall technical approach, the high level architecture, and the standards and tenets you will adopt.
The technical strategy is not meant to be a photograph—something static—but rather an evolving movie. To become a living, breathing, strategy, it must be continuously cross-checked with the changing business requirements. If adjustments are needed, you should ensure the solution continues to conform to the business requirements, and that any resulting changes to the architecture and standards only occurs on an as-needed basis and not as a result of whims or sudden changes in direction driven by dictates of fashion or politics. You will need to implement a governance to oversee the evolution of the strategy, as well as to manage the change control processes in order to avoid the dangers that so-often plague many large projects: scope diffusion, runaway requirements, or irrelevance of the solution.
One of the key roles of the strategic governance is to ensure the strategy is communicated and understood at all levels of the organization. The technical staff, from the most junior programmer to the most senior manager, should be intimately familiar with all the elements of the technology strategy.
While your communication to the technical staff will most likely emphasize the “How” of the strategy, the message to less-technical constituencies, such as the executives, will have to be framed in a more easy-to-understand ‘elevator-chat’ form dealing with the “Whys” and the “Whats” of the strategy.
In this elevator talk you can still speak about the core technical solution and the general principles regarding the transformation: Will you develop the solution internally? Will you rely entirely on the services of a third party vendor? Will you use a hybrid of internally developed modules, with modules available externally as a service? (Software-as-a-Service: SaaS). If you are going to build the solution internally, what role will the IT department play? Will you hire new developers, or integrate third party augmentation services? Will you bring in temporary contractors for software development or will you off-shore development? If so, which components will you off-shore? Will you outsource the whole damn thing? What are the timeframes and general costs? What are the benefits? When will the benefits be realized? Which vendors do you consider strategic?
Clearly, this (possibly long—it’s a tall building) elevator talk will not easily accommodate the explanation of the detailed architecture or standards, but you should at least be able to cover the general concepts, such as whether you plan to use open source software or whether the solution will be accessible via the web.
Now, why are there no longer elevator operators? Remember the days when operating an elevator was considered to be such a specialized role that it required a, usually bored-looking, attendant to press those buttons as a service to you?
Come to think about it, you may want to mention to the CFO that you will be using something called Service oriented Architecture. . .
Labels: Architecture, IT, outsourcing, SaaS, SOA, Software Development, Strategy, Technology, Transformation
posted by IT Transformation with SOA @ 8:58 AM
