What Do Software Analytics and Your Doctor Have in Common?
Software analytics, like the healthcare industry, must take a look at business-focused outcomes in order to make accurate conclusions.
Join the DZone community and get the full member experience.Join For Free
As it turns out, plenty.
Recently, the U.S. government has implemented healthcare reimbursements based on the outcome of medical treatments, rather than a traditional fee-for-service approach. These performance-based programs are designed to improve healthcare quality while lowering treatment cost. It’s this outcomes-based approach that Fortune 500 companies are considering as a way of reducing ADM costs while improving software quality.
For instance, if you are working with a service provider, quantifying desirable outcomes and the steps that the provider will take to meet those outcomes has always been a desired goal; SLAs are built on such thinking. But too often, there’s a misunderstanding about the difference between output-based pricing and outcomes-based pricing. There is an important differentiation here: one rewards the work done; the other (which is becoming more and more prevalent) rewards the positive results of that work.
Bob Krohn, a partner at the ISG consulting firm, talked about key success factors in driving toward an outcomes-based approach during a recent webinar. An essential factor, he said, was to define SLAs in business terms, using software analytics to measure output while monitoring the effectiveness of business processes. Using the healthcare analogy, he said an SLA that’s successful might result in a healthcare organization processing a certain percentage of healthcare claims without any errors during a predefined time period. Structures should be set up to drive desired behavior, but not be punitive, he said. Visibility can be tied into the measures of specific processes to identify risks before they enter production.
Well, what holds true for healthcare and what holds true for this kind of approach is also applicable to the entire issue of software quality. Too often, companies think about measuring everything except the software they use. That can increase the potential risks to the application’s performance, security, and increase the risk of outages. Bad software can cripple a company.
Software Analytics is the intelligent use of insight into the state of an application to improve IT investment decisions, operational performance, and customer outcomes. Generating software metrics involves the analysis of the software artifacts created or managed by a development or maintenance team. It includes insight about the structural quality of application, including metrics, and functional or technical size.
As it happens, there are industry-standard measures of what makes good software. Aspects such as transferability, changeability, robustness and performance efficiency can help prevent reduced output, late delivery of new features, the inability to test code updates, and even help make applications more resistant to security threats.
Again, these may be technical concepts. But if you apply them against business-focused outcomes, and use the results to benchmark how a given application is performing against industry standards, you’re far more likely to come up with results that can be measured against the bottom line.
Adopting an outcomes-based approach toward application quality can also increase a company’s agility, even as it reduces its overall costs. And that is precisely what the C-level is looking for these days.
There are a lot of experts will tell you that healthcare organizations have traditionally lagged behind other markets in the adoption of new technology and new approaches. But this is one case where other companies may do well to look at the successes that healthcare organizations are driving toward by focusing on their overall business goals and ways that they can quantify specific results.
Listen to the whole presentation here.
Published at DZone with permission of Frances Lash. See the original article here.
Opinions expressed by DZone contributors are their own.