At the UITSC strategic planning retreat, there was a lot of discussion about a "platform" approach to the Michigan strategic plan. I thought it would make sense to document what I heard, and frame it in a common nomenclature that we can use within the plan (as well as our other conversations). Below I offer a simple taxonomy of 4 terms, and one variant, that roughly describe a technology stack from an end-users point of view. The terms are:
What I heard at the retreat
- Our strategy should revolve around appropriate suites for end users
- Technologies should be combined into platforms whenever possible
- Services should be built on platforms and not raw technologies.
So, here is my (second) shot at defining the terms used in the principles:
Technology: A base-level capability, not normally directly usable by an end-user. Generally speaking, everything builds on technologies and technologies can be nested. Examples of technologies are networks, data centers (which contain even lower level technologies), and raw storage solutions.
Platform: A set of technologies, combined in such a way that they:
- can be built on
- have standard, defined interfaces for data, and possibly program control (APIs).
- are generally not consumable by the end user.
Examples of platforms are an Enterprise Service Bus, an Identity/Access Manager, and Amazon's EC2.
Service: A solution that solves a particular end-user need. This is often a wrapper around one or more platforms or technologies. Examples of services are Ctools, gMail, and Value Storage.
- Managed to a service level expectation
- Orderable
- Priced with a published pricing model
- Measured and monitored
Within our nomenclature, just sharing a service across units does not make it a Shared Service. Shared Services must have the above attributes.
We are going to present a more formalized version of this next Tuesday, May 1, so please leave your comments before Monday morning, if at all possible.
I believe platforms can be consumed by end users. They can and do provide direct functionality. The "built on" capability allows extensibility and innovation at the edge. I like the example of Facebook as a platform. It's useful "out of the box" but it's extended via apps and web plugins (e.g., the "Like box"). Platforms are hopefully architected and not just a set of things packed into a marketing bundle.
ReplyDeleteTypo note: Shared Services are managed not manged.
Maybe platforms are not "walk up and use" in the way that a service is. Platforms provide direct functionality, but maybe for expert or specific audiences? I heard platforms described as software supports the development of other software. One could say that facebook.com as seen in a browser is a service, and a "Like" button somewhere else uses the Facebook platform.
ReplyDeleteFor the vast majority of users, Facebook is a service (or arguably a suite). The users do not extend the site; they simply consume it. Today, Facebook sits on on a platform that can be used by developers. Using the descriptions in the blog, there is both a Facebook service and a Facebook platform.
ReplyDeleteI think it's important to note that Facebook originally launched as just a service. The site was well-adopted before they created a platform (or exposed the one that already existed).