How the FCC CIO Plans To Modernize 207 Legacy IT Systems

Lemeowski writes in with this interview of FCC CIO David Bray. "When David Bray took over as CIO of the FCC last year, he found the agency saddled with 207 legacy systems, which is about one system for every eight employees in the 1,750-person agency. Bray, who is one of the youngest CIOs across the federal government, shares his plan for updating those systems to a cloud-based, common data platform, that's "ideally open source." In this interview, Bray shares the challenges the FCC faces as it upgrades its systems, including keeping up morale and finding a way to fit longtime employees into his modernization strategy."

Comments

Good For Him

[rgbscan]

Good for him, he hit all the buzzword checkboxes. K street will have a lobbying job lined up for him when he's ready to golden parachute out of there.

Re:Good For Him

[plopez]

Youth is not a real asset here. He is going to destroy systems with years of business logic in them and try to replace all that work in a short period of time. Good luck with that.

Just another half bright kid who doesn't know what he has just proposed.

Re:Good For Him

[gstoddart]

Yeah, my thinking when someone talks about modernizing legacy systems is usually ... "Have you ever actually been on a project to do this?"

In my personal experience, the older the legacy system, and the more embedded it is in your business ... the harder it is to replace.

I've been on a few projects trying to replace 25-40 year old computer systems. And pretty much all of them have been epic failures because people woefully underestimate how much work is involved, and don't fully appreciate all of the things they haven't considered until it's so far into the process to be too late to fix.

It's an admirable goal. but usually proves far more complex than the people championing it realize.

Re:Good For Him

[gstoddart]

I am not disagreeing that maintaining the legacy system can be very expensive and a losing battle,

But, I've seen projects which run on for several years, and at ever increasing cost ... and sooner or later someone has to decide if they keep going or scrap it.

I've seen about 5-6 such projects get completely scrapped due to costs.

Because, and I have witnessed this several times ... the initial team guiding the project has the advice of someone who believes his pet technology can solve any problem. And the further you get into the project, the more you realize that pet technology can't even come close to doing the job.

I've seen one or two projects where within about six months, everyone except management (and the technology champion) have realized there is no way in hell the project can be done -- and then people start leaving to escape the fallout. Which then accelerates the rate at which the project fails.

And, very often, you realize the extent to which you would need to replace or retool another dozen things which integrate with the thing you're replacing --- and then you realize you need bout 10x more money than you thought.

Sometimes, you realize these things aren't just "dumb holdovers that nobody needs". Sometimes, you realize those things underly all aspects of your business, and changing them is almost impossible.

That's actually what I've seen more often.

I'm not saying you can't or shouldn't replace legacy systems. I'm saying sometimes companies discover it's a lot more expensive and difficult than believed, and can't justify the expense to keep trying.

Very often the person most loudly saying "we should modernize this" is the person who has the least insights and knowledge of the system being replaced, which means they might be talking out of their ass in terms of what is involved.

Re:Good For Him

[Matheus]

You are severely underestimating an organization's ability to apply band-aids when needed.

I'm in the middle (well towards then end) of just such a legacy replacement project. I can, without any hesitation, say this project is a success but the head aches we've dealt with are pretty severe and it took a great, well managed team, a solid couple years to get to a 95% point. The problem with legacy systems is not necessarily the errors in the code (of which there are plenty... can we say type UN-safe languages??) but the layers upon layers of process and paperwork and siloed domain knowledge that have been built up around the system to cover those bugs for *decades.

Requirements gathering is a fuzzy mess:
You start with the business and you better interview just about *everyone if you expect to get all of the edge cases the system will expect. Gather every tiny little requirement you can because at the end of the day *all of these little Easter eggs will be important.
You look to the original source code (assuming you still have access to it) to see what *it thought the business rules were and line that up with what the business thinks those rules should be. They will *not agree with one another.
You have lots of meetings to try to hash out what the rules really *should be and hopefully end up with an answer that everyone is happy with (including regulators if you're in a government office).
Than you develop the system and assuming you're being at least somewhat agile prepare for exhaustive labors every time the outputs of your system don't exactly match the outputs of the old system because even if the old system was wrong (which it was if you're doing your job right) you have to prove beyond a doubt that is the case before you can get past QA.
That pile of 500 reports the old system cranked out? Those are band-aids for bugs the old system had that the people "fixed" by reporting on the data. You will have to code the generation of a LOT of these only to throw most of them away when your code eliminates their need.
That convoluted process they want you to replicate? It is band-aid on band-aid on band-aid on band-aid on a system flaw that was never really diagnosed which you have now fixed in your reimplementation but still have to wade through how much of that process is no longer needed and convincing the stakeholders they really don't need to do it anymore because the problem is "fixed".

This is 1 system and you can guarantee all 207 will have the same headaches.

This is all "doable" but he really sounds like he has no clue about what it will take to "do" it. The mention of "cloud-based, common data platform, that's "ideally open source." also makes me want to shoot him and get started working on finding his replacement. Fuck your buzzwords and do your job. None of those concepts says *anything about the hard part of getting this done.

Re:Good For Him

[Last_Available_Usern]

Geez, who introduced a urine-based liquid into your corn-derived breakfast cereal?

Re:Longtime employees?

[MightyYar]

Maybe, but the legacy systems administrators are just high-tech janitors.

To the cloud

[jacobsm]

By moving everything to the cloud you're not eliminating problems, just making them someone elses problem, and enabling new ones to crop up.

Be careful of what you ask for, you might just get it.

Wow

[ThatsNotPudding]

Youth is not a real asset here. He is going to destroy systems with years of business logic in them and try to replace all that work in a short period of time. Good luck with that.

Just another half bright kid who doesn't know what he has just proposed.

Yikes. Proof that Ageism goes both ways.

Re:Wow

[houstonbofh]

Yikes. Proof that Ageism goes both ways.

Yeah, but the old guys have many years more anecdotal evidence showing they are right. :)

Re:What kind of "legacy systems" ?

[rickb928]

Where I work, we use a Wang system based on a Honeywell system to store and manage images. It's still state of the art, was when it was introduced, and is living on in emulated hardware that does, in fact, work very very well. Downtime is measured in single digit minutes per year.

It certainly meets the common definition of 'legacy'

People use 'legacy' to describe 'obsolete', 'expensive', or 'not new'. Wrongly in many cases.

Alas, it is popular to replace 'legacy' systems with new ones that the newer teams understand better and are more comfortable fixing. Note I did not say just 'understand'. Nor did I claim that these are 'better'. Just more comfortable.