Custom Software to Vendor Solution, job security?

July 6, 2013 6:23 AM

I work for a large public sector institution. We have about 30 developers. Our code base is about 2 million lines of code. It's been custom developed over about 12 years. New CIO wants to gradually replace it all with vendor solutions, 3rd party apps. Reasoning being is that they want their apps to do more and more and feel 3rd party (SAP/PeopleSoft/etc) can do it faster. They state that they won't need to let anyone go, since the new system to replace this one will be doing so much more there will be a need for programmers to do an maintain integration code. I'm a developer, what is the end scenario here? More developers? Less? All outsourced? Are there case studies of similar transitions?
posted by anonymous to Computers & Internet (7 answers total)

In the short and medium terms - and assuming she gets everything she wants - I agree with your CIO. All the work of integration will raise the status of developers in your organization, all things equal.

Eventually, yeah, I'd bet that headcount in your part of the organization might decrease. But it doesn't seem like something to worry about in, say, the next 5 years (large orgs can be incredibly slow at stuff like this; large public sector orgs especially).
posted by downing street memo at 6:47 AM on July 6, 2013

Part of the rollout of most major enterprise software packages is to do process re-engineering to make sure functional processes that are to be supported by the software follow generally accepted accounting practices and standard business document flows, as outlined in ISO 9001 and subsequent standards revisions. The idea is that by auditing organization process flows, and changing them to conform to the standards that commercial software is increasingly designed to support, you not only eliminate the expense and operational issues of developing custom software, but you better enable the organization to inter-operate with both vendors and customers. And it is a process that can be effectively managed as a project structure, with a definite beginning, and time certain end. Once implemented, no one in the right minds wants to extensively modify and support commercial software; part of the justification for going to commercial packages, is to ensure that upgrades and maintenance become a vendor responsibility, for which the organization can always find competitive sources. Customization defeats or greatly complicates that goal, and will be resisted by competent management, and vendor organization, with a passion.

Following that philosophy, as do SAP/Oracle, Peoplesoft (Oracle), J.D. Edwards (Oracle), SAAP and others, you can expect your organization to rapidly shed software developers during implementation, in favor of business analysts and implementation configuration specialists (usually supplied by the software vendor or third party implementation specialist). There may be short term work for developers doing legacy data cleaning and conversion, or writing short term custom interfaces to SAP/Oracle functions from legacy software modules, but frankly, it's generally easier and more effective to pre-train operating staff extensively on a pilot system, do a legacy data conversion/load on the pilot system, and then have a short term functional test, as the prelude to a system cutover. Even if you have to redo the pilot test phase a few times, once you've got signoff from the operational folks, you typically do a final data conversion/load onto the production system in a very short time (over a weekend). Thereafter, support for the go-live phase is provided by the software vendor's implementation team for a short period (typically from a week to a month or two), and then the project wraps up. These days, few organizations are so deeply manned that operational folks can afford to parallel operate on both legacy and new systems for any length of time. Rather than put forth the effort to drive dual parallel systems for weeks or months, most operational folks would prefer just to rip off the bandage of system conversion at once, and fight through any business process reorganization issues on the future side of the system changeover.

And really, if the organizational staff understand their business and processes, it's the lowest cost, lowest risk strategy, too.
posted by paulsc at 7:10 AM on July 6, 2013 [3 favorites]

With a large legacy base, it will take them a while to replace it all - if they ever do. Meanwhile, if you do stick around, you'll be acquiring experience with the new package, whatever it is, and that may make you more marketable in the future. The question is, how do you want to market yourself when (not if) you end up looking for another job?
posted by mr vino at 7:25 AM on July 6, 2013 [1 favorite]

Nthing what others have said, esp. paulsc. I suspect that your CIO is also probably telling the truth--they don't have plans to actively let anyone go. However, my guess is that, they won't replace anyone who leaves either. And so you'll ultimately see a reduction in the overall number of developers as well as a shift in the skill set of (the few) new people they do bring on-board. As in, no new jobs in software development, and any new job reqs will be in business process/systems integration/vendor app tech support.

IMO, if you're interested mainly in software development rather than systems integration, you might consider starting to plot your next move. You've probably got a 18 month - 3 year window, depending upon how well the transition is managed and how quickly your fellow developers decide to bail. No matter what you choose to do, sticking around for a while will, as mr. vino says, give you the chance to acquire some new skills, as well as see how these kinds of transitions can be managed/mis-managed which is highly worthwhile in case you ever need to make this kind of call in the future as a software architect or software manager.
posted by skye.dancer at 7:57 AM on July 6, 2013 [2 favorites]

I work for a large public sector institution, and we moved to a large vendor database/ enterprise suite. No developers have lost positions, some departments had developers who were moved to IT. There have been some losses due to attrition, as we don't pay as well as private sector, and we have trouble attracting great candidates. There are still lots of customized reports and some customizations. It took at least 3 years before all of the legacy processes were closed out. There are still lots of developers for integrating specific apps, and developing apps for which we have found no vendor substitution. I agree that you have the opportunity to develop skills that are and will be in demand. The newer demand is for data mining specialists who can not only pull data, but who can look for useful information that can be pulled, and who can present it well.
posted by theora55 at 8:57 AM on July 6, 2013

"... The newer demand is for data mining specialists who can not only pull data, but who can look for useful information that can be pulled, and who can present it well."
posted by theora55 at 11:57 AM on July 6

If your organization installs a capable BI (Business Intelligence) solution, like Cognos, and/or a BA (business analytics) solution, on top of the main enterprise/transaction/database system, a lot of your reporting and data mining jobs will convert, more or less automatically, if they are currently written as SQL queries. If not, they can soon be recreated, tested, and automated as necessary, not by developers or DBAs, but, more and more, by non-technical personnel working with business analysts or implementation teams.

The better commercial databases have greatly improved their query optimizers in the last 5 years. With processing power, memory and storage so cheap now, query optimizers run all the time now, as system processes, and installation of BI or BA applications generally gives you fairly amazing query optimizer extensions that literally rewrite bad queries on the fly, for optimal performance. Frequently used data access paths, indexes and files are all shadowed and maintained automatically, and resource allocations are changed automatically as use patterns change. The backup/restore applications of better packages also run in cooperation with the BI/BA packages, so that backup/restore operations are basically continuous with operations in many business shops.

The days of the specialist DBA or SQL guru are rapidly coming to an end in big organizations, in favor of specialist personnel like quants. But I agree that, if you work for a governmental entity, you may find that your implementation plan is 2x or more in length than most commercial projects (which are generally complete in under 18 months), and that length of time may offer you extended employment and training opportunities. But at the same time, the biggest vendors, like SAP/Oracle, have all been burned enough times in recalcitrant government implementation situations, that they are pretty hip to the usual tactics of "delay by review/test." They know that implementations that drag out over years cost a lot, and rarely deliver the financial benefits originally sought when the project was authorized. Moreover, with thousands of successful client installations under their belts, they are going to be contractually picky about implementations which require retaining custom legacy systems, or that call for implementation methodology that varies much from usual commercial schedules.

"Are there case studies of similar transitions?"

The world is lousy with ERP case studies, many even sector specific, which can be really educational in comparative benchmarking your probable planning. Start here, sign up, and read, read, read.
posted by paulsc at 10:53 AM on July 6, 2013 [2 favorites]

ask yourself: does a new CIO actually know anything about the quality of your codebase and what it will take to extend it? switching to a vendor is a time-tested political strategy for a CIO which shifts the organization center of gravity away from the people who built the code... at the large public sector institution I was employed at, the move to PeopleSoft, after some misleading personnel directives, eventually resulted in the consolidation of developers to a location hours away that no one wanted to move to and some explicit downsizing.

the bottom-line is that switching to a vendor likely has little to do with the state of your codebase and a lot to do with organizational politics. ask yourself what the politics of this decision are and that will tell you the future of your job. the CIO could very well be telling you that this is about feature implementation, but having talks with higher administration about cost savings.
posted by ennui.bz at 4:48 PM on July 6, 2013 [2 favorites]