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

Implementing IT Architecture is all about change

Implementing an IT Architecture is changing the way we look at the IT systems, the way we deal with them and so on. A change management approach appears to be best method to drive the implementation. Now change management in IT is a subject for a book on it's own, so for now I will only give some practical suggestions for IT architects how to position themselves during the implementation phase. Because this is where 90% of the architect's work is done.

As many can attest, change also seem to cause resistance. Almost like the third Newton law "actio et reactio". Why do people seem to resist to change? Well they don't, people change all day. Who sticks to his plan every day? Lack of insight what is going to happen, or even worse lack of influence on what is going to happen results in lack of control, which creates the anxiety and stress that people hate so much.

You typically see that there are many roads to Rome. The choices often makes implementers nervous whether their choice was right. The desire of people to control things in life and the fact that there are many ways to reach a destinations is something you should take advantage of. Let the people involved decide for themselves how to get to Rome. Appeal on their own brain power. Don't worry where they currently are and what they are doing. Waste of energy.

The lead IT architect should be very clear what the destination (reference architecture) is, this is no subject for debate. Those in doubt about the validity of the destination should search their own, but not argue with the IT architect. But how one gets to the destination can be very different for various stakeholders. And when they can create their own marching orders, they feel much more confident to pursue the change instead of resisting them. The lead IT architect should just join the program leader in his helicopter and make themselves available for anyone who is or seems to be lost.

Now I don't want to suggest that the destination is final. IT systems are very dynamic in nature and therefor the IT architecture is not so rigid as in the physical world of architecture. People may get confused when they are heading in a certain direction that the destination has moved. Instead of allowing the concept of a "moving target" which creates a lot of uncertainty, I prefer to explain that it is journey. We have therefor intermediate destinations. And let the organization decide themselves if and when it is worth continuing the journey.

© Peter Bodifée 2008. All rights reserved

To virtualize or not: that is the question

Virtualization is hot. Vendors are screaming that their product is "virtualized". Hype? Curse or blessing? Questions which will give you tons of answers depending on who you ask.

Let's first address what virtualization is. "Virtually" according to the dictionary is "in essence or effect but not in fact" or "seems to be present". The best description I ever found on the internet what virtualization is in an IT environment was written by Willem Joustra and can be found on his blog. He does away with application virtualization for good. Leaves us with virtual hardware in the forms of virtual cpu, disk, networks, etc. and virtual operating systems.

So am I adding now more words to the (mostly technical) discussion already taking place? No, I want to see if this notion of virtualization can ultimately solve all the challenges the IT organization faces that are directly or indirectly related to physical instances of hardware and operating systems. Challenges in maintaining them through their operational life. Because I envision that the flexibility possible with virtualization will make total new concepts possible in IT, having a dramatic impact on how we view hardware and operating system. In the end, the user's only concern is application functionality.

The effect of virtualization to the user is already visable in networking, data storage and to some extent in servers (mainly in high-end and in mid-range, less in low-end). The only area which seems to be untouched is end-user devices. Yes, seems, because it exists and only due to the huge number of end-user devices it is not visible on a large scale.

Virtualization on an end-user devices (most common devices today are still desktop PCs and laptops) gives the possibility to take your created environment - your set of applications customized to your liking - from one device to another device without a major effort. You can actually keep the virtual hardware in your wallet! Just think of the freedom you now have. I am currently involved in creating a major change for schools on how to implement the IT based learning environment. Using this virtualization concept makes innovation possible on when and where children use their own learning environment without having to supply everyone with a laptop, which introduces a new series of problems instead of solving ones. This is just one of the examples.

Any discussion of the pro's and con's of a particular virtualization technique in a product should be left to IT engineers to challenge their thinking and to product marketing managers who have nothing better to do. It is not something an user community has to worry about. If you have no need to be on the (b)leading edge, just wait 6 months, observe and you will be able to tell what product was hype and which ones stayed around. What the user community should worry about is how to break the conventional thinking on how use of machines fit into the total IT Architecture. Because machines can be easily virtualized without loosing functionality. That was discovered more then 35 years ago and still is applicable today.

© Peter Bodifée 2008. All rights reserved

The board's view on IT Architecture

The usefulness of having an IT Architecture (I rather prefer value instead of usefulness) for an organization is often subject to debate. To end the debate, it usually helps if the board (or executive team) fully supports the IT architecture, not only the existence of IT architect(s) in the organization.

Some people claim that a typical board can't understand the IT architecture by itself (who can?) and therefor is not likely to support or enforce an IT Architecture. In this case it is very likely that the organization's IT architects are at the top of their own Babylon Tower. Not necessarily a smart thing to do, as it will not lead to a wide acceptance of IT Architecture, certainly not with business executives.

Some of you had the privilege to meet with board members in order to present a proposition on which they should or could take a decision. For those who have not: the following questions are in the head of the board members:

• What is in it for me?
• Why should we (read our organization) do this?
• How much will this contribute to the bottom line this year and the next years?

Yes, it is that simple. They are held accountable and need to clarify their decisions to the shareholders. Even if the board is one person and the only shareholder!
No, "Partnering within our ecosystem will greatly benefit the IT mission to simplify the use of the Enterprise Messaging Bus using broadcast protocols on the secured transparent network" or similar wording will not make their day.

In quite a few organizations the responsability on IT matters within the board is taken by the CFO. Unfortunately many CIO's - despite their title - are not members of the executive team and do report to the CFO. If your CFO is the person to give the final nod, make sure that (s)he get the view on IT architecture in a language (or numbers to be specific) that is clearly understood.

Financial people love ROI: Return On Investment. With the formula for Arithmetic ROI it is simple to see if the investment is profitable or not. But calculating the investment values of a complex IT infrastructure or an elaborate software platform is not everybody's piece of cake. So IT has to satisfy the board with something else.

We are talking about the cost necessary to implement the change towards the IT solutions according to the IT architecture, the current cost of the IT landscape (usually already known) and the anticipated cost of the future IT landscape. And let's not forget the cost of creating the IT architecture and to maintain it. Good Architects have a fee, not an hourly rate.

Keeping in mind that I am talking about all costs*: both capital and operational expenditures (CAPEX and OPEX). I always suggest to use only the hard facts: the future combined CAPEX and OPEX should be lower then the current one. Divide the cost of change by the savings achieved and you will have the duration it takes before the savings are effective. If this period is longer then the life span of the solutions then you should think twice before going ahead. It certainly will not impress the CFO. Tip if your initial numbers don't look good enough: check if you included the cost of all relevant IT staff.

So how much detail should the IT architect bring to the picture? Not too much, because it will sidetrack the audience and you will get IT into slippery territory. If the IT architect is trusted using credible sources, the consolidated numbers should give enough insight to the board. And as for the cost for change: be bold when quoting numbers. Rather too much instead of having to say "oops" at a later stage.

As you can see, IT Architecture for Board Members is all about a financial view on the IT landscape. IT architects should demonstrate the financial viability creating, implementing and maintaining an IT Architecture.

*) Doing a TCO analysis - Total Cost of Ownership - is worth the effort if IT also would like to get a good financial understanding of the stuff they implement and maintain.

© Peter Bodifée 2008. All rights reserved