Microsoft Amalga Pricing and Licensing

Several readers asked to comment about the pricing structure and Total Cost of Ownership (TCO) for Amalga (aka, Azyxxi). I am still in pricing negotiations with Microsoft and of course need to respect the confidentiality of those discussions, so can't go into any detail, but will offer a few general thoughts, all of which I have shared with Microsoft.

Utility vs. Legacy Pricing Models: Unfortunately, I believe Microsoft is missing an opportunity to establish itself as a forward thinking leader in a new vertical, with a new product-- a prime greenfield opportunity for innovation-- by offering a traditional, legacy licensing model for Amalga. I have been encouraging them to offer a utility, pay-as-you-consume model which, I believe, would ensure more, not fewer customers. The licensing model they are offering now is very typical of transaction systems-- i.e., big up-front fees with smaller multi-year commitments. However, Amalga is more akin to a business intelligence tool than a transaction processing system, therefore, predicting the total adoption rate is very, very difficult for Amalga. The scope and adoption rate for transaction systems, like a PACS, EHR, or ERP system, are relatively easy to predict-- count the number of users and divide by the length of the implementation plan. The implementation timeline for transaction systems is usually driven by very clear organizational goals, i.e., "At least 90% of our employed physicians will be using our EHR within three years." For BI tools, counting "users" is very tricky and full of uncertainty and organizational cultures are much less likely to establish corporate goals around the adoption of a BI tool, so committing to a multi-year adoption rate in a high-dollar contract is risky business. Amalga and BI tools are perfect candidates for utility, Software-as-a-Service licensing.

Licensing Costs vs. Solution Costs: Though I see signs of awareness and change, Microsoft is still selling software licenses vs. total solutions. CIOs are left trying calculate the true Total Cost of Ownership-- comprised of hardware, software, implementation services, and support services. In my negotiations with Microsoft, offering a total solution cost for Amalga has not come naturally for them, but we are making progress.

Build vs. Buy: We are building an Enterprise Data Warehouse (EDW) at Northwestern and making great progress (keep my fingers crossed). Since the project started 18 months ago, we've spent only $1.4M on everything-- hardware, software, and labor-- and we've been generating useful analytics and other unique services from the EDW for at least 6 months. Recently, and into the foreseeable future, we will be focusing on developing the tools to easily interact with the content of the EDW. These tools, I believe, will soon rival and potentially surpass much of the functionality of Amalga. In my discussions with Microsoft, our strategy is to plug the Amalga application layer into our existing EDW data content layer-- but my EDW development team is making such great progress, building lean applications over the top of the EDW, I'm beginning to see less and less of a role for Amalga. At this pace, our total EDW "Build" costs will be much lower than the software licensing fees alone for Amalga. That said, Amalga still offers a much richer user interface than anything we will develop in the near future, but that rich user interface is less valuable for Northwestern where we already have a large amount of data integrated in our EHRs-- Amalga's strengths are best revealed in organizations with many disparate clinical diagnostic systems and no EHR.

People are Buying: Yesterday, Microsoft shared the names of several new and significant customers for Amalga, all of which will soon be announced publicly. Despite my reservations about the licensing model and total cost of ownership, other CIOs seem less concerned, and at the end of the day for Microsoft, paying customers definitely trump Dale Sanders' Quixotic opinions. ;-)

The CIO's Role in Healthcare Economic Reform

First, I want to recommend a book--Nudge-- for everyone in health care, especially CIOs. There are several elegant themes in the book, but one of the most pertinent is: If you simply expose people to data about their behavior and within a relevant context, you can often times "nudge" them towards a desired new state of behavior, without the need for a complicated, onerous, process improvement campaign... which usually nudges people away, not towards, the desired behavior. For example, the authors write about a campaign in California in which a utility company exposed data to consumers about their energy consumption as compared to other consumers in their neighborhood, including the lowest energy consumer in the neighborhood. Over time, the entire neighborhood reduced its energy consumption, including the lowest consumer, thereby establishing a new and constantly improving benchmark. Awesome. There are ample opportunities for us to leverage our data in health care to nudge better behavior, even if we can't completely overhaul the entire system.

Second, let's assume a few things for the sake of discussion:

1. Economics and Quality: Health care quality of care in the U.S. will not change significantly unless the economic model of health care changes to one which financially rewards physicians and hospitals for patient health vs. patient volume.
2. CIO Influence: Health care CIOs don't alone have the influence to radically change the economic model of health care.
3. Costs are Verboten: Health care is the only service-based business in the U.S. in which the service is provided without any discussion of the scope of costs during the course of the business transaction between the service provider and the consumer. In other words, neither the physician nor the patient have a clue about the true costs of care to the overall system of health care. In fact, discussions of costs prior to treatment are avoided like the plague.

I wrote an article for last Winter's edition of the HIMSS Journal which outlines the things which we can do as CIOs to help nudge the economic model of health care towards something more sensible. If you can afford it, do the right thing and pay for a subscription and download it from HIMSS. It's available here:  Winter 2008 JHIM.  If you don't have access to HIMSS archives, there's an interview here: Sanders' interview, CIO role in healthcare economic reform.

More on SOA in Healthcare

A reader commented: "In a future post, could you consider reflecting upon your reasoning for a "buy and develop" approach, the principles you use to govern this, and how you keep the vendor software/services/APIs and your own in-sync? Also, do you see this as a fundamental shift for all health care organizations, or only the largest?"

Differentiating Through "Buy and Develop": Although the key differentiators between organizations will always boil down to people and culture, it's fairly clear that information technology in the hands of great cultures can change the world. The effective use of IT is clearly an opportunity for all companies to differentiate themselves. Health care is nearly a green field IT environment in this regard, but if you imagine a future world in which we all deploy the same commercial-off-the-shelf (COTS) products, e.g., Epic, in more or less the same fashion, there is very little room to allow for the differentiating power of IT to blossom. Instead, the COTS investment becomes a utilitarian asset, not a discriminating advantage. The customers must do something "differentiating" with these COTS products, and vendors must allow for that by offering an open, standards-based SOA API in such a manner which allows Northwestern to differentiate itself from Loyola and Loyola from the University of Chicago, etc.

Balancing Development and COTS: Health care leaders such as Intermountain, Duke, Vanderbilt, Indiana Regenstrief, Partners, Columbia Presbyterian, et al saw the differentiating power of IT many years ago, and only in the past eight years or so have we seen COTS products which were capable of competing with the home grown systems of these leaders. Obviously, we can't and shouldn't all build our own version of HELP or TMR, but we also can't fall to the other extreme of buying a vanilla COTS product and expect doing so to differentiate us for very long as "leaders." A "buy and maintain" strategy around COTS products will not be enough to differentiate health care organizations of the future.

SOA Caution: The principles for governing and building SOA extensions to COTS products is worthy of a day-long discussion. Suffice to say for this blog that you must exercise caution in design so that your services don't dip too deeply with hooks into the proprietary dependencies of the COTS' product layers, thus creating problems for future upgrades, compatibility, and configuration management. Think of the "Services" in SOA as circles who interact at their tangents, but do not overlap.

Small Organizations: Differentiation between leaders and followers doesn't recognize boundaries around organizational size. Even if you are a small health care organization, yet you strive to be a leader within your realm, buying and maintaining COTS products will probably not be enough to achieve leadership-- unless, of course, the simple act of investing in a COTS product is enough to differentiate you, while your competitors are still wading in paper or constrained by minimalist legacy systems. I see ample of that scenario unfolding in the territory of private physician offices.

Repackaging Data: In addition to the differentiating power of SOA extensions, health care organizations of the future will distinguish themselves through the creative and powerful use of data-- i.e., in the traditional sense of reporting, analytics, and metrics-based decision making, and also through the secondary use of their data to support new perspectives on real-time workflow processes. They will extract their production systems' data, repackage it, mash it with other data, and present it back to the front line workflow, but not as a report or a metric-- but as a new perspective on transaction data.

CIO 2.0: Hiring and Retaining Great People

My colleagues at CHIME are sponsoring a series of lectures and education sessions to explore the changing responsibilities of the CIO in healthcare. One of those areas of change involves the way we recruit and retain great IT professionals in an increasingly competitive hiring market.

CIO’s in healthcare must start seeing ourselves in a competitive hiring market which extends beyond the boundaries of healthcare. Right now, and for the foreseeable future, the best IT talent is generally not attracted to healthcare. I am enormously grateful to say that we are a small exception to that trend at NMFF-- we’ve managed to put together a team of IT professionals which has the potential to be among the best I’ve ever worked with in any industry. So, my present team excepted, the best IT talent in the world is currently attracted to the pure eBusiness companies like Amazon and Google, and the gaming industry. If we want to be the best, we have to compete with the best.

Here are a few thoughts about competing for this IT talent, now and in the future, all of which I learned working for my Dad, bucking endless fields of 80-lb alfalfa hay bales at 7,000 feet elevation in the thin air and hot sun of southwest Colorado. Talk about a tight labor market. Try hiring and retaining people for that environment. :)

He paid well: My Dad paid more than the farmer down the road; Not much more, but enough to attract a slightly better worker. Healthcare IT leaders always surrender to the notion that “We’ll never be able to pay as much as [fill in the blank with another industry].” But, as long as we accept that notion and manage our budgets and staff in that fashion, such will always be the truth. Younger generation IT professionals are motivated more by money than their more altruistic forefathers. In short: You get what you pay for, and today, nobody works for charity. Money matters when you want talented employees.

He provided lunch: Not a big deal—it didn’t cost Dad much money—but it was an important perception of value to those of us who worked for him. It also kept us physically energized and prepared for the afternoon’s work. Also, he recognized that serving a healthy lunch on-site was a much more efficient use of time. CIO’s need to “provide lunch” for their staff in whatever form, either symbolically or tangibly. Judy Falkner at Epic gets this. Steve Jobs at Apple gets this.

He made us laugh: Dad was constantly joking around, poking good humored fun at each one of us. Laughing under those conditions is not naturally easy—bucking hay can be brutally uncomfortable—but he knew that the best way to distract us from the discomfort was to tickle the funny bone. CIOs in healthcare need to lighten up a bit, take themselves less seriously, and cultivate a cultural sense of humor that aligns with the new generation of IT professionals. CIOs of the future need to contribute to the Laugh Metric.

He paid a productivity bonus: We were paid hourly, but we benefited if we finished early. Rewarding productivity is essential to the future skilled worker, and healthcare is the worst industry I’ve ever been around for failing to recognize and pass the financial benefits of productivity down to the lowest levels of the organization. And, those bonuses need to be paid immediately after the good deed. Basic Skinner psychology there. It’s a very frustrating part of my career in the business, actually, and I believe one of the reasons that healthcare is still so terribly inefficient—the front line workers are not a part of the financial incentive program to achieve greater efficiency. Toyota gets it.

He bought the beer: When the hay was “in the barn”, Dad would always let us celebrate by having a beer—a single beer each-- even though we were all under legal age. Terribly politically incorrect, wasn’t it? Too bad we’ve bleached that sense of harmless fun from our society. At that time in America, nothing was more “cool” than having a beer in that setting with your Dad and/or boss—it was a coming of age….a redneck bar mitzvah… a ritual of healthy masculinity. CIOs in healthcare need to find a similar way to bind themselves socially to their teams. Again, the modern IT workforce expects it. Friday Beer Days are notorious at Google.

Here are some other important lessons I learned over the years and try to practice which I think help attract and retain great IT professionals:

Proactive salary management: None of my employees should ever have to ask for a pay raise. I should pay them well, proactively, and expect them to perform accordingly. I’ve missed my responsibilities as a leader if someone on my staff feels like they are underpaid to the point that they have to ask for a pay raise.

Transparent salary management: Similar to the above, I manage salaries as if they were not the secret we make them out to be. That is, if salaries were ever accidentally spilled on the table and everyone could see them, I would want people to react by rubbing their chin and saying, “Hmmm… Interesting…but these salaries look very fair. I’m o.k. with it.” Unfortunately, American corporate culture being what it is, we can’t be entirely transparent with salaries, but we can act and lead as if we could. And, BTW, I subscribe to an official salary survey every year from Computer Economics, and make that survey available to all members of IS. At least we can be transparent in that regard.

Hire your future boss: I hire people that I want to work for, just in case I blow my role as CIO and have to apply for a job with them. Seriously, I always hire direct reports who I could follow and trust as my leader and manager.

Develop people to leave: I try to develop the skills and self-esteem in my people so that they are marketable—so marketable that they could say “Screw you, Sanders. You’re a kook. I’m outta here. ”, and they could find a great job elsewhere, tomorrow. If you give people that sense of empowerment over their own fate, ironically, they’ll never leave.

Hire balanced overachievers: Create a culture of “40-hour-a-week overachievers.” Hire people who are so capable and efficient, that they can accomplish as much in 40 hours as the inefficient but self-glorified and one-dimensional workaholics who work 60 hours per week. Encourage your culture to be balanced, well-rounded human beings—the kind who are happy, creative, and team-oriented. The modern IT professional expects flexible work hours and a balanced life, even though IT is as much a hobby to them as it is a profession. They might work all night to solve a problem or test a creative idea, but they want to make that choice on their own, not be forced into it.