The Value Lies Further Up the Stack – Business bricks as a Service

In The other day Twitter was all a flutter with news that AWS had, once again, slashed its EC2 pricing. Regardless of the veracity of the actual percentage reduction – and Rackspace CTO John Engates in particular came out swinging about it – what is a fact is that all vendors seem to be continually reducing the cost of basic cloud infrastructure. One would have thought that in light of this move towards lower prices, if not full-blown commoditization, that the general move among vendors would be to strongly move up the stack to extract more value. To an extent this is occurring – AWS is certainly adding higher level services and other players are making at least an attempt (witness Savvis‘ acquisition of AppFog for example). But the reality is that despite the fact that there is extra value to be derived the further a vendor goes up the stack, and despite the fact that from a customer’s perspective, the higher level the service they adopt, the more value they generate for themselves in terms of focus and efficiency, uptake of services above IaaS and below SaaS has been less than stellar.

It seems to me that this reflects a symptomatic disconnect within organizations – SaaS has proven wildly popular because it generally sells to the business side of the organization. SaaS customers are about getting their application stood up as quickly as possible and obtaining the functionality they need. IaaS on the other hand sells to a more technical audience, even if it’s being acquired by the business itself, it’s a more technical user who is doing so. And therein lies a problem – the more technical a customer base is, the more they think about possible flip sides to a buying decision – match this to the fact that higher-than-IaaS services (not specifically PaaS but anything “PaaS like”).

Which takes me to a notion that my buddy, Rene Buest came up with – Business Bricks as a Service (BBaaS). Now first up I have to say that I really don’t want another -aaS acronym – the world has too many of those already. I’m not convinced that Buest’s BBaaS naming will stick (sorry Rene). But as a notion for the way vendors and customers should be thinking about what they do, it resonates and harkens back to what Warner Music Group CTO Jonathan Murray calls the Composable Enterprise (which is also another name that won’t stick I fear). That’s not to say that it’ll work however, more on that later.

In his paper on BBaaS, Buest explains that BBaaS is a:

…business model that encapsulates complete application scenarios in small self-contained blocks (bricks). These bricks are addressed via an API and can be integrated into existing external applications, frameworks, content management systems and other systems.

Essentially BBaaS breaks business operations into bite-sized chunks (think an application atomic unit) and allows customers to use those chunks to build new apps or integrate into existing ones. Obviously the “plumbing” for individual bricks (infrastructure and ongoing management) is handled by the provider of that particular brick.

It’s a notion that makes sense, and is analogous to Yahoo! Pipes – a very cool tool that Yahoo introduced a few years ago that allows non technical users to aggregate, manipulate and mashup content from around the web. Pipes even has its own really cool user interface that allows customers to visually manipulate the logic behind the pipe – see below for a screen capture from one of my Pipes.

MyPOV – Conceptually Great, Practically Problemmatic

BBaaS (despite the acronym) ticks the boxes for me – it further democratizes technology beyond monolithic application stacks, allows applications to closely be tailored to specific problem sets and allows end users to create their own workflows. But (and there’s always a but), for a concept like BBaaS to really work, it would need cross vendor buy in or at the very least the ability to ensure that data could flow between applications readily. Now it could be argued that by breaking applications down to their atomic unit level, data should be in consistent and simple formats. While that rings true as a notion, I suspect that commercials being what they are, vendors would always try and build some degree of proprietary code into each brick. We’ve seen previous examples of companies trying to create their own simple application development platforms (think Podio, acquired by Citrix) but these initiatives fail when a user want to use them across all of their functional needs – as soon as one application a user needs doesn’t integrate nicely with the development platform, the entire notion falls down.

That said, I do think an approach such as the one Buest suggests is the best way to balance specific organizational needs with a high level of abstraction. I’ve long suggested that application integration platforms need to think of themselves less as pure integration products and more as a way of creating a consistent UX and UI for customers. I’m looking forward to seeing something like this come to fruition, but at the same time I’m not holding out hope that it’ll happen anytime soon.

Business-Bricks-as-a-Service (BBaaS) – Business Building Blocks in the Cloud by René Büst