Government Technology

By Dan Lohrmann: Covering the technology challenges and innovative opportunities available today, from government efficiency projects to implementing cloud computing.

Enforcing Enterprise Standards: Who, What, When, Where and How?

April 24, 2010 By

Since posting a blog on the Apple iPad's effect on government standards a few weeks back, I've received several questions from around the country regarding Michigan Government's processes surrounding the enforcement of enterprise standards. This topic seems to have generated a lot of interest from readers. Here's a quick overview of some of our controls.

Almost all state and local governments have laws, policies, rules and regulations regarding purchasing various hardware and software products and developing technology standards. But enquiring minds want to know how we control purchases, enforce policies, provide guidance, and manage the product standards once they are determined. Are there any "best practices" that I can share from Michigan on policy and standards governance? Beyond credit card limits and purchasing work flow approvals, how do we manage the formal approval process for requests and get to "yes" for our business customers? When do we bend and who gives in when business areas come to us with genuine (essential) requirements and real needs - and not just wants?

 Actually, there are several helpful items I can share. After we consolidated technology into one agency eight years ago, it took us several changes to get where we are today. We hope and believe that our architecture is fairly flexible to meet a variety of circumstances, but some would argue otherwise. Our standards exception process has gone through at least three rounds of modifications over the past few years - and it has been painful at times.

As general background, you can access several relevant documents at this website which cover Michigan's Enterprise standards .  Our DTMB administrative guide lists many of our government-wide policies (see the 1300 and 1400 series policies on this page for some of the technology-related items). We are in the process of updating our technology plans and issuing a new strategic plan this summer, but the background provided in our current strategic plan from two years ago may be helpful.  

Like most governments, we have committees to pick products, evaluate requests for proposals (RFPs), and ad hoc cross-functional groups to look at all aspects of service delivery. We also have an enterprise architecture team to assist with difficult situations, refresh technology plans, offer advice, etc. These individuals and groups can offer "solution assessments" that help various agencies decide on the most appropriate solution to solve their business problem. They offer help on security controls, explain which "zone" servers need to sit in, explain what products are supported, and much much more.  

But the $6 million question is about enforcement of standards in security, technology architecture, and how do we deal with inevitable exceptions?

 All technology purchases in the state need to go through our department. We have service catalogues which describes infrastructure services and pricing from PCs and to networks. Changes to firewalls, networks, or other devices are controlled through the ordering and internal request for change (RFC) process, and this prevents unauthorized changes from occurring.

But what about stuff like the Apple iPad that's not on the list? In Michigan, we have a Technology Review Board (TRB) and an Executive Technology Review Board (ETRB) to provide oversight.  The TRB is a formal group that oversees exception requests. They deal with one-off problems and are empowered to grant temporary exceptions up to 6 -months. Longer exceptions and appeals go to the ETRB - which contains senior execs from all parts of our organization. Think of the ETRB as our technical "Supreme Court" for technology decisions, with representatives from all part of the organization (including the customer liaisons, CTO, deputy directors, CISO and others).  

Requests to the TRB (which comes first) or ETRB are made via online templates, and must contain the business case, return on investment (ROI), life cycle costs, support plans, and other relevant items.  The format and discussion is very structured and efficiency in the process is maximized. While this may seem very complex to many readers, the process works well. ETRB decisions are made on 2-3 cases in an under an hour, and the ETRB usually meets twice a month for 60 minutes or less. Emergency meetings are called when needed, and the group has even convened by phone.

The interesting thing is that quite a bit of role-reversal ends up happening amongst ETRB members. The security guys sometimes argue for business customer service and agency reps argue for security changes. The board is fair and management enforces the rulings all the way down the management chain, so everyone has skin in the game. The focus is always getting the agency business process working, and any risks identified with the technology exception is accounted for via signature by the business customer.      

Best of all, the "word" gets out to staff. Technical architectures and standards means something. If you don't follow the rules, your case will quickly get thrown out.

For example, exceptions for 6 months are reviewed in six months - and you'd better come back to the board with the system fixed or security flaw remediated. (Yes, we have an excellent "secretary function" keeping track of all exceptions and timelines for the TRB and ETRB.) Checkpoints are added to check status of changes.

The auditors love this process because it has real teeth and is based on repeatable processes. The businesses get to argue their security case, and no one (usually) ends up being the "bad guy."  Most decisions end up being unanimous now, although that wasn't true four years ago when we started the TRB/ETRB.    

Bottom line, the boards take the good, the bad and the ugly. We make lemonade out of project lemons. Our goal is to offer customer-focused answers while enforcing enterprise standards - a tough thing to do. 

 So what about that iPad you want - I mean  need? Submit your business case, and we'll take a look. Otherwise, you can fight for whatever you'd like during the next enterprise architecture technology refresh cycle.  

So what's your government's process for enforcing standards and balancing customer service? I'd love to hear other approaches.  I will also answer any follow-up questions.


| More

Comments

iwongeorge123@gmail.com    |    Commented May 1, 2010

Excellent blog post, keep up the good work. I read a lot of blogs on a daily basis and for the most part, people lack substance but, I just wanted to make a quick comment to say I'm glad I found your blog. Thanks. =================== iwon

sdzhains@onetel.com    |    Commented May 6, 2010

I can only echo George Iwon's sentiments - great blog that stands out against the many!

Martin    |    Commented December 31, 2010

I was kind of dissapointed since I was looking for standardization of smartphone hardware which might and should be enforced by government or even better by global agreement. Instead it's just standardization of govenment purchases of smartphones.


Add Your Comment

You are solely responsible for the content of your comments. We reserve the right to remove comments that are considered profane, vulgar, obscene, factually inaccurate, off-topic, or considered a personal attack.
Lohrmann on Infrastructure

Building effective virtual government requires new ideas, innovative thinking and hard work. From federal stimulus projects to enterprise architectures to cloud computing, Dan Lohrmann will discuss what's hot and what's not in the world of technology infrastructure.



More from Dan Lohrmann

Lohrmann on Cybersecurity