Slashdot Mirror
How Overhauling IT Was a Life-Saver For the American Cancer Society
Lemeowski writes: American Cancer Society CIO Jay Ferro lets readers peek behind the curtain of the nonprofit's IT organization, saying that when he took on the role a little over three years ago, the nonprofit had 12 different divisions — each with its own independent IT set-up and more than 600 independent applications in its portfolio. In the past three years, Ferro has aligned the entire IT organization into one global entity, consolidating dozens of data centers into three; increasing spending on strategic projects from 5 percent to 40 percent, and reducing 600 core systems down to fewer than 200. His journey is a powerful reminder that while streamlining IT can often be painful upfront for IT managers, the payoff for sticking with it, especially for nonprofits, can feed into saving more lives.
Yeah, similar to my experiences. As a software development contractor, I see a lot of management that care more for office politics, and who's toes they can stand on next, whilst playing the game of "hot-potatoe" when it comes to blame. Not my department! (points to next manager, as they're all stood in a circle).
Often they're looking for career progression, and not caring about the software development changes or support changes, but more about the "is it done yet?" - meaning, forget about it being right, refactored, consolidated, any kind of documentation, etc, and testing is assumed that the moment code is up and running, that it's fixed. So they ask you "how you're getting on" - and the only thing word they hear is "working", and they report that. Then when they find out it isn't, they immediately pile on the pressure. "you told me it was working!" - "you better get it done, quickly!, and get it in!" (meaning source control and released) so as to cover up their lack of understanding.
I've actually confronted a number of project managers, and their managers on such issues - even taking it as high as contacting board members through email (risking my contract!) to tell them they've got a communication problem. Once they hear this, I'm shuffled into an office for a long chat, where they say they're aware of, and working towards improvement, and it just so happens the software developers are always the last department to see these changes filtering in from "above".
Once I suggested they go and visit a place I previously contracted at, as they were actually a supplier - making some excuse about a project they could work on jointly, and learn the way they develop, thus, bringing their style of project management in house.
I ended up with a previous work colleague contacting me asking who the hell xxxx was, and so it seemed they may actually of listened to me. Whether that brought about positive change, I don't know. But the moral of the story is, managers love to talk, and pore over financial figures, but don't hear you when you talk about technical debt, need for refactoring, or consolidation, or offer new ways to do things that could prove beneficial. They only hear "risk". - and managing that doesn't seem appealing when they don't know that you're talking about.
As far as I can tell he created a single point of failure, reduced diversity and thus resilience, and instead of getting a cost advantage, it cost more.
And how did you determine that? 200 servers, 3 datacenters, if you can consolidate all your stuff onto 66 servers in each datacenter, say 22 clusters of 3 with global routing (3DNS or something similar) so every datacenter is "live" with a portion of the traffic, clustered DBs between datacenters, etc, you could have excellent redundancy. And if you replaced 600 older servers with new big honkin servers you could have even increased the capacity.
One would hope that the American Cancer Society would, at least, be an organization that understands that uncontrolled proliferation can be seriously detrimental to an organization; and that sometimes substantial resection, however unpleasant and expensive, is the best available course of action.
It's a lucky coincidence that that applies to IT systems as well!
Yep, I had a very interesting talk with my wife's friend.
She's an accountant and she was just complaining about IT.
So I talked to her about our side, and it's amazing the disconnect there.
We talked and I mentioned how every IT project needs a maintenance budget. You need knowledge retention in case the service needs to be updated in the future. You need someone to support it... You know, just like any other project. You wouldn't build a washroom and budget someone to clean it.
So she asked, well why don't you include that in your estimates? So we can have proper costing for the project.
Then I thought about it. There is a huge gap in accounting and IT. In IT, we often view accounting as something in the way. Stupid time tracking software. Bah, I'll just charge all my time to my assigned project. I have to provide an estimate. I'll just provide an estimate for the development. It's not my job to think about knowledge maintenance or operations...
Now of course the average IT person should not think about this, but the upper IT folks definitely should by setting up the right groups and proper leadership on how projects are structured. It's their job to get the funding so to speak.
It's not so much a problem that all the heads want to know is budget, on time...
It's largely that IT accounting is very poor to not account for all the costs. And we're so used to delivering something even if it does not account for maintenance that they get used to it.