The Politics of Codes

In the UK, the Royal Mail is celebrating the 50th anniversary of the postcode [BBC News, 30 December 2008]. As far as the Royal Mail is concerned, the sole purpose of the postcode is to speed the sorting of letters and parcels.

However, the postcode is reused by other organizations for many other purposes.

• Postcode used in pension sums
• Postcode "lottery" - home insurance, GP services, social care, cancer treatment, ...
  

For this reason, some residential communities have appealed to the Royal Mail to have their postcode changed.

• Residents of Windsor don't like having a Slough postcode [January 2003].
• Residents of Ilford want to have a London postcode, which they feel will enhance their property values [April 2005].
• A village near Coventry wishes to have a rural postcode rather than be classified as a suburb of Coventry [July 2008].

But the Royal Mail is unsympathetic to all such requests. After all, it's not our problem if other people choose to repurpose our codes, is it?

Social Networking as Reuse

Just been reading an excellent blog post by Tim Berners-Lee about the Giant Global Graph, telling a familiar story in a powerful and elegant fashion, and describing the development of the internet and semantic web in terms of increasing abstraction, interoperability and reuse.

• The Net - full name International Information Infrastructure (III). Abstracting away from the wiring to allow interoperability and reuse of computers.

• The Web - full name World Wide Web (WWW). Abstracting away from computers to allow interoperability and reuse of documents.

• The Graph - proposed name Giant Global Graph (GGG). Abstracting away from documents to allow interoperability and reuse of resources and relationships.

Berners-Lee focuses on the interoperability of relationship descriptions - friend-of-a-friend (FOAF) descriptions and the like - but of course these can be regarded merely as a special kind of document - a document that happens to be expressed in the form of a graph.

But that set me wondering about the next logical step. For some people at least, social networking is not just about finding new acquaintances (so-called "friends") but also finding new ways of connecting with existing acquaintances. I accepted a Linked-In invitation from someone I'd corresponded with on a Complexity-and-Management mailing list, and found myself deluged with messages asking me (among other things) to vote for him in some local election in the USA and to buy real estate in Florida. While this kind of reuse might be regarded as at least a breach of etiquette, if not downright spam, it is not unusual for people to try and forge business relationships with people they have met socially, and vice versa.

Why do wealthy people send their children to expensive schools? Not just because it gets them a better education, and a better chance of getting into a better university but because it buys them into the "old boy network". It is not necessary to know exactly how the child will benefit from membership in this network to be convinced of its value (and the disadvantages for those excluded, for whatever reason).

Here's a fictional example of the old boy network at work. An executive within the prawn sandwich industry talks to a journalist who is the Chief Sandwich Correspondent of the Daily Prawn, and is told about a plan by the National Prawn Authority to reduce the permitted level of iodine. When she gets back to her office she picks up the phone ... The following week, she and the Deputy Prawn Minister both happen to be present at an informal lunch, at which the conversation happens to touch upon the iodine question ...

I think it might take a while before Linked-In and Facebook can replicate this kind of affordance. This is not just a question of shared semantics (meaning) but of shared purpose (pragmatics).

However, this example illustrates the kind of instrumentality (use-purpose) implicit in social networking. We may wish to use other people's knowledge and know-how, we may wish other people to use our own knowledge and know-how, and we may wish to help our friends as well as ourselves. What we don't want is to feel we are being "used".

But just as the net has changed the way we think about computers ("the network IS the computer"), and the web has changed the way we think about (hyper-) documents and (web) services, so the graph (if that is what we must call it) is going to change the way we think about friendship and about social protocols (etiquette in the broadest sense).

If there are many people who have the required know-how, it is the graph that tells me which one to contact. Do I pick the one that is closest, or with the strongest connections? Do I pick one who is as distant as possible from my competitors? Am I looking to pay back past favours, or to put someone in my debt? Or do I pick someone who is outside the usual bunch, who would help me extend my graph into new areas?

It is already a known phenomenon that people sometimes seem more concerned with the quantity of their "friends" than with the quality of their friendships. As we get better tools for visualizing the Graph (across multiple platforms), some people may start to worry about the shape of their graph.

In the old days, people who were obsessed with the social position of their social acquaintances (and would adjust their relationships with people whose social position altered) were known as snobs or social climbers. Now there are people who wish to know how many venture capitalists are contained in their FOAF graph, in how many different countries, and people who would upgrade an acquaintance when he moves from a university post to an executive post. Plus ca change.

So that seems to be the direction we are heading. The graph is not merely a machine-readable description of a social network, it is the social network itself. And the value afforded by social networking comes from abstraction and reuse. In which case, there are some challenging implications to explore ...

Carrot and Stick

Motivating Reuse

From a software perspective, one of the possible benefits of SOA is reuse.

The notion of "reuse" is inherited from previous waves of software technology: module, object, component. Over the years, we have been told many times of the substantial economic benefits to be gained from reuse (greater development productivity, substantially reduced cost, faster delivery, and so on).

And when the actual scale of reuse turns out much lower than the apparent potential, we are given a range of explanations (excuses). Perhaps that technology wasn't quite powerful enough, but this new technology will release floods of reuse. Perhaps the technology was fine, but the people weren't properly trained or managed. And perhaps this additional technology will force the people to deliver reuse.

If we want people to do things differently, we have to consider the three Es.

Enabling	Do the people have what they need to do things differently? Skills, resources, tools, infrastructure, support?	For example, if the technology supporting a different way of working is clumsy and immature, it may be impossible to adopt this way of working without compromising speed or quality.
Encouraging	Do the people (and their managers and supervisors) have a reason to do things differently? Motivation, reward (or sanction),	For example, if a project manager's status depends on having a large project team, this conflicts with any incentive to improve productivity.
Empowering	Do the people have the power to do things differently?	For example, if people are forced to work on narrow, short-term projects, under strong design constraints, they may not have the opportunity to produce reusable artefacts.

According to Jon Udell, Verizon paid particular attention to questions of motivation in implementing its IT Workbench.

Stick	Project funding is contingent on the contribution of sharable services to the repository.
Carrot	Developers required to use the repository -- like all employees required to use centralized corporate services -- are effectively paying a tax. And like all taxpayers, they want to see their tax dollars put to good use. Verizon says that its IT Workbench rewards developers by wrapping useful capabilities -- auditing, debug tracing, security -- around the services they develop.

source: SOA heroes

Udell also refers to the public recognition and praise accorded to those developers who adopt the desired practices, and quotes Blue Titan's Frank Martinez "Make them heroes". However, I have a slight qualm about this, to the extent that reliance on heroes is a sign of an immature software practice.

Motivating Sharing

But I no longer think that reuse is quite the right concept for SOA. It raises all sorts of technical issues about deployment and instantiation of a service, which are not directly related to the grand economic benefits of software reuse. People are starting to talk more about sharing services rather than reusing software.

Many of the enabling / encouraging / empowering questions are still valid. Of course we must look at the transaction costs of sharing, including both the costs to the individual (effort, learning, moving outside comfort zone) and the costs to the organization (trust, complexity). Sharing potentially exposes us to additional interoperability risks, which need to be properly understood and managed.

The main advantage of sharing over reuse is that it is much more meaningful to the business. Software reuse is fine as an abstract idea; but sharing services has much more concrete implications for business users, whose support can be mobilized to help encourage and empower SOA developers.

Technorati Tags: interoperability reuse SOA service-oriented

Green Coffee Beans

Here's a little gem from page 26 of the SAP Magazine (November 2005), talking about the Global Business Services (GBS) division of Proctor and Gamble.

To obtain high economies of scale, GBS models the entire process flow but handles only those processes that are not part of the company's core business. For example, procurement of green coffee beans is managed as part of snacks and beverages purchasing, while GBS assumes responsibility for the P2P system and the vendor accounting involved.

As I interpret this, the process is decomposed into asset-specific tasks (those that are specific to green coffee beans) and generic tasks (those that are common across all purchased items).

The purpose of decomposing in this way is quite explicit. There is no stated intention of outsourcing the generic tasks, and there is no suggestion that they are not part of Proctor and Gamble's core competences. But there is a strong economic argument for managing these tasks as shared (reusable) services; and establishing these as shared services allows Proctor and Gamble to strengthen the underlying competences. The basis for this split (despite what it says in the article) is not core/noncore but asset-specific/generic.

To design services with significant levels of sharing (reuse), it is important to separate the asset-specific elements of the service from the generic elements. Asset specificity is a key determinant of service value. But here's the problem. The models that are commonly used within IT for designing component and services are type models. This means that they are already generic, they are at a level of abstraction at which asset specificity is not visible. (You don't see green coffee beans on a type model, you just see PRODUCT. You might happen to know that green coffee beans is a specific instance of PRODUCT. But you cannot use the type model to design a service that is specific to green coffee beans - or even to analyze a possible requirement for such a service.) This argument applies equally to process models or capability models, to the extent that they reference abstract types such as PRODUCT.

Thus although the Proctor and Gamble solution appears intuitively reasonable, it is not the solution that would be produced naturally and unforced by following any of the popular service-oriented design methods. (Of course, if you impose an arbitrary apriori separation of core/noncore on the problem space, you can produce pretty much any result you like, but that's not the point.)

The popular design methods (and tools) are geared for efficient solution of fixed problems, and do not provide a sufficient basis for reasoning about reuse, adaptability, complexity, and all the other things that service-orientation is supposed to bring. Asset-specificity is an important economic aspect of a service, and service engineers need ways of understand this aspect.

---

updated to remove the little symbol between "Proctor" and "Gamble" which caused problems with my XML feed earlier - sorry

Reuse and ROI

Are services assets?

If you can double the use of a service, while reducing the cost of provision, then surely this represents an economic improvement. 

Roughly speaking, the economic efficiency of an asset may be calculated as a ratio between the economic output (e.g. average use-value multiplied by usage volume) and the economic input (cost of making and maintaining the asset). 

Does this mean that it is a good thing (from an economic perspective) to produce services with a decent reuse rating? Should we reward software engineers for producing such services? Should we invest software production resources in services? Not necessarily.

Economic productivity and ROI

Factory thinking calls for factory-style cost accounting. There is some dispute in the manufacturing sector about the DuPont ROI model, in which inventory (work in progress) is valued in cash terms. In lean manufacturing (at least under certain interpretations - see The Ghost of Sloan), inventory represents not asset but waste. 

So shouldn't we reward software engineers for not producing services? Should we perhaps invest resources in the destruction of redundant and wasteful and non-SOA-compliant services? 

And how should we calculate the ROI of a service? How should we calculate the ROI for a service factory? The conventional cost accounting methods don't seem to work very well here. 

There's a particular problem with calculating the value of off-chance and long-tail services - services with a marginal value for a large and uncertain user community. ROI calculations might be expected to guide service factories to producing rival versions of existing commodity services, rather than innovate into unknown areas.

SOA governance

How should service engineers measure (and account for) their activities? How do we make service engineering more accountable and transparent to its various stakeholders? 

Within a single enterprise, competition between near-equivalent services may often be suppressed, and developers may be obliged to use a single corporate service. Meanwhile, across a service economy, the emergence of alternative services may be a sign of a healthy SOA ecosystem. But pointless competition of proprietary services may be unhealthy. 

SOA governance must maintain the health of the SOA ecosystem, and this includes making the distinction between healthy innovation and unnecessary conflict and waste between rival services. This cannot be done by decree or regulation, but calls for a collaborative / emergent governance process. 

So what happens to a service that attracts rivals, loses its market share, and ceases to be economically viable? Should anyone invest in a new (and hopefully more reused) version of the service? If the ROI calculations are to be of any help in making such investment decisions, then we probably need to write off sunk costs, and concentrate only on the incremental costs. 

Inventory (legacy) starts to look like liability rather than asset. Thus SOA thinking is pretty close to lean manufacturing.

Reuse or Repurpose

The software world has spent many years talking about reuse, especially in the context of Component-Based Software Engineering (CBSE). Reuse is linked to the economics of scale/scope, and is supposedly associated with a range of benefits including the productivity of development and maintenance.

But as the focus shifts from components to services, the word "reuse" doesn't quite reflect the opportunity. To my mind, the word never made quite as much sense for services as it did for components.

A number of commentators are now using the word repurpose instead of reuse. (PCMag, Zapthink)

A lot of discussion of repurposing seems to be largely about altering the format of information to suit different devices, channels or media. Such discussion is popular in the publication/syndication world, with reference to RSS and repurposing content for internet distribution. It is also relevant for transmitting content to a complex array of new devices such as mobile phones.

• Dynamic Content Repurposing for Mobile Phones (Connection Software)
• DeBabelizer for Repurposing Digital Assets (Equilibrium Technologies)

I don't deny the technical challenge of reformatting, but to my mind the more interesting aspects of repurposing is where there is a significant variation in the context of use. What is the (end-user) purpose that may be served by the content? For example, see this discussion Repurpose or Perish from 1998, which raises some of these issues:

• the users' choice of how they want to get this information and how frequently they want it
• users adopting different ways of reading/scanning material on-line (lean-forward versus lean-back)

See also Repurposing Data and Services (May 2005)
For a humorous definition of repurposing, see Buzzwords for Nerds.

Repurposing Data and Services

Does it make sense to talk about reusing services, or should we talk instead about repurposing?

The word repurpose is largely being pushed from the data/metadata side, especially the XML/XSL crowd. XML is certainly relevant to technical reformatting and interoperability, but may also support data being put to new uses.

• IBM defines repurposing in terms of metadata, with specific reference to XML
• The Role of XSL in e-business Solutions (May 2001), by Mark Colan of IBM
• Xerox Research on XML Schema Management

Meanwhile, some examples of data repurposing look like old-fashioned data sharing. Look at this abstract, which (when you strip away the fashionable technology such as intelligent agents) is just finding new uses for existing data.

• Using Intelligent Agents to Repurpose Administrative Data ... (Jan 2004) (abstract)

The word also makes the bandwagon-jumping antics of some product vendors explicit. For example, following 9/11, Siebel repurposed its CRM software to deal with Homeland Security. (Government Computer News, Sept 2002) What's terrorism got to do with customer relationship management, I hear you ask. Well it does, in the same sense that an FBI agent might say "He's a tricky customer."

XML is very good for this kind of repurposing, because it operates at a level of semantic vagueness where it doesn't really matter whether "customer" means "customer" or "terrorist". To my mind this is both a strength and a weakness of XML. It seems to me that if we want to promote the repurposing of services, we need to explain how to design services that can operate with a calculated lack of semantic specificity, with weak preconditions. (But strong postconditions.)


See also Reuse or Repurpose (May 2005)

Chrysler Has New Product Process

According to AP, Chrysler has created a process to better develop, build and market new products. The process is based on the creation of 50 separate product innovation teams which would work closely throughout the design, engineering and marketing of Chrysler vehicles.

Dieter Zetsche, Chrysler Group president and chief executive, said the new process would result in a greater "commonality" within the company which could result in sharing vehicle platforms and components with the automaker's Mitsubishi unit. There is also the possibility of sharing components with Chrysler's corporate cousin, Mercedes Benz. Greater commonality also would mean reducing the number of different types of the same component. For example, Chrysler currently has 25 kinds of batteries. Wolfgang Bernhard, Chrysler's chief operating officer, believes that only five are needed.

Rich Schaum, executive vice president for product development and quality, said it was hoped the new process could accelerate the time it takes from idea to launch, with 18 months as an objective.

Source: Chrysler Hatches New "Process" (Associated Press, 12 July 2001)

---

The management of 50 separate "product innovation" teams brings up two important challenges.

• Product architecture - How is the car decomposed into 50 chunks with maximum cohesion and minimum coupling. Assuming a degree of loose coupling (engineering tolerance) between the chunks, what are the consequences of this for the performance and reliability of the whole car? And how are the chunks assembled with minimum waste and zero feature interaction? 

• Development coordination - How are interactions between teams negotiated and controlled? How are procurement and supply chain issues coordinated? 

Another interesting aspect of the story is how the corporate interests within Chrysler appear to line up. At least as it is being described by Chrysler senior management, the new process seems to involve a shift of power away from "creativity" and "design" and towards "marketing" and "finance" - these are Chrysler's categories, not mine. A corporate programme of common components also helps to cement the merger between the US and German operations, and may also increase the bandwidth of the relationship with Mitsubishi.

Originally published at http://www.veryard.com/sebpc/manufacturing.htm