Modern software development involves a mind-boggling variety of moving parts. HealthCare.gov proves now we have to come back to basic project management.
Software development has come center stage in America due to discussions concerning the Affordable Care Act’s healthcare exchange website. It also has brought its share of drama, when Cheryl Campbell, senior vice chairman of CGI Federal, the prime IT contractor accountable for developing the web site, blamed system bottlenecks on work by another contractor.
Andrew Slavitt, executive vp of Optum/QSSI, the contractor in question, was probably more accurate when he testified to a home commerce committee that the true culprit was the complexity of the location. Lots of the critical components, which have been developed by multiple vendors, “were overwhelmed,” he said.
Ignoring the politics, the key is that modern software delivery is complex: Not just is the software itself complex, but so is the way it is assembled and built. There are layers of components and frameworks built by third parties, a number of whom and feature direct contact with, and a few you do not.
[ Nobody loves to admit his IT project crashed at the launchpad. Read Lessons For HealthCare.gov: Former DHS CIO Richard Spires Talks About Steps To Recovery. ]
To put modern software in context, today’s luxury car has nearly 100 million lines of software code running its climate control, transmission, and other systems. Compare that to the meager 24,000 lines of code that put a person at the moon.
We are absolutely within the age of software, or, as Marc Andreessen says, “software is eating the sector.” Not just has the sheer volume and complexity of the software increased, but in addition how that software is created. It is vitally rare for a brand new application to be written from the bottom up. Instead, it’s assembled from a mixture of frameworks, infrastructure, and services — and more to the purpose, it wasn’t written by your company or perhaps someone you recognize.
The reality of recent software is that this is an aggregation of cloth from a variety of sources, and relating to government software development, a lot of those sources are competitors, each with its own complex agenda.
What is worrisome is the undeniable fact that traditional software processes and supporting Application Lifecycle Management (ALM) software aren’t built to support this assembly-oriented approach. In reality, for many software organizations, the chance-management approach assumes that the software was written in-house or acquired from some key vendors.
The historic option to software delivery was to impose a consistent and defined process at the suppliers. That process had clear artifacts, milestones, and process gates that might allow people who use or build on top of the software to administer risk, schedule, and make sure that the consuming project will be ready for the software when provided. Ultimately, you trust the folk you already know, but you continue to provide them with a transparent process to aid avoid potential issues. Those processes tend to be lost as software is increasingly patched together.
Additionally, the supplier is accountable for providing software that was fully tested. When bugs are found, they must be addressed using an in depth and well documented process. It was often assumed, for schedule and budget purposes, that every one bugs will be discovered within one pass of the combination phase. But not every bug becomes evident during testing. And when it comes to the ACA website, most of the bugs weren’t discovered until the positioning was in production with the eyes of the realm on it.
Finally, the collaborative tools used to document and manage software development vary by supplier and tend to be different from those utilized by integrators. This often ends in an extended trail of inconsistent artifacts — from defective spreadsheets to project schedules — complicating collaborative efforts.
The HealthCare.gov website disaster is probably essentially the most public reminder yet that modern software isn’t supplied by a number of key vendors. Rather, it’s the collective work of a nearly mind-boggling array of businesses, individuals, vendors, and open-source projects.
Additionally, the issues being solved by software today now not lend themselves to linear or sequential process models, where software is designed after which used. Instead, modern software development requires frequent delivery, rapid feedback, and the chance for change.
Software has moved beyond carefully managed and regulated supply chains, to something that resembles an environmental ecosystem where the tip-users must look ahead to changes and reply to them. Traditionally, it truly is possible to regulate a supply chain, but with ecosystems it’s good to observe and respond. You may never control an ecosystem. But that you would be able to adapt to its characteristics.
In the ACA website example, the correct result would have come from a project manager viewing the total software delivery lifecycle and more fully engaging the participating vendors, including the final customer. This feedback would have provided the project owners with better information on which to make decisions — and would have delivered software that was not the source of widespread embarrassment.
Dave West is chief product officer at Tasktop Technologies. He’s a frequent speaker at industry conferences and a widely published author of technical articles, including a book on object-oriented analysis and design.
Moving email to the cloud has lowered IT costs and improved efficiency. Discover what federal agencies can learn from early adopters within the Great Email Migration report. (Free registration required.)
More Insights