Saturday, May 24, 2014

Towards an Open Architecture for the Public Sector

#diggovreview #publicsectorIT .

Attended an interesting workshop last week to discuss some of the architectural aspects of Digital Government, hosted by Skyscape. One purpose of this discussion was to feed into the Labour Party Digital Government Review, and possibly into the Labour manifesto for the next election. Under modified Chatham House rules, I believe I am permitted to blog about the workshop as long as I don't attribute anything to anybody or any organization.


There are several architectural themes that are probably shared between the political parties, although there may be some differences of emphasis and interpretation. For example, everyone seems to pay lip service to the idea of opening up public sector IT, and reducing the power of the incompetent and self-interested, whoever these may be. But there will undoubtedly be different views on the right tactics for redistributing commercial and bureaucratic power.

Openness leads to fashionable ideas about IT acquisition - a preference for consuming rather than self-build, and a preference for agile development rather than waterfall. These are great ideas when used properly, but we must be careful not to encourage the illusion that these ideas provide a magic solution to the troubles of public sector IT. Indeed, some recent IT disasters have been attributed to an ill-considered rush to "Agile". And the Buy-Not-Build agenda must be governed properly, to avoid ceding too much architectural control to the large platform providers.

Openness also means structural change. For example, a shift from vertical integration and vertical silos to lateral modularity and co-creation, which my friend and associate Philip Boxer calls Collaborative Composition. This connects with the notions of Shared Services and Platform.

Finally, there is the question of the tempo of change. Government policies have a fairly rapid cycle time - in some cases around 18-24 months depending on department - but we cannot afford to reengineer systems and services, let alone platforms, at this sort of frequency.

So there was considerable discussion about the role of Government in providing a platform, and whether the platform should be a Minimum Viable Platform (similar to the Internet) or provide added value. There was also some debate as to whether politicians could be persuaded to support systems and platforms that would last longer than the policies that they were intended to implement.

The Public Sector suffers, perhaps even more than other organizations, from a confusion between Requirement and Solution. So people like to talk about Open Standards or Agile as the solution to high IT costs, or advocate Big Central Database as the perfect solution to any information needs, instead of talking about the requirements, such as interoperability and low switching costs. I hope that the Labour Party (or any other party for that matter) can be encouraged to express its policies in terms of the requirements and governance approach, rather than mandating specific technological solutions.

As I've pointed out before, the term "Joined-Up Government" has several different interpretations. From an Inside-Out (supply-side) perspective, it is commonly taken to imply improved integration between separate government departments and agencies - in other words, some kind of reorganization, not merely of IT systems and services but also the agencies responsible for these services. Of course, reorganization might sometimes be needed, but this is merely one possible solution to the real requirement, which in my opinion comes from the Outside-In (demand-side) perspective - the citizen's need for a coherent experience of government services.

For example, the much-discussed integration between Healthcare and Social Care doesn't entail merging two massive and inefficient silos into one even more massive and inefficient silo, but could be achieved simply by opening up the silos and improving the flows of information between them. The Outside-In perspective merely calls for the citizen to get a coherent joined-up service across both healthcare and social care, however this may be done.

And consider the much maligned Contact Point, which had somehow morphed from an information sharing platform ("System of Engagement") to a Big Central Database ("System of Record"), largely under the control of people who didn't appreciate that these weren't necessarily the same thing.

Effective multi-agency working depends on effective information sharing, but this doesn't mean putting all the data into a single source of truth. Many of the breakthroughs of Digital Government have come, not from building massive central databases, but from improving collaboration between different agencies – health, social care, police, justice, etc – often dealing with the same problem families from different professional perspectives. As we say at Glue Reply, it’s about the conversation.


Some of us have been talking about these themes for a long time. In my own small way, I have written a number of articles and blogposts about eGovernment and Joined-Up Government, and I submitted something on Shared Services to the Cabinet Office in January 2006, most of which is probably still valid. See previous posts on this blog - eGovernment, Joined-Up, Shared Services.

Philip Boxer, Creating Value in Ecosystems (December 2010)

Jerry Fishenden and Mark Thompson, Digital Government, Open Architecture, and Innovation: Why Public Sector IT Will Never Be the Same Again (Journal of Public Administration Research and Theory September 2012)

Mike Martin, Open Architecture Critique - A Draft (March 2014)

David Sprott and Richard Veryard, Shared Services for the UK Public Sector (Submission to the Cabinet Office, CBDI Forum January 2006)

Richard Veryard, Joined-Up Services (Review of the Public Management and Policy Association. February 2002)

Richard Veryard and Philip Boxer, Public Sector IT - The CSA Case (December 2004)


See also David Sprott's response to this post. Open Architecture for the Public Sector (May 2014)

Thursday, April 03, 2014

The Enterprise Architect of Hamelyn


Stakeholder Concern Enterprise Focus Project Focus
The city of Hamelyn is plagued with rats. This indicates a serious problem with the “Public Health and Hygiene” capability. We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
The Pied Piper gets rid of the rats. Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem. Project successful.

The Pied Piper is too expensive. We need a careful transition plan while we build an in-house capability. Let us immediately renegotiate our contract with the vendor.
The Pied Piper gets rid of the children. It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes. !*!?**!
Which Role? Enterprise Architect?
Strategic Procurement?
Solution Architect?
Tactical Procurement?


See also my article “Requirements Engineering as if Stakeholders Mattered” (Requirenautics Quarterly, Issue 29, August 2003, pdf)


Wednesday, February 19, 2014

What's Wrong with Universal Credit? On The Rooting of the Particular in the Universal

According to Hegel, the administration of a corporation's affairs by its own supervisors will often be inept, "for although they know and have before them their own distinct interests and affairs, they have a less complete grasp of the connection between these and more remote conditions and universal points of view". (GWF Hegel, Elements of the Philosophy of Right, 1820)

Therefore, one of the challenges for enterprise architecture is to maintain a pragmatic balance between the particular and the universal, especially when many of the decision-makers (as Hegel observed) tend to see things from a narrow short-term perspective.

So at first sight, we might think that the UK Government initiative known as Universal Credit represents a welcome exception to this narrow short-term thinking. What a brilliant idea to consolidate all benefit systems into a single simpler system!

The devil, of course, is in the detail. Mark Ballard explains:

Universal Credit would not only re-engineer the complex administration of £70bn social security payments to 8m households, merging six benefits systems across two government departments and local authorities throughout the country. It would also rely on councils up and down the country making their own systems and processes compatible. It would depend upon HM Revenue & Customs completing its own income tax system reforms of unprecedented ambition, Real-Time Information. And HMRC would in turn depend on employers, banks and payroll software suppliers reforming their computer systems and processes as well. Universal Credit would have to navigate this exponentially explosive collection of risk factors. This was a spaghetti junction of high-stakes computer gambits from which Universal Credit would have to pull a benefits payment that was reliable and secure. (Mark Ballard, Universal Credit failures put coalition ICT strategy in purdah. Computer Weekly September 2013)

What went wrong? Agile Development? Procurement? Interdepartmental warfare? Bureaucracy?

"There was an extremely strong command and control culture at the DWP, which goes against agile. We were trying to alleviate that - but it wasn't working," said a source. "The fundamental problem was procurement," said an anonymous participant. "Our hands were tied because of procurement. If you don't set up the contract properly, you are on a hiding to nothing." (Mark Ballard, Why agile development failed for Universal Credit, Computer Weekly July 2013)
Iain Duncan Smith is stuck between using traditional waterfall and systems integration, advocated by DWP, and "agile hacking", advocated by GDS.  (Bryan Glick, The question that matters on Universal Credit: Do you believe Iain Duncan Smith? Computer Weekly Feb 2014, comment by John Alexander)
Any system which is designed to operate with a smaller bureaucracy will be opposed tooth and nail by the bureaucrats mandated to implement it. (Benedict Brogan, Whitehall is shuddering over Universal Credit problems Telegraph February 2014, comment by Littlegrayman)


And was it just poor execution, or was the vision faulty? Paul Spicker thinks the whole project was doomed.

It is easy to blame the IT when things go wrong, but when people are asked to do impossible things, it should not be surprising if they do not deliver. ... The most basic flaw rests in the idea that we can “personalise” benefits for millions of people. There are just too many moving parts; and in a system with millions of iterations, anything that can go wrong will go wrong. (Paul Spicker, Universal Credit: Don’t blame the IT Computer Weekly Feb 2014)

(I want to make two observations here. Firstly, requirements are not additive. Even if each requirement makes sense on its own, that doesn't mean that the whole set of requirements makes sense. And secondly, requirements that make sense in some contexts don't make sense in other contexts. For example, retail may be able to achieve a good level of personalization, because it doesn't matter much if a customer sometimes gets the "wrong" promotional voucher. But it matters a lot if people get the "wrong" benefits, so the stakes are much higher.)


And even the Spectator (a right-wing weekly magazine) complains about ministerial incompetence and inflexibility.

The Universal Credit fiasco exemplifies Duncan Smith’s narcissistic failure to admit and remedy mistakes. As Computer Weekly — a far better guardian of the taxpayer than the Conservative backbenches or press, incidentally – has said, Duncan Smith proceeded with a vast and complicated IT project without learning the lessons from the IT disasters of the Labour years. (Nick Cohen, The conservative case against Iain Duncan Smith, Spectator June 2014)


John Naughton compares Universal Credit with Obamacare, and detects the same problem with both.

How is it that governments stuffed with able and conscientious civil servants screw up so spectacularly whenever IT is involved? ... The strange thing about this is that you wouldn't need to have been a geek to spot the problem with healthcare.gov. You just had to think architecturally about it. Yet apparently nobody in the administration did. The same applies to the post-9/11 decision to link all the previously separate US security databases into one giant file to which at least 250,000 people had access, one of whom happened to be Bradley (now Chelsea) Manning. (John Naughton, Obamacare, universal credit… why do governments make such a mess of IT? Observer December 2013)


You don't have to be a geek. You just have to think architecturally. And thinking architecturally means - among other things - anticipating and resolving the kind of problems faced by projects like these.

Standing up for the universal point of view doesn't justify a Stalinist approach to smoothing out the unavoidable complexities of dealing with real individuals and their messy lives. Is this a failure for IT, or a failure for bureaucracy? And can we tell the difference?


Updated 3 July 2014

Friday, February 07, 2014

Spring Events 2014

Unicom EA Forum - Business-Driven Enterprise Architecture

The next EA Forum will be on Thursday 20th March. Unicom has kindly invited me to chair this event again, and I look forward to meeting some of you there.

This is usually one of the most interactive EA events, and always affords excellent discussion and networking opportunities. For my part, I am especially looking forward to hearing a new set of case studies. If you are interested in attending this event, please contact Unicom on 01895 256484. The full programme is available via the Unicom website.

Hashtag #UnicomEA

Jobs at Glue Reply

Glue Reply has vacancies for experienced architects based in the UK, especially with relevant sector experience.
  • Payments Solution Architect (Retail)
  • Solution Architect (eCommerce / Multi-channel)
  • SOA Consultant Senior
  • SOA Architect 
If you are interested in applying for any of these positions, please check out Glue Reply on Linked-In or contact Nick Allsop in our London Victoria office. Feel free to mention my name.


Reply website 
Glue Reply Linked-In profile, with details of current vacancies.

Sunday, September 15, 2013

Autumn Events 2013

Unicom EA Forum - Enterprise Architecture and its Application

Unicom has kindly invited me to chair this event again, and I look forward to meeting some of you there. It will be held at the Kensington Hilton in West London on Thursday 19th September. This is usually one of the most interactive EA events, and always affords excellent discussion and networking opportunities. If you are interested in attending this event, please contact Unicom on 01895 256484. The full programme is available via the Unicom website.


Open Group Conference - Business Transformation in Finance, Government and Healthcare

This conference runs from 21st to 24th of October in Central London.  I have been asked to talk about Enterprise Architecture and Systems Thinking, within the Professional Development track. My talk is scheduled for Wednesday 23rd. For the full programme and registration, please visit the Open Group London website.


Update: My presentation What can Enterprise Architecture Learn from Systems Thinking is now on Slideshare.


Saturday, August 17, 2013

Enterprise Architecture as Science?

It is common to describe Enterprise Architecture as a science. Here are a few examples.

  • We see enterprise architecture (EA) as a scientific sub-discipline both of computer science and business management. The twice mentioned word “science” here emphasizes our certainty that EA is an exact discipline able to produce precise approaches and solutions. Wolf Rivkin, Enterprise Architecture and the Elegant Enterprise (Architecture and Governance 5-3)

A few years ago, I discussed this question with @RSessions


Roger is one of the few people I know who is seriously committed to empirical investigation of EA. I believe he shares my view that much EA falls woefully short of anything like scientific method. To my eye, many knowledge-claims within the EA world look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

But why does it matter anyway? Why would people be so keen to claim EA as a science? Here is what Foucault had to say to those who wished to claim Marxism (or psychoanalysis) as a science.

"When I see you trying to prove that Marxism is a science, to tell the truth, I do not really see you trying to demonstrate once and for all that Marxism has a rational structure and that its propositions are therefore the products of verification procedures. I see you, first and foremost, doing something different. I see you connecting the Marxist discourse, and I see you assigning to those who speak that discourse the power-effects that the West has, ever since the Middle Ages, ascribed to a science and reserved for those who speak a scientific discourse." Michel Foucault, Society Must be Defended: Lectures at the Coll├Ęge de France, 1975-76 (English translation by David Macey, 2003)

In other words, claiming EA as a science is not about the rational basis for its knowledge-claims but about its authority, or what Foucault (in David Macey's translation) calls Power-Effects. Thus instead of claiming EA as a science, one might follow Gartner in claiming EA as a discipline.

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture. (Gartner website, retrieved 17 August 2013)

Foucault characterizes a discipline in terms of the selection, normalization, hierarchicalization and centralization of knowledge. We can surely recognize these processes in the formation and maintenance of EA frameworks such as TOGAF and PEAF, as well as various attempts to construct Bodies of Knowledge. Foucault notes that "the progress of reason" necessitates "the disciplinarization of polymorphous and heterogeneous knowledge". This might lead us to expect some institutional resistance to heterodox ideas, as well as the marginalization of "amateur scholars".

Foucault is interested in ways that people and organizations can respond to disruptive forces large and small, from "great radical ruptures, massive binary divisions" to "mobile and transitory points of resistance, producing cleavages in a society that shift about, fracturing unities and effecting regroupings".

Just as the network of power relations ends by forming a dense web that passes through apparatuses and institutions, without being exactly localized in them, so too the swarm of points of resistance traverses social stratifications and individual unities. And it is doubtless the strategic codification of these points of resistance that makes a revolution possible. [Michel Foucault, History of Sexuality Vol 1.]

Gartner's notion of EA-as-discipline seems quite consistent with this. It is focused on mobilizing the response to disruptive forces (for which Gartner uses the rather strange word "nexus"). EA gains its power from a kind of strategic codification (or discursive practice), allowing the enterprise to "harness the nexus", thereby "revolutionizing business and society, disrupting old business models and creating new leaders". (Gartner website, retrieved 17 August 2013)



Update

@tetradian commented on the dangers of spurious 'authority' - 'spurious' in sense of claiming an aura of 'authority' when there's none to be had (b/c it isn't 'science' anyway)

I agree that claims of scientific status or method in the EA world are generally spurious. But there are other ways of asserting authority. For me, the key question is why (and on what grounds) should anyone trust the pronouncements of EA. It is not just about danger versus safety, but about authority versus authenticity.

Sunday, July 28, 2013

Schism and doubt

On Friday 14th June, there was a public meeting of the EAST group, entitled Perspectives on Enterprise Architecture and Systems Thinking, kindly hosted by BT in its offices near St Paul's. Tom Graves has posted a detailed write-up on his blog At ‘EA and Systems-Thinking’ conference.

What is the purpose of dialogue between EA and ST? Putting aside the debate about what the labels "Enterprise Architecture" and "Systems Thinking" might mean, there is certainly a thought that the two (or more) communities can learn from each other. There are strengths and weaknesses on both sides - so we may be able to produce a critique of EA from an ST perspective, or a critique of ST from an EA perspective. For example, in his presentation, John Holland asserted that "EA is broken - How ST can help". (See Tom's blog for summary.)

This kind of material often arouses a certain kind of resistance. "He's not talking about me, he must be talking about someone else." Where are the EAs to whom such a criticism as John's might apply? Surely the fact that we are going to these meetings, or reading these blogs, or participating in these Linked-In discussions, puts us into the most sophisticated and reflective quartile? 

One of the fundamental questions underlying discussion of EA and ST is imagining some kind of landscape with more or less distinct zones: EA over here, ST over there, this or that school of EA, this or that school of ST, good EA versus bad EA, authentic ST versus fake ST, mainstream versus next practice.

I have written several pieces on the relationship between Enterprise Architecture (EA) and Systems Thinking (ST), on this blog and elsewhere, but such pieces are always open to challenge by those who disagree about the correct use of the labels.

  • "That's not what real Enterprise Architects do."
  • "That's not really Systems Thinking."
So it sometimes seems that we cannot even start talking about EA and ST, and about the relationship (if any) between them, until we can agree what these terms mean. The desire to name things properly is an ancient one, and can be found in the Analects of Confucius. (See my post on the Wisdom of Confucius). But the prevailing desire to impose one's own definitions leads to endless and mostly unproductive debate on Linked-In and elsewhere. For this meeting, we hoped for a more productive energy, and I like to think we largely succeeded.

Some of the speakers fell into a dialectic mode of presentation - on the one hand EA, on the other hand ST. This can be useful as a starting point, but if the distinction between EA and ST is taken too seriously it may drive a wedge between practitioners. As Tom commented, "there don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really." For my part, instead of trying to avoid making any distinctions whatsoever, I put up a few slides with some provocative and playful distinctions, flagged with "possibly" and "tongue-in-cheek". But I haven't always been consistent about this, and (as someone pointed out to me) I probably need to be more careful when making a rhetorical contrast between "mainstream" and "next practice".

The EA/ST landscape may include Confucian and dialectic modes, but it should also include Daoist and dialogic modes. (For a brief explanation of the difference between dialectic and dialogic, see Wikipedia: Dialogic.) Robust debate between dogmatic EA and dogmatic ST may lead to schism, but even that is preferable to bland and empty speech. If we want to have a serious discussion about the strengths and weaknesses of current practice, then we must be prepared for robust critique, and we should not have to worry about over-sensitive practitioners taking everything personally.

One possible aspiration is to build a bridge between two communities, or perhaps even one single community. In their presentation, Patrick Hoverstadt and Lucy Loh presented some recent work of the EAST working group, showing how the concepts and techniques of EA and ST could be combined to address business challenges. This work is ongoing.
If we take the view that community building depend on affiliation (finding common beliefs and values), then any schism and doubt may seem to undermine this agenda. However, there is a more robust path to community building, based on alliance (accepting and overcoming difference for the sake of collaboration). For an eloquent defence of what she calls Deep Disagreement, see Margaret Heffernan's TED Talk Dare to Disagree.

Perhaps some people will think me perverse, but I look forward to plenty more friendly disagreement between EA and ST in future.




Saturday, July 20, 2013

Executive Moves

Before the start of the football season, football journalists have little to write about except transfer speculation - wondering which player might be about to transfer from one overpaid job to another overpaid job. This period is known as the Transfer Window.

The simplest assumption is that a player's talent is completely transferable from one club to another. His individual performance at his new club will be similar to his individual performance at his old club, and this is why he commands a particular market valuation.

Of course it is never as simple as this. An astute manager may spot a player who is performing poorly for his current club, and may be able to acquire such a player cheaply, at a price that doesn't reflect his full potential. A well-known example is the transfer of Thierry Henry from Juventus (where he had a disappointing season playing on the wing) to Arsenal (where he made his name as a world-class footballer).

Conversely, there have been many players who have been transferred at inflated prices, and who have then performed disappointingly for their new club. Any football fan will be able to name examples. The possible reasons for such failures range from personality clashes and team culture, to differences in team strategy and style. A player that is brilliant in one formation may struggle in an unfamiliar formation. (See Wikipedia: Soccer formation.)

Similar considerations may apply when a senior manager moves from one company to another. An executive commands a high salary because of a widespread belief that her skills and experience are easily transferable within the same sector, or even across sectors. Thus if a company has challenges in (say) supply chain, it seems to make sense to poach some supply chain expertise from elsewhere.

This is turn relies on an assumption that supply chain is basically the same everywhere. In business architecture, such assumptions result in enterprise models that abstract away from what makes each company unique, and concentrate on showing what all companies in a given sector have in common. So naturally there will be a box called Supply Chain. (Or Supply Chain Management, or Manage Supply Chain, or whatever your naming standards dictate.)

When an executive move doesn't work out, this often leads to suggestions of personality clashes or company politics. Technocrats love these explanations, because they regard such matters as beyond their understanding or control. But personality clashes and company politics are often symptoms of some deeper (structural) differences. Perhaps the challenges of supply chain innovation (and the creative tension between supply chain and other capabilities) are not the same in all companies; in which case, we should be wary of relying too heavily on enterprise models that make supply chain appear the same everywhere. Obviously business architects are interested in the things that companies have in common, but business architects must also be able to articulate (and help reinforce) those things that make a particular company unique.

In my presentation to the IASA conference in April 2013, I discussed the evident differences between hi-tech companies (Amazon, Apple, Facebook, Google, Microsoft, Oracle), and challenged business architects to explain these differences in structural terms. I have my own ideas about how this can be done, and I am interested to hear other ideas.




@wimrampen writes that this post fits well with @jhagel's Strategy Made Simple. "Nothing simple about strategy ;) but @jhagel does great job showing what's really important", adds @wimrampen.