The planning meeting was held in Massachusetts. When brainstorming project names, someone mentioned that most New England of activities: Candlepin Bowling. Thus, the project is named Candlepin.

When describing a project, especially something fairly abstract like an entitlement system, you can clarify communication by using a strong metaphor for the system. So, to explain entitlements, I am going to use a bowling alley as my metaphor.

One way to think of an entitlement is this:

An entitlement is contract that you can hook up your computer system to my content stream.

But for our metaphor  I’m going to say:

An entitlement is kinda like getting a lane a bowling alley.

To which you say:

Huh?

Think about it.  When you go bowling, you pay money, but you don’t get a good, and you don’t get a service.  What you get is access to a resource for a limited time.  Say a small company wants to do a team building activity:

We’re going bowling!

This company has 18 employees.  So, we go over to Westgate Lanes (A nod to the local Candlepin Alley of my childhood.  Indulge me) and we walk to the main desk.  We’ve self organizaed ourselves into six teams of three people each.  We get our shoes, and our group gets three lanes assigned to us.  We go, and each team pairs up with another team, the two teams select a lane from the three available, and they bowl.  After each game, the teams re-shuffle the match ups, switch lanes and  play another game.  When each team has played against all the other teams, we return our shoes and go home.

Here is how the analogy maps to entitlement management.

The Data Center is the Bowling Alley.

The lanes are the physical machines that the virtual machines will run on.

The company is still the company paying the bills.

The front desk is the assignment system where you buy slices of time on the machines of the data center.

The three lanes that our company is assigned has a communication network due to the fact that we all need to coordinate our games.  This is the VPN and VLAN setup that lets you specify a cluster of machines can all work together.

The pin setter and the ball retrieval and the scoring projector are analogous to the resources required to run the programs.

The score card is the backing store for the database instance that your applications talk to.

We can extend the metaphor to a larger world, too.  Say we have a bowling league that spans multiple towns and multiple bowling alleys.  This league is composed of teams.  The league sets the schedule, the games are played at the various alleys through out the district.  At the end of the season, the lead team from our league actually plays against the lead team from another league.

This reflects the hierarchical structure of resource management.  You can see that the bowling alley doesn’t really care about leagues except as a way to generate traffic through the alleys.  From the Alley’s perspective, the league is just another customer, paying for lane time.  Perhaps in some cases, the league pays for the time, in others, the individual teams do.  Authority to use a specific lane may have to be cleared not only through the clerk at the desk of the alley, but through the league official that is managing a tournament.  Just like if my company buys a chunk of virtual machines on a cloud somewhere, and then delegates them for internal usage.

Note that the metaphor works for internal clouds as well.  At the Really Big Company (RBC) campus, they take their bowling so seriously that they have a series of lanes installed into a building on their campus.  Now, the scheduling and resource management have been brought in house, but the rest of the rules still apply.