6 IT trends government IT managers should be wary of

There are many good information technology innovations, but not all the current fads are good for government IT. Some trends are bad in general, and some are very bad for government IT managers in particular. Others are good for some uses but not others. Let’s examine a few of the IT industry fads that make bad matches for government IT, and why they are bad.

1. Cloud computing is a red herring. Chasing this fad now, before standards are in place and security concerns are dealt with, is a complete waste of time. Also, it still needs to be sorted out whether cloud computing is primarily a utility-based hosting solution, a new application-development model, or both. Although Web 2.0 start-ups can afford the risk associated with these desired IT cost savings, the government should take a wait-and-see attitude.

More on this topic:

Why you might want to be wary of cloud computing

2. Web 2.0 is not pixie dust. Anyone who has witnessed a crazed mob of sports fans on an alcohol-induced rampage would agree that crowds are not always wise. In the same way, Web 2.0 technologies are not a panacea nor should they be the No. 1 priority for government IT. Web 2.0 should be relegated to areas that tap its strength, which is primarily nonattributed commentary and workgroup collaboration.

3. Agile development is a programmer’s fantasy and a manager’s nightmare. In my more than 20 years of software development experience, I have never met a government program manager who is available on a daily or even weekly basis to help design an application on the fly. Extreme iteration and pair programming are almost exclusively programmer perks and not in the best interests of government IT. Please don’t build the next space shuttle that way.

4. Data standards cannot be market-driven. Although the government sponsors many emerging marketplaces, such as green energy, a standards marketplace should not be one of them. I have said this many times before, and I will now say it again: Data standards are not amenable to competition. Instead, government data standardization should be seen as one of those “inherently governmental” activities. Stay away from any standards development organization with a business plan.

5. Service-oriented architecture has not yet convincingly addressed older applications. SOA is absolutely the right approach for new application development, but its Achilles’ heel is its failure to come up with a workable transition strategy for legacy applications. Thus, SOA pilots get pigeonholed into a “nice dream” limbo or a “maybe someday” wistfulness. Finally, the coarse-grained “just wrap it” approach rings hollow when the devil delivers the details.

6. Web application development is still a kludge. Although the Google Chrome operating system steals headlines and Twitter changes the face of Iran, Web applications are still an uncomfortable amalgam of at least a half-dozen technologies cobbled together into an ugly patchwork. Fortunately, this is the underbelly of the Web that the users don’t see. They just taste the sizzling sausage that comes out of the ugly sausage factory, which conceals the cross-browser nightmare of HTML, JavaScript, Cascading Style Sheets (CSS), Extensible Application Markup Language (XAML), Extensible Markup Language User Interface Language (XUL), Asynchronous JavaScript and XML (Ajax), and numerous server-side options. And that does not even include Rich Internet Application technologies such as Silverlight, Flex and JavaFX. The messy reality here is that, although your next enterprise application should be Web-based, government IT managers must be careful to keep their critical path to well-trodden ground and limit their Web application design to the minimal number of technology hand offs.

The key to understanding these six warnings is to understand that government IT operates as a mission multiplier and not as a cost center. Just as there are inherently governmental business functions, there are inherently governmental IT practices. Government can no longer dictate the IT landscape — as evidenced by the failure of Ada — but government IT managers must still be keenly aware of the unique requirements for government IT systems. The latest IT fad might be well-suited for businesses but ill-suited for the government.

About the Author

Michael C. Daconta ( is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.

inside gcn

  • cybersecure new york city

    Cybersecurity for smart cities: Changing from reactionary to proactive

Reader Comments

Fri, Aug 14, 2009

This entire article is made up of opinions; where is there evidence of these. I can cite direct evidence where Agile saved the Government money in my agency; we had a small project estimated at $170K, we turned in $69K at the end of the project by using Agile development to meet what the customer needed ahead of schedule. Directly working with the customer saved the money without losing any requirements. Minimal (not zero) documentation was created; we passed C&A and deployed. The author must also not keep up with modern frameworks; there are dozens of tried and true development frameworks that provide developers tools to create cross-browser compliant applications without getting into arcane details. To the commenter on the Agile not meeting FISCAM requirements; I don't think you have read it - the organization sets up the controls and policies it will adhere to and the Audit ensures the agency does what it said it would do. There is nothing in this document that states Agile development techniques can't be used. BTW, if security is important, these will show as use-cases, user stories, features, etc. to be implemented in the application; after all they are requirements. A "security document" is not going to make the application secure; only proper coding and configuration will do that.

Thu, Aug 13, 2009 Harold Stull DC

Many good points. If I may continue the Agile thread, there is one significant problem with this kind of development: it leaves little documentation. The Agile Manifesto puts software delivery first. Documentation and management are considered hindrances. I have worked with some of the earlier buzzwords, too. There are good points to all, but they have mostly fallen by the way-side. Agile will go too in the Government sector when many agencies fail the new FISCAM audits. This new standard for security audits almost forbids some Agile practices and requires standard SDLC and governance. Its a big document but worth a read.

Wed, Aug 12, 2009 peggy

Interesting article . . .

Tue, Aug 11, 2009

Follow up on 3, Developers don't bemoan when the project managment is able to run a nice fence around the requirements and only simple and quick and easy inclusions can be made, that maybe where most projects have problems. You must wrap up the project and move to production when requirements have been met and maybe one or 2 short follow up releases to plug up the holes. Thats it, no cyclical or enhancments unless there is a justified ROI(Get value from the App). There must be a good working relationship between developers and management and the less chiefs, the better.

Tue, Aug 11, 2009 Arty

With regards to Agile Development: This is a new buzzword for an old concept. We called it "Rapid Prototyping," and that was a buzzword, too. The idea is that, unlike building a bridge, software engineering acknowledges its use in a changing environment. The idea is to incorporate cyclic development with a pace comparable to the aggregate of change in the particular application area. Engineers constantly bemoan "requirements slip" and the idea that the world won't freeze while they take their time building a "perfect" application. By the time that happens, the world has moved on. Requirements have to reflect that fact just as they need to reflect the constraints of the technology and the needs of the user. AND, BTW -- none of that is static, so your meta-process needs to allow for constant drift and adjustment as you build your system. The alternative is stasis, and trust me, you wouldn't like it....

Show All Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group