The Economics of Web Service Development
The financial consequences of your selection of software, hardware, and technology are often dwarfed by your decisions about the other component of every computer-based solution -- that is, people. In order to have a fairly concrete discussion of the roles people occupy in software development, I'll cite specific technologies such as web services and PKI; a specific industry -- healthcare; and a specific government regulation, HIPPA.
Management needs to be able to plan and control the activities of the organization. At the same time, people run organizations -- be they management, project managers, or developers -- who can perform with higher or lower levels of efficiency, creativity, and job satisfaction, and each of whom is required to make choices.
This article will discuss the economics and management of creating and later aggregating a new web service, from the perspective of people with different roles who contribute to the final outcome.
I'll also cover other related topics: how you might go about choosing which web services app(s) to develop, when resources are not available to develop all that have been requested, and the cost of complying with very recent federal regulations.
I've chosen the healthcare industry in general and hospitals in particular to provide a laboratory for studying the economics and management of software development (and deployment). Whatever your industry, you'll find some or all of the problems you face in the following sections. Hospitals often have many departments that are not managed centrally, with each department providing a unique solution, and few of them connected together.
Today their solutions are implemented by a mix of modern (web-based technology) and legacy (mainframes or client/server) systems. In addition, the hospital's internal data infrastructure must interact, subject to federal regulations, with those (often very different) of external enterprises such as insurance companies or governmental and legal entities.
Enter the patient: he or she will often go to several hospital departments for his or her treatment and have to deal with these same insurance companies or governmental and legal entities, independently of the hospital's own exchanges with them. This is a complicated system, even under business-as-usual circumstances.
In the next few sections of this article, I'll give an overview of the hierarchy (from developer to senior management) involved in the creation of a new web-services application. Following that, I'll discuss some of the main issues confronting this hierarchy, both its individual members and the entirety.
Figure 1 shows the players, some of their responsibilities, and some of the hard-to-measure parameters that characterize them. While nothing in my discussion is uniquely relevant to web-services development, this relatively new technology has appeared at the same time as the arrival of a remarkable array of other new technologies and, also, changing economic conditions. As a result, web services is a prime candidate for the issues that I'll address below.
What's the Problem?
Web services is a new paradigm that organizations should use to develop new applications only after rethinking their business model. This is where the business analyst comes in. Many software projects are considered failures because they do not actually solve a valid business problem or have a recognizable return on investment (ROI).
Why spend money building a system to automate a business process if the total cost of ownership is greater than it would have been had no system been built at all? Otherwise, software engineers may end up focusing their efforts on solving technical problems that ultimately do not address the original business problem. You need to be cautious about applying new web-services technology to your old problems.
For example, even though you have the ability to put wrappers around existing applications and reuse existing functionality, you should do so only when doing so saves time now, without creating additional costs later. Many development tools simply wrap existing application objects that were never meant to be exposed as public APIs. Doing so can reveal internal dependencies and make it very hard to change these interfaces over time.
And, in your rush to exploit the ease of interoperability afforded by web services, there's an increased danger of exposing yourself to possible legal liability, especially when expert systems or fuzzy logic are involved.
An early expert system developed at Stanford University School of Medicine to diagnose and recommend treatment for certain blood infections was never actually used in practice even though, in tests, the software outperformed many clinicians. This decision was made for ethical and legal reasons related to the use of computers in medicine (if it gives the wrong diagnosis, whom do you sue?)
The purpose of web services (or any other technology) is to improve the quality of service offered by an institution and, at the same time, when possible, to reduce costs. In some cases, the quality of the service can be related directly to a dollar benefit; in other cases it cannot. For example, what dollar value can be placed on the reduction in waiting time at a hospital emergency room? Yet the decision regarding the resources to expend in providing the improved service should be made primarily on the basis of some measure of performance.
In making such decisions, management often must choose which project to undertake from a list of them competing for the same limited investment dollars. Here's where "opportunity costs" are a factor: the winning project chosen by management must generate a rate of return at least equal to the economic return foregone from deferred investments in the losing project(s), plus the cost of implementing the winning project.
But, "opportunity cost" is hard to measure. At the same time, "opportunity cost" is important because it affects an organization's performance far out into the future, which also makes it hard to measure. Finally, cost estimates based on accounting data -- which record actual current or past costs and are thus historical -- must therefore be considered as only first approximations to the relevant costs in managerial economics.
Decision tree analysis is a decision-making tool that should be used, either formally or informally, for comparing the opportunity costs of different proposed projects. This tool provides a systematic framework for analyzing a sequence of interrelated decisions that may be made over time. It clarifies choices and risks and the related benefits of long-term investment alternatives. In Figure 2, square nodes indicate the decision points and round nodes indicate the chance event forks.
Since all decision making is about the future, which nobody can predict with certainty, guessing probabilities (risk) is an important part of the decision-making process. But be mindful that your chief financial officer will likely see the uncertainty surrounding the decision you make in a much different light than you. We aren't really bad at estimating risks. What we are really bad at is enumerating all the assumptions that lie behind our estimates.
After creating a decision tree, managers (assisted by a financial officer when necessary) may use the data it contains to calculate Net Present Value (NPV) -- the difference between the cost of an investment and the return on an investment measured in today's dollars -- or other like determinants of ROI. The article Web Services Return on Investment introduces this subject. Note, however, that building a decision tree and calculating NPV before management decides whether to undertake a proposed project -- without accounting for speed of rollout, system adoption rate, and the like -- can lead to an unexpected outcome.
And, the drawn-out process of "proving" value before implementation is the wrong approach when considering small projects. That's because a low-cost trial can more easily and accurately forecast the outcome. After all is said and done, the best choices about which project to undertake are sometimes made by experienced managers with successful track records, based as much on instinct and knowledge of their organization's human assets as any formal, quantitative analysis of the many variables involved.
Pages: 1, 2