Platforms are notoriously difficult to sell, because customers do not need tools, they need solutions to their problems. And they have no way of knowing in advance that a particular tool could be used to develop working solutions to these problems. That’s the reason why you always want to sell a platform by disguising it as an application.
Unfortunately, finding the “killer application” can quickly turn into a wild-goose chase. If you’re lucky enough, you might stumble upon one (eg. CRM for Salesforce.com), but if you pick the wrong one, you’ll never be able to develop a real platform business out of it. Platforms are tough.
That being said, platforms are irresistibly attractive, because when you manage to build one, you’re sitting on a gold mine. Fortunately, there is an alternative path for selling a platform through an application. Instead of focusing on a single killer application, you can focus on a killer application delivery model. This is what John J. Donovan managed to do extremely well at Cambridge Technology Partners when he and is team “pioneered fixed time/fixed price consulting services and RAD Methodology, helping clients transform from mainframe-centric solutions to client-server architecture and packaged solutions.” (Source: Wikipedia)
John’s strategy was made possible because the industry was undergoing a tectonic shift, moving from mainframe to client-server. A similar strategy could be applied today thanks to the cloud computing revolution. And this strategy is what we’re going after with our Fast Track Package. But we can’t stop there, because unlike John, we’re not trying to build a consulting business. Instead, we’re building a platform business, which could scale exponentionally once the underlying product is fully working.
For us, the first application that will be built for a customer through a Fast Track engagement will act as a Trojan Horse. It will give us a foot in the door. It will give customers a first taste of STOIC. And because the Fast Track Package is built upon a partnering model with small to mid-size consulting practices that tend to be very local and vertical, it has the potential to scale at a fairly rapid pace. Nevertheless, if we leave our Trojan Horse sitting there within the confines of a customer’s first and only application, there is very little chance that users will use the platform for anything more than the initial application it was deployed for. In other words, a platform remains a platform, and users still don’t know what they can use it for. At best, they’ll know that it was used to develop one application. Nice to know, but not game changing.
In order for us to move a step further, we need to make our platform consumable by users who are not looking for a platform. To do so, we need to slice our monolothic platform into bite-size services that could be used to solve very specific problems. In other words, once our mythical Trojan Horse is in the place, we need to conquer Troy by unleashing all the soldiers that were hidding into it. These micro services will be our embedded foot soldiers.
So, what are these micro services? These are services that are making all the goodness of cloud computing consumable by mere mortals. If you look at the countless products and services currently available under the Amazon Web Services umbrella, you quickly realize that you need to be a very seasoned architect to take advantage of them in order to develop your application. And if you’re a business user, or a less technical user, you need some kind of user interface that will make these infrastructure-level services consumable. for example, you’re not going to use Amazon SES for sending bulk emails, you’re going to use MailChimp.
Unfortunately, these off-the-shelf services are really good at doing one thing really well, but they quickly become cumbersome when you need to use multiple of them in order to address more complex scenarios. And because software is eating the world, these complex scenarios are becoming more and more commonplace, and are being encountered by more and more people, who are neither distributed computing experts nor data scientists.
Therefore, there is a need for a collection of micro-services that could be used in a few minutes to address a very specific need, then combined together in a few hours or a few days to implement a more complex scenario. Said another way, we need a generic platform capable of handling the multiple aspects of developing and deploying custom-built application in a cloud and mobile environment, yet packaged in such a way that it can be used for a wide range of simple scenarios. And last time I checked, it looked like STOIC was not too far from fitting that bill.
The micro services I am talking about would take two forms: single-page applications for business users, and single-page API for developers. Single-page because you want them to be as simple and consumable as possible; UI and API because you want to make the platform consumable to both business and technical user. And while the following list remains a work in progress, here is the set of services that can be offered by the STOIC platform today:
- Authenticaion: Enable cross-service access control.
- Authorization: Enable cross-service authentication.
- Badges: Add gamification to any application.
- Benchmarking: Benchmark anything in the cloud.
- Charts: Turn spreadsheets into charts.
- Database: Store complex data in the cloud.
- Drives: Get a single API for all online drives.
- Email: Get a single API for all email services.
- Forms: Turn spreadsheets into online forms.
- Formulas: Execute formulas in the cloud.
- Logs: Log machine data in the cloud.
- Mobile: Turn spreadsheets into mobile applications.
- Monitoring: Monitor anything in the cloud.
- Perspectives: Turn spreadsheets into visuals.
- Pipes: Connect anything to anything in the cloud.
- Processors: Automate multi-step processes.
- Scheduling: Schedule jobs in the cloud.
- Spreadsheets: Turn spreadsheets into APIs.
- Transformation: Transform data in the cloud.
- Widgets: Turn anything into widgets.
- Workflows: Add workflow to any application.
Once an application built on top of STOIC will be deployed within a company, its employees will automatically have access to this collection of micro-services. They won’t require any additional payment, or any new user registration. They won’t require anything new to be deployed, nor any expert skills. In other words, they’ll be eminently consumable. And if they work well enough, simple word-of-mouth within the company should make them spread.
Initially, these services will be used by users of the initial application that brought STOIC into the company. But sooner or later, an extended group of users will discover their benefits. At first, users will adopt one or two services that really matter to them. But over time, they’ll start to use more and more services, and when they do so they’ll discover that the more services they are using, the better these services are working together. They might not yet understand why (because they’re all powered by the same underlying platform), but they’ll realize that these services are working better than alternative standalone services that are available on the open cloud. In other word, some network effect will start to kick in.
For most users, it will stop there. Much like most users of Excel have never used it for antyhing more than laying out data within the cells of a grid, and have yet to write their first formula. But for others, the adventure will continue. Sooner or later, they’ll discover that our single-page applications also have links to a more complete user interface giving them access to many more features. Over time, they’ll start to develop some mental picture for the underlying platform. Then, on some glorious day, they’ll have an epiphany and they’ll decide to look behind the curtain. They’ll step into the world of the platform. And they’ll never look back…
To recap, our incremental adoption process will look something like that:
- Use an application that happened to be developed on top of STOIC
- Use a first micro-service in relation with the initial application
- Use a micro-service on its own
- Use multiple micro-services individually
- Use multiple micro-services together
- Use the platform to develop a new application
Once we make our 1.0 release (sometime in September), we’ll spend the next twelve months working with a few dozen customers to implement this incremental adoption process for the platform. We’ll start with small projects first, then tackle more ambitious ones. Initially, we’ll work with small datasets (gigabytes), then upgrade to bigger ones (terabytes and more). We’ll refactor many parts of our server and user interface to package these micro-services, which will strengthen the underlying platform by making it less monolithic. We’ll instrument their utilization by customers and monitor their adoption rates. We’ll discover which services are valuable, and which ones are not. We’ll learn what it takes to build a successful service. And when we get there, we’ll figure out a way to scale this up aggressively.
Let’s embark on this journey together!