For Whom

There are several enterprise architecture approaches (TOGAF, DoDAF, MoDAF) based on the work of John Zachman and his Kiplingesque sextet:

"I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who."

These six interrogatives are commonly presented as the columns in a table. There have been some suggestions (strongly resisted by Mr Zachman and his followers) to extend the table.

One of the extensions we’ve been looking at the CBDI Forum is the possibility of introducing a "For Whom" column. Because value (in SOA and the service-oriented business) is not just experienced by “The Enterprise” (regarded as a single centralized pot of costs and benefits) but may be distributed across a federation or ecosystem.

For example, does a service intermediary add value for the service provider, or for the service consumer, or both? Does a change in business policy improve the whole supply chain, or have we merely pushed the problems upstream? Does a security layer mitigate risk for the bank or for its customers? Does a compliance monitoring service protect the interests of the directors or the shareholders?

Some people have told me that this is already implicit in the "Who" column. Or perhaps it is implicit in the "Why column. But I don't believe that many enterprise architects currently interpret the "Who" or "Why" columns in this way.

"For Whom" is important for SOA when we start to look at service networks that span several organizations. One organization may produce a business case for doing some SOA, but this may only be viable if other organizations cooperate. Participation in a network is based on some form of self-interest (each participating organization gets out more than it puts in) and/or some form of governance (the organizations collaborate according to some agreed or imposed regime).

In addition, "For Whom" is important for security engineering. Some organizations focus their security on protecting their own internal systems against a narrow range of direct threats, but seem to pay little attention to a broader range of indirect threats against themselves and their customers. In my view, an organization such as a bank should take a 360-degree view of security, and should try to provide real security for its customers and their assets, as well as for itself.

Finally, "For Whom" is important for ethics. The distinction between "For Whom" and "Who" is similar to the distinction between "Customer" and "Actor" in Soft Systems Methodology (SSM). Some readers may be familiar with the SSM acronym CATWOE, which stands for Customer, Actor, Transformation Process, WorldView, Owner, Environment.

---

Philip Boxer, Modelling Structure-Determining Processes (19 December 2006)

Chris Bruce, Environmental Decision-Making as Central Planning: FOR WHOM is Production to Occur? (Environmental Economios, 19 August 2005)

Wikipedia: CATWOE



Related posts: Arguing with Mendeleev (March 2013), Arguing with Drucker (April 2015), Whom Does The Technology Serve? (May 2019)


Updated 18 August 2019 to emphasize the ethical dimension.

Service-oriented security 3

In a post called Preventing Identity Theft, venture capitalist David Cowan explains (referencing Kerckhoffs' principle via Bruce Schneier) why he regards protecting secrets as a lost cause. Instead of preventing people finding out your social security number, concentrate on preventing people abusing your social security number. Cowan enthuses about one of the companies in this space, in which he has invested.

Kerckhoffs' principle is that security should not depend on secrecy, apart from the key. Social security number is not a key - at least not in the sense understood by cryptographers. Another form of Kerckhoff's principle is Shannon's Maxim: "the enemy knows the system".

Gunnar Peterson uses a chess analogy for service-oriented security. The message is the king, and if you are not using WS-Security (and apparently only 28% of ESBs do) then it's WS-GameOver. This can be seen as another application of Kerckhoffs' principle: you don't make SOA secure by trying to obscure your web services - this just compromises reuse without actually improving security. You protect the payload not the design.

But what exactly is the payload here - the information or the transaction? By Cowan's argument, it may seem a waste of effort to protect the information. But of course if you are a commercial organization (say), you can't just leak people's private data with the excuse that everyone else is doing it so it's not worth protecting. The point is that you must protect the transaction as well, just in case the information is leaking somewhere else in the network.

Cowan thinks it is a good idea to provide a diverse set of security policies and mechanisms to the user. (See also his post on Doomsday Hackers and Evildoing Robots.) This supports my own belief in differentiated security.

Update

Not just commercial organizations leaking private data. See Henry Porter's comments in the Observer (Surveillance is really getting under my skin) about the ease with which the RFID chip on the new UK passport can be cracked, together with the casual unconcern of Governnment officials. FishNChipPapers comments:

"It is naive to believe ... you can build impregnable systems. Instead our government should be focusing on approaches, such as distributed, federated databases, lack of a common identifier to link into those databases etc to mitigate the very real risks."

Meanwhile, in his response to David Cowan, Chris Walsh asks whether the problem (together with the value of Cowan's investment) might be eliminated by legislation, "with a stroke of the pen". But I think Chris has answered this question himself by quoting Gerry Goffin and Carole King in the title of his post - "It's Too Late Baby".

Wikipedia: Differentiated security, Kerckhoffs' principle
Technorati Tags: SOA service-oriented

Reliability and Availability

One of the pleasures of being an industry analyst is that you get to read a lot of vendor material.

Yesterday I came across the following statement in a white paper by Jonathan Purdy of Tangosol on Data Grids and SOA.

"As Business Services are integrated into increasingly complex work-flows, the added dependencies decrease availability. If a Business Process depends on a number of services, the availability of the process is actually the product of the weaknesses of all the composed services. For example, if a Business Process depends on six services, each of which achieves 99% uptime, then the Business Process itself will have a maximum of 94% uptime, corresponding to more than 500 hours of unplanned downtime each year."

This might be true under certain circumstances, but it depends on how the business process is designed, and the degree of coupling within the process. A typical design objective is to compose services in a way that doesn't multiply the dependencies in this way. One of the principles of distributed systems has always been to avoid single points of failure, and this principle is surely inherited by SOA. When used intelligently, loose coupling and asynchrony should make a business more robust.

It is sometimes possible to orchestrate services in a way that that the reliability of the whole is greater than the reliability of the parts. Firstly, there may be underlying services that are not required for every transaction, so the reliability of these underlying services only partially impacts the reliability of the process. Secondly, there may be services that provide multiple or alternative provision of a given capability - alternative process paths can be defined to make the process more fault-tolerant.

That's not going to make the problem of reliability and availability go away of course, and there are undoubtedly some useful things that vendors such as Tangosol can offer in the physical implementation of SOA. And Purdy is right to warn his readers of the risks associated with complexity.

But what this raises for me is the general difficulty of reasoning about non-functional requirements. Do you add them, do you multiply them, do you average them, or do you need to perform a more complicated bit of algebra?


Technorati Tags: availability reliability SOA service-oriented Tangosol

Lost Bags 2

I posted something recently about my experience with Lost Bags, and made some service-oriented comments.

In a post entitled Bag Matching and Lost Bags, Adam Shostack points out that "Bag matching is a real security measure, designed to ensure that you're on the same flight as your bag. ... Shouldn't they not be letting 350,000 bags go astray every month?"

This error rate is a direct result of the half-baked security measures we all have to undergo at airports. There are restrictions about carry-on bags. So more people check their bags. So baggage handling systems are overloaded, and error rates increase. See my earlier post on Service-Oriented Security.


Technorati Tags: SOA security service-oriented

Business Case for SOA 3

ZDnet blogger Joe McKendrick has uncovered an interesting difference of opinion between stakeholders in the US Government and Defense space about the viability of SOA, as described in the following posts:

• Defense doesn't rest with SOA (Nov 10)
• Study: the public sector ‘gets’ SOA, or at least ’shared services’ (Nov 15)

The US Defense Information Systems Agency (DISA) seems pretty committed to SOA. The problem apparently lies with some large US contractors, who seem to think that this threatens a profitable line of business selling software to the Department of Defense. David Bryan, a retired general who is now a vice-president at Northrop Grumman Defense Group, says that "Industry is struggling to determine a sound business case for the SOA approach". [source: FCW.com, Nov 8]

There are four things I want to say in response to this, which relate to the business case for SOA.

1. The Department of Defense evidently appreciates the potential of strategic-level or Enterprise SOA to reduce their IT costs and to improve the efficiencies and flexibility of their business. And if SOA enables the Department of Defense to get better value-for-money from its contractors, then this strengthens the business case for SOA within the Department of Defense. (DISA is clearly doing something right.)

2. If the Department of Defense insists on the SOA approach, then this will create a very strong business case for SOA within the ecosystem of defense contractors. (If you don't want the work, there's plenty others that do.)

3. SOA is not just a technological initiative, but carries significant changes to organization and governance, including procurement arrangements. Enterprise SOA is, in part, about commodity services - buying pre-existent capability - and minimizing the custom development.

4. There is a learning curve for defense contractors. To be successful in the enterprise SOA market, traditional integrators will have to change their business models from being dependent on big custom software development projects. But some are still loading their bids with software costs, according to DISA Procurement Director Evelyn Palma. IBM has already won a major supply contract under the new regime, and we might expect future contracts to go to the most SOA-literate contractors.

Shuffle 2

In his Case Study: Soundflavor, Lane Becker of Adaptive Path writes:

'Have you ever been listening to your own music playing on shuffle and said, “Wow, I didn’t know I owned this song?” Or heard a song and said, “I wish I had more songs just like this one?” Or realized that your music ran out an hour ago and you’ve been listening to nothing but air, and yet you’re still wearing your headphones? These are the problems that Soundflavor set out to address with its new application and website.'

Problems?

I have a lot of respect for the Adaptive Path guys, based on their previous writings, and I have no reason to doubt that they have done a good job in helping Soundflavor. And perhaps Soundflavor has identified a viable market opportunity.

But, I mean to say, problems? Is it a problem to be wowed by something you forgot you owned, and is it a problem to be so engrossed in what you are doing that you fail to notice that the background music has stopped? Is it a problem if you prefer to listen to music that is homogeneous (because you like all the songs to sound just like the first one) and bland (because you don't notice when it stops)? Am I bothered?

And whose problem is it? Perhaps the music industry wants to persuade you to buy new material, instead of listening to the old stuff over and over. Perhaps it makes things easier for them if they can predict what you will buy based on what you already like. So perhaps they like to encourage people to have predictable and conservative musical tastes, and they might like to encourage services and devices that reinforce this tendency.

In a service-oriented world, we always need to ask two things.

• Whose problem is it - for whom could a new service create value?
• And who is going to pay - what is the funding mechanism?

So who is going to pay for Soundflavor? Should the consumer pay, or should the music industry fund such ventures? There is of course a third option - the delivery of homogeneous music to listeners with conservative tastes could be funded by advertising. This is called a radio station.

 

---

 

Some earlier posts about services and devices for recorded music:

• Shuffle (June 2005)
  
• Controlling Content (August 2005)
• Intrusion and Immersion (November 2005)
• Lessons from Zune (September 2006)
  

The Economics of Search

One of the things I like doing on this blog, as regular readers may have observed, is constructing mental mashups - creating new material by uncovering hidden relationships between old material from different sources. I am often stimulated by the diversity of material that comes into my newsreader.

Today's mental mashup puts together Alex Bosworth on Google: In your business, taking your money, and Masood Mortazavi on Transaction Costs and Search.

As Alex points out, there is clearly a difference between the following search outcomes:

• finding the best (cheapest, fastest, highest quality) supplier - from a complete and perfect search

• finding a good enough supplier from an incomplete and imperfect search

• finding the supplier that has the highest advertising budget - in other words, the one that is paying Google the most money

Meanwhile, Masood's post questions the assumption (found in neoclassical economics) that transaction costs can be understood as search costs, and also questions the assumption that internet search engines reduce search-related transaction costs. For my part, I'd like to know how does transaction cost theory address the trade-off between the perfect (and infinitely expensive) search and the imperfect search - where you don't get quite what you wanted, and get ripped off into the bargain?

These are questions that economists should understand. But what about the following outcomes?

• finding the supplier that meets your preconceptions of the requirement

• finding the supplier that meets Google's preconceptions of the requirement

• finding a supplier than can meet the requirement

As the difference between these outcomes indicates, search is a semantic/cognitive problem as well as an economic one. Google makes Herculean attempts to match content with advertising, or even content with content, and the consequent juxtapositions range from the helpful or serendipitous to the absurd or positively misleading. Earlier this week I relayed a story about such a juxtaposition - Cross Purposes.

In service-oriented world, as Rocky Lhotka pointed out recently, the transaction costs are dominated by questions of semantics. See my post on Semantic Coupling.

I should very much like to see an economic analysis of these semantic questions, but I somehow doubt whether this analysis is going to come from neoclassical economics.

Service-oriented security 2

Form Follows Function.

In a recent post, Bruce Schneier makes some interesting points about the relationship between Architecture and Security [via Confused of Calcutta].

"Security concerns have always influenced architecture."

"The problem is that architecture tends toward permanence, while security threats change much faster. Something that seemed a good idea when a building was designed might make little sense a century -- or even a decade -- later. But by then it's hard to undo those architectural decisions."

"It's dangerously shortsighted to make architectural decisions based on the threat of the moment without regard to the long-term consequences of those decisions."

End-to-End Process.

In a separate post on Voting Technology and Security, Bruce Schneier describes the steps in ensuring that the result of an election properly represents the intentions of the voters.

"Even in normal operations, each step can introduce errors. Voting accuracy, therefore, is a matter of 1) minimizing the number of steps, and 2) increasing the reliability of each step."

Whether this is strictly true depends on the architecture of the process - whether it is a simple linear process with no redundancy or latency, or whether there is deliberate redundancy built in to provide security of the whole over and above the security of each step. Bruce himself advocates a paper audit trail, which can be used retrospectively if required to verify the accuracy of the electronic voting machines.

Shearing Layers.

Security management doesn't necessarily operate on the same timescale as other elements of architecture. Our appproach to service-oriented security - indeed, to SOA generally - is based on the notion of a layered architecture, in which each layer has a different rate of change. (This is based on the Shearing Layers principle (now known as the Pace Layering principle). Thus the security layer is decoupled from the core business layer, and also from the user experience layer.

Previous Posts: Adaption and Adaptability, Business IT Alignment 2, Service-Oriented Security

Cross-Purposes

Seth Godin reports an interesting juxtaposition.

• Pain reliever recalled after metal found in pills.
  
• Google finds a matching image to illustrate the story.
  

Google is trying to be helpful here - repurposing an image (from elsewhere) to add value to a service.



Unfortunately, it's the right drug but the wrong brand. For many purposes, Google's semantics would be adequate. For recall purposes, however, the difference between DRUG and BRAND is very important.

This kind of semantic mismatch is what causes some of the trickiest interoperability risks.

Technorati Tags: Google interoperability SOA semantics service-oriented

Two-Sided Markets

There has been a lot of buzz around two-sided and multi-sided markets lately.

• Wikipedia: Two-Sided Markets

• Harvard Business Review: New Research Explores Multi-Sided Markets (March 2006), Strategies for Two-Sided Markets (Oct 2006)

• Emergic: Overview, Pricing, Examples, Business Application

In his HBS March interview, Andrei Hagiu identifies Wal-Mart as an example of an organization that is transforming from a traditional merchant into a two-sided platform. Let’s look at the (asymmetric) structure of this transformation.

The traditional retailer acts as a hub in the food supply chain, aggregating food supply from fields and factories, and distributing food to workshops and private kitchens. This is essentially a positional strategy: the retailer seeks to establish and maintain a strategic position within a value chain, as the bottleneck/hinge point between upstream and downstream. Within the positional strategy, the business drivers are understood in terms of the economics of scale and the economics of scope.



But if we shift from a value-chain perspective to a service-oriented perspective (effects-ladder), we can see that the retailer is providing a service (=delivering value) downwards as well as upwards - it is a food distribution platform for farmers and manufacturers as well as a food supply platform for consumers and catering companies.

So instead of drawing the merchant in the middle, we can draw the merchant as a new kind of platform providing various kinds of market interaction.




This takes us from a positional strategy to a relational strategy. No longer just focused on the economies of scale and scope, the relational strategy emphasizes how economies of governance are generated in relation to two kinds of demand context. The big question for a company such as Wal-Mart is how to balance the exploitation of each of these forms of asymmetric advantage.

 

See also

Philip Boxer, Asymmetric Demand is Multi-Sided Demand (October 2011)

Richard Veryard, SOA as Multi-Sided Platform (September 2009)

Semantic Coupling

In a recent post, Semantic Coupling, the Elephant in the SOA Room, Rocky Lhotka identified semantic coupling as one of the challenges of SOA. Udi Dahan agrees that semantic coupling is harder, but adds that in his view SOA is all about addressing this issue. Meanwhile Fergal Somers, chief architect at Cape Clear, doesn't think it is so hard in practice, although he acknowledges that the relevant standards are not yet mature.

Any systems that are linked together as part of a broader workflow involves semantic-coupling as defined above, but so what? We have been building these systems for some time.

Although I wouldn't go as far as saying SOA is all about any one thing in particular (see my earlier post on Ambiguity), I also agree that semantic coupling (and semantic interoperability) are important.

Rocky's argument is based on a manufacturing analogy.

• In simple manufacturing, the economics of scale involves long production runs, so that you can spread the setup costs across a large volume.

• In agile manufacturing, the economics of scope involves minimizing the setup costs, so that you can have shorter production runs without affecting the economics of scale.

• I interpret Rocky's argument as saying that a major element of the setup costs for services involves matching the semantics.

Part of the economic argument for SOA is that it can deliver economics of scope (adaptability, repurposing) as well as economics of scale (productivity).

But there's more. If we combine SOA with some other management innovations, we may also be able to improve the economics of alignment. I don't think this is illustrated by Rocky's manufacturing analogy.

However, Kenneth LeFebvre reads more into Rocky's post than I did.

There is meaning to the interaction between a consumer and a service. What does this mean? SOA is all about making the connections between applications using “services” but it does not bridge the gap between the real world of business and the “virtual” world that runs within our software. This is precisely the problem object-oriented design was intended to solve, and was just beginning to do so, until too much of the development population abandoned it in search of the next holy grail: SOA.

At my request, Kenneth has elaborated on this statement in a subsequent post SOA OOA and Bridging the Gap. I agree with him that the rhetoric of OO was as he describes. But I still don't see much evidence that "it was just beginning to do so", and I remain unconvinced by his argument that some things are better represented by objects than by services. (More concrete examples please Kenneth.)

For a definition of the economics of scale, scope and alignment, see Philip Boxer's post Creating Economies of Alignment (October 2006).

---

Note: earlier material used the term Economics of Governance. For various reasons, we now prefer the term Economics of Alignment.

Updated 25 October 2013

Starbucks Test

Just been reading a book review by Guy Kawasaki on The No Asshole Rule by Robert Sutton.

Guy quotes the Starbucks test as a simple detection mechanism. (In his blog, Sutton attributes this to Bill Maher.)

'If you walk into a Starbucks and order a "decaf grande half-soy, half-low fat, iced vanilla, double-shot, gingerbread cappuccino, extra dry, light ice, with one Sweet-n'-Low and one NutraSweet," ooh, you're a huge asshole.'

But compare this with Seth Godin's enthusiasm (Yes Substitutions) for companies that offer this kind of opportunity to their customers.

'I had lunch at the Pump in NY today. The Pump is about 350 square feet (total) and it's a money factory. They have nearly 50 ingredients, all healthy stuff, and offer them in precisely 41,000,000 combinations. So, you can have whole wheat pita with egg whites, chicken breast and hot sauce, no onions. Or no pita, double egg whites, double hot sauce and brown rice.'

So how do you describe the person who wants this combination? There are many organizations (both public sector and commercial) that seem to agree with Robert Sutton and regard their customers as assholes, for wanting anything slightly non-standard. Or perhaps regard them as cheats if they try to get something for nothing. (See my earlier post on the Ghetto Latte.)

But in an unpredictable world, the sustainable business is one that caters for the diverse tastes and behaviours of its customers, rather than dismissing them as assholes. The challenge is to build systems (both technical systems and management systems) that deliver a good level complexity without losing reliability or efficiency.