The architecture of enterprise strategy.
Architecture creates spaces for functions; Strategy creates functions for spaces. On with the show. Featuring ...taunts, riffs and reminders to find and fix the defects, omissions and errors in your enterprise mojo. Find or predict particular issues via the text-search tool, the archive categories, or (in the archives) the Topical Framework. To kvetch or co-conspire: comment on any articles, click here to contact me via email, or just gossip across your full six degrees of separation.
March 8, 2009
Networking Social Behaviors
With the help of the McKinsey gang, important thinkers such as Soumitra Dutta and Matthew Fraser of INSEAD are hosting discussions about how the internet and the recession might collide. Their angle: "When Job Seekers Invade Facebook". In their conversation starter, Facebook is offered as a venue that has its own culture, now threatened with an alien influence that could change the nature of social networking.
This is a somewhat romantic notion, best held by facebook's marketing and legal teams but not a plausible or fact-based reality. The concern wouldn't be how social networks behave; rather, it would be how social behaviors are networked.
Interestingly, it brings up the question of how much a given tool can control its users, versus how much design can flex to assure that the tool is fit to its purpose. What's not clear is that there is any cultural "end state" of facebook that represents its purpose. Instead, both on the surface and in theory, facebook is one of multiple grand collaborative experiments to discover what social "connectivity" really includes, with social propriety being a necessary but secondary concern. This experimentation seems likely to show ongoing morphing in what we see being social networking, but it hardly seems likely that a horde of unemployed invaders at one site will change social networking into something it is not already.
The dominant feature of the most popular social networking tools is that they are gateways to fundamentally public environments where privacy policy controls get applied. But the trick is that the policy applications are done based on personal preferences, and the personal preferences reflect many different cultures. It is unlikely that any one culture actually governs a social network unless the network's environment is administered according to some dominant policy model that proxies a culture. The default condition is that public spaces (like facebook) are polycultural, and that the less polycultural the space is made, the more constitutionally private it becomes -- just like a club. Punchline: unless internet economics eliminate the chance for more new "price"-free gateways, it is not social networking that will change, but instead the variety of social network venues.
There is some counter-thought to this that insists on some "critical mass" of members for a social network to be seen as useful -- and therefore in some Darwinian way likely to survive. This presupposes that the "natural" limit on the number of networks is a small number, since most networks won't offer enough richness to be worth the troulble. But I think this oversimplifies things by assuming (arbitrarily) that the "richness" (value) of a member of the network must be measured by the interconnections within that network. Real life shows that assumption to be silly; incredibly valuable people join and use networks on a very limited basis all the time; and, some small networks can be incredibly powerful, like the smoke filled back rooms of old. We'll remember that these smaller ones tend to be more private.
Rather, some members who are not "rich" when they join public networks have the ambition that they can achieve some richness within the network. That is precisely the current sex appeal of the term "networking", as used for painting in broad strokes; well, fine, as long as we don't pretend that social networking is actually hostage to any network.
Posted by Malcolm Ryder at 9:07 AM
February 23, 2009
Federation, Synchronization and Consolidation in I.T. -- a lot, but not enough.
Anyone who has done systems research or done the care and feeding of systems is familiar with the idea that a system is often made up of sub-systems -- for example the way that the human body is composed, or a good old-fashioned hi-fi stereo component hookup, or compounds made of molecules made of atoms. One of the key things to consider in managing the higher-level systems is that their sub-systems are indeed complete systems themselves and have their own internal complexities of components.
"CIs" are things that are similar to the above, in that a higher-level CI such as a "service" may be composed of other "sub"-services having, in turn, their own constituent services -- but this is why in the conversations about "CIs" in many companies, confusion develops amongst the terms "service", "system", and "component". Questions and even arguments follow this confusion, such as "when is a system a CI? Are all services CIs? Do components combine to make CIs? Do CIs combine to make other CIs?" This puts an end to the usefulness of speaking roughly.
So instead, if we take the term "Configuration Item" and break it down without regard to its actual linguistic history, we should think freshly: the term "configuration" means something on its own -- i.e., a certain arrangement of selected parts -- and the term "item" represents something involved in a configuration -- namely, a part. Any construction has a configuration, and the parts in the configuration are items. This conceptual abstraction is still easy language, and it completely covers the aspect of drilling down into one thing to find, among its parts, other things that each can likewise be decomposed. What follows below intends to apply such consistency across old terminologies as well.
For our purposes of discussion, the key construction is going to be some service that we want to have. As we'll see in the illustration here, there is an important and consistent way to discuss what is found in the drill-down on a service. Generally, we drill down onto two different kinds of resources for the service. On the one hand, sub-sections of a construction are what should be known as "components". On the other hand, the materials that are used to make up the subsection are what should be known as "elements". Like fire, earth, air and water, there are different kinds of elements; they combine to make up components that can be sub-sections of constructions, including of course constructions that have only one logical subsection: the unit whole. Logically, this is always true regardless of what particular construction is developed. But now, to address an earlier question, when is a construction a "CI"? And the answer is, a CI is not a thing; it is a management perspective on a thing. This thing might be an item or a configuration. What makes the thing a CI is management's attention to its role as an "element" of a service.
Now, when the main construction will be provided for use as a "service", and we are talking about the "components" of the service, we are referring to the configurations within the service. Remember that the essence of a "service" is in that it is something being provided for use in a given way; the type and complexity of a thing does not define it as being a service. However, logically, the components in the management view are the actual "instances" of whatever type of CI, since the instances are what the service user is actually reliant on.
Remember also that the configurations within the service are constructions themselves. What we must recognize is that for a construction seen at a "top" or "parent" level, the involved configurations have elements; but at a lower "child" level, those elements of the parent may be constructions for the child. In this way we see the drill-down through a structural hierarchy based on a recurring logic. For pragmatic reasons, organizations increasingly adopt names for the different levels, such as "Business" (parent), "IT" (child), and "Systems" (grandchild). By this logic, systems configurations become items for (i.e., elements of) IT configurations, and IT configurations become items for business configurations. Meanwhile, "services" may occur at any level, because what defines a service is how something is provided, not what something is.
What is more interesting, then, in this whole thing is not so much the parts (items) themselves but the relationships that become the structural arrangement (or actual configuration) within the construction provided as a service.
In a management scenario, relationships become important mainly because, not surprisingly, they make the configuration manageable. This intent immediately makes some relationships more important than others depending on the perspective of the particular manager. And most interestingly, it throws attention on items (parts)that are not "equipment" such as hardware and software, but instead are "instruments" such as supervisory people, or regulatory documents -- indeed, any influential entity that can be logically assigned (i.e., related) as an enabling part in the ongoing functionality of the construction.
Now, since one of management's primary concerns is to establish and maintain the appropriateness to task of whatever is being managed, then another large focus of management is configurability. To throw quality control into configurability, there is initially the aspect of design, and quickly thereafter the matter of change-control.
The design side of things calls for specifications, which basically are descriptions of the particular configuration and/or item that is intended to be realized. With design and specifications, many instances of the same type of thing should be possible to produce with sufficient similarity to make the instances interchangeable if necessary, but all of the instances would be examples of a specific and unique version of a specific and unique model.
The value of specification is in its precision, which allows managers and users to have confidence that they have their hands on exactly what they need. The specification may point out that there are characteristics of a configuration that are produced or contributed by supplier X while other characteristics are given by supplier Y.
Keeping a central library of trusted configuration descriptions is the idea that gave birth to the Configuration Management DataBase or CMDB. In a CMDB, it is usually the case that configuration characteristics are identified as parts meeting specifications called "attributes". It stands to reason that a CMDB needs to gather reliable data from multiple suppliers responsible for the attributes of any of the configurations on record. The problem of managing the CMDB itself, then, is no different from keeping any complex database in good shape. If anything, the degree of confidence that the CMDB users want in its data makes the complexity that much harder to cope with.
Centralization of the data is the easy way to describe the strategy for meeting the goal of a highly-reliable CMDB. To really appreciate what this means, it is necessary to understand "centralization" in three tactical ways that reflect and resolve the CMDB's complexity:
- federation,
- synchronization, and...
- consolidation.
Federation refers to the multiple donors of trusted information working in a co-operative manner so that they do not fail to contribute the right thing by the right time. As teammates, they need to all be on the playing field together when the play is about to be run.
Synchronization refers to the possibility that more than one party knows about the same thing, but they know it and talk about it in dissimilar ways. In this case, if one of them is more up to date in its knowledge than is the the other one, the other needs to get up to date in the terms that it uses to refer to the same thing. This paralleling, in which if A=B and B=C then A=C, calls for some mechanism that can assure the parties' two different terms (A and C) can again represent each other correctly in the same moment.
Consolidation refers to the case where multiple terms that refer to the same thing are reduced to one term which becomes the singular preferred referent, making the redundant others unnecessary.
Ideally, any configuration in a CMDB is an instance of some single type that is a successful consolidation of descriptions. Each unique type can have, theoretically, an unlimited number of instances.
In typical implementations, a CMDB may or may not be federated, since the CMDB might be held responsible for only certain types of configurations that could be confidently composed and described without multiple suppliers. Federation, always a possibility, is usually more the exception than the rule.
Synchronization is initially an issue when the first decisions are being made about which data sources are the ones that should be considered authoritative. If there are already multiple systems recording descriptions of the same thing, they probably need to be checked against each other to see how well they match, before either one is chosen over the other. This will be most useful when CIs are being initially defined for inclusion in the CMDB, since there is no point in recording a CI unless there is a trusted mechanism for keeping the record up to date.
As the above issues go, things tend to resolve in a way that there is not much discussion about federation, synchronization or consolidation (!) -- however, a different term is constantly used and rules the roost: reconciliation.
Reconciliation refers to the need to take recent validated discoveries about the characteristics of actual instances of configurations, and compare the findings to the record about those configurations as found in the CMDB. Updating the CMDB records means that the recorded versus discovered information must be checked, with mismatches resolved through a manager's decision about whether to change the CMDB record or change the actual configuration instance. Because a CMDB is not trusted unless it is known to be up-to-date in its authority, reconciliation is a critical success factor for the CMDB utilization. However, in a little recognized nuance, "reconciliation" is often mis-applied to the effort to remain up-to-date.
To appreciate this nuance, consider that two parties start out disagreeing, but they wind up agreeing with each other in the end. This would be reconciliation. However, if the two parties cannot agree with each other, and a third party is required to make the decision for both of them, then the original two parties (still disagreeing) did not have a reconciliation but instead an arbitration. An important thing to note here is that an arbitration effort can always come up with the same results that a reconciliation can, but a reconciliation effort cannot always come up with the results that an arbitration can.
It is often the case that I.T. managers rely on a mix of tools providing highly reliable feedback each in its own terms. This sets up the important necessity for arbitration to the degree that the tools do not share a common descriptive dictionary. Arbitration rules enforce "tiebreakers" and properly dispose of exceptions; this clears the way for consolidation of information within the CI record.and brings the CMDB closer to the capability that management really wants the CMDB to support -- risk avoidance in decisions, under the pressure of Quality of Service expectations.
Posted by Malcolm Ryder at 4:17 PM
February 19, 2009
Innovation Revisited, Kinda
Wharton's project with the Nightly Business Report convened a panel to select the top 30 innovations of the last 30 years. A key problem for the panel was to have a working definition of "innovation". And the next key problem was to rate the importance of innovations against each other.
Listing signature characteristics of "importance", the panel came up with this:
-Impact quality of life
-fulfill a compelling need
-solve a problem
-exhibit a "wow" factor
-change the way business is conducted
-increase efficiency
-spark new innovations
-create a new industry
Like many lists, this is a collection of "notables" that leaves open the matter of which ones may overlap or compete with each other. That might not matter except that the list is one of competitive "qualifiers" or "criteria", so we need to know when to apply them, and when not. It doesn't make sense that all of them would apply to every issue thought of as an innovation, so it's fair to imagine that some kind of categorization is implicit in the list. To investigate that, let's reorganize the list a bit.
1a. Impact quality of life
1b. create a new industry
1c. change the way business is conducted
2a. fulfill a compelling need
2b. solve a problem
3a. spark new innovations
3b. exhibit a "wow" factor
4. increase efficiency
Group 1 clearly shows what we want innovation to affect. Life, industry and business are of course strongly interconnected because they co-exist in a shared environment, and they co-operate in the creation of that environment.
Group 2 clearly shows "how" we want the innovation to affect any of the members of Group 1.
Group 3 clearly, but somewhat abstractly, represents a sense of "why" -- of whether the innovation is compelling due to the "push" of its character (sparking) or the "pull" of its character. (And these would not necessarily exclude each other.)
And Group 4 is a throwaway. The mystical attracton of "efficiency" might be nicely appreciated as a need to avoid waste or resistance; but at best this is a type of micro-problem to be solved, and at best it should be a member of a list of various things dealt with by group member 2b. Additionally, the different members of Group 1 probably have some micro-problems in common, but (for example) surely the idea of inefficiency versus "quality of life" is not the same as inefficiency versus "new industry". So going ahead, we'll drop it (at least until the other worthy micro-problems, from various perspectives, are also identified).
What the new grouping offers is three dimensions of consideration -- the what, how, and why -- that ought to account for the competitive inclusion of each given innovation in the Top 30 list. 3-D space is of course a framework, and with a framework in hand it should also be possible to anticipate (predict), find (detect), and position other issues that would be candidates or actuals of "innovation"...
We don't know exactly how much the panel may have made decisions this way -- whether explicitly by agreed formula, or intuitively. But for the panel, there was also the prior matter of defining an "innovation" in the first place. Their definition was as follows: "It's something new that creates new opportunities for growth and development", which resulted in "a list dominated by technological and medical advancements".
Let's go back to that loose end of "inefficiency", though. With this panel, it seems either clear or feared that inefficiency is a major thorn in the side -- perhaps the single most aggravating barrier to innovation itself? This would be an indicator that innovation is perceived almost entirely in the context of an already known or targeted outcome, objective or goal. What else could the context be?
For one, conspicuously absent from the list is both (a.) specific unprecedented "concepts" and (b.) virtually all "fine art". In other words, nothing having to do with the evolution or revolution of consciousness made the top 30 list. Granted, the initial invitation to compile the list most likely did not try to attract a range of candidates that included those two. However, aside from entertainment value, what is the point or use of a Top 30 list? There will be those who study the list in order to try to understand where innovation comes from. And for that very reason, it is critical to survey as well the growth and development of the mind that we will eventually watch, hire, or follow because we expect innovation from it. It was Einstein, wasn't it, who said that "To raise new questions, new possibilities, to regard old problems from a new angle requires creative imagination and marks real advances in science... The significant problems we face cannot be solved at the same level of thinking we were at when we created them." The most important innovation(s) would be ones that allow, or even force, us to think in a different way than we did before.
And another take on context involves the ability to undertand growth and development not as checkpoints towards a known or certain end, but instead as evidence of new potential and/or capability despite being accompanied by uncertainty. Normally we reserve the term "innovation" for something that we can retrospectively view; but the difference here is that the desired certainty need not be about what comes "next" due to the innovation. Instead, it can be about "what became different" from a past known or shown to be obsolete. In this sense, a surprise encounter with something that already exists, but that is a clear alternative that might then be adopted, makes the adoption itself an innovation, and should be understood alongside our interest in inventions.
Posted by Malcolm Ryder at 8:53 AM
February 16, 2009
Consent and Dissent: the Decision Gate
In the four key scenarios, the decision-maker reacts to a suggested change in different ways. Meanwhile, there is no guarantee that, at the end of the path, acceptance will be reached. The change-presenter must determine which paths need to be navigated, and what sequence is called for. With that, the suggested change that is input to their decisioning may finally be output as an agreement.
- The idea of change that is being presented may in effect test the decision-maker's current level of acceptance. This is mostly like marketing for the purpose of highlighting a match between what both parties prefer. Messaging would be important here.
- More challenging than that, for the decision-maker, is being caught by surprise when the suggested change provokes some new or latent realization (discovery) that must be considered. Education would be important here.
- The third possibility is that an already acknowledged option is presented with higher priority, based on the attractiveness of its expected impacts. For the most part, selling is useful here, insofar as it emphasizes and offers the new availability of favorable future positions for the decision-maker.
- If the suggested change is not conceptually new to the decision-maker, but has not previously been acknowledged as an option, then the situation is most likely to initially be about considering trade-offs between the proposition and any personal alternatives believed to exist. Analysis would be important here.
Described more tersely, the factors that "gate" a decision include identity, knowledge, future value, and opportunity cost. Taking those factors as elements of a campaign, and orchestrating them to work with each other, the change-presenter can strategically and proactively design the presentation to the necessary audiences.
Posted by Malcolm Ryder at 8:44 AM
February 9, 2009
Street Smarts
In the post Gut Versus Analytics: What's the Real Story?, Intelligent Enterprise's blogger Neil Raden riffed on an article from CIO Magazine citing takes on research by Accenture and Forrester.
The key sub-topic here is about vendors of BI and Analytics allegedly and programmatically prioritizing subjective instinct over objective calculation [my summary labels].
If that characterization of the choices is a left-vs-right choice (x-axis), I find it distracting and not as useful as a top-vs-bottom (y-axis) difference.
Namely, it seems almost always more useful to approach analytics as a way to take things apart, and BI as a way to put things back together. For example, it might really take only 4 (not 4000) data points to spot a trend, etc., but the magic would be in picking the correct four data points first. So wouldn't we expect "analytics" to help us pick the right four, and "BI" to tell us about their effects and co-effects? Do we need an industrial do-over to get tools orientated this way?
This relative difference is far more interesting than the difference between the brain and the gut, since in this view you get to use both organs on both the take-apart and put-together efforts.
Moreover, if the issue is really about "how managers decide what actions to take", then let's consider this real-world observation: actionable decisions and decisive action are not the same thing; the politics of the manager's position in the organization will sway things one way or the other.
Generally, the first decision made is about which evident problems the manager prefers to solve, whereas the first action taken is generally based on opportunity cost.
Those bases change from person to person and from time to time, but nearly all organizations try to implement some kind of policy or other standard(s) to bring about consistency in what is acceptable as "preference" and "cost".
The point is that the tension is not between the head and the gut; rather, it is between responsibility and accountability, each as practiced under the prevailing terms of risk and reward at the management venue.
Posted by Malcolm Ryder at 11:01 AM
January 22, 2009
Notes 3.0 about Web 3.0
What kind of company could take advantage of the revealed "deep structure" of web 3.0? A company managing the intersections of community, culture and market.
Off-the-cuff example: a fictitious merger of Neilsen, Harris (polls), and Yahoo would go to market providing interactive services to web users that, within legal constraints, could acquire enough feedback and observation to discover hugely rich profiles of users and groups and offer the profiles in B2B transactions and public service sectors.
Posted by Malcolm Ryder at 9:50 AM
November 27, 2008
Notes 2.0 about Web 3.0
Overview: online capabilities in search, collaboration and invention follow each other in a cycle driving the evolution of the "Web" from earlier levels of maturity to later greater levels. This diagram illustrates the interrelated dynamics.
Each of the capabilities continues to increase in functional sophistication and reliability over time. For each respective capability, this change broadens its range of usefulness, which increases the range of user-roles that may adopt it -- as in, adapt tasks to include it in the task. While each of the different basic roles -- Producer, Provider, and Receiver -- will take advantage of enhancements, the roles respectively tend to drive particular rates and types of enhancement of some capabilities more than others. This relative difference is represented by their positioning in the diagram.
Interaction of the roles is selective but continual, as all are active all the time. It is important to accept that much of the "selective" interaction is speculative; however, any person in the role may program the interactions in various ways, such as to cultivate a particular scope of interconnectivity:
- one-to-one
- one-to-many
- many-to-many
- many-to-one
... or perhaps to fulfill responsibilities or special interests that reflect the following dynamics:
- Cultural: especially involving attraction and development; driving and/or driven by identity; strong focus on designing
- Community: esp. involving development and distribution; driving and/or driven by policy; strong focus on building
- Market: esp. involving distribution and attraction; driving and/or driven by economy; strong focus on exchanging
Those three fundamental "interest groups" are not simply points-of-entry into the web; instead, they are dominant perspectives within which web interactions and facilities are discovered, recognized, weighed, formulated, and so forth, by web users. As seen in the diagram, web interaction amongst roles facilitates a point of view and goal (design, build, exchange) that is characteristic of each perspective and has a high priority in the group view of potential web operations. As the web interaction becomes more and more enhanced and reliable, the web as a whole is perceived to evolve to a next generation for the benefitting users (or stakeholders).
The table below gives a closer look at the underlying architecture of an existing facility in use on the web, in generic terms of role and task. As discussed in the companion article Notes 1.0 about Web 3.0, the notion of "web content" is a high-level abstraction signifying what the web user supplies to the web and/or accesses the web to use. The related architecture accounts for what exists on the web as components of content, which may be intermixed, coordinated or integrated across roles to generate a more complex web facility.
The terms in the table below generically label what each role is looking for on the web and why -- with the background assumption that these items are engineered and reengineered over time to fit the particular "type" of player (e.g., student, artist, businessperson, scientist, etc.) within the role. As an example, the end-to-end architecture of acquiring an email, or purchasing an item from Amazon, or manipulating an avatar in Second Life can all be described in terms of the production, provision and reception activity involved, per the different parties that see to the main roles being satisfied. So, for example, while web content such as "stock", "factory" and "platform" is specialized to the involved Producer, the combinations of web content across the Producer, Provider and Receiver ultimately makes up the facility that the receiver may call email, Amazon, or Second Life.
To reiterate a key thought from the earlier Notes 1.0 article, the most interesting thing about the "web", after all, is that the interconnectivity and maturation allows a given participant to play multiple roles -- either concurrently or differing from time to time. The significance of discussing "generations" in web evolution is mainly in the degree to which a generation indicates reliable and adequate support of the user's intended activity. This will derive mainly from the enhancement and maturity of the web content in the web architecture.
Posted by Malcolm Ryder at 8:25 AM
November 22, 2008
Notes 1.0 about Web 3.0
Earlier I have written about how and why I hate the "Web 2.0" shtick.
In fact, demonstrating the disregard, I've generally completely avoided any semblance of writing anything about it to anyone but an invitational or hypothetical audience. Nonetheless, the popularity of the subject leads one to things said by others that warrant being remembered and shared. In which case, there is an ethical responsibility to give credit where credit is due.
Example: by Googling the phrase "Web 3.0", find a path to Sramana Mitra and more than a year of comments about her Web 3.0 "framework". For latecomers like myself, Mitra seems to already have "celebrity status" -- albeit earned. I mention that only to point out that except for the internet's easy way of cultivating coincidences, I may have never heard of her (as I'm sure she has not heard of me). I think that very fact is one of the main and most simply profound points of having the internet at our disposal -- which is to say that it reflects more about the internet than it does about Mitra, a point about which I hope she would share my appreciation. And it should fit into her greater scope of thinking about the web.
Suffice it to say that her framework for defining Web 3.0, offered as a catchy formula (Web 3.0 = 4C + P + VS... see for yourself), provoked me to say what I have said on her website's comments and again said below. I do not agree with her definition of web 3.0, but what I'll say below is a part of a different framework that can contain the points covered by Mitra's framework or formula.
Web 1.0, 2.0 or 3.0 have different definitions depending on what kind of stakeholder is given top priority amongst the many different kinds.
Let's overgeneralize and start by pointing out that the difference between having the web and not having it is simply that the web (the "internet") is another place a person can go to do something.
The biggest difference in stakeholders is between Producers, Providers and Receivers.
All three types are consumers, but they go to the internet to consume very different classes of "content"...
- Content is simply the material that the receiver needs, that they don't already have, in order to execute individual tasks to a conclusion.
- A task can be anything from self-entertainment to industrial development.
- In every case, the task is executed to conclusion, with the content, within the "workspace" of the web, without leaving the web.
However, a better instrument for understanding the evolutionary dynamics would not restrict itself to debatable examples, but instead would explain why examples fit where they do. This calls for the abstraction of a model.
In web 1.0, the recipient acquired prefabricated content in a closed package.
- Search created a transitional opportunity to web 2.0 by encouraging choice of packages.
In web 2.0, the recipient acquired prefabricated content in a modifiable package.
- Collaboration and personalization created a transitional opportunity to web 3.0 by encouraging comparative and cooperative content sourcing.
In web 3.0, the recipient acquires modifiable content in a modifiable package.
- Lacking any better term so far, invention strikes me as the transitional opportunity to web 4.0, as ontologies and cultures begin to take over a greater percentage of activities *such as* the creation and materialization of new products, outside of (but in addition to) conventional corporate instruments and academia.
What then distinguishes one web "generation" from another is the notion that an adequate level of reliability in the given generation's degree of task support can be taken for granted by most stakeholders.
And what these definitions mean, in reality, is that at any given time, some stakeholders doing some things have already been at a different generational level than others doing other things. Meanwhile, over time, the technologies and practices that emerge and mature in a generation of the internet environment also "level the playing field" across different stakeholders.
This ongoing leveling (or maturing) allows any individual participant to go to the web for more and more of the various things that constitute the individual's range of interests. As a result, the participant inhabits the internet environment more and more.
Turn off the internet, and they go somewhere else to do all of the same things, with a lot less affordable speed and range at their disposal.
All that said, it makes less sense to talk about web 1.0, 2.0, etc. than it does to talk about the relative maturity level of the internet environment as a resource (e.g. support levels 1, 2, 3, etc.).
The most interesting implications I find are these two:
- stakeholders will remain distinguishable as types, but an individual participant will occupy multiple stakeholder roles simultaneously;
- and the individual can readily change, thanks to the maturing web, from being a recipient to a provider, or from a provider to a producer. And so on.
Posted by Malcolm Ryder at 9:15 PM
November 16, 2008
Control: Got, or Not?
Execution means operations, and whoever is behind the wheel must have control; otherwise we can pretty much anticipate that things won't predictably get where they are supposed to be, and/or that there will be a crash.Control of operations, by definition, means controlling the range of effects produced by driving a collection of interactions. The usual approach to tracking degrees of control is to put gauges on each one of the smallest number of critical states (conditions) produced within operations -- and to use real-time gauges as continuously as possible. The correlation of the information from the various gauges tells whether overall operations are proceeding within an acceptable range of behaviors.
The collection of gauges is readily recognized as a dashboard. But the correlation of them is where the actual control begins. The diagram above shows the Archestra model for this correlation.
The model shows how to avoid non-sense metrics and focus on essential observations and connections. For example, there is a shared boundary between Priority and Plan, where the sharing indicates the need for an instrument that coordinates the priority and the plan. The instrument is Policy. Meanwhile, the primary rational coordinator of Priority and Quality is a Standard. And for example, the primary rational coordinator of Accounting and Reporting is Rules.
Each part of the model is a part that has an independent definition and can be independently produced, implemented, tracked and changed. In putting all the parts to use, procurement and architecture and engineering are required to assure that they can interact in an appropriate way; while management controls assure that they probably will interact appropriately.
The explanation so far leaves two areas for further clarification.
First, the model shows four "parts" that are more like regions: Priority, Plan, Activity, and Quality. Many people may detect some similarity in this quadruplet to earlier models such as the "Deming cycle", so it is important to note that the terms in the Archestra model do not attempt to share the Deming vocabulary or any other. In the Archestra model here,
- Priority refers to identifying and grading preferences, which logically precedes the other three terms as a management or "controls" concern.
- Plan is seen as step two, by which priorities are organized to be actionable with presumed resources.
- Activity then logically follows the plans.
- And Quality -- although it is always a target and likely referenced in both prioritizing and planning -- is not actually in the sequence until Activity has caused some output or outcome that must be held against the need for quality. In a control model, the place of this last step is important because quality must practically pertain to all actuals, not hypothetically pertain to all possibles. In fact, a major intent of building controls to this model would be to achieve streamlining and transparency of observations about each part, so that as little time as possible is required to get awareness of whether priorities and quality are aligned. Misalignment is dealt with by corrections.
Second, let's take one of the four main items just discussed, for example Quality: the model shows that two of its shared boundaries are Standard and Process. But what about the other two apparent boundaries -- Practices and Goals? Frankly, this may be a flaw in the visual representation offered. However, the intent here is not that the Practices and Goals arrows connecting Monitoring, Modeling and Accounting are boundaries. Instead, using Quality again as the example, Modeling is the primary referent for Quality, and if Modeling is to be able to succeed as the referent for Quality, then Modeling must be logically complemented by the definitions of Monitoring and Accounting. Likewise, Reporting (aligned with defined Rules and defined Events) is the primary referent for Plans. And so on.
Customarily, Archestra models offer "maps" to use for identifying defects, discontinuities, or other problems that exist in an already active environment. The model is an abstraction and can be taken prescriptively, but it does not assume that the actual environment is already organized as illustrated. The argument of the model is that its illustrated organization can comparatively expose an important disorganization in an existing actual environment, and help to promote the source of the disorganization to a high level of corrective attention.
Posted by Malcolm Ryder at 8:56 AM
November 1, 2008
What Matters versus What Counts, Encore
Any time you're busy with analysis, construction or movement, you're working on "distinctions". Such efforts generally result in ideas like Part X not Part Y or more vs. less; newer vs. older; or near vs. far (and here vs. there) ... These general differences each go on to be both specified and named with much more precision, for particular situations.
These efforts aren't happening by accident. So we often take it for granted that we should really bother seriously with their outcomes. But this default attitude might be a mistake.
Now that John Bogle's new book Enough is published, one of the fundamental concepts underlying archestra's separated definitions of "value" versus "worth" will be in the spotlight on a multinational basis for a while.
Outside of the book, but to recap archestra notes, there are a number of ways to summarize the working idea involved, such as the three cases below. In all of them, there is the underlying base dynamic that some kind of effort, let's call it work, is producing some measured distinction -- more... better... enough, or whatever -- that didn't exist before the work was done.
But all of the cases point at the need for understanding that unless we know what matters, counting by that measure is always possible but risks being (at least) irrelevant or even (at most) irresponsible.
The Who Cares Case: In this instance, unless a distinction causes us to consider each element it creates in some way different from before, the distinction would not be "significant"... But if the distinction is significant then we say it has value. Still, the value that it has may be irrelevant to some parties, while crucial to other parties. So that same value has a different worth to one party versus the other. The problem, then, is in diligent pursuit of a worthless value.
The Hero Case: in this instance, the usual reference is the old saying "it's not whether you win or lose, it's how you play the game." On that note, first consider the ersatz "Government Employee's Credo" which says:
We the Willing,
Led by the Unknowing,
are doing the Impossible
for the Ungrateful.We have done so much,
for so long,
with so little,
that we are now Qualified
to do Anything
with Nothing.
The issue being described, by the largely "invisible" public service workforce, is really the issue of character, which is often described as "the quality you choose to exemplify when nobody is watching". This is pointing at the decision to pursue the correct value, especially in the face of substantial opportunity (or worse, pressure such as from politics, greed or fear) to avoid responsibility for pursuing it.
The Do the Right Work versus Do the Work Right Case: In this case, the issue comes up in so-called "performance" measures, where confusion between compliance and progress is rife. The classic examples today are problems such as "learning to test well" versus "acquiring actionable knowledge"; the pre-crash share price of Enron; and of course the ever popular joining up with the legions of "the unhappy rich". Scorekeeping is seemingly inevitable, but there's nothing better than keeping the wrong kind of score to put new clothes on the emperor.
In short, value is what counts, but worth is what matters. Sadly, so much of what appears to be valuable can easily turn out to be worthless.
Posted by Malcolm Ryder at 9:33 AM
September 22, 2008
The Busyness of Information
MicroStrategy has published an online article about the 5 Styles of BI, which is interesting primarily in its view that these are operational styles that "evolved" in the form of tool functionality.
It might be more precise to say that the article promises understanding of the adoption of BI capabilities by the currently recognized differing types of BI users, which are relabelled and listed here:
- activity monitors
- managers and dataset explorers
- information explorers and power users
- professional information analysts
- information subscribers
This offers a view of how business is learning to adapt to BI technology so that the tools can be more effective. The individual user may find it easier, as well, to identify where he or she fits into the big picture of possibilities. In turn, that refines demand for the BI tools and helps to organize deployments.
But to get a real grip on this, it makes sense to reorganize the groups into producers, providers and consumers.
- Information Producers find and manipulate data to create information appropriate for describing and distinguishing events and conditions.
- Information Providers group and package information for managed delivery to designated recipients per requirements mandated by rules and/or agreements.
- Information Consumers receive and examine packaged information to determine what correspondence its included descriptions and distinctions may have to prior expectations and/or to prior received information.
What makes this more complex is the accompanying issues confronting each party (producer, provider and consumer) such as:
- formulation (validation/certification) of information
- formatting of information
- information access methods
The challenge, then, is to establish logical connections between how producers solve those three issues, how providers solve them, and how consumers solve them.
(You've read the book; now see the movie!)
One continuing dynamic affecting that interconnectedness is the shifting balances between the willingness of the different parties to use solutions offered to them versus working up their own solutions. The shifts occur from time-to-time, from place-to-place, and according to prevailing levels of urgency and risk. This brings up the matter of standards and governance in the overall BI "practice", but from an evolutionary perspective it is most likely that "standards" must be seen mainly as negotiable "agreements" that are living (changeable) but socialized. Given that, some agreements could become jurisdictional (e.g., consumers should not force information formulation) and others may become promotional (e.g., providers should diversify for consumers) -- which sets the stage for different roles to be defined and anticipated in the organization's ecosystem of BI.
In BI, there are also higher-level operational problems to be solved such as how to compare word-of-mouth with statistical analysis, or how to repackage existing information on demand for a different party. It is fair to say that the day-to-day experience of business is pretty rich with such higher-level "BI" problems, and that the presumptive evolution of BI should be describable in terms of what solutions to these problems have turned out to be most broadly feasible. These may generally surface as "use cases" during the construction of RFPs or in the design phase of implementations, but without a survey it is difficult to know whether they are usually seen as necessary or just nice to have, short of any Darwinian force they might prove to exert. What may be the most interesting question of all, then, is this: increasing rationalization of different tools makes BI more likely to help advance the cause of businesses, but isn't it still mainly the case that BI is adapting to each business more than that business is adapting to BI? No harm meant in the question: the point is only to encourage adequate attention to managing the internal business environment of participants (producers, providers and consumers) before making valuations of a BI tool's importance.
Tools referenced in the MicroStrategy article:
- Enterprise Reporting - incl. scorecards/dashboards
- OLAP Cube Analysis
- Ad Hoc Query and Analysis and automated OLAPslice and-dice into all data
- Statistical Analysis and Data Mining
- Alerting and Report Delivery
Posted by Malcolm Ryder at 5:46 AM
September 17, 2008
Business Process vs. Business IT: again?
These frustrate the chances of recognizing "a business process called IT".
On the one hand, this is hard to overcome if people don't say what aspect of IT they mean to identify when they say "IT". An interesting point to put on the matter is that the primary expectation of IT users is actually "process management automation" -- not the same problem to solve as "information management" nor the level-setting about which sanctioned company processes are strategic/tactical/operational.
On the other hand, the word "alignment" itself continues to provoke and refresh the difficulty of reaching "I get it". The more important term to emphasize is not "alignment" but "integration". Imagine that some decision-making sector called "Business" was not integrated with the decision-making sector called "Finance". Since managing IT, like managing Finance, creates and governs a critical dimension of the business operational environment, some businesses cannot be dis-integrated with it and still rationally expect to succeed.
What might be really interesting short-term is to see and compare what stances about "alignment" come from CEOs who are Lawyers or are Technologists as opposed to Finance alumni.
Furthermore, however, as long as the "alignment" banner keeps getting hoisted by analysts and pundits in the trade, they'll keep educating CxOs to think about things in the wrong way. When it comes to IT, CxOs should be working on the management process competency at all levels -- an approach that would make it more obviously the responsibility of CEOs and CFOs to cultivate, not just for CIOs to offer.
Posted by Malcolm Ryder at 10:04 AM
