Archive

Posts Tagged ‘Standard’

Building an IT Standards Framework – Part 1

August 19, 2008 Comments off

When we set out on the journey towards an Enterprise Architecture two years ago, we had very few documented “Standards” in the organization.  We saw this as one of our key issues to reduce the complexity of our IT operations and simplify the enterprise architecture.

What is a Standard? For every 3 experts we asked, we got 4 opinions.  We chose to define a standard as the top level record for any information regarding the process, practice, implementation, or use of a technology.  Specifically, a standard would fall under one of the following types:

Technology Standard
Defines the use case, capabilities, and implementation constraints of a particular technology

Process Standard
Defines a business or IT process flow, checkpoints, inputs, and outputs.  This is technology independent.

Design Principle
High level principle that guides the use, implementation, and design of processes and technologies.

Target Architecture
The desired target state of an architecture.  This involves both the technology and process aspects of the architecture, and governs the direction that changes will occur in those systems.

How do we create, approve, and govern standards? To begin defining and documenting standards in the organization, we created the Architecture Standards Council (ASC).  The ASC was composed of eight representatives from the relevant technology and business backgrounds and was responsible for the review and approval of standards.

The creation of these standards was left to individual teams or projects when the need arose or was forced upon them.

Governing the use of standards was left to Enterprise Architecture.  Each project architecture was reviewed and measured based on its compliance with the documented standards.  If no such standard existed, or one was violated, EA would refer the project to the ASC for approval.

This process has been running for a year at this point and has been received with moderate success, but we have room to grow.

What lessons did we learn?

  • [GOOD] Putting the control of standards (and their deviation) outside the boundaries of Enterprise Architecture was a good decision as it increases the feeling of inclusion for the rest of the organization.  It also prevents Enterprise Architecture from being perceived as an “Ivory Tower”.
  • [GOOD] Creating a single organization and process for review, approval, and governance of all standards across the organization leads to better communication between groups.
  • [BAD] ASC does not have the time commitment to define and flesh out new standards, leaving that role up to projects.  This slows down the execution of projects, forcing them through extra beaurocracy.  We need to have a process to submit a request for a new standard to be defined outside of the restrictions of a current project.
  • [BAD] Standards were not analyzed on the ROI of their compliance, nor were they reviewed by the IT Management team.  This led to the creation of unfunded mandates from the ASC, expensive tasks for projects and teams with no funding to execute them.

What’s next? I am currently defining “ASCv2” to address these problems.  In the next post I will outline the next iteration of my Standards Framework for the organization.  Stay Tuned!

Bookmark and Share

Categories: IT Governance Tags: , ,