Five things I hate about unit pricing

My dear readers, the subject of cloud brokers that I raised in my last blog post brought a lot of attention and views but no comments. Maybe the futurologist role I played was difficult to digest. It is also possible that you were all collectively stunned by the deep razor of my thoughts, making you unable to react to such revelation. If I may choose I would prefer the second scenario.

In this post, I’d like to explain why I hate the unit pricing concept, already popular in the IT industry and now broadly adopted by the cloud computing world.

We’re all aware of the unit pricing concept, in which price is given per a specified single abstraction called a “resource unit” such as user, gigabyte of storage or virtual machine. The concept has been around for a long time in IT, and cloud computing accommodated it quickly. However, because of the increased complexity of delivered services and multiplication of possible units, the concept is no longer intuitive and transparent.

I will explain here what elements of that concept are the subjects of my pure disgust.

Enjoy.

1. Smart aphorisms

I hate popular aphorisms like “we need to compare apples to apples and oranges to oranges.” People sharing this wisdom in reference to unit pricing tend to do exactly the opposite. They jump directly to comparisons of unit prices that sound similar but are in fact very different—not even “apple to orange” but more like “white rhino to computer mouse.” The conclusions drawn from these caricatured comparisons vary widely, confusing clients’ perception and potential decisions. Cloud computing providers, delivering long lists of proprietary unit prices, fuel this fire of comparisons and ambiguities.

2. Lack of standards

“The nice thing about standards is that there are so many of them to choose from.”

This sentence, though true in many areas, doesn’t reflect the current unit pricing situation in the IT marketplace. Every provider calculates unit costs and resulting unit prices using its own methodology. There’s no clear external reference point or standard for precise construction of reference resource units. By construction I mean specification, a kind of bill of material for a specific resource unit that would characterize all hardware, software, service and labor components included in the unit together with clear rules for applied amortization, allocations, treatment of one-time costs and other aspects.

3. Ocean of assumptions

Even if assumptions are documented and clearly expressed, their impact on calculated unit cost and final unit prices can be stunning. Take for example an IT provider that is asked to provide unit prices for two scenarios—one including hosting of cloud infrastructure in a provider-owned data center, the other assuming location of infrastructure in a customer-owned data center. The second scenario is a beautiful playground for speculation and long-shot guesses.

Is this customer data center ready and fully operational? Should the IT provider deliver surrounding infrastructure like racks, console switches, terminals and power supplies? Are shared storage and shared networks available? If yes, at what cost? If there’s no shared infrastructure, what assumptions should be made about needed components? Small changes in assumptions can result in very different unit prices. Finally, don’t be surprised when these calculated unit prices are compared as “apple to apple” to similar-sounding units from other providers that were developed with a very different set of assumptions.

4. Allocation nightmares

Let’s assume that a customer asks providers to deliver offers for cloud services with unit prices specified within “technical” domains such as virtual servers, storage and network. These parts constitute a majority of costs but not all costs on the provider’s side. What about costs of service management, focal points, delivery management, contract office, account financials and others? How should providers allocate these costs to particular “technical” units?

What about implementation costs that involve the work of project management offices and subcontractors? They appear in the beginning of the project, can be amortized and allocated to the final price units, but how exactly, and using what distribution key? An amortization period usually doesn’t match a required timeframe for delivered services, so should unit prices change in time? Changes in allocation assumptions and percentages will lead to very different results, making possible that one group of technical price units looks cheap and others sky high.

5. Naming pitfalls

Resource units and related unit prices have a certain base—the unit—that needs to be clearly specified. From the first glance it seems rather straightforward, but is it really so simple? If an IT provider offers a platform to be billed “per user per month,” what does it mean? What kind of user is it—concurrent user, named user? This can have an impact on the needed license type and resulting cost. Does the user fee include hardware capacity? If yes, what kind of capacity, and in which domain—virtual CPU, memory, storage? Maybe the name of the unit should be “concurrent user with hardware capacity” with hardware capacity specified further?

Another example is the modern desktop cloud concept—“desktops” that are run on data center servers with “look and feel” transmitted to users over the network. The potential “desktop price unit” can be misleading. In reality it can be a published desktop where the pool of desktops is based on the same shared operating system, or the more-demanding virtual desktop, which is run on a dedicated virtual machine for every user. The latter can also be equipped with a persistent image, meaning that a user can introduce modifications to the desktop that will be remembered after the end of the session. These published desktop and virtual desktop expressions are coming from the Citrix world; other providers such as Microsoft will use other names for similar concepts such as “remote desktop session,” “pooled virtual machine collection” or “personal virtual machine collection.” A potential customer needs to be careful to avoid a situation in which his requests for unit prices imply usage of certain technologies and providers.

What’s the solution?

Yes, expressing personal dislike can be relaxing for a moment, but for the longer term we need a solution. Can we see light in the tunnel of ambiguities regarding unit pricing? One solution is eventually having standards—detailed specification of commonly used cloud resource units, their cost components, amortization periods, proposed allocations and naming. The solution for now is normalization activity on the customer side, which unfortunately requires work and knowledge. If a customer receives offers from various IT providers, he needs to translate them into the same base for meaningful comparison. Examples of normalization activities are spreading additional account management fees into technical units, adding separate transformation efforts/costs to the equation, adding data center/hosting costs to pure service units and so on. Perhaps it is enough to write a clear request for proposal to avoid these problems. Yes, right. But if you find such a clear and self-explanatory paper you are luckier than the Lucky Luck cartoon hero. Even if such a magnificent artifact is released one day, the responses from providers will still vary because interpretation and speculation are interesting characteristics of human nature. Narrowing these interpretation margins is an important step in the adoption of the cloud computing concept.

About Maciej Sztukiewicz

Maciej Sztukiewicz is a Senior Technical Solutions Manager from IBM Strategic Outsourcing with 13 years of experience at IBM. Maciej designs new IT services for IBM customers with special focus on underlying cost models and service definitions. He supports large multinational accounts with complex delivery structures. Maciej is a member of Solution Design Authority board at IBM major outsourcing account. In the past he worked as certified SAP consultant. He also enjoys programming from Java to Prolog and holds TOGAF certificate in corporate architecture. Follow him on Twitter: @Maciej_MyPoznan

6 Responses to Five things I hate about unit pricing

Maciej- Great explanation &logic. Excellent written. Agree 100% as a person who has to design & sell IT services in the "Service Catalogs". I really had fun to read it. The unit pricing is a quick tool for managers to select the IT provider. Do not expect too much depth in the decision making process. Simply speaking they need tangible justification for their pickups.

Thank you. Yes, unit pricing view/comparison is a quick way for fast decision making/insight however to become valid approach it needs to be somehow 'unified' or 'brought to common base'. As I explained in my text potential standardization could help here, however there is no body on a horizon that is proposing something in this area. Time will tell …

Fabulous post for couple reasons! It is rare to write about complex topic in such vivid language … I can wait for the next story of this guy, the importance of this commercial aspect of resource units is often forgotten in discussions on cloud and even the good offerings can be disregarded through irrational comparisons. Last but not least I like the concept of standardization here we have hundreds of IT standards but seems that non for structuring the services … and what about sub-capacity licensing standards that disallow comparable offerings in cloud are? Not sure who should take a lead here but we need them!!

Thanks TomLee ! Yes agree, sub-capacity licensing topic or even general licensing approach should be also part of a standard for unit costing/pricing in IT domain. The real question is who could be influencer here proposing solution… Maybe readers have own ideas ?? -> pls share with us !

@IBMCloud on Twitter

IBM Cloud on Facebook

IBM Cloud marketplace

We collect your name and email address solely for the purpose of accepting and posting your comment. Only your name will be posted with your comment, not your email address.
Social media buttons on this site may log certain information such as your IP address, browser type and language, access time, and referring Web site addresses, and, if you are logged in to those social media sites, they may also link such collected information with your profile information on that site.