Tag Archives: value chain

How to Architect for IoT

Last week I had the pleasure of doing a podcast with Forbe-contributor Mike Kavis on how to architect for the Internet of Things (“IoT”). We originally connected on Twitter regarding a discussion on whether the IoT and sensors are Big Data. That discussion led a podcast on architecture challenges–from device to data to data consumer–created by the onset of millions (or billions) of connected sensors and smart things.

Here in an excerpt of what we discussed

  • Connected devices bring back some classic engineering challenges back into the forefront.  How do you transmit data securely and with low power consumption? How do you handle lossy networks and cut-off transmissions?
  • Not everything is smartphone app transmitting JSON over HTTP (that would be cost prohibitive from both a hardware and bandwidth perspective). How do you handle communication myriad protocols, each of which could be using a near-infinite variety of data encoding formats?
  • IoT data is messy. Devices get cut off in mid-transition (or repeat over and over until they get an acknowledgement). How do you detect this–and clean it up–as data arrives?
  • IoT data is of incredibly high volume. By 2020, we will have 4x more sensor and IoT data than enterprise data. We already get more data today from sensors than we do from PCs. How do we scale to consume and use this. In addition, connected devices are not always smart or fault-tolerant. How do you ensure you are always ready to catch all that data (i.e., you need a zero-downtime IoT utility)
  • IoT and sensor and of itself is not terribly useful. It is rarely in a format that a (business or consumer) analyst would even be able to read. It would be incredibly wasteful to store all this as-is in a business warehouse, DropBox repo, etc.
  • IoT and sensor data needs context. Knowing device Knowing that FE80:0000:0000:0000:0202:B3FF:FE1E:8329 is at GPS location X,Y is of no use. You need to marry it to data about the “things” to get useful insights.
  • IoT data simultaneously “lives” in two points of view: what does this mean right now and what does this imply for the big picture. The Lambda Architecture is an ideal tool to handle this.
  • Finally, while all the attention is on the consumer stories, the real money is the Industrial and Enterprise Internet of Things. It’s also where smart things are far less creepy.

Listen to the podcast to hear more of the details

You can find the full podcast on Cloud Technology Partner’s website and SoundCloud:

I also want to take a moment to extend a big thank you to the folks at Cloud Technology Partners, SYS-CON Media, and Cloud Computing Journal for sharing this podcast.  I also want thanks to all of you on Twitter who retweeted it. I was happily overwhelmed by the sharing and interest!

How to price new enterprise software products

The enterprise software market is almost always a paid one. So how do you price a brand new enterprise innovation?

sw_px-200pxSoftware is one of those “magical” goods in microeconomic terms: it has virtually no Marginal Cost. So how do you get a customer to pay you thousands—or even millions—of dollars to buy something you can reproduce for free?

If you’re looking for a “magic formula” to calculate the price of your software, you can hit the ‘back’ button. You won’t find that here. Instead, if you are looking for a strategy to establish a tangible, defensible price for an intangible innovation, read on…

STEP 1: Price by the value you create

There are many, many software pricing models. However, at the end of the day, you’re going to have to defend your quoted price. This is easiest to do, if you price based on what your customers value. Figure out what units your customers use to measure value, and then pick a price model based on those units. Now you have Value-based Unit Pricing.

STEP 2: Use ROI to establish your “list price”

Enterprise software purchases are investments in “promised value.” However, it will take a lot of work for your customer to “unlock” that value: they have to get budget approval, initiate a program, execute it without over-runs, integrate it into their business operations, etc. To make it worthwhile, your software will have to provide a large return on this upfront cost—at least 40-50%. If your software cannot do this, it will never clear the triple wicket of business sponsor, IT manager and procurement manager.

Look at the market—and more importantly—what it costs your customers to do the very thing you are trying to automate or improve. Calculate the cost per year and subtract enough for a 40% ROI. Now you have your List Price. (Note: if there is already software you want to displace, price your product to make replacement of it something that yields a 40% ROI. Why should anyone take the risk to buy your product if it is not good enough to do this?)

STEP 3: Use co-development to establish your “maximum discount”

When you go to a new customer with a new product and quote a price, they will immediately ask for a discount (especially if you are new to the market). How do you insulate yourself against this? Establish a fixed lower bound for your software that you can legitimately never price below (at least until 1-2 generations pass and everything changes).

The best way to do this is by using co-development partnerships. Co-development partners not only buy and use your product; they provide added time, people, teamwork and insight to make it better. (This is not only good for them, it is also a path you can use to establish market leadership). Co-development should be rewarded with your Maximum Discount.

Once you have done this, whenever a follow-on customer pushes for a larger discount, you can point out that your co-development partner only received your maximum discount because of the work and time they contributed.

STEP 4: Build your price rate cards

You now have all the tools you need: value-based unit pricing, list price and maximum discount for co-development. You are now ready to give your sales and contracts team all those wonderful spreadsheets to calculate the price of your new enterprise software—at least until the next generation of innovation arrives…

A Few Closing Remarks: Two things to NEVER do when pricing your software

Give it away for free to get the deal*. You will inevitably get enticed to give your software away for free to get a major customer. Don’t fall into this trap. Once you have done this you have established your software truly has zero Marginal Value (not just zero Marginal Cost). It is really hard to negotiate UP from zero. Give away add-ons, charge implementation at cost—do anything—but don’t give away enterprise software for free (*unless you are using a Freemium model, of course).

Demand premium pricing. You may be so proud of your latest and greatest software that you will want charge more than “legacy providers” for your innovation. Unfortunately, unless you can demonstrate—at a visceral level—that your software provides value that no one else can, you have destroyed the ROI value proposition of your product.

Article first published as How to price new enterprise software at Oulixeus