#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.
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)
Showing posts with label joined-up. Show all posts
Showing posts with label joined-up. Show all posts
Saturday, May 24, 2014
Friday, September 17, 2010
Chinese Walls
In Joined up Daily Mail, @psbook via @chris_yapp points out a contradiction between the front page (attacking @stephenfry) and an advertisement on page 27 (featuring @stephenfry). "Perhaps the Daily Mail should try a little harder not to offend their advertisers?"
The Daily Mail is not my favourite newspaper (as readers of my posts on the POSIWID blog will know), but with this news my respect for the Daily Mail has gone up a notch - at least they aren't allowing their advertisers to influence the front page.
What's this got to do with architecture? We have here an example of a clash between economics (which apparently favours joined-up thinking) and ethics (which in this case apparently favours the opposite), typically resolved by the erection of an intra-organizational boundary known as a Chinese Wall. This is a structure within an enterprise intended to reduce conflicts of interest, asymmetrical information and moral hazard.
For example, financial institutions are supposed to have Chinese Walls, to prevent various patterns of inappropriate behaviour, including Insider Trading and Insider Recommendations. Among other things, the Chinese Wall is supposed to protect investment analysts from commercial pressure from other parts of the same organization. Recently, there has been much criticism of financial analysts (especially in America) who recommend the purchase of stocks simply because their colleagues have a commercial interest in promoting that stock.
Sometimes of course, the Chinese Wall is just a notional boundary, with little real effect - for symbolic or compliance purposes only. Although the actual information flows may be concealed, a strong correlation between activities on both sides of the wall may be sufficient evidence that some collusion has occurred. (Clearly architects need to appreciate the differences between official structure and defacto structure.)
In journalism, there is always supposed to be a Chinese Wall between editorial and advertising, to protect the objectivity of the journalists from commercial bias. This principle is often blatently breached, so it is pleasing to see the Daily Mail following the principle on this occasion. Although I disagree with their attack on Mr Fry, I respect the fact that the Mail has chosen to offend their advertisers rather than abandon its strongly held views.
The Daily Mail is not my favourite newspaper (as readers of my posts on the POSIWID blog will know), but with this news my respect for the Daily Mail has gone up a notch - at least they aren't allowing their advertisers to influence the front page.
What's this got to do with architecture? We have here an example of a clash between economics (which apparently favours joined-up thinking) and ethics (which in this case apparently favours the opposite), typically resolved by the erection of an intra-organizational boundary known as a Chinese Wall. This is a structure within an enterprise intended to reduce conflicts of interest, asymmetrical information and moral hazard.
For example, financial institutions are supposed to have Chinese Walls, to prevent various patterns of inappropriate behaviour, including Insider Trading and Insider Recommendations. Among other things, the Chinese Wall is supposed to protect investment analysts from commercial pressure from other parts of the same organization. Recently, there has been much criticism of financial analysts (especially in America) who recommend the purchase of stocks simply because their colleagues have a commercial interest in promoting that stock.
Sometimes of course, the Chinese Wall is just a notional boundary, with little real effect - for symbolic or compliance purposes only. Although the actual information flows may be concealed, a strong correlation between activities on both sides of the wall may be sufficient evidence that some collusion has occurred. (Clearly architects need to appreciate the differences between official structure and defacto structure.)
In journalism, there is always supposed to be a Chinese Wall between editorial and advertising, to protect the objectivity of the journalists from commercial bias. This principle is often blatently breached, so it is pleasing to see the Daily Mail following the principle on this occasion. Although I disagree with their attack on Mr Fry, I respect the fact that the Mail has chosen to offend their advertisers rather than abandon its strongly held views.
Sunday, October 25, 2009
Towards an Architecture of Privacy
@futureidentity (Robin Wilton) posted some interesting ideas about Identity versus attributes on his blog.
However, there is an important difference between Robin's two examples. Blood transfusion is a transaction with longer-lasting consequences. If a batch of blood is contaminated, thereseems to be is a legitimate regulatory requirement to trace forwards (who received this blood) and backwards (who donated this blood), in order to limit the consequences of this contamination event and to prevent further occurrences.
There is a strong demand for increasing traceability. In manufacturing, we want to trace every manufactured item to a specific batch, and associate each batch with specific raw materials and employees. In food production, we want to trace every portion back to the farm, so that salmonella outbreaks can be blamed on the farmer. See Information Sharing and Joined-Up Services 1, 2.
Transactions that were previously regarded as isolated ones are now increasingly joined-up. The eggs that go into the custard tart you buy in the works canteen used to be anonymous, but in future they won't be. See Labelling as Service 1, 2.
There is also a strong demand for increased auditability. So it is not enough for the barman to check the drinker's age, the barman must keep a permanent record of having diligently carried out the check. It is apparently not enough for the hotel or bank clerk to look at my passport, they must retain a photocopy of my passport in order to remove any suspicion of collusion. (The bank not only mistrusts its customers, it also mistrusts its employees.)
There is a large (and growing) class of situations where so-called joined-up-thinking seems to require the negation of privacy. I am certainly not saying that this reasoning should always trump the needs of privacy. But privacy campaigners need to understand that all transactions belong within some system of systems, and that this provides the context for the forces they are battling against, rather than pretending that transactions can be regarded as purely isolated events. The point is that authorization is not an isolated event, but is embedded in a larger system, and it is this larger system that apparently requires greater disclosure and retention.
@j4ngis asks how long chains to use for traceability. What "length" of traceability is sound and meaningful? How do we connect all these traces? And also backward and forward in the "chain". For how long should records be kept?
Robin clearly supposes that attribute-based authorization is a "Good Thing". I am sympathetic to this view, but I don't know how this view can stand up against the kind of sustained attack from a certain flavour of joined-up systems thinking that can almost always postulate the possibility (however faint) of saving lives or protecting children or catching criminals, if only we can retain everything and trace everything.
For my part, I have a vague desire for anonymity and privacy, a vague sense of the harm that might come to me as a result of breaches to my privacy, and a surge of annoyance when I am required to provide all sorts of personal data for what I see as unreasonable purposes, but I cannot base an architecture on any of these feelings.
Traditional arguments for data protection may seem to be merely rearguard resistance to integrated and joined-up systems. Traditional architectures for data protection look increasingly obsolete. But what alternatives are there?
Update May 2016
Traceability requirements for Human Blood and Blood Components are specified in Directive 2005/61/EC of the European Parliament and of the Council 30 September 2005 (pdf - 63KB)
Robin's point was that blood type was more important than identity, and of course this is true. Donor and recipient identity must be retained for 30 years, but that doesn't mean sharing this information with everybody in the blood supply chain.
"For an awful lot of service access decisions, it's not actually important to know who the service requester is - it's usually just important to know some particular thing about them. Here are a couple of examples:
- If someone wants to buy a drink in a bar, it's not important who they are, what's important is whether they are of legal age;
- If someone needs a blood transfusion, it's more important to know their blood type than their identity."
However, there is an important difference between Robin's two examples. Blood transfusion is a transaction with longer-lasting consequences. If a batch of blood is contaminated, there
There is a strong demand for increasing traceability. In manufacturing, we want to trace every manufactured item to a specific batch, and associate each batch with specific raw materials and employees. In food production, we want to trace every portion back to the farm, so that salmonella outbreaks can be blamed on the farmer. See Information Sharing and Joined-Up Services 1, 2.
Transactions that were previously regarded as isolated ones are now increasingly joined-up. The eggs that go into the custard tart you buy in the works canteen used to be anonymous, but in future they won't be. See Labelling as Service 1, 2.
There is also a strong demand for increased auditability. So it is not enough for the barman to check the drinker's age, the barman must keep a permanent record of having diligently carried out the check. It is apparently not enough for the hotel or bank clerk to look at my passport, they must retain a photocopy of my passport in order to remove any suspicion of collusion. (The bank not only mistrusts its customers, it also mistrusts its employees.)
There is a large (and growing) class of situations where so-called joined-up-thinking seems to require the negation of privacy. I am certainly not saying that this reasoning should always trump the needs of privacy. But privacy campaigners need to understand that all transactions belong within some system of systems, and that this provides the context for the forces they are battling against, rather than pretending that transactions can be regarded as purely isolated events. The point is that authorization is not an isolated event, but is embedded in a larger system, and it is this larger system that apparently requires greater disclosure and retention.
@j4ngis asks how long chains to use for traceability. What "length" of traceability is sound and meaningful? How do we connect all these traces? And also backward and forward in the "chain". For how long should records be kept?
- Should we also know the batch number for the food that was given to the chicken that laid the egg you included in the cake?
- Do we have to know the identity of the blood donor after six months? 10 years? 100 years?
Robin clearly supposes that attribute-based authorization is a "Good Thing". I am sympathetic to this view, but I don't know how this view can stand up against the kind of sustained attack from a certain flavour of joined-up systems thinking that can almost always postulate the possibility (however faint) of saving lives or protecting children or catching criminals, if only we can retain everything and trace everything.
For my part, I have a vague desire for anonymity and privacy, a vague sense of the harm that might come to me as a result of breaches to my privacy, and a surge of annoyance when I am required to provide all sorts of personal data for what I see as unreasonable purposes, but I cannot base an architecture on any of these feelings.
Traditional arguments for data protection may seem to be merely rearguard resistance to integrated and joined-up systems. Traditional architectures for data protection look increasingly obsolete. But what alternatives are there?
Update May 2016
Traceability requirements for Human Blood and Blood Components are specified in Directive 2005/61/EC of the European Parliament and of the Council 30 September 2005 (pdf - 63KB)
Robin's point was that blood type was more important than identity, and of course this is true. Donor and recipient identity must be retained for 30 years, but that doesn't mean sharing this information with everybody in the blood supply chain.
Wednesday, March 26, 2008
Public Sector SOA
The UK Government has identified four primary opportunities for using SOA in eGovernment:
This is essentially a call for public-private mashups - in other words, joined-up services. There are some interesting opportunities for voluntary agencies and community groups to create customized "added value" services for particular target groups. This kind of thing can help to extend the reach of government services into otherwise disadvantaged groups, and thereby supports an "inclusivity" agenda.
This can also support an agenda of autonomy and decentralization, including alternative notions of identity (e.g. Identity 2.o).
Among other things, this supports an agenda of "joined-up policy making", because it helps with the coordination, monitoring and maintenance of a broad range of policies across a broad portfolio of government systems and services. Ideally, government should be working towards closed-loop policy management, in which (i) policies can be directly associated with the sum of their outcomes, using service-oriented business intelligence and analytics, and (ii) policies can be adjusted in a coordinated manner to improve outcomes.
In other words, joined-up infrastructure. At the infrastructure level government requirements are pretty similar to those of any other large organization, except that governments often put greater emphasis on open standards, multi-vendor support and interoperability.
Finally we come to joined up business processes - orchestration and workflow, choreography and collaboration. This is perhaps the most obvious type of joined-up government, but not (as we have seen above) the only type.
So who does the joined-up thinking? Apparently, the joining-up initiative isn't imposed by any centralized planning body, but merely stems from "an agency wishing to interact with another agency". (So no arm-twisting from the Prime Minister then?)
UK GovTalk e-GIF FAQ
[update] For a description of current initiatives in Canada, see John Gøtze: Aligning the Ducks.
- Syndication
- Rule Engine
- Joining up internal architecture
- Hand-shaking between agencies
Syndication
"This is where the services of a single Agency are to be aggregated with that of others and delivered by a third-party. This approach is supported by the introduction of common vocabularies and category lists such as the Integrated Public Sector Vocabulary (IPSV). A potential example would be DirectGov."
This is essentially a call for public-private mashups - in other words, joined-up services. There are some interesting opportunities for voluntary agencies and community groups to create customized "added value" services for particular target groups. This kind of thing can help to extend the reach of government services into otherwise disadvantaged groups, and thereby supports an "inclusivity" agenda.
This can also support an agenda of autonomy and decentralization, including alternative notions of identity (e.g. Identity 2.o).
Rules Engine
"Where a number of Agencies are dependant upon the rules set by another agency, and where those rules are complex and likely to change. A Web Services ‘call’ can be embedded into an application to perform calculations and return results into local data."
Among other things, this supports an agenda of "joined-up policy making", because it helps with the coordination, monitoring and maintenance of a broad range of policies across a broad portfolio of government systems and services. Ideally, government should be working towards closed-loop policy management, in which (i) policies can be directly associated with the sum of their outcomes, using service-oriented business intelligence and analytics, and (ii) policies can be adjusted in a coordinated manner to improve outcomes.
Joining Up Internal Architecture
"Where an Agency operates enterprise technologies, such as Workflow, Records Management, Middleware, Content Management. This approach avoids embedding API(s) from one component into another. The potential to create Web Services wrappers around proprietary technologies leads to the ‘swapability’ promoted by the e-GIF."
In other words, joined-up infrastructure. At the infrastructure level government requirements are pretty similar to those of any other large organization, except that governments often put greater emphasis on open standards, multi-vendor support and interoperability.
Handshaking with other Agencies
"Where an Agency wishes to interact with another Agency (G2G). This may be in terms of: Creating Workflow Instances, Making Appointments, Shared CRM facilities. Access to Data."
Finally we come to joined up business processes - orchestration and workflow, choreography and collaboration. This is perhaps the most obvious type of joined-up government, but not (as we have seen above) the only type.
So who does the joined-up thinking? Apparently, the joining-up initiative isn't imposed by any centralized planning body, but merely stems from "an agency wishing to interact with another agency". (So no arm-twisting from the Prime Minister then?)
Final remarks
Joined-up government is not just about joined-up processes - it also includes joined-up services, joined-up policy and joined-up platforms. There are some interesting initiatives underway in the UK government, and I look forward to seeing some practical results soon.Sources
UK GovTalk e-GIF FAQ
[update] For a description of current initiatives in Canada, see John Gøtze: Aligning the Ducks.
Friday, May 25, 2007
Joined-Up Healthcare
25 May 2007
A report has just been published on the sad death of Penny Campbell, who died of blood poisoning two years ago, after calling the health service eight times in four days [BBC News, May 25th 2007].Apparently each of the calls was treated as a separate event, with no linkage made between them.
Joined-up services doesn't just mean joining up disparate events and processes. Sometimes it's hard enough to join up multiple instances of the same event/process.
In an earlier post on Healthcare Reform, I referred to the possibility of triage. If we can separate simple cases from complex ones, then nurses and other professionals can take some responsibility for the simple cases, call in the doctors for medium cases, and send the most complex cases into hospital.
But it appears that Penny Campbell's fate was the exact reverse of this. The system (if you can call it a system) of out-of-hours healthcare seems to result in highly trained doctors perfoming at a level of capability barely any better than what could be achieved by nurses and other professionals.
A number of issues for event-driven SOA there.
10 March 2010
This case was mentioned on BBC radio this morning. Dr Simon Eccles of NHS Connecting for Health appeared to suggest that the NPfIT Summary Care Records might have saved Penny Campbell's life. As Tony Collins points out in his blog (BMA and CfH argue it out over NPfIT Summary Care Records), this claim assumes that the relevant doctors would be able and willing to add sufficiently detailed notes to the Summary Care Record in such a case. As it happens, the current scheme (which is something like ten years overdue already) doesn't allow for such notes to be added to the Summary Care Record. (Perhaps the word "summary" provides a little clue there.)
The key point here is that "joined-up" doesn't just mean putting all the data into some vast and horribly expensive data store, so that thousands and thousands of people around the country can look at your summary care record, it's about having a joined-up process that allows the doctors and other health professionals actually involved in your case to use their medical expertise and intelligence to produce the best possible outcomes. Lots of people remain sceptical that the current scheme would ever achieve this. See my post What's Wrong with the Single Version of Truth.
Monday, January 15, 2007
Information Sharing and Joined-Up Services 2
My colleague David Sprott has just posted a critique (Big Brother Database Dinosaur) of the latest UK Government proposals [Note 1] for putting citizen data into a large central database.
As many commentators have pointed out [Note 2], a large central database of this kind would have to be built to extremely high standards of data quality and data protection. Given the recent history of public sector IT, it is hard to be confident that such standards would be achieved or maintained. There is also the question of liability and possible compensation - for example if a citizen suffered financial or other loss as a result of incorrect data.
But in any case, as David points out from an SOA perspective, the proposal is architecturally unsound and technologically obsolescent. Robin Wilton (Sun Microsystems) comes to a similar conclusion from the perspective of federated identity.
Government ministers are busily backtracking on the "Big Brother" elements of the proposal [Note 3], but the policy paper confirms some of the details [Note 4].
David's comments refer mainly to the proposed consolidation of citizen information across various public sector agencies within the UK. But there is another information-sharing problem in the news at present - the fact that the UK criminal records database does not include tens of thousands of crimes committed by UK citizens in other countries. [Note 5]
Part of the difficulty seems to be in verifying the identity of these records. Information sharing requires some level of interoperability, and this includes minimum standards of identification. There are some serious issues here, including semantics, which can never be resolved merely by collecting large amounts of data into one place.
The problem of information sharing within one country is really no different from the problems of information sharing between countries. But at least in the latter case there is nobody saying we can solve all the problems by building a single international database. At least I hope not.
As I said on this blog in 2003 [Note 6], we need to innovate new mechanisms to manage information sharing. This is one of the opportunities and challenges for SOA in delivering joined-up services in a proper manner. Then centralization becomes irrelevant.
Note 1: BBC News January 14th 2007
Note 2: Fish & Chip Papers: Government uber-databases,
Note 3: BBC News January 15th 2007. See also Fish & Chip Papers: Data sharing does not a Big Brother make.
Note 4: Daily Telegraph Microchips for mentally ill planned in shake-up.
Note 5: According to ACPO, some 27,500 case files were left in desk files at the Home Office instead of being properly examined and entered into the criminal records database. [BBC News]
Note 6: See my post from 2003 on Information Sharing and Joined-Up Services.
As many commentators have pointed out [Note 2], a large central database of this kind would have to be built to extremely high standards of data quality and data protection. Given the recent history of public sector IT, it is hard to be confident that such standards would be achieved or maintained. There is also the question of liability and possible compensation - for example if a citizen suffered financial or other loss as a result of incorrect data.
But in any case, as David points out from an SOA perspective, the proposal is architecturally unsound and technologically obsolescent. Robin Wilton (Sun Microsystems) comes to a similar conclusion from the perspective of federated identity.
Government ministers are busily backtracking on the "Big Brother" elements of the proposal [Note 3], but the policy paper confirms some of the details [Note 4].
David's comments refer mainly to the proposed consolidation of citizen information across various public sector agencies within the UK. But there is another information-sharing problem in the news at present - the fact that the UK criminal records database does not include tens of thousands of crimes committed by UK citizens in other countries. [Note 5]
Part of the difficulty seems to be in verifying the identity of these records. Information sharing requires some level of interoperability, and this includes minimum standards of identification. There are some serious issues here, including semantics, which can never be resolved merely by collecting large amounts of data into one place.
The problem of information sharing within one country is really no different from the problems of information sharing between countries. But at least in the latter case there is nobody saying we can solve all the problems by building a single international database. At least I hope not.
As I said on this blog in 2003 [Note 6], we need to innovate new mechanisms to manage information sharing. This is one of the opportunities and challenges for SOA in delivering joined-up services in a proper manner. Then centralization becomes irrelevant.
Note 1: BBC News January 14th 2007
Note 2: Fish & Chip Papers: Government uber-databases,
Note 3: BBC News January 15th 2007. See also Fish & Chip Papers: Data sharing does not a Big Brother make.
Note 4: Daily Telegraph Microchips for mentally ill planned in shake-up.
Note 5: According to ACPO, some 27,500 case files were left in desk files at the Home Office instead of being properly examined and entered into the criminal records database. [BBC News]
Note 6: See my post from 2003 on Information Sharing and Joined-Up Services.
Saturday, December 10, 2005
Joined-Up Government
Robin Wilton collected these trophies of Joined-Up Government at an e-Government conference in Manchester.
There have always been several different notions of J-U-G in play (as I have written before). I think it's particularly interesting to distinguish between an internal (service-provider) perspective and an external (citizen, service-consumer) perspective.
But internal joining-up is only half the story ...
Applying for a student place and applying for a loan are part of the same process. If government doesn't allow the citizen to synchronize these steps, then the citizen is forced to bear extra risk.
Joined-up government is then a way of improving service and reducing risk from the citizen's perspective as well as from the government's own perspective.
My CBDI Journal article on this topic is in the pipeline. Meanwhile, you may wish to look at an earlier article of mine on Joined-Up Services (2002).
Technorati Tags: government joined-up SOA service-oriented
I've been meaning to blog about Joined-Up Government (J-U-G) for a while now, and this just gives me a final nudge.
There have always been several different notions of J-U-G in play (as I have written before). I think it's particularly interesting to distinguish between an internal (service-provider) perspective and an external (citizen, service-consumer) perspective.
Internal Perspective
Governments can use SOA to connect within or between large departmental silos. There are enormous potential benefits in efficiency and effectiveness, which indirectly benefit the citizen.But internal joining-up is only half the story ...
External Perspective
... and this is an example of what joined-up government looks like from the citizen's perspective.Applying for a student place and applying for a loan are part of the same process. If government doesn't allow the citizen to synchronize these steps, then the citizen is forced to bear extra risk.
Joined-up government is then a way of improving service and reducing risk from the citizen's perspective as well as from the government's own perspective.
My CBDI Journal article on this topic is in the pipeline. Meanwhile, you may wish to look at an earlier article of mine on Joined-Up Services (2002).
Technorati Tags: government joined-up SOA service-oriented
Tuesday, December 23, 2003
Information Sharing and Joined-Up Services
In the UK, there have been two recent cases where lives might have been saved if certain information had been shared between certain organizations. The failure to maintain and communicate this information has been blamed on the Data Protection Act, although these particular cases may have been subject to excessively cautious interpretations of the Act.
Firstly, a police force failed to maintain and communicate information about a young man seeking employment as a school caretaker, who had been subject to a series of serious allegations of sexual misconduct. The man has now been convicted of the horrific murder of two girls at the school.
Secondly, a gas supplier failed to notify social services when disconnecting the gas supply of an elderly couple. The couple were later found dead.
Let’s take the second case. It has been suggested that the DPA might have permitted the gas company to pass information to social services if the couple were known to be at special risk, or already clients of social services. But this solution simply doesn’t work without a greater breach of privacy – it implies that the gas company already has access to some information about the couple, to justify treating them differently.
Once upon a time, utility companies were either in public ownership, or were run by private bureaucracies whose operational ethos was broadly similar to the civil service. Many of our expectations of “joined-up service” – where police and schools and social services and gas companies share vital information in the public interest – overlook the fact that we no longer live in this world, but a world of competitive commercial self-interest, outsourced operations and off-shore processing. Perhaps some companies behave honourably with the information they hold – but we can no longer take this for granted.
This means we need to innovate new mechanisms – social/institutional as well as technical ones – to manage information sharing between separate organizations, in a way that delivers the highest possible standards of joined-up services while respecting privacy and other social policies.
Firstly, a police force failed to maintain and communicate information about a young man seeking employment as a school caretaker, who had been subject to a series of serious allegations of sexual misconduct. The man has now been convicted of the horrific murder of two girls at the school.
Secondly, a gas supplier failed to notify social services when disconnecting the gas supply of an elderly couple. The couple were later found dead.
Let’s take the second case. It has been suggested that the DPA might have permitted the gas company to pass information to social services if the couple were known to be at special risk, or already clients of social services. But this solution simply doesn’t work without a greater breach of privacy – it implies that the gas company already has access to some information about the couple, to justify treating them differently.
Once upon a time, utility companies were either in public ownership, or were run by private bureaucracies whose operational ethos was broadly similar to the civil service. Many of our expectations of “joined-up service” – where police and schools and social services and gas companies share vital information in the public interest – overlook the fact that we no longer live in this world, but a world of competitive commercial self-interest, outsourced operations and off-shore processing. Perhaps some companies behave honourably with the information they hold – but we can no longer take this for granted.
This means we need to innovate new mechanisms – social/institutional as well as technical ones – to manage information sharing between separate organizations, in a way that delivers the highest possible standards of joined-up services while respecting privacy and other social policies.
Subscribe to:
Posts (Atom)