Crowd Sourcing Pilot

I've been thinking for some time about ways to get a larger community involved in high-level IT discussions.  As technology advances, it gets easier and easier to use crowd sourcing methods to bring more, and more informed, voices into a conversation.  Below you'll find a link to an interesting tool called IdeaScale.


IdeaScale is like Google Moderator on steroids.  Basically, you can do three things:

1. Add a new idea
2. Vote on an existing idea
3. Comment on an idea

The gist is that anyone can put an idea into the discussion, people then vote the best ideas to the top, and they can discuss their opinions on each idea.

Soooo....I would like to try this out.  I've chosen a topic that's near and dear to a lot of people and a key component of our emerging IT strategic plan - collaboration.  I'd like to get an understanding of people's expectations and desires for collaborating, so we can make sure this section of the plan hits the mark.  I'm looking for three kinds of ideas:

1. Examples of collaboration that currently work.
2. Examples of collaboration that currently don't work.
3. Examples of how you'd like to see collaboration work.

Hopefully, the ideas already in the list will get you thinking and make you comfortable participating in, and adding to, the conversation.

What I'd like you to do...

1. Sign up for the site and use it.  Add your ideas to the mix.  Vote and discuss the ideas you see. 
2. If you're in a position to talk to faculty or students, spend five minutes with a few of them and ask them for a single example to add to the list.  Then add it to the site.
3. If you know of anyone who would like to participate in this pilot (or if you are on this blog, but don't have access to IdeaScale) drop a note to ceag@umich.edu and I'll add them (or you) to the site. The more people in the conversation, the more robust the results.

We'll run the pilot for about two weeks, starting March 23.  I'm not sure what we'll do with the results (or if they'll even be useful).  For those of you who participate, I'll be asking for feedback on the tool and crowd sourcing at the U in general.

Here's the link to the IdeaScale pilot.  I thank you in advance for your participation.  I really think that if we can get this right, we can make a material change on how high-level, strategic discussions are held at U-M.

Identifying Stakeholder Roles in the Strategic Plan

In order to move forward with strategic plan, we are attempting to document the stakeholders in the plan and their roles.  Examples of the value of this exercise are helping us understand exactly who has to approve a chapter (and who doesn't!) and who is guaranteed formal input (and who isn't).

In order to do this, we've put together a Responsibility Assignment Matrix.

If you are a chapter author, we are asking that you add missing people or groups to the left hand column and then fill in letters (and blank cells) the best you can, for both your chapter and any place else that you feel comfortable filling out.  We understand you might not get it exactly right - a lot of the value of the chart is to launch some discussions around, for example, who actually gets an approval vote, or who isn't guaranteed formal discussion on a document.

For our chart we're only using three letters. They are used as follows:
R = Responsible - the people/groups who are doing the actual creation of the chapter
A = Approver - the people/groups who get a vote on the approval of the chapter.
C = Consulted - the people/groups who provide formal feedback before the chapter is approved.
Blank - no special stake. Informal feedback only.

Due to the crowdsourced nature of the strategic plan, anyone is welcome to provide feedback on the chapters, but 'C's are guaranteed a formal opportunity to discuss the document via a meeting or other forum.

Here is the link to the spreadsheet.  We would like an initial pass from each author no later than Friday, Feb 15th.

Please use the discussion space below for any questions or comments you may have.

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.