@Cybersal complains about Amazon. "Yet again Amazon ships a tiny book with an unreliable courier that my postman could have shoved through my letterbox." and explains "Post office 10 min walk. Courier depot 30 min drive. Courier not a good option for such a low value item."
This raises an important question about Amazon's capability and willingness to manage complexity - specifically differentiation. Amazon already uses multiple alternative delivery channels, but introducing an automatic selection according to the value and size of the item might well further complicate its delivery processes. If Amazon wished to differentiate customers according to the convenience / cost of different delivery channels, it would presumably need to have some geographical reasoning capability. And if Amazon wished to differentiate those products that would fit through a customer's letterbox, it would presumably need to know the size of each customer's letterbox.
We can easily imagine that Amazon could build this kind of capability, perhaps using Google Maps and Google Streetview to check the exact location of Sally's house and estimate the size of her letterbox. But has Sally a right to complain if Amazon doesn't bother?
To what extent do customers have a reasonable expectation of sophisticated differentiation of service - from organizations in general or from Amazon in particular? We may note that most large commercial organizations are way behind Amazon in their ability to enhance customer value through differentiation, while most small commercial organizations are way behind Amazon in their ability to integrate across a complex ecosystem. Because Amazon has already done some amazing things, we may expect it to go even further. But even Amazon has a practical limit of how much complexity it can manage.
We are surrounded by organizations that really can't be bothered, and the value deficit in some sectors is quite disgraceful. So it may be unfair to pick on Amazon, an organization that has done more than most to stretch the limits of the possible. But Sally is right - the future belongs to those organizations able and willing to pay attention to this kind of detail, if it helps to produce direct or indirect value.
Sunday, March 27, 2011
Tuesday, March 22, 2011
Systems of Engagement and Indirect Value
I've just been reading Geoffrey Moore's new white paper Systems of Engagement and The Future of Enterprise IT : A Sea Change in Enterprise IT (AIIM 2011). He calls out a major shift of emphasis in IT, from what he calls Systems of Record (focused on transactions) to Systems of Engagement (focused on interactions). See also presentation by John Mancini and commentary by Jacob Morgan and James Taylor.
Why is this shift necessary? According to Moore, it is because most organizations are dependent upon suppliers or distributors or partners to deliver their fundamental value proposition to their customers. Which means that the new communication and collaboration systems are essential competitive tools. Grab onto them, says Moore, or you will simply end up as roadkill.
(Of course, these challenges aren't just for commercial organizations. Public sector organizations are under just as much pressure to deliver value, even if this pressure is transmitted politically rather than commercially.)
Moore identifies five steps for the CIO to develop systems of engagement for B2B enterprises.
And five steps for B2C enterprises. Note the strong emphasis on social media.
In his "Confused of Calcutta" blog, JP Rangaswami (now with Salesforce) talks about how Systems of Engagement need to deal with Jyri Engeström's concept of social objects, and explores some of the architectural implications of the granularity of these social objects within the enterprise. (JP also puts in a plug for the Salesforce Chatter platform, which I plan to look at in more detail soon.)
But Moore's thesis about Systems of Engagement only provides part of the story. To take this thinking further, we need to look not just at more collaborative ways of delivering value to customers, but also at the ways in which that value is indirectly experienced by the customers and by the customers' customers and so on. In his paper Creating Value in Ecosystems (December 2010), my friend and associate Philip Boxer argues that "for a supplier to sustain its identity within a dynamic environment ... it needs to change the way it understands how it creates value, in order to include the indirect forms of value it creates within the larger ecosystem".
Similar ideas have been emerging from the Harvard Business School. In their piece on Shared Value, Michael Porter and Mark Kramer complain about companies "trapped in an outdated approach to value creation", which "view value creation narrowly, optimizing short-term financial performance in a bubble while missing the most important customer needs and ignoring the broader influences that determine their longer-term success". Porter and Kramer believe that the principle of shared value "involves creating economic value in a way that also creates value for society by addressing its needs and challenges" and argue that markets are defined by societal needs, not just conventional economic needs.
Given that organizations must deliver indirect value as well as direct value, the required systems of engagement will take the form of an agile sociotechnical platform to support collaborative composition of value-creating activity. That's a bit of a mouthful, so I'll try and explain it in a future post. Or you could come to my workshop.
See also
Why is this shift necessary? According to Moore, it is because most organizations are dependent upon suppliers or distributors or partners to deliver their fundamental value proposition to their customers. Which means that the new communication and collaboration systems are essential competitive tools. Grab onto them, says Moore, or you will simply end up as roadkill.
(Of course, these challenges aren't just for commercial organizations. Public sector organizations are under just as much pressure to deliver value, even if this pressure is transmitted politically rather than commercially.)
Moore identifies five steps for the CIO to develop systems of engagement for B2B enterprises.
- Make meetings work better across time zones.
- Address complex issues collaboratively.
- Keep collaborators connected for faster decision making.
- Mine community content to extract insights to enhance the business.
- View collaboration and social systems in context.
And five steps for B2C enterprises. Note the strong emphasis on social media.
- Use social media to attract and hold consumer attention.
- Use social media to extend and improve customer service.
- Use social media to develop deeper brand relationships and consumer insights.
- Integrate social media with systems of record to provide a better end user experience.
- Mine metadata to personalize offers for greater relevance and conversion.
In his "Confused of Calcutta" blog, JP Rangaswami (now with Salesforce) talks about how Systems of Engagement need to deal with Jyri Engeström's concept of social objects, and explores some of the architectural implications of the granularity of these social objects within the enterprise. (JP also puts in a plug for the Salesforce Chatter platform, which I plan to look at in more detail soon.)
But Moore's thesis about Systems of Engagement only provides part of the story. To take this thinking further, we need to look not just at more collaborative ways of delivering value to customers, but also at the ways in which that value is indirectly experienced by the customers and by the customers' customers and so on. In his paper Creating Value in Ecosystems (December 2010), my friend and associate Philip Boxer argues that "for a supplier to sustain its identity within a dynamic environment ... it needs to change the way it understands how it creates value, in order to include the indirect forms of value it creates within the larger ecosystem".
Similar ideas have been emerging from the Harvard Business School. In their piece on Shared Value, Michael Porter and Mark Kramer complain about companies "trapped in an outdated approach to value creation", which "view value creation narrowly, optimizing short-term financial performance in a bubble while missing the most important customer needs and ignoring the broader influences that determine their longer-term success". Porter and Kramer believe that the principle of shared value "involves creating economic value in a way that also creates value for society by addressing its needs and challenges" and argue that markets are defined by societal needs, not just conventional economic needs.
Given that organizations must deliver indirect value as well as direct value, the required systems of engagement will take the form of an agile sociotechnical platform to support collaborative composition of value-creating activity. That's a bit of a mouthful, so I'll try and explain it in a future post. Or you could come to my workshop.
See also
- Noah Flowers, Going beyond market-based solutions to create “shared value”(Feb 2011)
- Umair Haque, The New Calculus of Competition (Jan 2011)
- Michael Porter, What is Value in Health Care? (December 2010)
- Michael Porter, Discovering - and Lowering - the Real Costs of Health Care (2011)
Thursday, March 17, 2011
Emergent Architecture
#entarch #emergence #systemsthinking What is emergent architecture, and what are the practical implications for enterprise architecture?
In August 2009, Gartner produced a definition of
At the same time, Dion Hinchcliffe produced a similar list of properties and one of his trademark diagrams [Pragmatic new models for enterprise architecture take shape, August 2009]. Meanwhile Dion was also talking a lot about WOA (which he credits to Nick Gall of Gartner), and there was clearly a link in their thinking between WOA and some notion of emergence [A Web-Oriented Architecture (WOA) Un-Manifesto, December 2009].
Overall, the
For example
The practice described in that article can only be described as
My own view is that all of the characteristics Gartner and Dion Hinchcliffe originally proposed (with the possible exception of resource constraints, which are nothing new) could be regarded as emerging, in the sense of being new and trendy and representing a departure from the modernist paradigm of
Wikipedia defines emergence as
Although some writers like to use biological and ecological analogies when talking about emergence, the sociopolitical analogies are probably more relevant to enterprise architecture because they include the notion of human intentionality. (And some people use the terms
The distinction between planned and emergent architecture is akin to the distinction introduced by Henry Mintzberg between deliberate and emergent strategy, the latter referring to strategies that originate in the interaction of an organization with its environment [Wikipedia: Strategy dynamics].
This distinction also maps onto some recent work in the system-of-systems (SoS) domain. Mark Maier introduced a distinction between directed and collaborative systems (1998), and this has been developed by the U.S. Department of Defense (DoD) into a more complicated four-part schema (directed, acknowledged, collaborative and virtual). See for example System Engineering Guide for System-of-Systems Engineering (Version 1, August 2008). Planned architectures tend to assume directed or acknowledged systems-of-systems, while emergent architectures are associated with collaborative and virtual systems-of-systems.
Boxer and Garcia write:
The
Gartner is closer to the mark when it talks about decentralized decision-making (which it calls
I don't know whether Gartner is still promoting the idea of emergent architecture, or whether its definition has evolved since 2009, given that Nick Gall's recent work (such as his latest piece on Panarchy) doesn't seem to use the term at all. However, Gartner's original piece on emergent architecture remains available on its website, and continues to be referenced as one of the primary sources for the term.
What are the practical implications of emergence for enterprise architecture?
One of the most important practical differences between planned architecture and emergent architecture is that we tend to think of planned architecture as a design-time artefact - something that is envisioned, designed and then implemented by architects. So architecting is regarded as a special kind of designing. Implementation may be directly managed by the architects, or indirectly by means of a set of architectural policies to govern acquisition, development and use.
The implementation of a planned architecture always involves a gap between plan and reality. Plans take time to realise, some bits of the plan may never get realised. There is always a defacto architecture, which we may call architecture-in-use, which is a structural description of what-is-going-on, paying attention to certain structural and sociotechnical aspects of a (run-time) system of systems from a given observer position.
Devotees of planned architecture see this in terms of a simple transformation from AS-IS to TO-BE. Their attention to the existing defacto architecture is largely motivated by the need to define a business case and a technical transition strategy for replacing AS-IS with TO-BE, possibly in discrete phases or chunks.
But emergence tells us this: that the architecture-in-use emerges from a complex set of interactions between the efforts and intentions of many people. The architects cannot anticipate, let alone control, all of these interactions. There may be some areas in which the architects are able to carry out something that looks a bit like design, either autonomously or collaboratively, but there will be other areas in which the architects are simply trying to understand the structural implications of some messy situation and make some useful interventions. The primary activity of architects is therefore following not a design loop but an intelligence loop.
However that depends what we mean by design. There is a renewed interest in a generalized notion of
In August 2009, Gartner produced a definition of
Emergent Architecturewith two synonyms (Middle-Out EA and Light EA), two characteristic practices (modelling lines not boxes, modelling relationships as interactions) and seven characteristic properties (non-deterministic and decentralized; autonomous, rule-bound, goal-oriented and locally influenced actors; dynamic or adaptive systems; resource constraints) [Gartner Identifies New Approach for Enterprise Architecture, August 2009].
At the same time, Dion Hinchcliffe produced a similar list of properties and one of his trademark diagrams [Pragmatic new models for enterprise architecture take shape, August 2009]. Meanwhile Dion was also talking a lot about WOA (which he credits to Nick Gall of Gartner), and there was clearly a link in their thinking between WOA and some notion of emergence [A Web-Oriented Architecture (WOA) Un-Manifesto, December 2009].
Overall, the
emergentand
evolvingdefinition of Emergent Architecture across the internet is pretty muddled: although other writers in the Enterprise Architecture world may reference Gartner and/or Hinchcliffe, they don't always pick up the full richness and power of their definitions. In addition, these writers may be influenced by the agile community, where
emergentis contrasted with
upfrontand seems to mean something like
making it up as you go along.
For example
The architect should collaborate with the development team to define and code higher-level contexts, responsibilities, interfaces, and interactions, as needed, and leave the details to the team. The development team, through the rigorous use of automated unit and story tests via continuous integration, is then able to improve the system design incrementally and continually—both within and across model-context boundaries— without compromising system functionality. Gartner uses the termEmergent Architectureto describe this practice. Keeping Architectures Relevant, Microsoft Architecture Journal
The practice described in that article can only be described as
emergenton a fairly narrow interpretation of the word, presumably based on the
rule-boundcriterion and ignoring the other characteristics.
My own view is that all of the characteristics Gartner and Dion Hinchcliffe originally proposed (with the possible exception of resource constraints, which are nothing new) could be regarded as emerging, in the sense of being new and trendy and representing a departure from the modernist paradigm of
traditionalenterprise architecture. (See my post on Modernism and Enterprise Architecture.) But not all of the characteristics they proposed are directly associated with emergence, in the complex systems sense.
Wikipedia defines emergence as
the way complex systems and patterns arise out of a multiplicity of relatively simple interactions[Wikipedia: Emergence]. As I see it, the notion of emergence leads to a key distinction for enterprise architecture, between a planned order (which Hayek called Taxis) and an emergent spontaneous order based on self-organization (which Hayek called Cosmos).
Although some writers like to use biological and ecological analogies when talking about emergence, the sociopolitical analogies are probably more relevant to enterprise architecture because they include the notion of human intentionality. (And some people use the terms
top-downand
bottom-up, but nowadays I try to avoid these terms because of their potential ambiguity. See my note on Service Planning.)
The distinction between planned and emergent architecture is akin to the distinction introduced by Henry Mintzberg between deliberate and emergent strategy, the latter referring to strategies that originate in the interaction of an organization with its environment [Wikipedia: Strategy dynamics].
This distinction also maps onto some recent work in the system-of-systems (SoS) domain. Mark Maier introduced a distinction between directed and collaborative systems (1998), and this has been developed by the U.S. Department of Defense (DoD) into a more complicated four-part schema (directed, acknowledged, collaborative and virtual). See for example System Engineering Guide for System-of-Systems Engineering (Version 1, August 2008). Planned architectures tend to assume directed or acknowledged systems-of-systems, while emergent architectures are associated with collaborative and virtual systems-of-systems.
Boxer and Garcia write:
In the complex systems-of-systems contexts supporting distributed collaboration, the architecture of the collaborative enterprise has to be approached as emergent, created through an alignment of individual architectures.[Enterprise Architecture for Complex System-of-Systems Contexts, 3rd Annual IEEE Systems Conference in Vancouver March 23-26 2009 (abstract) (pdf)] See also Type III Agility and Ideologies of Architecture.
The
acknowledgedcategory of systems of systems allows for some flexibility and autonomy for local development of component systems, while remaining under central oversight and direction. This is surely where
rule-bound actorswould fit, and would include the practices described in the Microsoft Architecture Journal article mentioned above (Keeping Architectures Relevant). There is also some scope in the
acknowledgedcategory for dynamic or adaptive systems and adaptive processes. But this is some way short of a genuinely emergent architecture.
Gartner is closer to the mark when it talks about decentralized decision-making (which it calls
non-deterministic) involving autonomous goal-oriented actors, responsive to local influence. Similarly, Dion Hinchcliffe talks about community-driven architecture run by autonomous stakeholders, producing decentralized solutions with emergent outcomes.
I don't know whether Gartner is still promoting the idea of emergent architecture, or whether its definition has evolved since 2009, given that Nick Gall's recent work (such as his latest piece on Panarchy) doesn't seem to use the term at all. However, Gartner's original piece on emergent architecture remains available on its website, and continues to be referenced as one of the primary sources for the term.
What are the practical implications of emergence for enterprise architecture?
One of the most important practical differences between planned architecture and emergent architecture is that we tend to think of planned architecture as a design-time artefact - something that is envisioned, designed and then implemented by architects. So architecting is regarded as a special kind of designing. Implementation may be directly managed by the architects, or indirectly by means of a set of architectural policies to govern acquisition, development and use.
The implementation of a planned architecture always involves a gap between plan and reality. Plans take time to realise, some bits of the plan may never get realised. There is always a defacto architecture, which we may call architecture-in-use, which is a structural description of what-is-going-on, paying attention to certain structural and sociotechnical aspects of a (run-time) system of systems from a given observer position.
Devotees of planned architecture see this in terms of a simple transformation from AS-IS to TO-BE. Their attention to the existing defacto architecture is largely motivated by the need to define a business case and a technical transition strategy for replacing AS-IS with TO-BE, possibly in discrete phases or chunks.
But emergence tells us this: that the architecture-in-use emerges from a complex set of interactions between the efforts and intentions of many people. The architects cannot anticipate, let alone control, all of these interactions. There may be some areas in which the architects are able to carry out something that looks a bit like design, either autonomously or collaboratively, but there will be other areas in which the architects are simply trying to understand the structural implications of some messy situation and make some useful interventions. The primary activity of architects is therefore following not a design loop but an intelligence loop.
However that depends what we mean by design. There is a renewed interest in a generalized notion of
designin the enterprise architecture world, especially with the current popularity of Design Thinking (and such derivatives as
Hybrid Thinking). But that's a subject for another post.
Sources
Gartner identifies new approach for enterprise architecture (Aug 2009)
Commentary on Gartner's emergent architecture concept by Abel Avram, Leo de Sousa, Adrian Grigoriu and Mike Rollings (then with Burton Group).
Dion Hinchcliffe, Pragmatic new models for enterprise architecture (Aug 2009)
Mark Maier, Architecting Principles for Systems of Systems (InfoEd June 1997)
See also
Peter Cripps, Enterprise Architecture is Dead. Long Live Interprise Architecture (Oct 2010)
Tom Graves, Hybrid-thinking, enterprise architecture and the US Army (May 2010)
Three or Four Schools of Enterprise Architecture (December 2011)
Tuesday, March 08, 2011
Creeping Business Dependency
People are slowly waking up to the fact that we have created yet another single point of failure into our business ecosystem. It seems that businesses have gradually made themselves dependent on Global Positioning Systems (GPS) and satellite navigation (satnav). So we are now starting to hear doom-and-gloom stories about the dire economic consequences of any interruption to the service, which could apparently be caused by anything from cyberterrorism (Daily Mail 8 March 2011) to solar flares (Daily Mail 21 Sept 2010).
Those with long memories may recall the millennium bug scare, which postulated that widespread computer error might result in total economic collapse when the date went from 99 to 00. Many companies took the opportunity to carry out a long overdue inventory of their software programs, and decommissioned a fair amount of obsolete code, as well as reviewing their disaster recovery procedures; even though the scare was probably exaggerated, some useful work was done. (I myself picked up some contract work in this area, so I can't complain.)
The Royal Academy of Engineering has just issued a report on Global Navigation Space Systems, which takes a more balanced view of the subject than the Daily Mail, but still warns of the danger of over-reliance on satellite navigation [Report (pdf), Press Release].
Chairman of the RAoE working group, Dr Martyn Thomas, told the BBC:
Maybe this does sound pretty speculative (as @martinjmurray complains). Nonetheless it may be a good idea for any business that has gradually become dependent on this or any other technology to check out the possible risks.
From an architectural point of view, what I find most interesting about this situation is the tendency for critical business dependencies (and the associated risks) to emerge, as a particular technology migrates unobtrusively from marginal use to core business use.
Another example of a creeping business dependency is the extent to which Google has now inserted itself into the relationship between any business and its customers. If a business offends Google in some way, and consequently disappears from Google search, this will have serious business consequences. (BMW disappeared from Google for three days in 2006 - see my post BMW Search Requests). And yet it's still rare to see Google shown as a business-critical service partner in business architecture or business process diagrams.
If we think of an architecture in terms of a set of dependencies, we can distinguish between a centrally planned architecture, in which the dependencies and their implications are understood from the outset, and an emergent defacto architecture, in which unanticipated dependencies and risks can be created by a quantity of uncontrolled activity. In a planned world, all innovation must be controlled to prevent emergent risk; in an evolving world, innovation (such as the use of Google or GPS) can be encouraged provided that there is a robust mechanism to detect and manage emerging risks.
Related posts: BMW Search Requests (Feb 2006), Cloud and Continuity of Supply Risk (March 2013)
Those with long memories may recall the millennium bug scare, which postulated that widespread computer error might result in total economic collapse when the date went from 99 to 00. Many companies took the opportunity to carry out a long overdue inventory of their software programs, and decommissioned a fair amount of obsolete code, as well as reviewing their disaster recovery procedures; even though the scare was probably exaggerated, some useful work was done. (I myself picked up some contract work in this area, so I can't complain.)
The Royal Academy of Engineering has just issued a report on Global Navigation Space Systems, which takes a more balanced view of the subject than the Daily Mail, but still warns of the danger of over-reliance on satellite navigation [Report (pdf), Press Release].
Chairman of the RAoE working group, Dr Martyn Thomas, told the BBC:
"We're not saying that the sky is about to fall in; we're not saying there's a calamity around the corner. What we're saying is that there is a growing interdependence between systems that people think are backing each other up. And it might well be that if a number these systems fail simultaneously, it will cause commercial damage or just conceivably loss of life. This is wholly avoidable." [BBC News 8 March 2011]
Maybe this does sound pretty speculative (as @martinjmurray complains). Nonetheless it may be a good idea for any business that has gradually become dependent on this or any other technology to check out the possible risks.
From an architectural point of view, what I find most interesting about this situation is the tendency for critical business dependencies (and the associated risks) to emerge, as a particular technology migrates unobtrusively from marginal use to core business use.
Another example of a creeping business dependency is the extent to which Google has now inserted itself into the relationship between any business and its customers. If a business offends Google in some way, and consequently disappears from Google search, this will have serious business consequences. (BMW disappeared from Google for three days in 2006 - see my post BMW Search Requests). And yet it's still rare to see Google shown as a business-critical service partner in business architecture or business process diagrams.
If we think of an architecture in terms of a set of dependencies, we can distinguish between a centrally planned architecture, in which the dependencies and their implications are understood from the outset, and an emergent defacto architecture, in which unanticipated dependencies and risks can be created by a quantity of uncontrolled activity. In a planned world, all innovation must be controlled to prevent emergent risk; in an evolving world, innovation (such as the use of Google or GPS) can be encouraged provided that there is a robust mechanism to detect and manage emerging risks.
Related posts: BMW Search Requests (Feb 2006), Cloud and Continuity of Supply Risk (March 2013)
Friday, March 04, 2011
A Twin-Track Approach to Government IT
#ukgovit @instituteforgov has just published a report called System Error: Fixing the Flaws in Government IT.
The report recommends a twin-track approach to government IT, based on the two concepts of Agile and Platform.
The report acknowledges the tension between these two concepts ...
One way of understanding the twin track approach is to think of the different kinds of economics involved.
Combining the two introduces some complex architectural challenges, as I've written about here and elsewhere before. We call this Asymmetric Design. For an example of this approach applied to public sector IT, see an analysis of the CSA Case by Philip Boxer and myself. See also The Impact of Governance Approaches on SoS Environments (pdf) by Philip Boxer and others.
In the current economic situation, the public sector as a whole is charged with making massive cost savings, and it is crazy to imagine that cost savings of this scale would not be associated with significant structural change, including IT systems. This kind of disruptive innovation goes way beyond the economies of scale and scope, and introduces some serious questions about the economics of alignment.
The word "architecture" is mentioned a few times in the Institute for Government report, but only in passing as something that the Government CIO will look after. (Mostly technology or solution architecture, I only found one single reference to business architecture.) So there is an implicit idea of central thinking and hierarchical governance. But there are some architectural challenges here that are some way beyond the current practices of enterprise architecture.
Governance is also a significant problem. The report comments on the pendulum swings between centralized and decentralized provision, which is something we noted in the CSA case, and was also present in the case of ContactPoint (which we were in the middle of writing up when it was cancelled). Such pendulum swings are often a characteristic symptom of weak or unsustained governance.
Not only is this stuff structurally complicated, but there are some commercial stakeholders that have every incentive to maintain the complicated status quo, thanks to a grossly dysfunctional procurement process.
And there is an even bigger problem with the report, which is that it looks at government IT exclusively from within government - in other words, from the perspective of civil servants. For example, the report adopts a supply-side notion of "joined-up government", understood largely in terms of internal linkages and efficiencies between systems, and fails to mention the demand-side notion of "joined-up government" that involves a coherent experience for the citizen. (See my post on Joined-Up Government from December 2005.)
Meanwhile the notion of "user" appears to refer mainly to civil servants and other public sector workers. Surely the purpose of government IT is not to provide direct value to civil servants but to provide various forms of indirect value to individual citizens and socioeconomic communities.
The report regrets that "government IT [is] falling further and further behind the fast-paced and exciting technological environment that citizens interact with daily" and indicates "the potential for IT ... fundamentally changing the relationship between citizen and state". "Around the world governments are using technology to help them deliver better services, be more transparent and accountable, and connect more directly with their citizens." (Examples are cited from Canada, USA and Malaysia.)
And yet the report fails to explain how "agile" can adequately represent the demand side requirements of citizens, interacting with a broad range of government services while going about their public business. There is a completely different notion of "platform" required here - government as a platform, which Tim O'Reilly and others have been talking about for a couple of years. And a different notion of agility, which goes a lot further than agile software development.
Harry Metcalfe (2 March 2011) observed that many of the recommendations in the report were really hard, and was one of the first to complain about the insufficient attention to procurement in the report.
The report recommends a twin-track approach to government IT, based on the two concepts of Agile and Platform.
"The platform must standardise and simplify core elements of government IT. For any elements of IT outside the platform, new opportunities should be explored using agile principles. These twin approaches should be mutually reinforcing: the platform frees up resource to focus on new opportunities while successful agile innovations are rapidly scaled up when incorporated into the platform."
The report acknowledges the tension between these two concepts ...
"Treating items as commodities reduces cost but can limit flexibility; coordinating elements of IT across departments frees up resources but may move them further from frontline users; common standards support interoperability but also restrict the freedoms to innovate."... and offers some general ideas for managing this tension.
Trouble is, some of this stuff is really hard. The report talks glibly about "a less than intelligent customer", referring first to business users having an inadequate conception of the possible, and then to the public sector as a whole lacking the collective knowledge and skills to negotiate effectively with suppliers. This lack of intelligence is apparently blamed on the V-model development process, which creates the impression that the adoption of Agile methods would solve this problem. But the idea of Agile as a silver bullet is a dangerous one, as many people have already pointed out on the Linked-In discussion group.
- To act fully in the interests of government, an agile approach requires a light touch form of coordination at a system level.
- To minimise duplication of effort in solving the same problems, there needs to be system-wide transparency of agile initiatives.
- Existing elements of the platform also need periodic challenge. ... Transparency, publishing feedback and the results of experiments openly, will help to keep the pressure on the platform for continual improvement as well as short-term cost savings.
One way of understanding the twin track approach is to think of the different kinds of economics involved.
- 'Platform' means delivering economies of scale and economics of scope.
- 'Agile' means delivering economies of alignment.
Combining the two introduces some complex architectural challenges, as I've written about here and elsewhere before. We call this Asymmetric Design. For an example of this approach applied to public sector IT, see an analysis of the CSA Case by Philip Boxer and myself. See also The Impact of Governance Approaches on SoS Environments (pdf) by Philip Boxer and others.
In the current economic situation, the public sector as a whole is charged with making massive cost savings, and it is crazy to imagine that cost savings of this scale would not be associated with significant structural change, including IT systems. This kind of disruptive innovation goes way beyond the economies of scale and scope, and introduces some serious questions about the economics of alignment.
The word "architecture" is mentioned a few times in the Institute for Government report, but only in passing as something that the Government CIO will look after. (Mostly technology or solution architecture, I only found one single reference to business architecture.) So there is an implicit idea of central thinking and hierarchical governance. But there are some architectural challenges here that are some way beyond the current practices of enterprise architecture.
Governance is also a significant problem. The report comments on the pendulum swings between centralized and decentralized provision, which is something we noted in the CSA case, and was also present in the case of ContactPoint (which we were in the middle of writing up when it was cancelled). Such pendulum swings are often a characteristic symptom of weak or unsustained governance.
Not only is this stuff structurally complicated, but there are some commercial stakeholders that have every incentive to maintain the complicated status quo, thanks to a grossly dysfunctional procurement process.
And there is an even bigger problem with the report, which is that it looks at government IT exclusively from within government - in other words, from the perspective of civil servants. For example, the report adopts a supply-side notion of "joined-up government", understood largely in terms of internal linkages and efficiencies between systems, and fails to mention the demand-side notion of "joined-up government" that involves a coherent experience for the citizen. (See my post on Joined-Up Government from December 2005.)
Meanwhile the notion of "user" appears to refer mainly to civil servants and other public sector workers. Surely the purpose of government IT is not to provide direct value to civil servants but to provide various forms of indirect value to individual citizens and socioeconomic communities.
The report regrets that "government IT [is] falling further and further behind the fast-paced and exciting technological environment that citizens interact with daily" and indicates "the potential for IT ... fundamentally changing the relationship between citizen and state". "Around the world governments are using technology to help them deliver better services, be more transparent and accountable, and connect more directly with their citizens." (Examples are cited from Canada, USA and Malaysia.)
And yet the report fails to explain how "agile" can adequately represent the demand side requirements of citizens, interacting with a broad range of government services while going about their public business. There is a completely different notion of "platform" required here - government as a platform, which Tim O'Reilly and others have been talking about for a couple of years. And a different notion of agility, which goes a lot further than agile software development.
Other commentary
See Linked-In discussion groupHarry Metcalfe (2 March 2011) observed that many of the recommendations in the report were really hard, and was one of the first to complain about the insufficient attention to procurement in the report.
Wednesday, March 02, 2011
April Events
stop press A limited number of workshop places are available at £195 per person per day. Please phone Unicom on 01895 256484 quoting code EA04.
I shall be presenting at the following events.
April 11th. "No Intelligence Without Feedback" SCiO Open Meeting, Manchester.
April 13th. One day workshop "Managing Complexity with Enterprise Architecture". Unicom, Middlesex
April 14th. One day workshop "Organizational Intelligence". Unicom, Middlesex
I shall also be speaking about organizational intelligence at the Open Group Conference in London on May 10th. note changed date
I shall be presenting at the following events.
April 11th. "No Intelligence Without Feedback" SCiO Open Meeting, Manchester.
April 13th. One day workshop "Managing Complexity with Enterprise Architecture". Unicom, Middlesex
April 14th. One day workshop "Organizational Intelligence". Unicom, Middlesex
I shall also be speaking about organizational intelligence at the Open Group Conference in London on May 10th. note changed date
Subscribe to:
Posts (Atom)