* A risk associated with architecture is that it is irrelevant
In the last newsletter we identified one of the reasons why architecture was risky. That reason being that based on the views of the CIO, working in an architecture group can be career limiting. In this newsletter we will elaborate on the risks associated with architecture.
Several months ago Jim was hired by the IT organizations of a Fortune 20 company. The company had grown significantly over the previous decade primarily through acquisitions. Not only had the company grown, but the company’s set of applications and IT infrastructure had also grown dramatically, and most of this growth was organic. In this case, the word organic is a polite way of saying that the growth in IT occurred without any real direction.
Initially, it appeared as if Jim was being hired to help the company develop an architecture. As it turns out, the company had already developed a very sophisticated architecture. The problem was that nobody in the IT organization had been required to follow the architecture, and as a result, few did. That may sound a bit odd to you, but it did not sound that odd to Jim. He had experienced that phenomena before.
A number of years ago Jim was responsible for transmission, switching and routing for Digital Equipment Corporation’s (DEC) network. Every year, DEC’s global IT organization would create an architecture that focused on many aspects of DEC’s IT Infrastructure. Unfortunately, there was no pressure on any of the various IT groups within DEC to follow the architecture. All of this points us to another risk associated with architecture – it is irrelevant. Actually, the risk of irrelevancy is not entirely distinct from the risk that working in an architecture group could be career limiting. In particular, working in an architecture group is more likely to be career limiting if indeed the architectures that get produced are irrelevant.
As an aside, it is interesting to note that the architecture that the DEC global IT organization created made very little, if any attempt, to relate DEC’s infrastructure to DEC’s applications. We would like to believe that with all of the attention currently paid to application delivery, that any architecture created today would clearly make a significant attempt to link the infrastructure architecture to the requirements of the company’s applications.
We would like to hear from you. Does your IT organization have an effective architecture? Does that architecture link the infrastructure architecture to the requirements of the company’s applications?
