Evaluating platform architectures within ecosystems: modeling the supplier’s relation to indirect value

April 26th, 2012

by Philip Boxer, PhD

I have completed a PhD by publication at Middlesex University’s School of Engineering and Information Science under the supervision of Professor Martin Loomes.  Here is its abstract:

This thesis establishes a framework for understanding the role of a supplier within the context of a business ecosystem. Suppliers typically define their business in terms of capturing value by meeting the demands of direct customers. However, the framework recognises the importance of understanding how a supplier captures indirect value by meeting the demands of indirect customers. These indirect customers increasingly use a supplier’s products and services over time in combination with those of other suppliers . This type of indirect demand is difficult for the supplier to anticipate because it is asymmetric to their own definition of demand.

Customers pay the costs of aligning products and services to their particular needs by expending time and effort, for example, to link disparate social technologies or to coordinate healthcare services to address their particular condition. The accelerating tempo of variation in individual needs increases the costs of aligning products and services for customers. A supplier’s ability to reduce its indirect customers’ costs of alignment represents an opportunity to capture indirect value.

The hypothesis is that modelling the supplier’s relationship to indirect demands improves the supplier’s ability to identify opportunities for capturing indirect value. The framework supports the construction and analysis of such models. It enables the description of the distinct forms of competitive advantage that satisfy a given variety of indirect demands, and of the agility of business platforms supporting that variety of indirect demands.

Models constructed using this framework are ‘triply-articulated’ in that they articulate the relationships among three sub-models: (i) the technical behaviours generating products and services, (ii) the social entities managing their supply, and (iii) the organisation of value defined by indirect customers’ demands. The framework enables the derivation from such a model of a layered analysis of the risks to which the capture of indirect value exposes the supplier, and provides the basis for an economic valuation of the agility of the supporting platform architectures.

The interdisciplinary research underlying the thesis is based on the use of tools and methods developed by the author in support of his consulting practice within large and complex organisations. The hypothesis is tested by an implementation of the modeling approach applied to suppliers within their ecosystems in three cases: (a) UK Unmanned Airborne Systems, (b) NATO Airborne Warning and Control Systems, both within their respective theatres of operation, and (c) Orthotics Services within the UK’s National Health Service. These cases use this implementation of the modeling approach to analyse the value of platforms, their architectural design choices, and the risks suppliers face in their use.

The thesis has implications for the forms of leadership involved in managing such platform-based strategies, and for the economic impact such strategies can have on their larger ecosystem. It informs the design of suppliers’ platforms as system-of-system infrastructures supporting collaborations within larger ecosystems. And the ‘triple-articulation’ of the modelling approach makes new demands on the mathematics of systems modeling.

The following summarises the argument in terms of Value for Defence:

Value for Defence

View more presentations from Philip Boxer

Investing in e-Government: evaluating ROI without direct revenues

October 25th, 2011

by Philip Boxer

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.



Asymmetric Demand is multi-sided demand

October 18th, 2011

by Philip Boxer

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 support.

[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).

Supporting social complexity in collaborative enterprises

October 12th, 2011

by Philip Boxer
Richard’s presentation at the UNICOM Enterprise Architecture Forum was on Next Generation Enterprise Architecture (EA).  In it he distinguished two agendas:

  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 addressed this third agenda. It described multi-sidedness and gave a number of case examples, including e-Government and Healthcare.  It made the point that with this third agenda, the architecture of the enterprise was not longer the primary concern.  Rather it was understanding the variety of ways in which the social complexity of collaborations created value for the customer, and therefore how, from the perspective of the supplier, platform architectures needed to be able to capture indirect value.[3]

[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 for which 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 for 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.

Unicom EA Forum

September 22nd, 2011

Philip Boxer and Richard Veryard will be speaking at the Unicom Enterprise Architecture Forum in London on Thursday September 29th.

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


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

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

A Categorial expression of Demand Asymmetry

July 28th, 2011

by Philip Boxer

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.

(w)Edges – working at the edge

February 19th, 2011

by Philip Boxer

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.


[1] A first step towards managing this tension is through identifying the multi-sided matrix in terms of which it can be expressed. This ‘multi-sided matrix’ sits in the middle of a stratified set of relations linking underlying behaviors all the way through to the ultimate contexts-of-use in which demands arise, and is the key link between supply-side and demand-side ‘logics’ of supply and demand.

Ideologies of Architecture

December 17th, 2010

by Philip Boxer

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 Practices1. 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.

[1] Note, however, that the ‘platform-based architectures’ that fall under Product-Line Practices are restricted to supporting a one-sided relation to markets.  They are to be further distinguished from the multi-sided platform architectures that are network-based that support multi-sided relations to demand. See what distinguished a platform strategy.

The multi-sided matrix – analysing the technical *and* the social

April 16th, 2010

by Philip Boxer[1]

An ecosystem is a community of managerially and operationally independent organizations interacting with each other and with their environment. Software-intensive ecosystems—ecosystems in which the behaviors of the participating organizations are themselves dependent on software because of the intensive use they make of it—are an increasingly important social, financial, and political force in the world. We find examples of software-intensive ecosystems in industries concerned with such things as transport, healthcare, defense, government, and communications. These software-intensive ecosystems are different from traditional “closed-world” software systems that can be analyzed independently of the contexts in which they are embedded; and their emergent properties cannot be predicted by the designers of the software systems on which they depend.  A number of key drivers underlie this change, challenging the former “closed-world” perspective on software engineering. Amongst these are the tempo at which the ecosystems are themselves expected to evolve, the ubiquity and criticality of the software on which they depend, and the entanglement not only between software systems and the way they are used by people, but also between interoperating software systems that are themselves managerially and operationally independent of each other [2]. To understand the behaviors of such ecosystems, the analysis of their architectures must not separate the software systems from the organizational contexts-of-use that depend on them. This is the case even where the interactions between the organizations within the ecosystem primarily concern the use of software itself, such as is to be found in the Microsoft and iPhone ecosystems [3].

The core-periphery distinction
The Metropolis Model [4] provides a starting point for understanding how software systems are constructed, maintained, and operated. At the heart of this model is the distinction between the core and the periphery, which has been often noted as a key architectural construct in complex software systems [5]. The core-periphery architectural pattern provides the maximum opportunity for developers at the periphery (and the producers and consumers—sometimes called prosumers—of content) to embed the behavior of a system into their own contexts, enabling their own activities or those of eventual customers and end-users within a larger ecosystem. Examples of cores include the Linux kernel, the Android platform, Facebook’s application platform, the Apache core, iPhone’s iOS platform, Hadoop Common, and so forth. Each of these “cores” provides an abstraction upon which the functionality of the actual customer/end-user-facing application (’App’) is built. The core itself provides little or no end-user value, but rather provides the architectural foundation upon which others build value. The core is typically relatively small, compared with the size of the periphery. For example the (iOS) core of the iPhone enables application developers and users to develop Apps independently that can in turn by taken up within a wide variety of contexts; and making GPS location data accessible to users and application developers on the iPhone platform has spawned a wide variety of location-based services.

This core-periphery distinction can be applied to the way modularity and its associated inter-dependencies are defined for a software system. For modules in the core, tight coupling between them creates mutual dependencies. In the periphery coupling is much looser, creating a measure of independence in the way modules can be used. The strength of the core-periphery pattern is therefore the relatively few constraints at the periphery on how modules may be used and combined, and how their use may be modified. Consequently a core-periphery structure is less over-determining of its use at the periphery than it is at the core, enabling the necessary dependencies defined by the core to be combined with chosen dependencies created by developers in their Apps.

Direct scenarios and direct interactions
Apps are developed to deliver their functionality within a direct scenario in which they are used. These direct scenarios, in addition to describing the direct interaction of some end-user with the App, also describe a quality attribute of the system (a latency goal, for example) within the context defined by the scenario. The achievement of these quality-attribute-related responses brings benefit to the stakeholders in the behavior of the App. For example, a correct response might be of great value to an end-user stakeholder if it arrives predictably within 100 ms., of moderate value if it arrives predictably within 1 second, and of little value if it arrives unpredictably or if it predictably arrives in 10 seconds.

This is depicted in the above figure, where there is one core and three different direct scenarios represented at the periphery. Each of these direct scenarios connects some end-user input—a stimulus—to an output. Consider, for example, the connecting lines for each scenario: α1β1, α2β2 and α3β3. These might represent different direct scenarios in which end-users are making voice-over-IP (VoIP) connections, for example conferencing, or saying hello to a colleague on the other side of the world, or giving a seminar. The end-users within each direct scenario might be employing different App software, but in the end they are using and sharing some resources at the core—name servers, protocol translators, routers, satellite links, IP stacks, fiber-optic cables, etc. Furthermore, the stakeholder perspective on each of these scenarios could be that the VoIP call would only be of value if latency and jitter were both kept within specified ranges.
Direct scenarios can be used to trace through the core-periphery interactions when trying to identify, measure, and understand the benefits radiating out to the end-users at the perimeter on the basis of their direct uses Apps. Scenarios such as these are necessary to analyze a shared core infrastructure, illuminating such things as contention for resources. Consider, for example, understanding the load on an operating system core when multiple processes are operating and competing for shared resources. On a larger scale, cloud computing platforms such as Amazon’s EC2 support large numbers of simultaneous users, each of which could request thousands of server instances. And social computing platforms such as Facebook have over 250 million active users each day, each of whom will consume core resources, potentially interacting through applications that are built on top of Facebook’s core application platform.

Indirect scenarios and indirect interactions
In the larger ecosystem within which Apps are being used, the under-determining effects of core-periphery systems enable Apps to be used by end-users independently of each other, but they also enable indirect interactions between Apps and end-users. The indirect scenarios associated with these indirect interactions are not necessarily related to their use of any one App, and may actually involve multiple core-periphery systems that are operationally and managerially independent of each other. For example, Facebook’s location features allow users and service providers to interact with each other in ways that are only made possible by their use of a smartphone. This potentially creates a much larger and more complex environment defined by interactions that are indirect (from the perspective of the core software systems). For example, the actors within scenarios 1, 2 & 3 may belong to different research institutions, but are all involved in a single research collaboration for which a number of core systems become a key enabling element. This research collaboration is shown in the figure below as an indirect scenario linking indirect interactions between particular direct uses of Apps to the ultimate end-use. The figure below represents this by adding an extra ‘App use’ layer to the onion:

A new challenge arises therefore for the analysis of architecture: what is the impact of these indirect interactions on the architecture of the operationally and managerially independent core-periphery systems (for example VoIP, Screen-sharing, etc.)? For example, consider the indirect effects that might arise where the end-users in the research collaboration are combining the use of VoIP, screen-sharing, and file sharing systems. These indirect interactions represent architectural challenges. For example, many users of the VoIP systems will be competing for resources, such as computation and bandwidth, affecting latency. Or the developers of those Apps may have chosen a common protocol affecting the development time of individual systems. Or charging schemes may affect an end-user’s choice of combined systems to employ (for example as a result of differential charging schemes for relatively time-sensitive internet-traffic such as VoIP packets, and relatively non-time-sensitive traffic, such as file sharing). Such considerations are of real concern to core providers because these indirect interactions can collectively have a huge effect on the performance and behavior of the core. As an example, Google Maps imposes resource restrictions on the services that it provides to other organizations, in an effort to moderate worst-case resource usage.

The multi-sided matrix
Consider the multi-sided matrix in the figure below, in which the sets of columns correspond to sets of direct scenarios associated with direct use of an App (for example particular uses of VoIP or screen-sharing), and in which each set of columns is operationally and managerially independent of the others. The rows correspond to the indirect interactions between multiple Apps supporting, each row corresponding to a particular indirect scenario (for example a research collaboration, or a marketing project). From the perspective of the App developers in the periphery, each row represents indirect interactions between Apps that creating indirect effects within the social collaborations that they are supporting. A one-sided approach to App development will only examine the mix of direct scenarios represented by a column. But each the indirect scenarios create multi-sided demands on the direct scenarios depending on how the App is expected to interact with other Apps:

Thus decisions made affecting the capabilities of core-periphery systems will also impact on the way they can participate in the indirect interactions chosen by stakeholders. The variety and scale of these indirect interactions arising between stakeholders within indirect scenarios will determine the emergent qualities of the larger ecosystem in which these interactions are taking place. Multiple X’s in a row reflect social collaborations that also present technical challenge: how will the Apps interoperate, and how will collaborations manage that interoperation within their larger contexts?

Platform scope
Returning to the example above, each column for VoIP stream, screen-sharing, and file-sharing session must have direct scenarios defining their direct scope across the rows. But since the rows themselves represent indirect scenarios, the dependencies and alignment processes between the direct scenarios along a row must also be considered, each of which presents an interoperability requirement and a potential contention for shared resources between operationally and managerially independent systems supporting the direct scenarios. Thus an end-user in the Research Collaboration in the first row above may wish to capture the content of a screen-sharing session and share that with other end-users. Such an indirect scenario imposes an interoperability requirement between the screen-sharing and file-sharing systems. A platform that enables this to be accomplished may be said to have a platform scope defined by the number of direct interactions it can enable to interoperate, shown below as a separate set of columns.

Analysing the technical *and* the social
The presence and impact of indirect interactions is an essential characteristic of ecosystems arising from the entanglement of the technological core-periphery systems with an environment of social systems. To understand and analyze these ecosystems, we therefore need to be able to characterize a statistically representative variety of indirect interactions between many independent actors across independent core-periphery systems. But if we just analyze the direct impact of the αβ paths of each direct scenario on the core-periphery architecture of a system in any given column—the traditional architectural analysis—we will not understand the collective impact of the indirect interactions within indirect scenarios across many core-periphery systems caused by the social collaborations taking place within the larger socio-technical ecosystem.

We will thus not be in a position to analyze the potential emergent effects and behaviors arising from the way the core systems are used within this larger context. It follows that we will also be unable to define the architectural characteristics of the supporting platforms needed.

[1] With special thanks to Rick Kazman for his contributions to an earlier draft.
[2] Coyle, L., et al., Guest Editor’s Introduction: Evolving Critical Systems. Computer, 2010. 43(5): p. 28-33.
[3] Jansen, S., A. Finkelstein, and S. Brinkkemper. A Sense of Community: A Research Agenda for Software Ecosystems. in 31st International Conference on Software Engineering (New Ideas and Emerging Results Track). 2009. Vancouver, Canada: IEEE CS Press.
[4] Kazman, R. and H.-M. Chen, The Metropolis Model: A New Logic for the Development of Crowdsourced Systems. Communications of the ACM Vol 52 No 7, 2009: p. 76-84.
[5] MacCormack, J., C. Baldwin, and J. Rusnak, The Architecture of Complex Systems: Do Core-Periphery Structures Dominate? MIT Sloan School of Management, 2010. Working Paper 4770-10.

The ‘wickedness’ of socio-technical ecosystems

April 15th, 2010

by Philip Boxer

Software-intensive ecosystems—systems with large numbers of independent software-intensive and human agents and adaptive behavior—are an increasingly important social, financial, and political force in the world. These systems are different from traditional “closed-world” systems: they are constantly evolving, they have no centralized control, they have many heterogeneous elements, their requirements are inherently conflicting and unknowable, failures are normal, and the boundary between people and systems is blurred. [1]

Such ecosystems have emergent properties – properties which their original designers could not predict – and present a kind of “wicked” problem.[2] Wicked problems have the following characteristics:

  • There is no definitive formulation.
  • They have no stopping rule.
  • Solutions are not true-or-false, but good-or-bad.
  • There is no immediate or ultimate test of a solution.
  • They do not have a well-described set of potential solutions.
  • Every implemented solution has consequences.
  • Every wicked problem is essentially unique.
  • Every wicked problem can be considered to be a symptom of another problem.
  • The causes of a wicked problem can be explained in numerous ways.
  • The planner (designer) has no right to be wrong.

Wicked problems are thus not amenable to traditional reductionist analysis. As Rittel and Webber say: “As we seek to improve the effectiveness of actions in pursuit of valued outcomes, as system boundaries get stretched, and as we become more sophisticated about the complex workings of open societal systems, it becomes ever more difficult to make the planning idea operational”. We simply cannot draw a box around the “system” and analyze it. This presents us with a challenge not just at the level of the software ecosystem, but also at the level of the socio-technical ecosystems that they support. While this challenge appears to undermine our ability to do any meaningful analysis, simply not analyzing such ecosystems is not an acceptable option given that society is increasingly dependent on them – for example, the ecosystems supported by the internet and the “smart grid” for energy production and distribution.

The US Army considered the impact of these wicked problems on the Commander’s Appreciation and Campaign Design, which it defined as “ill-structured”. It concluded that a different approach to problem solving was needed that was inductive in nature, concerned with producing “a well-framed problem hypothesis and an associated campaign design—a conceptual approach for the problem.” [3] Thus as much attention had to be paid to the way the problem was framed (i.e. to the way the boxes were defined), as to the subsequent analysis of what was placed within those boxes. The conclusion reached was as follows:

“The issue is whether a commander should begin by analyzing the mission, or whether complexity compels the commander to first understand the operational problem, and then—based upon that understanding—design a broad approach to problem solving. The answer to this question depends upon the problem and the mission. If the problem is structured so that professionals can agree on how to solve it, and the mission received from higher headquarters is properly framed and complete, then it makes sense to begin with the analysis of the mission (breaking it down into specified, implied, and essential tasks). However, if the problem is unstructured (professionals cannot agree on how to solve the problem), or the mission received from higher headquarters is not properly framed (it is inappropriate for this problem), or higher headquarters provided no clear guidance (permissive orders), then it is crucial to begin by starting to identify and understand the operational problem systemically. This is one of the functions of operational art.”

Another way of stating the challenge, therefore, is to analyze our understanding of the contexts-of-use into which our systems are being deployed before analyzing any proposed architectures for such systems, or proposed architectural changes, to ensure that they are as suitable as possible given our understanding of those contexts-of-use. In this way, architecture analysis becomes an alignment mechanism, ensuring that the software infrastructure that we build is as appropriate as possible for the needs of the contexts-of-use, which collectively form a socio-technical ecosystem.

These socio-technical ecosystems are distinguished by the presence of both task systems and the social systems of meaning that they support. [4] In order to examine the architectural characteristics of both software-intensive and socio-technical ecosystems, traditional architectural analysis must be extended to account for how alignment impacts on the wicked (ill-structured) nature of ecosystems. Such an analysis can give us insight into the properties of an ecosystem and can help us reason about the alignment of the ecosystem with the goals of its many stakeholders.

[1] This perspective on complex adaptive systems exhibiting organized complexity is to be found in Northrop, L., et al., Ultra-Large-Scale Systems: The Software Challenge of the Future. June, 2006, Pittsburgh: Software Engineering Institute, Carnegie Mellon University.
[2] The original use of this term is to be found in Rittel, H. and M. Webber, Dilemmas in the General Theory of Planning. Policy Sciences, 1973.
[3] TRADOC, Commander’s Appreciation and Campaign Design. 2008.
[4] The original work on this emphasized that while sentient and task groups might correspond, the nature of task systems and snetient systems were essentially incommensurable. Quoting from Miller, E. J. and A. K. Rice (1967), Systems of Organization: The Control of Task and Sentient Boundaries. London, Tavistock: “We have considered many different words – commitment, identity, affiliation, cathexis – to denote the groups with which human beings identify themselves, as distinct from task groups, with which they may or may not become identified. We have chosen sentient – ‘that feels or is capable of feeling; having the power or function of sensation or of perception by the senses, 1632’ (Shorter Oxford English Dictionary) – as expressing most clearly what we mean. We shall therefore talk of sentient system and sentient group to refer to that system or group that demands and receives loyalty from its members; and we shall talk of a sentient boundary to refer to the boundary round a sentient group or sentient system. We shall use sentience to mean ‘the condition or quality of being sentient’ (Shorter Oxford English Dictionary)”.