From information architecture to evidence-based practice

@bengoldacre has produced a report for the UK Department for Education, suggesting some lessons that education can learn from medicine, and calling for a coherent “information architecture” that supports evidence based practice. Dr Goldacre notes that in the highest performing education systems, such as Singapore, “it is almost impossible to rise up the career ladder of teaching, without also doing some work on research in education.”

Here are some of his key recommendations. Clearly these recommendations would be relevant to many other corporate environments, especially those where there is strong demand for innovation, performance and value-for-money.

• a simple infrastructure that supports evidence-based practice
• teachers should be empowered to participate in research
• the results of research should be disseminated more efficiently
• resources on research should be available to teachers, enabling them to be critical and thoughtful consumers of evidence
• barriers between teachers and researchers should be removed
• teachers should be driving the research agenda, by identifying questions that need to be answered.

Clearly it is not enough merely to create an information architecture or knowledge infrastructure. The challenge is to make sure they are aligned with an inquiring culture.

to be continued ...

---

Ben Goldacre, Teachers! What would evidence based practice look like? (Bad Science, March 2013)

From Design Thinking to Creative Intelligence

Some fans of Design Thinking got very excited about the references to design thinking in the US Army Field Manual 5-0: The Operations Process (pdf), published in March 2010, where design is described as a kind of sensemaking or orientation process - an intelligent front-end to the real business of decision making and action.

the importance of understanding complex problems more fully before we seek to solve them through our traditional planning processes ... applying design to understand before entering the visualize, describe, direct, lead, and assess cycle.

Thus design is part of the intelligence loop (rather than the other way around). See also @EllenNaylor on Design Thinking for Strategic Competitive Advantage.

In April 2011, Bruce Nussbaum, described as "one of Design Thinking’s biggest advocates" posted a blog entitled Design Thinking Is A Failed Experiment. So What’s Next? His answer: Creative Intelligence, the ability to frame problems in new ways and to make original solutions.

On the one hand, Nussbaum dreams that that his godchild will win admission to a top university on the strength not only of her IQ but also her creative intelligence - in other words, seeing creative intelligence as an attribute of individual genius. On the other hand, he wants to frame creative intelligence not in terms of a psychological approach of development stages but a sociological approach in which creativity emerges from group activity - in other words, seeing creative intelligence as an attribute of a group or organization, not just the individuals within it.

See further commentary by Tom Berno, Cameron D Norman, Erica Schlaikjer.

---

The draft of my book on Organizational Intelligence is now available on LeanPub http://leanpub.com/orgintelligence. Please support this development by subscribing and commenting. Thanks.

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:

"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)

Is Enterprise Architecture a Science? Part 2

@RSessions was in London this week, so I sat down with him to continue our previous discussion Is Enterprise Architecture a Science?

The first question to address is - which enterprise architecture are we talking about? I think we both agree that there are some activities within the EA world that look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

For example, in his post What's Right with the Zachman Framework, Grant Czerepak states that "the architectural metaphor conceals what the six perspectives are actually about: Entities, Relationships, Attributes, Constraints, Definitions and Manipulations". And referring to the Kipling-Zachman lens, Grant claims that "the interrogatives have a foundation that goes back over three thousand years across every human culture". In a separate post, he says It's not Aristotle's fault, it's your fault. See my post Arguing with Mendeleev (March 2013).

Lots of EA frameworks are essentially abstract classification schemes that start from an abstract ontological argument ("obviously all businesses are made of objects" or "obviously all processes are made up of nouns and verbs") and make assertions that are not amenable to empirical verification.

Roger's SIP methodology is at least based on an empirically testable (and quantified) hypothesis. That a system of systems with such-and-such measurable structural qualities (in terms of Roger's definition of complexity) will have such-and-such predictable costs. So this provides the basis for a scientifically-grounded engineering practice. I think SIP methodology has a reasonable claim to be scientifically grounded: it can be evaluated not just on whether its prescriptions are practical, cost-effective and useful, but also whether its predictions are true. (Incidentally, I think it would be interesting to compare SIP with Christopher Alexander's early book Notes on the Synthesis of Form. This contains detailed and mathematically grounded work on architectural complexity: although the software gurus who developed structured methods in the 1970s were aware of Alexander's book, they left out most of the difficult detail.)


I think there is a further step before EA could ever dream of becoming a fully empirical science, and this would involve large-scale collection and analysis of empirical data, so that there would be a closed loop between theory and practice, connecting structure and value. In order to achieve this, we should need the active participation of some of the more powerful players in the EA game - the large consultancies and above all the key government agencies that govern IT expenditure. (You know who you are.) At the moment, there is little sign that these organizations are seriously interested in any game-changing innovation. (Roger and I should be delighted to talk to representatives of these organizations, please contact us.)

Is Architecture the Enemy of Innovation?

asks @EnterprisingA . Well, obviously architecture is not the avowed enemy of innovation. As Jon points out, they ought to be on the same side, because there are some strong shared values.

But surely the real question is not whether they ought to be helping each other, but whether (good intentions notwithstanding) they actually do support each other's efforts more than they (inadvertently) hinder and interfere with each other.

I think there is some evidence for the proposition that Architecture and Innovation don't actually collaborate as well in practice as they ought to in theory. This does not necessarily mean a critique of Architecture as such, but a critique of current "best practices".

Jon talks about the TO-BE architecture, but I am also interested in the TO-BE practice of architecture.

Loose Coupling: Innovation and the Web

"Cosy social networks are stifling innovation", according to an article in the New Scientist (5 August 2009).

This is a familiar argument in a new context. It has often been argued that corporate culture can inhibit innovation, and that groups responsible for experimental products and processes tend to perform better if they are put into a separate organization unit at some distance from the main offices. In recent years, many companies have set up R and D units in special science parks, co-located with similar units from other companies, usually with links to a nearby university. This is essentially applying architectural thinking to the geographical location and distribution of certain classes of capability, and reflects a common belief in the importance of these factors.

But interaction and clustering is nowadays much less dependent on physical geography, and much more dependent on virtual online communities and networks. The New Scientist article quotes Viktor Mayer-Schönberger of the National University of Singapore, who argues that today's software developers work in social networks in which everyone is closely linked to everyone else. "The over-abundance of connections through which information travels reduces diversity and keeps radical ideas from taking hold."

What Mayer-Schönberger sees as an over-abundance of connections is actually another form of tight coupling. If we want to build the capability for radical innovation, we need to create a decoupled space to support a loosely coupled knowledge cycle. Which means careful attention to the effects of social networking and organizational intelligence.

IT Innovation at Small Bakery

Can your IT department innovate like this bakery? asks Mark Raskino (Gartner) via Sally Bean. Mark describes an East London bakery that uses Twitter to notify its customers whenever freshly baked bread comes out of the oven.

The system involves a specially designed wall-mounted device that the bakers can operate with one hand, while holding a tray of bread with the other.

Mark clearly doesn't think most IT departments would be comfortable with this kind of system. So I asked Mark and Sally who would lead that kind of innovation in a typical IT department. Would it be the business analysts? The enterprise architects?

The trouble is that many people in those kind of IT roles have been trained to value abstraction and adaptability above everything else, and to avoid thinking about mundane technology when building pure business models. But how often does that kind of abstract thinking produce concrete innovations like this bakery? In many organizations it is quite the opposite - technology-driven opportunistic change to the business model is discouraged because it runs contrary to prevailing thinking. And as Mark points out, corporate IT departments don't like purpose-designed hardware. This system is not designed for adaptability, it is designed to improve the business.

So this project was driven by a marketing agency. Business innovation may depend on the latest technology; but wouldn't it be a disgrace if it turned out that the most innovative companies are those too small to have an IT department?

Grandpa's SOA

JJ complains about SOA misconceptions, including the widespread claim that "SOA is not new, people were doing SOA 30 years ago". And it's not just SOA that attracts claims like these. I meet people who claim they were doing BPM and workflow twenty years ago.

JJ believes we can date SOA ("as we know it today") to the appearance of XML-RPC in early 1998. If we define SOA and BPM in technological terms, involving the use of a particular set of technologies, then it is certainly difficult to see how SOA and BPM could predate these technologies.

But if we define SOA and BPM in architectural terms, involving certain styles and patterns, then it is quite possible that some people were experimenting with these styles and patterns perhaps long before the associated technologies appeared. Indeed, according to writers like Lewis Mumford, this kind of pre-technological experimentation may be a vital step in the development of new technologies.

To take an analogy from electronic music, I am quite comfortable with the idea that Karlheinz Stockhausen and Delia Derbyshire were producing synthesized music before synthesizers existed. (See my post on Art and the Enterprise.)

But before modern synthesizers existed, the field of electronic music involved a very small number of brilliant composers (and a slightly larger number of not-so-brilliant composers), devoting enormous effort and expense to produce a very small amount of music (of varying quality).

Likewise, there were no doubt a very small number of brilliant software designers thirty years ago, doing amazing stuff with CICS and PL/1. Okay, so there wasn't a critical mass of network-accessible reusable IT assets then, but nor was there in 1998 either.

Mass adoption of industrial-strength SOA has only been feasible in the last few years. Thirty years ago, we didn't use the language of service-orientation. By the early 1990s there were lots of people in the ODP world looking beyond CORBA and talking seriously about services. And by the late 1990s there were lots of vendors trying to talk up the SOA vision.

The trouble is that when people talk about SOA, they typically lump together a load of different stuff. Some of this stuff was possible with CICS and PL/1 if you were very clever and your employer had deep pockets; some of it is possible today with the latest web service platforms; and some of it really isn't available yet.

How much of SOA is new is an impossible and subjective question. (See my post on the Red Queen Effect.) SOA champions spend half their time explaining how radical SOA could be, and half their time reassuring people how tried-and-tested and safe and based on sound principles it all is. So maybe grandpa is right some of the time, after all.