The Real Problem with Healthcare.gov

The biggest story in IT this year is without a doubt, the rollout issues surrounding Healthcare.gov - a.k.a Obamacare. The story is both bizarre and quite familiar at the same time and does represent perhaps the first time that national politics has been so laser-focused on an IT project. Many people who have been introduced into the world of IT through this might think that the saga of Healthcare.gov is unique or somehow unusual - well, it is isn't. By many accounts, more than half or more IT projects fail - this is consistent across government and industry (there have been spectacular failures in both arenas).

As the media circus has picked up steam over the past 2 weeks, we've been treated to a Congressional attempt to hire John McCaffee and Edward Snowden's offer to fix the problem because he knew what it was. We're just waiting on Miley Cyrus to weigh in...

that is, if you can sign on...

The figure associated with the project so far - (approx $170 million) is not in fact that large for a complex IT project. Just last year, the AF Logistics ERP project, ECSS was cancelled after $1.2 billion was spent - no one seemed to notice it (outside of interested circles). The director of Health & Human services has held herself personally accountable in multiple apologies so far for the various problems associated with the site; which seem to include the following:

• An inability to handle the anticipated user traffic (multiple site crashes)
• An inability to generate user logins
• Errors which involve policy termination
• password reset failures
• Failure on the underlying data integration hub
• Multiple page not found related errors
• Various problems surrounding form processing
• Data center crash

There have been any number of armchair quarterback giving simple fix suggestions to the problem - as with most similar situations such advice is generally less than useful. The most common one I've seen relates to the need for the government to use open source coding practices (which it was in fact doing with code up on github). So, let's be clear - for projects like this - there is not now and never will be silver bullet fixes - they are too complex. It's also important not make knee-jerk comparisons to commercial solutions either. I've seen a number a quotes trying to compare Healthcare.gov and Amazon.com; Amazon spent more than a decade perfecting their technologies and likely invested several billions of dollar in it. From news accounts, it seems as though coding for Healthcare.gov only began sometime early this year.  

So what happened? Well, I've only got clues from various articles but several key elements seem to stand out:

1. Somehow, the team seemed to have made a decision regarding who should enroll and when didn't occur until very late in the game (when isn't exactly clear).
2. That enrollment capability seems to be tied to Oracle Identity Management suite - which is a very complicated tool and requires a significant amount of engineering (custom code, performance considerations, etc.).
3. For whatever reason, the development timeline got pushed to the right but the rollout deadlines didn't change. 
4. There seems to be some lack of clarity as to who was the integrator (the prime vendor or government agency).
5. The contract was issued in December of 2011, but requirements were delayed - and requirement changes were being made up through this September. (very common story actually)
6. There were a great number of moving parts - more than 50 contractors. This may also imply an overly complex architecture.
7. It appears that there was an excessive amount of code involved - which begs the question - why wasn't more of this handled with prepackaged (portal) software?
8. The prime vendor didn't seem to have had experience architecting portal solutions with the type of volume that would clearly be associated with Healthcare.gov. 

John McCaffee is not the tech support we need to solve the Healthcare.gov mystery

Unfortunately, given the nature of the problems, it seems as though fixing Healthcare.gov while doable may take longer than is being promised. Sometimes, throwing extra money and attention towards a problem at this stage has the unwanted effect of making things even more complicated. Here are some suggestions though that may help alleviate the current crisis:

1. Eliminate the need to register just to shop for plans.
2. Refine project roles and responsibility immediately - choose / assign a lead integrator.
3. Switch to incremental roll-outs for actual enrollment (e.g. shopping available nationwide by enrollment opens up state by state).
4. Assign tiger teams per critical problem (e.g. one for identity management, one for the data hub, one for performance engineering etc.)
5. Do not oversell the fix timelime; in other words don't promise something you can't deliver - extend the overall compliance timelines in order to give the project time to catch up. 

Copyright 2013, Stephen  Lahanas

#Semantech

Read More

3 Common Cloud Challenges

Like all new technology trends, Cloud Computing brings with it both opportunities and challenges. Unfortunately, the current hype cycle across the IT industry hasn't done the best job of defining either very well (at least not yet). Most of the information out there tends to portray the Cloud as a the ultimate (latest) silver bullet technology.

So, is it?  From my perspective - it could only be viewed as a a conditional, evolutionary improvement - and only if - the organization adopting it fully understands the implications of the technology. Which brings us to a discussion of common Cloud challenges...

Before we jump into that though, let's quantify what we're talking about a little better. There are several types of Cloud-related capability that an organization can pursue; these include:

• Construction of one's Clouds
• Exploitation of 3rd party Clouds (Amazon, Rackspace, Google etc.)
• Adoption of (limited) 3rd party Cloud services or software (SAAS)
• or some type of Hybrid solution

We shouldn't get too bogged down in the differences between Infrastructure, Platform and Software as a Service or Public versus Private Clouds at this point because the challenges we're examining today cut across most of these distinctions. 

Common Cloud Challenges:

1. Proliferation and Governance
2. Automation
3. Integration

Now if any of these seem familiar, they should. These are all challenges that first became apparent during the explosion of  "legacy" data centers for distributed computing back in the 90's and early 2000's. Let's look closer...

Proliferation: Just because you can provision a completely new environment rapidly doesn't mean that you really need to or some cases even should. The model that Amazon uses to serve millions of different customers shouldn't be the same as the model you use for a single enterprise. The more environments (virtual or otherwise) that you have to create, the more you have to manage. Growing these exponentially is a particularly bad idea (although knowing that you can is somewhat cool). This is where Governance should come into play. However Cloud Governance is a practice that's running about 2 to 3 years behind deployment and provisioning - not good...

Automation: It took about 15 years to begin to get the traditional data centers running smoothly - much of that was due to the introduction of network and system administration automation tools. The explosion of Cloud solutions over the last 3 or 4 years has led to the creation of mountains of custom code and glueware to help run IAAS, PAAS and SAAS solutions. This is a serious problem and one that can be remedied soon given that nearly every major automation vendor has now re-architected their solutions for Cloud environments.

Integration: The last issue bleeds into this one. What happens when you introduce a Cloud, or multiple Clouds into your organization? Does all of the legacy capability go away? How do you control data, security, performance and interfaces across hosting platforms? Integration is the number one challenge facing Cloud adopters today and will remain so for quite some time. There is only way to solve the Cloud Integration dilemma - that's through the introduction of comprehensive Cloud Architecture. We will define that in our next post...



Copyright 2013, Stephen Lahanas

Read More

Revisiting Agile Business Intelligence

The other day the TDWI (the Data Warehouse Institute) sent me a brochure highlighting Agile BI workshops and seminars. Here's how they define it:

"Agile business intelligence addresses a broad need to enable flexibility by accelerating the time it takes to deliver value with BI projects. It can include technology deployment options such as self-service BI, cloud-based BI, and data discovery dashboards that allow users to begin working with data more rapidly and adjust to changing needs.

To transform traditional BI project development to fit dynamic user requirements, many organizations implement formal methodologies that utilize agile software development techniques and tools to accelerate development, testing, and deployment. Ongoing scoping, rapid iterations that deliver working components, evolving requirements, scrum sessions, frequent and thorough testing, and business/development communication are important facets of a formal agile approach. "

Now I found this very interesting given it's something I have been advocating for some time. Although, the definition above left me a bit concerned that what in fact is being suggested is merely the adoption of Agile methodology with minimal regard to Business Intelligence architecture (we've been given a laundry list of related solutions with not clear idea of how they integrate). More importantly, the heavy focus on the development methodology leaves out what we considered the most important aspect of Agile BI (when we first presented this back in 2007) - the end user and how they are integrated into the development process and /or how they drive the very structure of BI by defining it "on the fly" themselves (this goes beyond data discovery).

We presented this in the Fall of 2007 in Chicago

Agile BI must encompass a wider architectural approach...

Since 2007, a number of tools have come out that specifically answer this end-user consideration. A good example of this is Tableau (which markets itself as "visual analytics for everyone"). So on the one hand it is both gratifying and exciting to see that Agile concepts are being extended to Data Architecture and that new products are being introduced to help bridge the gap between IT development and IT capability - on the other though, it is disturbing to see that they haven't quite merged yet in the data industry.

Why is this important? Well, because when viewed out of context (of each other) the value proposition for these innovations diminishes significantly. Data Architecture, BI Methodology and the expectations for how users will exploit data are part of the same problem space...


Copyright 2013, Stephen Lahanas

Read More