Geography has been my theme for a while now. Functional cultures present us with geographies. Ideas present us with geographies. IT departments present us with geographies. Interfaces present us with geographies. Interactions between minimal marketable functions present us with geographies, likewise, product roadmaps. So what is a geography? My take is that a geography is anything that can be better expressed in a GIS system, rather than a list. Is time an issue? Are the relevant issues spatially organized? Then, you have a geography.
When I was working as an ITIL change manager, we were adding the change management component of ITIL to an existing ITIL implementation. I was supposed to track down managers willing to be responsible for improving their change management processes. I was supposed to find the potential conflicts between changes scheduled to be made to code, hardware, and other infrastructural elements across a huge IT shop in any particular time interval. It took me one day to decide that this was a GIS problem. We were trying to get this done via a relational database system and Excel. Oh, hell. Worse, I said that we needed a GIS system on my second day on the job. They were installing an upgrade or a completely new relational system at the time, so ….
Just keep your mouth shut until you’ve wired the joint.
In their system, you had wires, tons of wires, routers, switches, network stuff. That is was physically located in particular places tied to physical geography quite well. Servers exist in physical space. So drawing the map of their physical system wouldn’t be that difficult. So before we make a leap let’s explore this geography and what it means in terms of game theory.
I took my son on a spring break trip down Route 66. Route 66 emerged from the efforts of various chambers of commerce along the route and the states involved. The road was a bottom up, business proposition from day one. It is obviously geographic. Services were stretched out along this road. The road is celebrated today as history and a user experience–the stories of the road.
Several value chains stretched down this road simultaneously. In one sense, the cafe in this town competed with the cafe in the next town. But, in the larger sense, the road, competed with other roads, so all the competitors on the road collaborated in the competition between their road and the other roads.
So lets look at the road as a value chain and move it into a Shapely Value representation.
Here we take a length of the road and partition it into sections based on the contribution made by each town along the road. That town has a geographic reach. Using the frequency of use idea would let us build other measures of the value contributed by each town along the road.
Next, we measure the length and normalized that length. When you normalize a collection of numbers, the largest number becomes 1.0, and the other numbers, except for zero, become some fraction of that number vs. the largest number. Normalized values express probabilities. Notice that the existence of the road is taken as a given. If a section of road where to become impassible, the value of much of the road would disappear soon enough. Likewise, if your trunk connection to the internet went down, the value of your enterprise network disappear while you were screaming into the phone. Ah, but for redundancy.
If all of this were in a GIS system, we could consider gas station pumps, beds, lunch counter seats, booths, tables, tourist attractions, movie houses. We would be playing many games.
So our next rep is the Shapely Value of our road.
This representation was built from the totals from the previous figure. This representation is optimal, as such it assumes maximum collaboration. The Shapely Value is a number equal to the area of the gray area, the core, in the figure. The white area represents space that cannot be reached due to inefficiencies and the lack of the necessary capabilities.
The Shapely Value is typically introduced as a 3-party game, which leads to a triangle. It is also three dimensional, which puts it at the limit of our ability to visualize. Shapely Values use perfect polygons, aka polygons where each side is the same length. This just makes the math easy, but the math is not based on shape. Matrices or tables are used to compute the value of each coalition.
In this figure, the town associated with the value 8 is having some problems and is not contributing to the value chain to an optimal degree. The town associated with the value 18 has not been impacted, but all the other towns in the value chain are seeing their earnings decline.
That’s just one value chain. Instead of cities, think about your network infrastructure. So now we’ll move on to a server, a server hosting a database. That server is in town, a city unto itself. It connects to another server hosting a data warehouse. There are connections upon connections, layers upon layers, maps upon maps. You can imagine it yourself. Just try mapping out your Twitter experience, or your blog host and RSS feed reader experience. Diligence will get this map done. You will end up with game upon game, onions of games. GIS is the tool that can take you there. Relational can define a single layer, but the toilet map, otherwise known as the sewage system doesn’t relate well with the electrical system.
There I was working hard to do a GIS analysis with an RDBMS, but I was wondering why ITIL system vendors hadn’t gone GIS. It’s probably cultural. If your IT organization hasn’t gone GIS yet, why would an IT management system be the first to do so. Ultimately in the abstract, it all boils down to features and how they relate to each other. All those features end up on a vector. Bivectors relate vectors, but work makes those features work.
In an application, its features comprise a coalition. Each feature contributes to the value a customer derives from an application to different degrees. Since I prefer to deliver features as networks of related functionality, or minimal marketable functionality (MMF), because it enables me to deliver some value to the customer, the economic buyer, earlier, allows users to learn the application over time, and allows a vendor to schedule their revenues and cash flows more consistently, I’ll focus on the MMF as the unit of coalition.
In the comment, Kenny Bastani, asked about a list of “features” that tend to be layers of crosscutting concerns or aspects, thus leading to Aspect-Oriented Programming (AOP). His considerations were
- Integration of CRM, data warehouse extracts, aligning vendors for product integration, designing a support strategy for all third party systems and data integrated into the product?
- Security risks for centralizing a data layer from so many different systems?
To get our hands around this, we can consider each aspect to be a vector. When I talked about bivectors in the previous posts, I summed them up into a single technology vector, a single product vector, and a single business components vector. Vectors sum up easily enough. But, let’s take a more expansive look at the base vectors that were summed up.
Back when we sold technology, instead of a webpage, the product was built on top of a technology. Customers bought the product, but installed and configured that technology before the product would work. Much of that technology was already present in the product. The product wouldn’t install otherwise. With webpages, we use a server, a browser, tons of technologies, but we don’t sell any technology. Our products are not fostering adoption of some technology. The underlying technology has already been adopted and for the most part is situated in Moore’s late mainstream market, much of it approaching the horizontal asymptote at the top of their S-curves. These technologies that we use, but don’t sell per se, are our whole product components. The cloud likewise, our whole product components. In this figure the whole products are shown as one summative vector, instead of as a collection of individual vectors representing each component. Notice that the granularity and summative vectors or not is up to you.
I’ve shown two technology vectors to illustrate that a vendor that actually sells a technology will always need a second, subsequent, discontinuous technology available to switch to when the initial or prior one commoditizes. In my Slideshare presentation, I summed these vectors and their S-curves, starting with slide 53. But, in the Framing Post For Aug 12 Innochat: The Effects of Booms and Busts on Innovation, I came to realize that not only are these technologies discontinuous, the market is likewise discontinuous. Why this surprised me is just that I knew this for discontinuous technologies, you can’t sell the next one to your current market, but I had not extrapolated that to the vector and s-curve visualizations.
For both the product and business components in the offer, I used a shorthand, the eigenvector to build those vectors. Why shorthand, well, I’m not showing that each minimal marketable function (MMF) or business capability (BC) need not be aligned. Showing them aligned was just quicker to draw. The current representation isn’t like an eigenvector, in that eigenvectors are used as unit vectors. I do think of MMFs that way, because MMFs originated with feature-driven design (FDD), an agile approach, which means that a single MMF is delivered in a single release. That release is a timeboxed across all releases. Think one per quarter and tie it to the quarterly revenue goals of the subsequent quarter. The BCs are another matter. By capabilities I mean not just processes, abilities, people, but also policy. Policies arise or are explicated from implicit expectations in a mostly reactive, event-driven manner.
A company can be represented by its cost structure and policy structure as vector
This figure takes us back to the comment. Each of those aspects in the comment can be represented by a summative vector, or that vectors collection of base vectors. When all the vectors for an aspect share an origin, via translation, just because we want to do that, we end up looking at what linguists would call a morpheme, or a probability cloud defined by those aspect vectors. When laid end to end, we end up a road. The road shows us that we can get to a Shapely Value with any collection of vectors.
All of this goes to show us that we have our vectors of differentiation. Those vectors compete and collaborate. Those vectors have an internal price/cost and an externalizable performance, a performance relative to a market, large or small. Those vectors have populations involved with them, and from the Slideshare presentation that implies Poisson distributions, Markov processes, grammar, machine learning associated with them. Those vectors have triangle models associated with them and several other representations I have yet to discuss. Math is a massively distributed, collaborating population of various types like people, ideas, theorems, calculations all rolled up into a massive geography that no one is entirely familiar with.
So goes any IT system as well. Please, do your ITIL people a favor. Get a GIS system. They need it.
The math under the Shapely Value is easy. Google it until you find an accelerator that makes it easy for you. The point behind the Shapely Value is that the system has more value in it than that obtainable by its parts alone. This should make it clear that value is not at the interface, it is in the interactions deeper into the space of work where your feature feeds someone else’s, where emergence and radiosity tip their hand.