« Project Fault Lines in Implementation Designs | Main | The Art of Aligning Alignment »

October 18, 2005

Generating Network Value through Services

When Network Computing magazine recently changed its name to "IT Architect", it triggered recollection of this observation: a network is a coveted environment, so we emphasize the quality of that environment; but the value of it is in the design of its usage. Why is this instance of stating the obvious any more interesting now than during the last few years?

I.

In answer, one general thought is this: now, a huge proportion of our assumptions as productive people, about achieving needed performance, rest on embracing at least an abstract notion of "networking" -- sometimes on multiple levels of operation. Whether our management agenda is about job-hunting, workgroup teaming, espionage, market collaboration, or distributed industry of any kind, the presumption is that prevailing performance level standards for "success" will require interconnectivity that generates synergies (more bang per buck) and that overcomes (i.e., navigates) environmental complexity.

But why consider networks in any expanded sense? Because, a failure to acknowledge organizational principles behind a network leads to lost opportunity and an inability to resolve problems inherent to "networked" environments -- which, because of the above noted reasons, are becoming the rule (not the exception), if not ubiquitous.

Practically, we approach a network as a production environment for some work to be done. And typically, the reality is that as individuals we encounter networks that are already in place. So we have to learn to use the network, i.e., to train ourselves. This accounts for the regularity and range of what we do.

But the mere fact of interconnectivity does not "make a network work." Instead, we think that the network is working when it turns out that it enables what we want to do. Admitting this tells us that we don't think a network is valuable unless we expect it to satisfy our requirements. How do we get the network -- whether it is an information system, an organization, a knowledgebase, or whatever -- to meet those expectations?

We train it. That accounts for the regularity and range of what the network does.

II.

At face value, labels that switch from "computing" to "architects" seem to shift attention from usersto providers. But more importantly what happens is that thinking shifts from the increasing momentum of experiencing the network as a "place" back towards seeing the network as a virtual construction.

Now we investigate the implications of training as the model for a type of value-adding dynamic construction or reengineering. Training designs behavior to correspond with requirements, and architects make the plans that render the design actionable. To "train" a network, an architect develops the network's enablement of services.

This is a shift that managers can appreciate. Before the shift, computing managers are struggling with trying to derive or rescue value through dwelling on network users' "negotiated experience" and its expensive preoccupation with remedial support. After the shift, they are focusing on "negotiated design" -- and its far less expensive preoccupation with planned services.

Because services optimally align the network user to the network capacity, we can take it as a general principle that services are what generates value from a network. Correspondingly, architects who enable services are on the critical path to the network's value.

Since we're considering an expanded definition of "network", two other thoughts related to that pair of findings also expand to capture familiar ideas in a fresh way. .

III.
First, we can readily see "architects" involved in all kinds of networks. The networks can be systems, teams, communities, and other entities that are formed from designing environmental interconnectivity to support distributed industry. The architects are engineers, coaches, policy-makers, and many others who we often call architects only after-the-fact; but we ultimately credited them with being the architects because they designed the interconnections we recognized that assure our prescribed requirements can be functionally met.

For example, the writers of Sports Illustrated consider the Hall of Fame candidacy of (as they state it) Lakers assistant Tex Winter, 81, the architect of the triangle offense and Phil Jackson's right hand man during all his championship years in Chicago and L.A.

Second, if a network's value originates in its services, how does the idea of a "service" pertain to small "networks" like teams? By analogy, this calls for understanding the "use of the team" -- as in what requirements the team must support. Here, the idea of services will correspond mainly to the "responsibilities" defined around the capabilities of the team, which organize the team to execute things relevant to the requirement.

Does this make sense? Well, as a demonstration, by stitching the two thoughts together we can ask, "what is my network responsible for?" -- and this leads pretty directly to defining services. On the other hand, if we don't know the answer to the question, then it is nearly impossible to decide what value the network has. Naturally, a trained resource is more valuable than an untrained one. A network is a resource.

Finally, it should be taken as words to the wise, that pursuing collaboration, social networks and other interconnected environments as an organizational strategy will likely yield meager results or even counterproductive ones if the services are not first defined for those environments.

(Note: the above comments are not intended to mean that IT Architect magazine has actually changed in any way other than in its title.)

Posted by Malcolm Ryder at October 18, 2005 7:58 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/146

Comments

Post a comment