Quality and Responsibility

One of the key challenges with shared data and shared services is the question of data quality. Who is responsible for mistakes?

@tonyrcollins raises a specific example - who's responsible for mistakes in summary care records?

"NHS Connecting for Health suggests that responsibility for mistakes lies with the person making the incorrect entry into a patient's medical records. But the legal responsibility appears to lie with the Data Controller who, in the case of Summary Care Records, is the Secretary of State for Health."

From an organizational design point of view, it is usually best to place responsibility for mistakes along with the power and expertise to prevent or correct mistakes. But that in turn calls for an analysis of the root causes of mistakes. If all mistakes can be regarded as random incidents of carelessness or incompetence on the part of the person making the incorrect entry, then clearly the responsibility lies there. But if mistakes are endemic across the system, then the root cause may well be carelessness or incompetence in the system requirements and design, and so the ultimate responsibility rightly lies with the Secretary of State for Health.

Part of the problem here is that the Summary Care Record (SCR) is supposed to be a Single Source of Truth, and I have already indicated What's Wrong with the Single Version of Truth. Furthermore, it is intended to be used in Accident and Emergency, to support decisions that may be safety-critical or even life-critical. Therefore to design a system that is vulnerable to random incidents of carelessness or incompetence is itself careless and incompetent.

What general lessons can we learn from this example, for shared services and SOA? The first lesson is for design: data quality must be rigorously designed-in, rather than merely relying on validation filters at the data entry stage, and then building downstream functionality that uses the data uncritically. (This is a question for the design of the whole sociotechnical system, not just the software architecture.) And the second lesson is for governance: make sure that stakeholders understand and accept the distribution of risk and responsibility and reward BEFORE spending billions of taxpayers' money on something that won't work.

Architect Certification and Trust

@mattdeacon @wendydevolder @karianna @flowchainsensei @gojkoadzic @unclebobmartin .

---

Lots of good comments on Twitter and elsewhere about certification, in various contexts (enterprise architecture, agile, ...).

The purpose of a certificate is to enable you to trust the bearer with something. So we need to understand the nature of trust. In their book Trust and Mistrust, my friends Aidan Ward and John Smith identify four types of trust ...

• authority
• network
• commodity
• authentic

... and we can apply these four types to the different styles of certification that might be available.

In his attack on the World Agile Qualifications Board, @gojkoadzic quotes the Agile Alliance position on certification: employers should have confidence only in certifications that are skill-based and difficult to achieve. Yet, as Gojko continues, "most of the certificates issued today are very easy to achieve and take only a day or two of work, or even just attending the course".

If a certificate is issued by a reputable professional organization, then the value of the certificate is underwritten by the reputation of the issuing organization, so this counts as authority trust. In my post Is Enterprise Architecture a Profession? I have already stated my view that claims for professional status for enterprise architecture are at best premature, so there is no organization today that has sufficient authority to issue certificates of professional competence. However, if you can acquire a certificate simply by attending a short course and/or memorizing some document (such as TOGAF), then this is a commodity-based form of trust. Basically, such certificates will only be regarded as valuable if just enough people have them. (Which seems to be why some large consultancies have put all their practitioners through TOGAF training.)

Bob Marshall (@flowchainsensei) prefers vouching

Just found http://wevouchfor.org - Should keep me busy vouching (why oh why "certifying???") for capable folks for some time.

which is a form of network trust. If someone receives a lot of vouchers from his friends, that could either mean he is very popular or that he is involved in a lot of reciprocal back-scratching. (This kind of mutual recommendation is easily visible on Linked-In, where the list of incoming recommendations often exactly matches the list of outgoing recommendations.)

The trouble with all these mechanisms is that they are both one-sided and lacking context. The certificate purports to tell us about a person's strengths (but not weaknesses), in some unspecified or generic arena. This can only go so far in supporting a judgement about a person's qualifications (strengths and weaknesses) for a specific task in a specific context. What if anything would serve as an authentic token of trust?

---

Aidan Ward and John Smith, Trust and Mistrust - Radical Risk Strategies in Business Relationships. John Wiley, 2003