Build - Run - Consume - Monetize

  • Article

Build - Run - Consume - Monetize a.k.a BRCM (pronounced "breekam"?!) is a simple model that I am experimenting with to explain the primary concerns of each of the "actors" involved in software delivered as a service as well as understanding the multiple angles of platform support required by this fast growing trend. Below a high level description of this model. Being early thinking, do not hesitate to provide feedback and/or leave comments!

 

 

Build

The primary task of build is to encapsulate domain knowledge into code. The main concerns are around Application Architecture. There are 3 aspects of build:  The creation of the features, the internal optimization, the designed for * (pronounced: "designed for star"). Let's briefly go through these 3 aspects.

  • Creation of the features:
    This is of course the core value of the application: the business logic, the rules, the data model etc. This should be minimally impacted by the delivery or monetization model of the application. It is quite clear to me that the features you create for helping, for example, an enterprise better manage its supply chain, has little to do with whether it is monetized as a subscription, a perpetual license, delivered on the web or on premise. A "business logic" feature is a "business logic" feature. Besides, you might want to monetize the features in multi ways so separating the two, at least conceptually is good.
  • Internal optimization:
    I call internal optimization the elements introduced into the architecture that benefit the service creator, but will be, at least in theory, unknown to the consumer of the application. My canonical example for this is multi-tenancy support. Deciding the level of support of multi-tenancy is an internal optimization of your architecture. (This post can help understand some of the implications.) The buyers might benefit from your multi-tenant optimization since you might decide to pass the saving to them but you could, assuming that the competitive landscape allows it, use this internal optimization for higher margins. Or you could be completely multi-tenant unaware and still have a great value proposition for your customers.
    Another possible optimization is the use of "cloud services" as part of the application architecture. For example, if the reading patterns of your data are not uniformly distributed (i.e. you have 20% of the data that is read very often and the rest is read very rarely); you could imagine to only store the 20% "hot data" in your local hosting environment and for the "long tail" of data, use some utility storage a la S3. This would allow you to be in control of your most important data and tap into beneficial cost structures for data that you need to store but do not need to serve often. The relative cost of storage vs. computation vs. network was discussed here. There are many other examples of internal optimizations.
  • Designed for * :
    Designed for * (note that * "star" here is used as the wildcard identifier we all have learned to love in our Unix,dos etc. days) is a term I have started using in my conversations with service builders. It encapsulates all the specific design decisions and additional elements added in the architecture for "facilitating someone else's life". An example of this would be "designed for hosting" (dfh). Designed for hosting would be all the things that a service creator would add in the architecture to "play well" in a hosting environment. For example not use absolute file paths, no need of elevated privileges, no assemblies in the GAC, implementation of halting interfaces (Pause/Stop/Restart) etc. Designed for composition (dfc) would be the things added to the architecture facilitating compositions (mash-up/aggregation), for example single sign on support, multi-protocols (REST, SOAP), multi-format (XML, JSON, ATOM) support... Like with internal optimizations, there are many instances of designed for *

These three aspects are neither sequential nor separate, all three have to be taken into account when making design choices, but separating the concerns I think is helpful. When developing your code, you could compare and prioritize the efforts you are putting into facilitating others vs. optimizing your code vs. creating the appropriate feature set. With LitwareHR and a couple of whitepapers (here and here) we have covered how to use the Microsoft platform for the creation of features delivered as a service and touched upon some internal optimizations aspects, in the future expect more guidance around design for *.

Run

The #1 goal of run  is to provide a hosting model. The same way the Windows OS is the hosting model for a .exe, or IIS is the hosting model for ASP.NET or SQL for store procedures, a Service Delivery Platform is the hosting model for software delivered as a service. The objective of an SDP is to deliver the software at the lowest cost possible for a agreed upon service level agreement (SLA). The concerns are therefore around Delivery Architecture. The aspects of run are:

  • The depth and breadth of support for software delivered as a service
  • The processes in place to maintain an efficient, reliable, available, scalable, high performance service delivery platform (SDP)
  • The SDP SDK.  (how to expose the SDP as a programming model)

Eugenio provided some information about SDPs here (a must read) and as mentioned previously, this is the topic of our next whitepaper which should hit the shelves early June. So stay tuned on this one. 

Consume

Consuming software as a service is a very different discipline than building or running it, I would go as far as saying that they have pretty much nothing in common. From an architecture perspective, consuming cloud services is mainly about integration and aggregation as mentioned in this August 2006 post. The canonical example I use for illustrating the need of integration is to think about how to retrieve the opportunity pipeline stored in the cloud (e.g. CRM live) and feed, with this information, the revenue forecasting system running in the mainframe so that the CFO can prepare for the analyst call she is having the next day. Since this scenario crossed corporate boundaries, "internal tokens" such as Kerberos have little value; a new set of protocols and tokens (e.g. SAML tokens) as well as the notions of claims and secure token services need to be embraced. But this is only about Identity and single sign on (SSO). What about data management and canonical schemas? What about business process integration? Governance? As you can see, consuming services in a many-to-1 fashion requires some deep architectural thoughts and additional support from the underlying platform. Initiatives such as Biztalk Labs as commented by Clemens here are very important components for such future platforms. More established products such as AD-FS are also great enablers. The goal here, I would say, is to be able to "platformize" a lot of common requirements, instead of treating all the integration projects as "ad-hoc".

For those who have not read it, the SaaS: an enterprise perspective whitepaper provides some additional information about this. But additional guidance is required around:

  • Integration and aggregation:
    How to mix and match on premise and cloud services regardless of the cross boundaries aspects: identity, data, business processes, UX, tools and governance. (hey, that sounds awfully similar to the pillars of SOA and this old post can always help.)
  • Procurement strategy (buy/rent/build):
    Enterprises used to have a buy vs. build choice. Now they have a buy vs. build vs. rent choice. Understanding the right decision factors (when to buy, when to build, when to rent) so that the most optimized IT environment can be created is key. 
  • Vendor / SLA management:
    With increased dependency on software suppliers, the discipline of business continuity, supplier relationship management as well as SLA management will evolve. Another key area where a platform can provide great support.

 

Monetize 

I have to confess that I have not spend too much time in trying to generalize the architectural challenges related to the monetization aspects. This said, as mentioned in previous posts, monetization can be put into 3 main categories: subscription, usage based (a.k.a transaction based) and ad-funded. Below a few comments based on my only superficial investigation.

  • Subscription:
    A "per user, per month" scheme, which happens to be, at least currently, the most popular option, can be implemented mostly "out of band". (is this why it is the most popular option?) What I mean is that the billing/invoicing can be mostly separated from the application itself. A business contract is established for say 50 users, a monthly bill of 50 x cost per month is sent to the buyer.
    Of course, there are multiple areas where a provider could benefit from a tighter linkage between the order system and the application. Automatic/self provisioning comes to mind, but also more accurate monetization. A non paying customer could be cut out of the system earlier, a customer using more than the allocated seats could be billed for the additional used seats at the end of each cycle... The provider of the service delivery platform can play an important role here.
  • Usage / Transaction based:
    A usage based monetization scheme (by definition) requires the application to know about how it is used. Metering and raising monetization events becomes a key piece of the architecture. Dynamic pricing modules might be needed if a specific usage depends of external variables such as time of day or simply who the user is. Non repudiation might be required based on the trust levels and/or the cost of a specific transaction. Usage reporting becomes critical allowing customers to monitor in real time their usage and therefore their cost. Tools allowing to cap the expense or simply being notify when the cost goes beyond a certain threshold would be a good service to provide. All this is clearly not dissimilar to cellular phone usage where I can monitor how many minutes I have used in my plan, how much the SMS I sent cost me etc. However, it is not something that has historically been implemented by many ISVs. Again the SDP can greatly help here, and it looks like that a "designed for usage based monetization" section in the designed for * book will be needed :)
  • Ad funded:
    Very trendy and at the core of many new ventures business models, the ad-funded model is increasingly investigated. Advertisement being so closely related to the demographics of the audience as well as the intent of the audience (awareness, purchase...), the architecture will need to be able to capture these two parameters to increase advertisement effectiveness. Also, if placement is done within the application, tools, APIs and/or SDKs must be provided to the media buyers allowing them to optimize their campaigns by placing the appropriate ad. Support for rich media, typically video, might become an important piece of the architecture. From a platform perspective, technologies like Silverlight can become a very powerful tool.
    With ad funded comes also the possibility of fraud (click fraud or equivalent); understanding how to detect and prevent it, could take a big toll on the architecture. Similarly, being able to "fight" filters or ad-blockers, for example by degrading the functionality if ads are not viewed or clicked, could be required. 

Whether the model is right or needs tweaking, one thing is sure, the surface area is huge. Providing the appropriate level of architecture guidance and more importantly full platform support will take some time. The good news is that many things can be used today already, and much more will come over time. In the coming months, expect my team to build on the success and great feedback received on LitwareHR and start exploring all the additional facets of the BRCM model.

As a final note, below a simple table summarizing which aspect you are most likely going to be interested in, based on "who you are" ISV, Hoster or Enterprise:

  

As mentioned at the beginning of this post, I am just starting experimenting with this model, so feedback and comments very welcome.