A Common Technology Stack Nomenclature - Updated

(note: this is a copy of the last blog post, updated to reflect comments)

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:

Technology

Platform

Service (and Shared Service)

Suite

What I heard at the retreat

There were three important strategic principles that I captured.  If we can get consensus around these principles than they can be baked into the strategic plan.  They are: 

1. Our strategy should revolve around appropriate suites for end users
2. Technologies should be combined into platforms whenever possible
3. 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.

Shared Service: A shared service is a particular type of service that is:

• 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.

Suite: A set of services that provide value to a common user community. Suites can be arbitrarily narrow or broad in scope, depending on their targeted user community. Examples of suites could be Student or Researcher, or Java Developer or Librarian.  Individual services can be in more than one suite.  We should strive to not have duplicate suites - i.e. suites that satisfy the same needs only with different services.

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.

A Common Technology Stack Nomenclature

After last week's UITSC retreat, I thought it made sense to try to define some terms so we're all talking the same language.  Here is a proposed set of terms and descriptions for parts of the technology stack at Michigan.  If we can come to consensus on terms, it will really help us be accurate in the strategic plan (as well as our other conversations).
I'm proposing a rather simple taxonomy of 4 terms, and one variant, that roughly describe the stack.  They are:

• Technology
• Platform
• Service (and Shared Service)
• Portfolio

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 storage solutions like NetApp.

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.

Shared Service: A shared service is a particular type of service that is:

• Manged 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.

Portfolio: A set of services that provide value to a common user community. Portfolios can be arbitrarily narrow or broad in scope, depending on their targeted user community. Examples of portfolios could be Student or Researcher, or Java Developer or Librarian.  Individual services can be in more than one portfolio.  We should strive to not have duplicate portfolios - i.e. portfolios that satisfy the same needs only with different services.

What I heard at the retreat is that :

1. Our strategy should revolve around appropriate portfolios for end users
2. Technologies should be combined into platforms whenever possible
3. Services should be built on platforms and not raw technologies.

We are going to present a more formalized version of this next Tuesday, May 1, so please leave your comments before the end of the week.

What is a platform?

As you may know, the Unit IT Steering Committee is helping to create a Strategic Technology Plan for the university. Next week, we're having a 2-day retreat to begin to work out some of the details.


Within the committee, there has been a lot of discussion regarding taking a “platform approach.”  At next week’s retreat, much of the planned discussion is around these platforms.  And yet, I don’t have a well-defined understanding of what people mean when they say “platform.”  Is it role based (a student platform; a researcher platform)?  Is it knowledge-based (a platform for creating data; a platform for sharing data)?  Is it function-based (a platform for high-speed computing; a platform for collaboration)?  Is it something else completely?


Once we agree on the types of platforms, can we use the standard definition of a technology platform: "infrastructure upon which other technologies and applications can be built?" If so, where do we start? Once we agree on a classification from the previous paragraph, would we then start enumerating the hardware and/or software elements that would make up the platform, or is there another path we should follow?


In order for us to have the most productive discussion next week, I thought it would help to reach out to a broad audience to hear thoughts on strategic technology platforms. It would really help if you could add your comments to this post by Friday so we can see if there's a consensus around what constitutes a platform and how to go about defining the ones we should be building at Michigan.