Yesterday, I talked about the location of a dev-test environment.  I argued that  there is a good reason for an agency to consider hosting their own virtualized dev-test environment in their data center.  I said:

To take a first step into cloud computing and to evaluate the role of being a cloud provider versus a cloud consumer.  The dev-test environment is a low-risk candidate because it does not support any operational mission systems, so impact is low if there is a problem.  What’s more, a lot of what you pay for with a commercial cloud computing provider (e.g. wide bandwidth, huge capacity, managed services) is not very valuable in a dev-test environment where the system is only supporting a handful of users and test data. 

Today, I want to talk about a related issue, that of governance.

Governance

A virtualized dev-test environment speeds development and cuts up-front costs by eliminating the need to buy and configure equipment.  However, agencies can get ongoing savings and efficiencies if they also unify the operating system and support software underlying those development environments.  If that is done, maintaining the agency’s portfolio of applications becomes much easier.  This common operating environment is, of course, the agency’s target Technical Reference Model (TRM) from their Enterprise Architecture (EA).    

But arriving at a consensus between multiple independent projects can be difficult.  Going from an environment where each project team has carte blanc to a shared environment in which they must use a standard system configuration may be seen as unduly risky.  And it is unlikely that any agency could collapse all development to a single environment, if only to accommodate different operating systems.  But to the extent the number of development environments can be rationalized, the agency will realize efficiencies.  

To gain acceptance and buy-in for a shared environment, the CIO should constitute a Change Control Board (CCB) with representation from an appropriate cross-section of the community using that shared dev-test environment.  The CCB serves as the gate keeper for that dev-test environment.  So, for example, the CCB might question the need to add an obscure programming language or a legacy application; is there a real need, or does it just represent an arbitrary preference by one person?   And by controlling the Agency’s shared IT environment, the CCB also ensures that the agency’s IT investments are updated and secure.   So the CCB assures program managers that they have not sacrificed control for collaboration.

Jeff Koch is an Associate Partner in IBM’s Strategy and Innovation consulting practice providing thought leadership on government management and the intersection of technology and mission. Prior to joining IBM, Jeff was at the Office of Electronic Government and Information Technology at the Office of Management and Budget (OMB) where he managed 12 government-wide E-Gov programs, and played a key role in the Federal budget and legislative process.

Jeff also worked for the Chief Information Officer at the U.S. Department of Labor where he managed the Benefits.gov program and provided leadership on IT budget and information policy. Jeff also worked as the Chief of Staff for a Member of Congress, and as an engineer for a large defense contractor where he designed radios for military communications and surveillance systems.

0 comments

Your name: *

E-mail: *

The content of this field is kept private and will not be shown publicly.

Subject:

Write a comment...

Your comment will appear after administrative review.

CAPTCHA

This question is for testing whether you are a human visitor and to prevent automated spam submissions.

What code is in the image?: *

Enter the characters shown in the image.

1875 recommendations

Recommended