Been Thinking about Patrick's Post About Schools

Skip to first unread message

Gary Davison

Apr 3, 2010, 8:45:40 PM4/3/10
to Community Fiber for Baltimore
Patrick (
- you've got a point. We have been concentrating on differentiators
between Baltimore and our competitors, very likely at the expense of
other elements of our proposal which, while not necessarily unique to
Baltimore, do contribute to our community. In concurrence, I'd like
to suggest an approach to the matter that would integrate unique
(e.g., STScI) and more generic (UA) benefits

In particular, I'd like to suggest setting up a spreadsheet that lists
three pieces of information about each use case: use case-related
information, the features that are associated with it, and the
resultant benefits. I've attached an illustrative example as a shared

Use case-related data include the name of the use case, the
technological difficulty associated with it, and the overall value of
the total benefit (more on this later). Two other elements are
Baltimore Global Leadership, and Baltimore Uniqueness. The former
field (type can be 1-10, Boolean, or low-medium-high) can refer to how
well Baltimore places relative to other cities in the world (e.g.,
Johns Hopkins Hospital in telesurgery). Uniqueness means that
Baltimore has some irreplaceable facility (e.g., NSA) or capability
that no other competitor can match. These two fields overlap, but are
slightly different. A final field pertaining to use cases is
technological maturity (a non-negative way to describe risk).
Maturity on this project runs from low (Walters) to relatively high
(SuperCloud, Cybersecurity, etc.)

Each use case, in turn, will be predicated upon the exploitation of at
least one type of feature associated with the Bmore Fiber project.
Remember - features refers to attributes of the Bmore Fiber project.
Benefits, on the other hand, refer to how these attributes positively
affect someone involved in it. Although bandwidth will be the primary
feature of this project, the set of features needn't be exclusively
bandwidth-related: the conduits use case (if we can call it that),
for example, is based on City ownership of conduits, which has nothing
to do with bandwidth.

Benefits, in contrast, relate to how the features help someone. In
this case, we should note that t he benefits accrue to at least three
parties: Google, Baltimore, and the outside world. For any one
feature, the attendant benefits needn't accrue to all three parties,
but something must accrue to at least one. Among the data pertaining
to benefits to be tracked are: aggregate value of the benefit (note -
these will be rolled up to the use case level), percent of total
benefits accruing to Google, Baltimore, and Rest of World,
respectively, and a description of the type of benefit, if any,
accruing to each of the three parties.

To summarize, I'm describing a small relational database with two
Use Case Table
- Name of use case (Text)
- Baltimore Global Leadership (Boolean, 1-10, lo-med-hi)
- Baltimore Uniqueness (Boolean)
- Technological Maturity (1-10, lo-med-hi)
- Aggregate Value of Use Case (1-10, lo-med-hi; rolled up from
benefits table below).

Features/Benefit Table
- Feature name
- Benefits to Google (note - we're listing multiple benefits/field
here, for simplicity's sake). (Text)
- Value of Benefits to Google (1-10, Low-Med-Hi, Est'd $ value)
- Google Value as % of total value (Real)
- Benefits to Baltimore
- Value of Benefits to Baltimore (1-10, Low-Med-Hi, Est'd $ value)
- Baltimore Value as % of total value (Real)
- Benefits to Rest of World
- Value of Benefits to Rest of World (1-10, Low-Med-Hi, Est'd $
- Rest of World Value as % of total value (Real)

(Technically, the spreadsheet is, more or less, a JOIN of these two
tables. Sadly, Google spreadsheets apparently don't allow one to
merge cells - otherwise, the use case-related cells would span
multiple feature-benefit rows.)

A DBMS normalization expert would probably have a cow over the
structure, but it's good enough.

This all may sound gratuitously geeky, but there is a payoff, namely,
a graphic that displays all this data in one place. In particular, a
Kolm Diagram is a graphic device that illustrates in two dimensions
the relative allocation of resources between three parties. It is
based on the principle that, in an equilateral triangle the sum of the
minimum distances from any given point to the three respective sides
equals the height of the triangle. Thus, if you label each of the
three vertices with Google, Baltimore, and Rest of World,
respectively, you can associate the relative allocations with how far
the point is from the side opposite that vertex. More succinctly, if
less elegantly, the closer to a corner a point is, the more the party
associated with that corner gets.

I've attached an illustrative example in a separate file.

Besides the Kolm Triangle, we can dig deeper into our bag of Tufte
tools to add more information to the graphic. Two ideas are
representing each use case not as a point, but as a circle, where the
size of the circle represents the aggregate value of the use case, and
the color represents technological maturity (red -> yellow -> green ->
blue). Although not implemented in the illustrative case, we could
also use the tone (i.e., light - dark) as an indicator of how generic/
differentiated the use case is from a Baltimore perspective. I am
concerned, however, about readability if the cases are too opaque.

If implemented this way, however, it will quickly create a very busy
diagram after a few cases. However, it could be used to illustrate
individual use cases and show where they fit into the overall

At any rate, I thought I'd try to come up with some sort of taxonomy
of what we're presenting - in particular, one that accommodates the
generic, but important, benefits we hope to bring to Google, the
world, and ourselves. I'll be somewhat busy over the next week, and
hoped to get the idea a bit hammered out before filling everything in
with data.

Have at it.


Reply all
Reply to author
0 new messages