The goal of e-Government is to enable government to become more responsive to its citizens while at the same time reducing its costs.  We did a study for a government that wanted to invest in the use of on-line search capabilities. The problem the government faced was that there were insufficient direct revenues or savings to set against the value of such an investment, so that the normal approaches to establishing Return on Investment (ROI) would not work.  The approach we took was to approach the demand for on-line search capabilities as multi-sided, in order to establish the indirect value of the investment.

We considered four different types of search, corresponding to rcKP types of relationship to demand (the examples are taken from a presentation relating to this case):

• r-type: wholly standardised responses, usually in the form of Frequently Asked Questions (e.g. where and when do I get a vaccination)
• c-type: responses that have to be customised to the particular circumstances of the querent (e.g. why is there not enough vaccination available at my hospital)
• K-type: responses dependent on specialist knowledge from more than one source that has to be brought together to answer the particular problem presented by the querent (e.g. what are the contraindications of the vaccination given my condition)
• P-type: responses needing wholly new kinds of response, frequently requiring collaboration with organisations outside government (e.g. what precautions do we need to take for our school excursion).

We examined actual queries, establishing their variety and frequency and how these factors changed as the knowledge relating to any given domain of query matured (e.g. for swine flue in this case). We represented these queries in a multi-sided matrix, in which the columns represented individual services provided by different departments and organisations; and the rows were the different types of query.  A pattern of X’s along a row thus represented the collaboration between services needed to respond to the query in that row.  The matrix as a whole represented the variation in forms of collaboration needing to be supported by the architecture of the search platform.

Based on this matrix, we then modeled the way the organisation responded to it, identifying its associated costs:

In the case of the r-type and c-type queries, direct benefits flowed from the direct costs of using on-line search.  But in the case of K-type and P-type queries, the indirect benefits that flowed from the impact of these direct costs were based on the government’s costs of alignment across the variety of collaborations.  We were able to analyse the value of these indirect benefits based on Monte-Carlo simulation of the change in the way the organisation could work using the search platform.

The architecture of the platform itself had to be able to support dynamic alignment processes, resulting in a solution that was 20% of the cost of the investment that had been proposed initially by the government.  The indirect benefits that flowed from the impact of this platform on costs of alignment were then further increased as the tempo of variation in the domains of query themselves increased, resulting in savings being generated of the order of 50% of the total savings over a static solution.   The conclusions we drew were that:

• The multi-sided character of the demands that queries made on the government departments created a clear need to take into account the government’s costs of alignment.
• These costs of alignment depended on the way the governance processes that the government used could dynamically align responses to changing and evolving queries (i.e. using distributed or collaborative approaches).

This meant that the government could continue to consider the traditional economies of scale and scope available from any particular supporting department and systems platform.  But it also meant that the government needed to develop a governance approach appropriate to e-Government – one that assumed variability in the needs of citizens creating multi-sided demands on government.  Thus government had also to consider the economies of alignment it could secure in the way it responded to the resultant variation in the forms of collaboration demanded of it.

In effect, the government had to change the way it was able to respond to its citizens.

Social Flights, like airlines, provides flights. Except that Social Flights, unlike the airlines, has defined the demand they are responding to as asymmetric, developing a platform that can support the multi-sidedness of this demand. This is an early blog by them:

“Social Flights starts by enabling consumers to consider flying on private aircraft vs. commercial airlines. Our original theory was that “selling seats” and enabling consumers to create on demand flights would bring value to the market of travelers. We tested our theory, finding ways to lower the cost and present the better way to travel using social technology as the backbone for communicating with multiple markets of interest.”

Thus Social Flights is providing a business platform that can support a two-sided market: on the one side are travellers with particular routes in mind, and from the other side are the owners of private aircraft selling capacity on particular routes ^[1]. What makes it two-sided is the different relationship that Social Flights has with each side.

In describing the multi-sidedness of a market, we can usefully distinguish the following:

• Customer situations – situations in which there is a need for a particular form of collaboration between customers and complementors. In this case, the need (for example) for members of a team to travel together to play an ‘away’ match.
• Customers – the end-users within a customer situation i.e. the team members.
• Complementors – the suppliers whose product/service offerings are needed within particular customer situations i.e. owners of private aircraft offering lower overall costs on the particular route.
• Platform – the means by which customers and complementors are enabled to come together to form a collaboration i.e. the capability of Social Flights to bring customers and complementors together.^[2]

Other multi-sided examples are shown below:

From the perspective of any one complementor, say an airline or a clinical specialty, the market is one-sided: they are there to provide flights or operations to the market.  This one-sided view of demand defines demand as symmetric to their service offering of a direct benefit.

But if they define their market as multi-sided, they must take an asymmetric view of demand, identifying the customer situations giving rise to the collaborations that include a demand for their particular service offering – the types of travel situation creating demand for their routes, or the types of patient condition creating demand for their clinical services. And they must organise their propositions to extract indirect value from these (asymmetric) customer situations, not just from particular (one-sided) direct demands. Code-sharing airlines or hospitals are the result ^[3].

Thus what makes the demand asymmetric is the competitive need to consider the larger situation within which the particular demand arises, and to take into account the way the interactions within that larger context affect the particular demand.^[4] How does the business platform ‘extract value’?  It has to be able to support the greater social complexity involved. And it has to be able to support it in a way that creates value for the customer by reducing the customer’s costs of alignment of the various complementors to their particular situation.^[5]

The take-home?  We have to be able to understand the relationship between the platform architecture and the variety of forms of indirect value it can

Footnotes
[1] See also Richard’s earlier blog on two-sided markets using the example of retailers.
[2] The platform approach thus enables the tension to be managed between rings and wedges (i.e. between the economies of scale & scope of particular services provided by complementors, and the economies of alignment involved in bringing them together as a collaboration responding to the customer situation as a whole).
[3] What is challenging in this, of course, is that it involves a change in the way the business defines its competitive identity – from a supply-side definition of itself (we fly these kinds of route or we perform these kinds of surgery) to a demand-side definition (we can organise your travel or we can manage the treatment of your condition). But this change in competitive identity also drives innovation and transforms industries.
[4] In terms of rcKP services at the edge, only the r-type proposition treats demand as one-sided, all the others becoming increasingly involved with the larger customer situation within which demand arises.
[5] This value for the customer is indirect value from the perspective of the platform.  The need to establish economies of alignment is currently a major issue in public services, where the government ultimately pays for these indirect costs arising when citizens fall into the gaps between direct public services. This kind of analysis was used in a Swiss e-Government case (also outlined in this blog and published here).

1. Simplify and Unify systems to align them with the business, and
2. Differentiate and Integrate systems to help manage complexity.

In the first case the drive is towards a single unified system supporting the enterprise, while with the second it is towards differentiated systems brought together under a central authority as a system-of-systems.

He then introduced a third agenda in which the forms of integration could themselves be differentiated, enabling systems to be brought together in varieties of ways forming different systems-of-systems.  This third agenda he associated with enterprises that were having to form collaborative alliances with other enterprises, working within business ecosystems ^[1] to meet multi-sided demands ^[2].

My own presentation on supporting social complexity in collaborative enterprises addresses this third agenda. It describes multi-sidedness and gives a number of case examples, including e-Government and Healthcare.  It makes the point that with this third agenda, the architecture of the enterprise is not longer the primary concern.  Rather it is understanding the variety of ways in which the social complexity of collaborations create value for the customer, and therefore how, from the perspective of the supplier, platform architectures can capture indirect value.^[3]

Footnotes
[1] A business ecosystem is made up of numbers of operationally and managerially independent suppliers and customers interacting with each other in support of many different kinds of demand (e.g. the suppliers of the products, applications and services clustering around customers’ uses of Apple’s iPhone platform).
[2] A one-sided demand is one that the supplier can define its product or service in a way that is independent of the context within which it is used by the customer (e.g. the demands met by a retail outlet).  A multi-sided demand is one in which this is not possible, so that the supplier must take account of how the customer uses its product or service in combination with other products and services (e.g. the multiple interacting services involved in treating a complex medical condition).
[3] A platform architecture is the means by which East-West accountability can be delivered, providing a way of managing the tension between rings and wedges.

We have a few free tickets, so please contact us in the usual way if you are interested. Alternatively, please add your name to the Linked-In event notice. http://events.linkedin.com/Enterprise-Architecture-Forum/pub/746066.

Update Links

Summary

Philip’s presentation on Slideshare
Supporting Social Complexity in Collaborative Enterprises

Richard’s presentation on Slideshare
Next Generation Enterprise Architecture (EA)

Some papers sent to me recently by James D. Smith, II at Carnegie Mellon’s SEI set me thinking about how demand asymmetry might be expressed in Category Theoretic terms. Work by Nick Rossiter et al uses category theory to establish a natural basis for interoperability, comparing functors representing the constructs under which an enterprise organizes its data.    This work argues that the conditions for semantic interoperability between systems depend upon their functors commuting at all levels.  Heather et al use this to argue the need for a global enterprise (my italics):

Modern information systems operate at every level: from data held in a single purpose fixed device, through common PCs at home or mobile computing with business systems of an SME, to databases, intra-acting locally and at national level, inter-acting between nation states and even then open to wider global systems outside of Europe. This interoperability requires global coherence which in synecdoche correlates with the interoperation of the EU itself.

Semantic interoperability defined in this way cannot accommodate the pragmatics of demand that involve going beyond the perimeter of a single sovereign enterprise.   The enterprise may be forced to deal with demand asymmetry.

Let us say that an enterprise is an enterprise context, defined by the existence of a natural transformation between the functors representing its sub-contexts i.e. its functors commute at all levels. These sub-contexts may be further refined by defining sub-sub-contexts etc in terms of sub-functors.  In these terms, the hierarchy of the enterprise can be expressed in terms of the ‘is-part-of’ relations between the enterprise context and these subordinate functors representing subordinate enterprise contexts.

Let us now say that a customer situation (the experiencing of a need) is also defined as a natural transformation between the functors representing its sub-situations. These sub-situations may be further refined by defining sub-sub-situations etc in terms of sub-functors. In these terms, an effects ladder for the customer situation will be expressed in terms of the relations between the customer situation and its subordinate functors representing subordinate situations.

For example, a hospital is an enterprise, with one of its sub-contexts providing a hip-replacement service.  A patient’s condition would then be a customer situation, the need for a hip replacement being one of this condition’s sub-situations.

Now consider that the patient’s condition demands a number of different treatments provided by different specialist organizations – physiotherapy, home nursing, orthoses, home help. This would be a demand higher up the patient’s effects ladder, addressing more of the need arising from their condition (and thereby reducing the patient’s value deficit).   Let us say that a geometry-of-use is a functor composing some number of sub-functors within the hierarchies of some number of different enterprises.   A stratification can be expressed in terms of  the ‘is-used-by’ relations between the geometry-of-use and these sub-functors, representing how these sub-functors are composed.

Which brings us to demand asymmetry.  A demand arising from a customer situation is asymmetric for an enterprise if the functor of the geometry-of-use can not be made to commute at all levels with the functors of the enterprise i.e. there is no natural transformation between the functor for the customer situation and that of the enterprise as a whole. It is this demand asymmetry that forces us onto the ground of collaborative systems of systems and beyond.

Delivering East-West dominance involves finding the ‘edge’.  But how is a strategy-at-the-edge to be delivered?  How are services at the edge to be supported if they must be responsive to the customer’s context-of-use?  This represents a challenge to the architecture of an enterprise that questions the ideological basis of the enterprise itself.

In the following diagram, two organisations are shown, each with a reporting hierarchy under which a number of functional units operate, providing particular types of treatment. This accountability to the ‘North’ is exercised in terms of the costs incurred by each unit (typically over the course of a year)  in the provision of its services. These costs are influenced by the economies of scale and scope that each unit can generate, given the way each unit provides its services.

To the ‘East’, two patient episodes of care are identified, each episode demanding a particular combination of treatments.  This combination is represented by the horizontal blue line, and for the episode to be effective, the constituent services have to be aligned to the particular patient situation.  Accountability to the ‘East’ would involve holding the clinician responsible for this alignment, the costs of which would depend on the economies of alignment possible in the way treatments from multiple organisations can be aligned.

The complexity of creating economies of alignment can be seen more clearly in the following diagram, in which each functional unit is represented by a ring:

Each episode-of-care is represented now by a wedge, representing the particular alignment of treatments needed for that patient’s condition. The economies of scale and scope depend on the way functional units (rings) can deliver services into multiple wedges, while the organisation of the wedges determining the economies of alignment possible.

• These (w)edges involve working at the edges of healthcare ecosystem in delivering effective treatments to the patient; and
• with East-West dominance, the tension between the Northern economics of scale & scope and the Eastern economics of alignment have to be managed dynamically, and therefore explicitly.

The rings need not belong to a single organisation, so that each (w)edge becomes a collaboration.  The architectural challenge of East-West dominance is therefore how to manage the tension between wedges and rings dynamically.

While following up on a NECSI and MIT ESD seminar, I came across this paper by Joel Moses on three different organizing ideologies for the design of large scale engineering systems.   He summarizes the three as follows:

Such approaches are usually called design methodologies. We discuss the top-down structured methodology, the layered or platform-based methodology, and the network-based methodology. Such design methodologies are associated with organizational structures or architectures, such as tree-structured hierarchies, layered hierarchies and generic networks. We point out how these design methodologies relate to cultural attitudes toward engineering.

While the systems engineering ideology is still rooted in the ‘tree-structures’ of hierarchical decomposition, its more recent recognition of ‘directed’ and ‘acknowledged’ systems of systems (SoS) belong to the ‘platform-based architectures’ that fall comfortably under the canon of Product-Line Practices. The challenge comes with the ‘network-based architectures’, in which layering becomes an emergent property of the network. The environments in which these architectures are to be found exhibit Ultra-Large-Scale characteristics, the forms of social organization being supported are collaborative and co-producing, and the architecture of the systems of systems supporting these environments themselves need to be collaborative.

The difference between the platform-based and network-based architectures is whether or not layering can be treated as an a priori property of the architecture.  Network-based architectures enable the emergence of multiple forms of layering with respect to the multiple concurrent forms of collaboration that they support.  There is no longer a direct relationship between design and predictable uses, rendering the design of network-based architectures asymmetric to the architectures of demand.

This paper was presented in collaboration with Pat Kirwan and Hans Sassenburg at the 4th IEEE International Systems Conference in San Diego , 2010. It had the following abstract:

Governments worldwide are turning to Information and Communication Technology (ICT) based systems of systems, commonly termed Electronic Government (eGovernment), to enable more timely, efficient and effective interaction with their citizens and with the business community. Citizens and businesses have dynamic and evolving demands related to the complexity of their lives and operational environments, respectively. A major challenge for government is to be able to understand the value derived from investment in eGovernment in order to improve its consequent ability to respond to the variety of demands of its citizens and businesses. To be able to understand the value derived from planned investments in eGovernment, their analysis needs to extend beyond the familiar approaches that address economies of scale and scope to encompass economies of alignment. These economies of alignment arise from being able to reduce the costs of the multiple forms of collaboration needing to be supported by systems of systems in providing greater responsiveness.

The paper was based on a more detailed report on the work itself.

I attended the Schloss Dagstuhl conference in December 2009. my argument was that critical systems evolve because they are embedded in socio-technical ecosystems.  This subsequently became a paper published in IEEE Computing in collaboration with Philip Boxer, with the following abstract:

Classical engineering fails to model all the ways in which a critical sociotechnical system fits into a larger system. A study of orthotics clinics used projective analysis to better understand the clinics’ role in a healthcare system and to identify risks to the clinics’ evolution.

The paper was part of a special issue bringing together software engineering researchers and practitioners focused on evolving critical systems. The introduction identified five game changers framing the research agenda in this field:

• Software ubiquity. More software is being deployed in more consumer devices, meaning that failures are more likely to affect ordinary people.
• Software criticality. As software embeds itself deeper into the fabric of society, single software failures have greater potential to affect more people. This increases the potential for software to be considered critical even when it isn’t complex.
• People-in-the-loop. As software is deployed to control systems in which human actors participate, the issue of human interactions with software becomes more important.
• Entanglement. Software dependencies have become more complex, and much real-world software is entangled with software developed by third-party providers.
• Increased evolution tempo. The tempo of evolution will continue increasing as users expect more from software. The software market is often unforgiving when even small changes can’t be done cheaply and quickly.

This paper was presented in collaboration with Dr Nicholas Whittall (formerly Strategy Director, Thales UK Aerospace Division) at the 12th Annual NDIA Systems Engineering Conference in San Diego with the following abstract:

Recent studies into the operational use of a UAV system have shown that the variety of mission situations in which the UAV system was used had far exceeded those anticipated at the time it was acquired. In effect, the dimensions of the operational capability space had expanded beyond the particular dimensions of the capability design space constrained by the acquisition paradigm. Whilst this may be regarded as the benefit of network-enabled approaches, which are intended to increase the variety of ways in which capabilities can be combined to create composite capabilities within systems of systems (SoS), this raises the question of whether the engineering of SoS can be addressed adequately from within the perspective of the capability design space.

From the point of view of the supplier, one way of approaching the impact of an expanding operational capability space is to think in terms of its being multi-sided, its multiple ‘sides’ corresponding to the multiple ways in which a supplied system can participate in larger systems of systems. This multi-sidedness yields an additional value to that normally associated with the direct use of a system’s particular capability. This additional value is associated with the system’s ability to support multiple ways of being used in conjunction with other capabilities, creating a multi-sided market in which two kinds of value have to be considered.

For the supplier of a component system within the context of a SoS, “Directed” or “Acknowledged” processes for acquiring SoS establish a single customer for the performance of the component system against a particular capability requirement, so that the supplier’s focus can be on the capability design space alone (referencing OSD’s Systems Engineering Guide for Systems of Systems, v1.0 August 2008). But in the case of “Collaborative” SoS, no such ‘top-down’ requirement is established, and a community interested in the uses of the operational capabilities of the SoS (possibly a Community of Practice) has to define its requirements ‘bottom-up’. In this case, the supplier of a component system faces customer requirements that must span a variety of different ways of being used operationally, making the supplier’s market multi-sided. As a result, the system’s supplier must approach the capability design space from the perspective of an expanding operational capability space in which two kinds of value must be generated for the customer.

The paper will outline an approach to Collaborative SoS in which the multi-sidedness of the SoS is defined in terms of its expanding operational capability space. The paper will use this approach to distinguish the two different kinds of value associated with supporting the SoS as a multi-sided market, and show how these two kinds of value impact differently on the design of its component systems.