12.29.09
The Grass is Always Greener
[Cartoon]
Once Information Technology problems are encountered or anticipated, there are months of study to find a solution. In the outcome, a new system is usually recommended. Following this is the “build or buy” scenario. Top vendors of solutions are brought in for evaluation. There may even be a formal RFP (Request for Proposal).
In the end, a new system is selected. Everyone believes that they have done their due diligence. They documented and weighted their requirements. They rated each proposed solution against each requirement and derived the final scores. The one alternative that stood out was selected as the best approach.
All of this sounds like good management, but, architecturally speaking, this approach usually only maintains an existing silo. Since new systems will take a considerably long time to install and requirements may change during the installation, this may not be good management after all.
First, consider the human side of the entire evaluation process. Most of us would always prefer something new over continuing to use the old. This is especially true if the old requires us to work harder to get the results expected.
How about the solution ratings? They are usually very subjective. Individuals can be influenced by the vendor in many ways. For example, all the ratings of one individual may tend to favor one vendor due to one single positive or negative fact. This happens because people are not computers. They may simply like or dislike something and often for reasons they cannot identify.
The ratings are done by the Subject Matter Experts. Some of the experts will see the participation in the process as a way to influence the outcome to their personal benefit. This could be either to take more responsibilities in the final outcome or during the implementation.
Why not take an architectural approach? Examine the entire enterprise and determine what new business entities and processes will be needed. Maybe only extensions to existing components will be required. Define what new services may be needed to expose the new information and the processes. Let each line-of-business verify that the services defined can be incorporated into their existing processes.
The architectural approach will not have the excitement and glamour of an encompassing RFP. It will usually take place with very little fan-fare. Purchased solutions, developed solutions, or cloud-based solutions are all evaluated against the ability to deliver the needed services. Ratings are done by determining the costs of mapping what is available to what is needed. There are no likes or dislikes; this is pure engineering.
Of course it takes the special skills of an Enterprise Architect to orchestrate this type of evaluation. This is not within the realm of a Project Manager. The broad, enterprise perspective of an Enterprise Architect is needed when Information Technology problems are encountered or anticipated.
Closing the Business / IT gap
