A recent conversation with a group of senior technologists
unwittingly turned into an interesting debate. This post covers a few areas
that I felt may be relevant to all engineers.
We discussed at length about platforms, services, APIs and
offerings or products. I stand more focused on building offerings and services.
Hence I poured out my opinions on how offerings and services bring a variety of
challenges and need focus on business and engineering which is complex in its
own way.
Such debates seldom finish with a decided winner. Our debate
was no different. However mid-way into the debate, I realized that each of us
had a definition of “platform” and “service” that varied significantly. Our
arguments were based on our biased definitions of these terms. Fighting these
definitions seemed harder than concluding the debate. Indeed the debate was
beyond just these definitions.
In any case, the conversation inspired me to get my own
definitions right and also look at comparative answers at Wikipedia and beyond.
So here is a compilation of a few definitions in my own words borrowed heavily
from the Internet.
Platform or Computing
platform: Hardware and a software stack that provides engineers a ‘stack’
to extend and build a particular type of solution. By definition it is expected
to set constraints and serve as the basis to solve a particular type of “technical”
problem. Most platforms offer a framework based on best practices and suggested
ways to solve a problem. So far so good. The interesting aspect of a platform
is that it rarely solves any business problem in itself. It is for most part a
suggested way to solve problems of a particular type in any domain. Work flow
platforms, Content platforms, BPM platforms. These platforms are suggested ways
to solve a problem in many enterprises. The platforms that come to my mind are
– J2EE, Android platform etc. A platform is too broad based to help build
solutions at a faster pace. It only paves the way to setup “services” or “APIs”
which in turn will help setup the right solutions.
Services and APIs:
API is an interface against which one can program. Typically an API is
download-able piece of code that you can deploy with your own code and leverage
the API’s functionality. APIs also fine grained by nature and does not always provide
a business service by itself. One is expected to stitch up a few API calls and
orchestrates these calls to setup a service. The term service today is associated
mostly to “SOA” or Service oriented architecture. Services by design solve a
business problem, are scalable, are available on the net, are secure and are
platform independent (client and service need not be coded in the same
language).
The word API is often used in place of service – E.g. Facebook
graph API. Some of these online APIs, are essentially services. As these APIs do
not solve a business problem themselves and only expose the underlying data
over the web; the word APIs suits them better.
Most products have to begin their journey with a strong
service / API layer. Depending on your domain, clientele and ecosystem, you
would have to build a service / API strategy and develop the offering around it
or even share the services so that engineers can program to it. The dominant
design patterns of today discourage engineers from building APIs and allow the
ecosystem to “download” it. Services built on top of APIs or hosted APIs that expose
the underlying data / logic leverages the advantages of distributed computing
and scales better.
Services and APIs are written on top of a platform. They are
hosted as per the platform specifications and the clients who invoke them care
less about the platform that was used to setup the services.
Offering or the product – The offering or the product is
what a company creates for their customers. The Interface, packaging,
distribution, support, reliability etc. form an integral part of this offering.
A Saas offering is best developed by creating services and then building the
offering around it, as though the offering was the first customer for the
services.
The key difference between platform and service is the kind
of problem it solves. A platform does not solve a business problem. It only
provides a path for engineers to build services / offering. A service is the solution that engineers have to build if they wish to setup an
offering or offer a service to their customers.
Very often I hear engineers intending to say "services", but instead, they say "platform". I believe that the intent of these 2 engineering terms is to define something very different and a broad agreement on what does it take to call something a service or a platform is important. At least 1 engineer going forward will be more careful when using these terms.
