There is little debate that the “Obamacare” rollout has been choppy at best. Regardless of which side of the political debate you fall, many of us in technology, CIOs and software executives alike, can learn from this highly publicized initiative as we approach the November 30th deadline. Development of new applications, especially web applications, is no longer just about the myopic focus on Design, Develop, Test, and Rollout. The successful development and deployment of these applications must have a holistic, information-driven approach, which includes the following four key processes:
- Application Quality Analytics – the constant tracking of the errors, exceptions, and problems that are occurring in each new release of the code.
- Application Performance Analytics – the real-time measurement of the performance of the application as the users are experiencing it.
- Security Analytics – the real-time information required to analyze and conduct forensics on the security of the entire application and the infrastructure on which it runs.
- User Analytics – real-time insights on which users are in the application, what pages they are viewing, and the success they’ve had in conducting transactions in the application.
Application Quality Analytics – Is it really necessary that in the year 2013, that development of applications still need to be 4 parts art and 1 part science? I’m sure that the Secretary of Health and Human Services, Kathleen Sibelius, wished it was more science when she testified in front of Congress about why the site was not ready. She had no real-time information or metrics at her disposal about the number of defects that were being fixed each day, the number of errors being encountered by users, the severity of the errors, and the pace at which these errors and defects were being resolved.
These metrics are sitting there in the log files (data exhaust from all applications and software components to track what the software is doing), and are largely untapped by most development organizations. Moreover, this data could be shared between multiple teams to pinpoint the root cause of problems between the application itself and the network and infrastructure on which it is running. It was so frustrating to see CGI (the contractor hired to build the application) and Verizon (the contractor hired to host the application in their “cloud”) passing the buck between each other in front of Congress.
Application Performance Management – Much has been made about the performance of Healthcare.gov. The HHS secretary even had gall to say that the site had not crashed, it was just “performing slowly”, while in the congressional hearing there was a live image on the screen informing users that the site was down. The site was down AND performing slowly because the site’s developers are stuck in a previous generation of thinking – that you can measure the site performance without taking into account user analytics. It’s not good enough to measure application performance by sampling the transaction response times periodically. Testers and managers need access to real-time information about each user, the session they were running, the performance at each step, and the outcomes (e.g. new plan sign-up created or failed, 5 insurance plans compared, pricing returned from 2 out of 3 carriers, etc.) along the way. Most monitoring tools look at just the application or just the network and infrastructure it runs on, and have little to no visibility about the outcomes the user is experiencing. Guess what? Most, if not all, of this information is sitting in the logs waiting to be harnessed.
Security Analytics – I appreciated when Secretary Sibelius was asked about what steps had been taken to ensure the privacy and security of the data that fellow Americans had submitted on Healthcare.gov. The reality is that most IT organizations have very bifurcated organizations to address security and application development. The old school view is that you put a web application firewall in place and you close down the ports, and your perimeter is safe. The reality today is that there is no perimeter. People have mobile phones and tablets and use third-party services to store their documents. Healthcare.gov itself is dependent on 3rd parties (insurance carriers) to provide and receive private information.
The most effective way today to ensure some level of security is to have a real-time security analytics and forensics solution in place. These solutions can scan every element of user and system activity, from – you guessed it – the log data, and determine everything from invalid logins and potential breaches to unauthorized changes to firewall rules and user permissions.
User Analytics – Ok, I get it, the Obama administration did not want to share information about how many people had signed up on Healthcare.gov for weeks. The argument was made that the accuracy of the data could not be trusted. Either it was a political maneuver or incompetence, but either reason is sad in the year 2013. And why do the White House and HHS have the right to keep this information a secret? The American taxpayers are paying the hefty sum of $200M+ to get this application up and running. Shouldn’t we know, in real-time, the traction and success of the Affordable Care Act? It should be posted on the home page of the web site. I guarantee the information about every enrollee, every signup – successful or failed – every county from which they logged in, every plan that was browsed, every price that was displayed, every carrier that’s providing quotes was AVAILABLE IN THE LOG DATA.
There has been a lot of coverage about President Kennedy recently and we are reminded that he challenged our government to put people on the moon in the 1960s, and they did – with a very limited set of computer and software tools at their disposal. I would ask the CIOs and software types out there, let’s learn from the Healthcare.gov rollout, and embrace a modern, information-driven approach to developing and rolling out applications. And President Obama, if you need some help with this, give me a shout – I’m ready to serve.