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 (SSOT), and I have already indicated What's Wrong with the Single Version of Truth (SVOT). 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

What does Application Modernization really mean?

@cbdi #SOA My friends at the CBDI Forum have been applying their expertise in Service-Oriented Architecture to the question of Application Modernization. See David Sprott's blogpost The meaning of life and application modernization (Jan 2010) See also Application Modernization Special Issue (CBDI Journal December 2009).

Of course, people have been talking about Application Modernization for many years (see note), but David's approach is strongly based on his favourite architectural principles - not just SOA principles (loose coupling, abstraction, and so on) but also model-driven development.

In general terms, modernization contains two opposing ideas - separation (Latour calls this "purification") and mixture ("hybridization"). In application modernization, separation of concerns is a well-established architectural notion, related to modularization and encapsulation. Hybridization refers to things that are neither one thing nor the other - for example, the creation of processes and systems that are neither wholly automated nor wholly manual, neither wholly inhouse nor wholly outsourced, but some complex and potentially volatile mixture. This means creation of highly reusable components and services, that can be redeployed and repurposed in unforeseen ways.

---

Bruno Latour, We have never been modern (trans Catherine Porter, Harvard University Press, 1993)


Peter J. Leithart, Semi-Modernism (November 2006) We Have Never Been Modern (October 2013) "We Have Never Been Modern" (December 2014)

Wikipedia: Separation of Concerns

---

Note: In October 2006, HP, Intel and Oracle jointly launched an Application Modernization Initiative (HP Press Release. See also Dana Gardner, Not just a nip and tuck, application modernization extends the lifecycle of legacy code assets, October 2006). During 2008, a couple of niche application modernization companies were acquired: Jacada by Software AG (ebizQ, January 2008) and Relativity Technologies by Microfocus (Press Release, December 2008). IBM's webpage on Business application modernization services is dated October 2008.