How software and architecture standards drive IT business alignment

The Real Niel Niel Nickolaisen

In my pre-IT days, one of my favorite complaints was software and architecture standards. It seemed to me that IT staffers hid behind such standards so they could kill my initiatives. I would have an idea for a technology or application that would advance the cause, and IT staffers would give several thousand "standard" and "architecture" reasons why they would not consider my idea.

In my new IT life, I learned to love software and architecture standards. They helped me fight the inherent trend toward system and software complexity. When someone in marketing brought me some whiz-bang technology tool he or she wanted us to implement, I could hearken back to my standards to make sure this grand solution did not require me to adopt a new database, programming language or operating system. Using my standards, I did not have to worry about implementing and supporting someone's must-have, FoxPro-running-on-Universe-written-in-PICK application.

One day, as I was successfully using my standards to thwart attempts to make IT more adaptive and accessible, it occurred to me that I had become what I had previously disliked. I was using standards as an excuse. But how could I find a balance between chaos and structure while meeting customer needs?

More from The Real Niel How to build a remote-site disaster recovery plan -- a CIO's advice Virtualization project success factors from CIOs

As I was wrestling with how to satisfy these competing constraints, I realized that I did not have to solve this problem by myself. This led me to what has been a fine solution. What did I do? I invited representatives from the business to not just attend but to also be members of our architectural standards board.

My architects were stunned. The business was frightened. These were two groups that did not normally interact. The first few meetings were a little rocky. But then it started coming together. The architects got a better sense of business needs and the business got a better sense of our challenges. Our resulting standards seemed to find a balance between flexibility and complexity.

For example, we standardized on database technology and a development environment with the caveat that our standards must be something considered market-leading, with a future (think Oracle or SQL Server, not Btrieve, and .NET or Java, not FORTRAN). We also agreed that applications that connected to our ERP and customer relationship management systems should do so only through certified, tested, supported interfaces.

The net result of this interaction was improved self-filtering of requests by people on the business side. As they explored and investigated technology solutions, they considered choices that they now knew would make our lives easier. For example, the business would only consider applications that ran against our standard database system.

I invited representatives from the business to be members of our architectural standards board. My architects were stunned. The business was frightened. Then it started coming together.

And the architects started to loosen up. They decided that we should have a preferred operating system (Windows), but we could also deal with some alternatives like Linux. However, they did draw the line at DEC Alpha 64 and the like.

The architects also started looking at technology in terms of business trends rather than technology trends. In uncharacteristic behavior, they worked with the business to develop an architecture roadmap that projected how our standards would evolve, based on current information. Having these standards in place and a common business/IT sense of the downside of managing nonstandard applications, operating systems, databases, etc., helps us decide which technologies we should start to explore and which of the newly orphaned systems we should plan to retire.

This entire approach tethers back to my rule of thumb for IT customer service: It is more important to be helpful than it is to be right. If we hide behind our standards as a way to make sure that we are precisely "right," it is doubtful that we are being helpful. At the same time, we cannot let ourselves fall into the trap of being so helpful that we let chaos ruin our service levels. Taking a sensible, customer-value approach to standards and architecture can help us sort through the options for how we choose and implement such standards.