Recently, Marc Andreessen of Netscape and Ning fame, proposed a maturity model for platforms on his blog.  I urge you to read his article, but I also want to propose a BSG Alliance position for everyone in our company to adopt, so that we are talking about the right meanings of “platform.” 

Andreessen is clearly talking about technology platforms – mechanisms that reduce many of the barriers of application interoperability - that house or interface to other applications according to a common set of rules.

Big P

At BSG, we’ve been using the term “platform” two ways. The first way describes our overall business. 

We wish to build a “Platform” of services – a collection of components from education, research, advisory services (e.g., Strategy on a Page), applications (e.g., e.laborate, our collaboration hub) and delivery (e.g., integrating a customer’s single sign-on facility with e.laborate). 

By building a “business” Platform, we make it possible to configure our services in any combination (including external components) to specifically and uniquely address our customers’ business needs.  (BTW, BSG’s Bob Morrison provides an excellent perspective on the role of platforms in NGEs in the Boardroom Imperative – a document that is still very much on my list of required BSG reading.)

Little p

The second way describes our “technology” platform – every Next Generation Enterprise leverages technology and the Web to give it process flexibility (agility) and a connectedness to the outside world like never before. 

It’s not just about doing business differently, it’s about putting technology to work to change the game; to continuously gain and regain competitive advantage.  Technology is at the heart of what makes BSG different.  We will demonstrate how we use it to our advantage, and we will show our customers how to leverage technology to enjoy key business outcomes.

We are in the process of designing and implementing our own “reference architecture.”  This is a geeky-sounding phrase that simply stands for our rules of the game. We will develop and run applications on our reference architecture – our platform.  We will publish the details of our platform so that we and others can develop applications that plug-and-play into it.

Why?

One benefit of a platform is that it enables ready interoperability.  We create a piece of code – a Web service – that lives on our platform and can be combined with other Web services to create composite applications.  These composite applications are nothing but special combinations of Web services designed to meet a particular need.  We can create new virtual functionality simply by devising a particular sequence (“mash-up”) of existing functions that execute only when they are requested.

We hear stories of clever programmers delivering amazing functionality with “20 lines of code.”  This is not an exaggeration – because the bulk of the code is sitting within the Web services! The 20 lines of code simply dictate how the Web services are to interact with each other and with the user.  It takes months to hand-craft a Lamborghini – it takes hours to build a BMW.

Another benefit of a platform is reuse.  We only need to maintain one instance of a given Web service. There is no need to duplicate them – we simply “reference them into” a runtime environment where they interact seamlessly with other services, on demand.  Also, because a service exists in only one place, when we enhance it or maintain it, this latest version is the one that executes – no matter what mash-up uses it.

A Code Ecosystem

The following diagram depicts our platform and four different types of applications.  (The dashed line is the firewall between our runtime environment and the outside world.)

A-type – these applications (or services) are designed to be highly interoperable/reusable and to run in our multi-tenant runtime environment. They interact seamlessly with other A-type applications and are the easiest to mash up into composite apps.

B-type – these are applications that are hosted within our runtime environment, but are not initially designed to interact with A-type applications.  They are “one-offs” of a sort – but the key is that we host and run them on our platform.

C-type – these are applications that execute somewhere outside of our runtime.  They can be other SaaS applications/services (like Salesforce.com) or applications that interact with our A-type applications via an API.  (The two-headed red arrow is our API.)

D-type – these are applications that are hosted entirely outside of our firewall and do not interact with our platform.

So what does this all have to do with Andreessen’s platforms???

A lot. If you think about it – BSG Applications’ runtime environment is a kind of Level 3 platform.  But for now, it’s only that for two audiences – BSG Applications and BSG Delivery. We write A-type apps to run in this environment, and tell other parties how to write A-type apps as well.  Plus, given that our platform is so standards-based, we expect that third-party applications will run natively in our runtime with little modification.

The Role of BSG Applications

Role 1- Define, Publish and Maintain the Platform

We have identified about 40 different components of our Reference Architecture (the platform) – from security, to single sign-on to how we interact with databases. Some of these we will need to create – but most of them will be acquired through open source or via partners.  We plan to deploy the platform in phases, in parallel with new A-type applications we wish to host, and in accordance with the requirements of those applications.

We’ll publish the Reference Architecture so that others (e.g., BSG Delivery) can develop new A- and B-type applications that are hosted on the platform.  With the RA specs in hand, there is little more required to ensure compatibility. As components are designed in or implemented, we will also be updating the documentation so that everyone’s on the same page.

Role 2 – Accumulate Applications on the Platform

Clearly, BSG Applications will be creating new A-type applications. But we don’t want to be the only source of these applications. Third parties (initially, BSG Delivery) will develop applications for our platform, and we’ll host other companies’ applications as well.

We’ll also be creating linkages to C-type apps – like Salesforce.com.

The Role of BSG Delivery

A traditional systems integration project focuses almost exclusively on D-type applications.  You spend time getting the customer’s requirements, understand their environment, and build new capabilities that interface with their IT infrastructure.

We must make the transition from D-type applications to C-type and eventually, purely A-type applications.  This provides the kind of leverage that our technology platform will enable – and will characterize us more as a technology company vs. a services company.

I do not expect this to happen overnight – and depending on the rigor we apply to customer opportunities, we may have to “walk” from a few purely D-type deals. 

But the sooner we can begin to address our customers’ challenges with solutions drawn from both the Big P and little p platforms, the faster our on-demand flywheel will spin, and the more differentiated we will become in this market.

Going Forward

We’re working hard on defining our Big P – the business Platform – which is being driven by our market segment work.  BSG Applications is also working hard and fast to define the little p platform so that we can give our partners (especially BSG Delivery) the information they need to enjoy great leverage and reusability.