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.
- 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.
What I heard at the retreat is that :
- Our strategy should revolve around appropriate portfolios for end users
- Technologies should be combined into platforms whenever possible
- 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.
Thanks, Chris. This is helpful to me. I wonder if you (or others) can add to this by slotting in one example that we talked about (Hadoop) and a couple of others.
ReplyDelete(1) I'm supposing that in this taxonomy, Hadoop is a "Service" rather than a "Platform."
(2) The Library runs a "Data API" that makes books available to users, but only books in a specific repository. Would that be a "Service"? And, further, if the Library bundled together *all* of its content management services into a single thing that could either be (a) searched to find any type of digital object or (b) addressed to be able to extract and use any specific type of digital object (e.g., book, image, geospatial data), would that be a "Platform"?
My opinion:
Delete1) As it stands right now, Hadoop is a service, since users consume it directly. I would not be surprised to see 3rd party interfaces to Hadoop become the norm, in which case it will retreat to a platform that is primarily used for others to build on. Many things can't be solely classified into a single area in the taxonomy - but I hope that most things can be *primarily* one of them.
2) I'm not sure what "Data API" is. API normally means something that's used by a program in which case the API would be an interface for the platform and the programs would be part of a service.
2.5) I think it depends on the presentation. For example: Platform=presented as an API for others to build on. Service=presented as a single search box that could access all of the CMSs. Portfolio = a program or website that groups all the CMSs together.
Not to beat this to death, but box looks to me a lot like a service. If I were a developer using their API, it would like more like a platform.
DeleteBut isn't the best reason to discretely identify the two functions? The platform part and the service part are aimed at two completely different user sets.
DeleteThis is great Chris, thank you. I thought this short article did a good job explaining why we should move towards platforms:
ReplyDeletehttp://www.inc.com/phil-simon/why-your-company-should-build-platform.html
One wacky idea would be to consider what a technology / platform / service approach would be to something like an application for recruiting and admitting PhD students across campus. The proliferation of CMSs and related web development environments on campus would seeming need to be addressed along the way.
DeleteThanks Chris - I think the taxonomy you've proposed does a great deal to get us toward a logical way to articulate our discussions around campus IT direction and offerings. My biggest point of confusion though was around technology vs. platform. Conceptually, I think the definitions make perfect sense, but the examples served to confuse rather than clarify for me.
ReplyDeleteSpecifically, it would seem "network" and "data center" both fit the definition of "platform," even though they're cited as "technology" examples. Also, "NetApp Storage" seems like a specific product (a 5th level of taxonomy, perhaps... for example, would "Storage" be a "technology" where "NetApp Storage" and "BlueArc storage" would each be specific products that provide storage technology?
Also, to help in understanding the taxonomy, how would something like the Wolverine Access Gateway be categorized? Seems like "platform" would be the best match, even though it doesn't meet platform definition completely??
David, thanks for the comments (this is probably a good place to reiterate that 'strawman' means I expect it to get beat up and changed.)
DeleteRe: Network and DC. A platform is a set of technologies with defined data I/O and system controls. I don't think of network as a set of technologies. I don't generally think of DCs as having defined in/outs, but it would pretty easy to convince me that a "good" DC was a platform. A bread-rack with a powerstrip wouldn't qualify though :)
Re: Netapp Storage. I think you're spot on. Storage is the technology. Technologies can be provided by multiple vendors. I'll change this in the next iteration.
Re: Wolverine Access. Isn't this classic portfolio (or multiple portfolios)? To me, it's a bunch of services grouped together by user type. I definitely don't think platform since it's consumable by end-users, not really able to be built on, and doesn't expose it's data.
One definition of 'infrastructure' is 'an application that belongs to somebody else.' On the topic of whether Hadoop is a service or not, looking at http://hadoop.apache.org/ could be informative / confusing. Hadoop could be a technology . http://pig.apache.org/ describes pig as a platform.
DeleteDefining these kinds of things might help define, or at least describe, what stays on campus and what goes into the cloud. And what it goes into the the cloud as? As IaaS? As an app in Google App Engine?
If I were to take a shot at this, I'd classify:
DeleteTechnology: Map/reduce.
Technology Solution/Vendor: Hadoop
Platform (for Map/reduce using Hadoop): Pig
Yes, I think defining these kinds of things helps us create appropriate road maps. For instance, it seems that for each technology, we should have a single 'go to' solution. This is not to say it's the only solution available but IT resources should be focused on the go-to solution whenever possible. In this example, if you say "for map/reduce, our preferred platform is Pig on Hadoop" a lot of stuff becomes clear.
Chris,
ReplyDeleteThis is really helpful in giving me the hooks for further discussion. The other comments and examples are very useful as well. Further refining and delineating of these things will be the key to explaining this to the larger groups who are going to need to understand it so I think we should continue to work on making this easy to understand for folks who don't have either time, skills, or energy to deal with complex explanations.
I'll also play my one string fiddle regarding the need for the platform interfaces to be open, as much as possible, and consumable by a wide variety of external tools so we don't exclude potential developers.
--Bill
As we have been discussing many of these same concepts as part of NextGen Michigan and Shared Services, we use the term Portfolio a bit differently. In our structure, Portfolio is a concept for governance, planning, and investment decisions. "A domain steward has a portfolio." We strive to keep a service in only one Portfolio. It's only a guideline but it helps with accountability at the Domain Steward level.
ReplyDeleteI wonder if the use of term Portfolio here could be changed to something like "Suite?"
I'd like to make terms match AND I like Suite. Unless someone objects, I'll change 'portfolio' to 'suite' in the next version.
Delete