IT Standardization is the Result of a Principle

When asked, smart people will tell you that technology independence is a very important principle for IT architecture. The most important reason is that technology changes over time. Mostly the changes are fundamentally minimal; paradigm shifting changes occur less frequent. But even when the changes seem minimal, it remain necessary to define a standardization policy with it's associated guidelines to create a technology independence.

Please note: IT architecture is mainly about principles, policies and guidelines and less about designs and/or solutions.

The whole purpose of such a standardization policy is to define the right standards. Taking the wrong components as standards can actually cripple the IT organization and make changes very expensive and even cost inhibitive. With all the devastating effects for the user community.

What are the right standards? Even though a lot of organizations pick strategic solutions and solution providers as their standard, this is not the right starting point. A good starting point are the interfaces. Your guideline for standardizing could be things like "open" (that is not-propriety, not bound to royalties and/or licenses), well accepted and so on. If you concentrate on those qualities you can be assured that many people were involved in making sure that the interface has the necessary attributes to make it useful.

Look for anything with "protocol" in it's description (or title). For example it is perfectly OK to say that IP is your standard for networking. You may laugh - since this is a no-brainer today, but some 20 years ago people would look as if you were nuts, because in those days a lot of IT shops opted for IBM's SNA. And SNA stands for Systems Networking Architecture. But if you take a closer look it was a propriety design of a set of solutions for networking systems together. Not even close an architecture. Which brings me to the point that architecture is probably the most ill-used keyword in descriptions used in the IT world. But that is a subject for a different post.

If you focus on standardization of interfaces you and the IT organization will be able to keep things under control while remaining flexible. The problem is that you won't find many people today understanding the purpose of a standardization effort. A lot of people, in particular in the user community, think that standardization is all about limiting choices to reduce costs. Yes, if you standardize on products, services and solutions you will have to fight battles. Battles, because the organization will think that they are being limited. Isn't IT about supporting the mission of the organization?

Make it part of your plan to explain first what standardization is all about. After sometimes lengthy discussions within the IT organization, people turn to me and ask for my preference or opinion. I usually get only one question: Is solution A better then solution B? This question obviously is the conclusion of the wrong discussion. My usual answer is "It doesn't matter what you choose, as long as you choose." Which leads to restarting the discussion but now with a different route.
If there is no time to loose, use one of my favorites: "Standardization is not about the color of the PC, the color of the cables, the operating system or the application software to be used for office automation. Standardization is needed for how applications and systems communicate with each other so that the users can maximize the information derived from the data that is stored in these systems. When you take this into account, which solution would best fit according to you?"

© Peter Bodifée 2008. All rights reserved