IT Standards

  • Article

For any IT organization to remain agile, efficient, and cost-effective, it must implement a set of technical and process standards to guide project implementations. Now, many people recoil at the notion of standards – at “someone else telling me how to do my job.” But properly managed, standards can be liberating, and far from slowing innovation, can actually enhance and encourage technical breakthroughs.

Here’s a simple example of what I mean by enhancing innovation: one of our more straightforward standards in Microsoft IT was that all IT applications had to use Active Directory for authentication. Some of the benefits from this (utterly non-controversial) standard were:

  • No one wasted any time or resources building their own authentication mechanism; instead their focus was on new features;

  • Third party applications we purchased had to comply with this standard;

  • And therefore our operations staff only had one identity mechanism to manage.  

Thus standards reduce operations cost while focusing development on those areas most likely to provide business value (and not reinventing wheels that were perfectly suitable and in fact where considerable investment had already been made).

Standards for integration mean that applications can interoperate and new applications can smoothly join the ecosystem; standards for development mean that applications use consistent methodologies and libraries so they function predictably; standards for data mean that applications can understand each other’s models and thus take better take advantage of IT’s core asset, information; standards for security lead to a demonstrably and quantitatively more secure environment.

One of our more interesting standards was one that required applications to “stay current” on latest versions of system software (OS, database, and so forth). We created this standard in response to an internal study that clearly showed dramatic decreases in support costs (number of tickets, average time to resolution) for applications on n or n-1 versions of system software.

So how do standards get created and operationalized? While standards were the responsibility of the Enterprise Architecture team, EA only managed the process. A cross-group team called the Standards Review Board, composed of senior individuals, reviewed all proposed standards. Here, in brief, was the process we followed:

  • Anyone could propose a standard;

  • Proposals were reviewed by the SRB and if reasonable, a working group of SME’s was created to hammer out the details. We tried hard to get diverse opinions on the WG so that no standard would reflect parochial interests of a single group;

  • The final version was review by the SRB. The final version had to include:

    • The motivation for the standard;
    • The final text;
    • An impact statement
    • An adoption plan, including, if needed, how to
      retrofit existing applications

Over time, we learned a lot about how to streamline the process and how to drive change management through the organization. For example, we chose specific technical areas on a quarter-by-quarter basis where we wanted to prioritize; we scorecarded applications during the Architecture Review on improved compliance to standards; we assigned a PM to track the working group activities and ensure they met their deadlines.  

We said that “standards focus innovation;” and while standards require a certain amount of investment (and executive buy-in) their return is significant.