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 ...
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.
Looking for the latest gov tech news as it happens? Subscribe to GT newsletters.