Under the pavement

@pbmobi asserts that "Infrastructure Architecture is the foundation for #entarch, not the other way round". This suggestion draws on a book review of "The Works: Anatomy of a City", in which the reviewer suggests that the tubes, wires and pipes under the pavements of New York are collectively more important than the city of towers above them.

So that's one sense of the word "foundation".

@pbmobi also quotes Frank Gehry via @nate_berg "There’s a lot of layers of bureaucracy that make it impossible to do creative work in cities."

So that's a completely different sense of the word "layer".


Bruno Latour gave a brilliant lecture at Brunel University in April 1998. Among other things, he talked about the (usually invisible) stuff under the pavements of Paris. As I recall, he showed some slides of various control rooms, each providing a different slice (are these layers or perspectives?) of the Parisian infrastructure. The point here is that there isn't one homogenous infrastructure, but a complex system of infrastructure systems that barely talk to each other except in an emergency. Sadly, the lecture is no longer available on the Brunel website, but I found a transcript on a Hungarian website.

---

Nate Berg, Frank Gehry on City Building, Atlantic Cities, 9th Jan 2012.

Bruno Latour, "Thought Experiments in Social Science: from the Social Contract to Virtual Society"
1st Virtual Society? Annual Public Lecture Brunel University 1st April 1998. [transcript] See also [Invisible Paris, pdf].

Alex Marshall, The Works Reveals City's Essential Systems. Spotlight Vol. 5, No. 2. January 26, 2006. Review of Kate Ascher, The Works: Anatomy of a City. Penguin Press 2005

See also my post OrgIntelligence in the Control Room (October 2010)

On the misuse of general principles

#entarch There is a common fallacy among enterprise architects that radical structural and behavioural change can and should be driven by a few simple and powerful ideas. Alas, the public sector is strewn with the disastrous consequences of this fallacy.

We can find countless examples from the National Health Service (NHS) in the UK. For Steve Harrison, Honorary Professor of Social Policy at the University of Manchester, the idea that NHS reorganisations can be triggered by a few general ideas is one of the Seven Fallacies of English Health Policy. He points out that high levels of abstraction (beloved by academics and architects alike) do not allow proper assessment of the plausibility of claims about benefits of reorganisation and how the system will work. (HT @mellojonny)

Where do health reorganization principles come from? I asked a popular search engine, and was led to a paper called Basic Principles of Information Technology Organization in Health Care Institutions (JAMIA 1997); (I suppose from the high search ranking of this paper that it is a widely used source for such principles.) The paper concludes that all organizations MUST have certain characteristics, based on a single case study where these characteristics seemed to be beneficial; in other words, arguing from the particular to the general. (I'm sure there must be some more rigorous studies, but they don't seem to get as good search rankings for some reason.)

But many of the principles that govern sweeping architectural reforms of the public sector aren't even derived by thinly based generalization from such observed vignettes, but are derived from purely abstract concepts such as "choice" and "competition" and "justice", to which each may attach his or her own politically motivated interpretation.

This leads to several levels of failure - not only failure of execution and planning (because the generalized principles are not sufficiently refined to provide realistic and coherent solutions to complex practical problems) but also failure of intention (because a vague but upbeat set of principles helps to conceal the fact that the underlying vision remains woolly).

The Purpose of Enterprise Architecture

@adrianrcampbell wants to explain #entarch to IT architects who don't see the wood for the trees (via @itworks). Adrian reckons that the primary Purpose of Enterprise Architecture is to support strategic change.

@nickmalik says that IT Archs still won't get it. "Need examples of individual activities that make a difference." So let's hope Adrian provides some useful examples in his subsequent posts.

In the meantime, I'm concerned that the phrase "supporting strategic change" lacks bite. What is support really worth? Let me look at a parallel case - sports coaching.

Let's say that the purpose of a sports coach is to support one or more athletes and help them win competitions. For example, Scottish tennis star Andy Murray has recently appointed another former tennis star Ivan Lendl as his coach. This follows Murray's lack of success at the highest level - his repeated failure to win a Grand Slam tournament. Perhaps Lendl's presence on Team Murray will make some unspecifiable difference to Murray's performance; but even if Murray's performance now improves, nobody can ever be sure how much difference is due to Lendl. Murray has survived without a coach for extended periods, and might possibly have won sooner or later anyway, so we have to regard the coach as an optional extra. There is a sense that the appointment of a coach is an admission of some inadequacy on Murray's part. (John Seddon would call this "failure demand".)

At this level considerable sums of money will change hands, and it is not clear how this is negotiated. What is a fair reward for the "support" of the coach? Does the coach get a flat fee or a percentage of winnings?

I don't think there are many enterprise architects who work on a no-win-no-fee basis. But there are certainly many executives who believe they can manage so-called strategic change perfectly well thank you, without having enterprise architects sitting in the player's box tutting and fretting. It's not just IT architects who don't appreciate enterprise architecture.

Teaching Enterprise Architecture

#entarch @leodesousa asked if one had to teach a 1 wk mod on EA, what would be the approach?
@leodesousa asked if it was necessary to say what #entarch was before describing the value+process

I am not convinced it is necessary, and I started a discussion on Linked-In Does it matter what enterprise architecture is?

@nickmalik suggested tellimg story of a company without EA doing planning. Show class complex / silo happens. Do Root Cause Analysis ... then walk them through EA data collection, EA taxonomy, and models. ask class to make decisions again w/ data

Nick's solution to Leo's requirement assumes the goal is to appreciate the difference between EA and its absence. Yes, as foundation, says @nickmalik Build understanding as first step to empower collaboration between biz and #entarch

@leodesousa confirms that his objective is for the students to know there is an approach called #entarch that can help manage chg ... I would want them to know enough to ask for #entarch services to help the business - partnership ... which is a good way to explain the capabilities and value that can be derived from a planned approach

@aleksb6 is trying to cope with the idea that value of a planned approach needs to be explained ... can't we just tell people to go read The Art of War before they start learning #entarch ? :) ... imo #theartofwar is a pre-req for any strategy/planning function, not just #entarch

---

My idea of a learning objective is that the students learn to do something, not that they are persuaded of (the value of) something. What is more important for the students to be able to do at the end of the week - talk about architecture or solve real business problems? And if the students manage to solve some meaningful problems using the tools of enterprise architecture, this is surely more likely to convince them of the value of EA than any amount of theory and rhetoric?

How does reading The Art of War contribute to such learning objectives? Clearly there is a value in shared stories, and being able to refer to certain patterns of activity. @greblhad has been posting an EA version of the Art of War by instalments. Maybe when he's finished he can do an EA version of the Aenead: "De Architectura Virumque Cano".

(I don't know any Latin by the way; I just plugged the title of one work into the first line of another. Doesn't that always work?)

Unruly Google and VPEC-T

Google has been hoist by its own petard: it seems obliged to ban its own browser from its own search engine for infringing its strict rules. Apparently the infringement resulted from some misbehaviour somewhere down the subcontract chain, unknown to Google itself or its prime subcontractor (which with fitting irony is called Unruly Media). A number of blogposts were created to promote Google Chrome, containing direct hotlinks to the Chrome download page. Google has recently penalized a number of other companies for such behaviour, including J C Penney, Forbes and Overstock. See also my 2006 post on BMW Search Requests.

A number of offending posts were discovered because they contained the magic words "This post was sponsored by Google", and the Google search engine dutifully delivered a list of webpages containing these words. (This kind of transparency was foreseen by Isaac Asimov in a story called "All the troubles of the world", in which the computer Multivac was unable to conceal its own self-destructive behaviour.)

As a number of search engine analysts have pointed out, there are two problems with the sponsored pages. Besides containing the offending links, they are also pretty thin in terms of content. (Google has recently developed a search filter code-named Panda, which is intended to demote such low-value content, but this filter is extremely costly in computing power and is apparently only run sporadically.) Many of these pages credit Google Chrome for having helped a company in Vermont over the past five years, despite the fact that Google Chrome hasn't been available for that long. None of them explain why Google Chrome might be better than other browsers.

So here we have an interesting interaction between the elements of VPEC-T.

Value	How is commercial sponsorship reconciled with high-value content? Does this incident expose a conflict of interest inside Google?
Policy	How does Google apply its strict rules to itself?
Events	How was this situation detected (with the aid of Google itself)? Will any future incidents be as easy to detect?
Content	What is the net effect on the content, on which Google's market position depends?
Trust	What kinds of trust have been eroded in this situation? How can trust be restored, and how long will it take?

---

Sources

Aaron Wall, Google caught buying paid links yet again (SEO Book 2 Jan 2012)

Danny Sullivan, Google’s Jaw-Dropping Sponsored Post Campaign For Chrome (SearchEngineLand 2 Jan 2012)

Charles Arthur, Will Google be forced to ban its own browser from its index? (Guardian 3 Jan 2012) Google shoves Chrome down search rankings after sponsored blog mixup (Guardian 4 Jan 2012)

Three or Four Schools of Enterprise Architecture

#entarch @lapalj has written an interesting article on the Three Schools of Enterprise Architecture.

The schools are distinguished along two dimensions: scope and ends (purpose).

Scopes	Ends
Enterprise wide IT platform (EIT). All components (software, hardware, etc.) of the enterprise IT assets.	Effective enterprise strategy execution and operation through IT-Business alignment. The end is to enhance business strategy execution and operations. The primary means to this end is the aligning of the business and IT strategies so that the proper IT capabilities are developed to support current and future business needs.
Enterprise (E). The enterprise as a socio-cultural—techno-economic system; hence ALL the facets of the enterprise are considered – the enterprise IT assets being one facet.	Effective enterprise strategy implementation through execution coherency. The end is effective enterprise strategy implement. The primary means to this end is designing the various facets of the enterprise (governance structures, IT capabilities, remuneration policies, work design, etc.) to maximize coherency between them and minimize contradictions.
Enterprise-in-environment (EiE). Includes the previous scope but adds the environment of the enterprise as a key component as well as the bidirectional relationship and transactions between the latter and its environment.	Innovation and adaption through organizational learning. The end is organizational innovation and adaption. The primary means is the fostering of organizational learning by designing the various facets of the enterprise (governance structures, IT capabilities, remuneration policies, work design, etc.) as to maximize organizational learning throughout the enterprise.

Besides scope and purpose, I have always considered it important to identify a third dimension of perspective (viewpoint). (For example, I talk about these three dimensions in my 1992 book on Information Modelling, pages 16-22.)

Among other things, perspective helps us to address the question: What kind of system is the enterprise being understood as? For example, the (micro-)economic perspective views the enterprise as a production system (value chain or value network), while the management cybernetic perspective (such as Stafford Beer's Viable Systems Model) views the enterprise as a thinking system or brain. Gareth Morgan's book Images of Organization contains a good survey of several contrasting perspectives.

Most enterprise architects in the first school adopt the traditional IT perspective of regarding the enterprise as an information processing system. Most of the well-known EA frameworks (such as those listed on the ISO 42010 website) are solidly within the first school.

Lapalme's second school explicitly invokes the socio-cultural perspective, and calls for all facets of the enterprise to be considered - this clearly implies going beyond the traditional IT perspective.

However, there is a considerable body of work that looks at the enterprise-in-environment, but remains within the IT perspective. This would include the Open Group work on the extended enterprise, as well as the Systems-of-Systems community. A key scoping question here is the exercise of governance over large distributed systems of systems. Mark Maier distinguished between directed and emergent systems (or we might think about directed and emergent enterprises), and this has been developed into a four-part schema by the US Department of Defense: Directed, Acknowledged, Collaborative and Virtual. Some useful work at the SEI, where this thinking has been connected into work on SOA and enterprise architecture.

Lapalme's article identifies James Martin as one of the leaders of the third school, based on a minor work published in 1995, but most of Martin's work belongs solidly within the first school. In his 1982 book, Strategic Data-Planning Methodologies, Martin shows how IBM's BSP methodology could be used to decompose the activities of the organization, as a precursor to planning IT systems. The primary aim of such methodologies from the 1980s onwards was to identify opportunities to install more computers and develop more software, and I think it is no coincidence that a number of the pioneers of enterprise architecture (from Martin to John Zachman) had worked for IBM. See my note on The Sage Kings of Antiquity.


So I think it makes sense to divide Lapalme's third school into two distinct sub-schools. There is clearly a lot of work in School Three A, which extends the scope of architecture without introducing the socio-cultural or other perspectives which Lapalme associates with School Two. There is as yet very little formal work in School Three B. 

School One Single Enterprise IT Perspective	School Two Single Enterprise Multiple Perspective
School Three A Extended Enterprise System of Systems	School Three B Ecosystem Multiple Perspective

---

James Lapalme, "3 Schools of Enterprise Architecture," IT Professional, 14 Dec. 2011. IEEE computer Society Digital Library. IEEE Computer Society, http://doi.ieeecomputersociety.org/10.1109/MITP.2011.109

3 Schools of EA

View more documents from jlapalme
See also Linked-In discussion ("Considerate Architecture" group).

Enterprise Architecture Tempo

#entarch Like many complex capabilities, enterprise architecture operates at several different tempi. (See my post on Enterprise Tempo.) A workshop at the SEI last year identified three tempi, which it called "Operating Modes".

1. At the lowest level, enterprise architects operate in an urgent response mode, reacting to crises as they arise.
2. Next, enterprise architects may operate in a continuous improvement mode, making incremental changes and generally avoiding crises.
3. Finally, enterprise architects may operate in a transformative change mode, collaborating with business leaders to enable new business capabilities and new business models.

The SEI observes that, in practice, enterprise architects are nearly always operating in all three modes, but suggests that the most effective organizations will spend less effort in the urgent response and more in transformative change.

Most of the process frameworks for enterprise architecture concentrate on the longer-term operating modes - sometimes called tactical and strategic planning. Some frameworks distinguish between solution architecture (with a typical cycle time of 6-18 months) and enterprise architecture (with a typical cycle time of 3-7 years).

But surely it is the less effective organizations, where more effort is devoted to urgent response, that are in greater need of process guidance? As I said in my post on Enterprise Architecture as Viable System, the dilemma for EA is how to appear useful in a crisis without (a) throwing all the EA professional discipline out of the window or (b) demanding at least four months to carry out a proper study. So what good is a process framework that simply tells such organizations that they really ought to put the urgent stuff aside and concentrate on long-term transformation? Or a process framework that is incapable of Learning from Stories?

---

John Klein and Michael Gagliardi, A Workshop on Analysis and Evaluation of Enterprise Architectures (pdf) SEI, November 2010.

Elsewhere the term "operating modes" has been used for the EA archetypes identified by John Gøtze and his colleagues, but this is completely different. See my post on the Dimensions of EA maturity.

Risk and Responsibility in Self-Service

A cabbie asked @jkuramot to enter his destination into the GPS. @dahowlett suggests this is because he didn't speak good English. @jkuramot confirms that the driver didn't speak English very well but adds that "this was his go-to move".

The reason we are talking about this fragment of service design is that it is unusual in this context: we normally expect the driver to enter the destination into his navigation device. But the normal procedure is prone to error; the pasenger may not speak clearly, the driver may not understand correctly, there may be a lot of background noise: the passenger arrives at the wrong destination and it's the driver's fault.

However, if the passenger enters the destination directly into the navigation device, then any error is the passenger's fault. Many service providers in other areas now follow this pattern; shifting responsibility onto the customer may help to reduce administration costs, but more importantly reduces the service provider's liability. But if the customer is not able to perform these tasks easily and accurately, this kind of shift adds more to the cost and risk for the customer than it reduces for the supplier, and therefore diminishes total value. See my review of The Support Economy.

Asking the customer to do the work makes an assumption about the customer's capability. I don't know Jake personally, but he looks from his photo and his Twitter profile like someone who would know how to operate this kind of device. The driver may have had the same impression; it is conceivable that he would have treated Jake's grandmother differently. Whereas if the device (belonging to the driver) is unusual and difficult to use, we would always insist that the driver should operate it. Self-service only works if the interface design offers a reasonable level of usability.

The other difference between the passenger and the driver is the question of which is more familiar with the destination. When I get a cab home from the airport, obviously I know my address better than the driver does. But when I arrive in a strange city, I expect the cab drivers to be more familiar with the hotels than I am: if I get the name of the hotel slightly wrong, the driver should ask if I really meant something else, rather than drive for an hour to a hotel in the next city whose name exactly matches what I said.

By the way, Google has been correcting our searches for a long time now, but has now chosen to issue a series of advertisements in which this correction (and the collection of vast amounts of data to make this correction possible) is highlighted as a service enhancement feature. See my note Towards a VPEC-T analysis of Google. This kind of service enhancement is unavailable if the driver takes himself out of the loop, and regards his job as merely enacting a specification agreed between the customer and an electronic device.

Meta-Architecture (Yawn)

#entarch people seem to spend a lot of time defining the building blocks of architecture, and insisting on the correct definition. Some of my friends have been doing it on Twitter recently, and I've certainly participated in this kind of debate myself in the past.

@chrisdpotts Appearing to not know the difference between a strategy and a roadmap can damage your reputation and influence. 

@tetradian On function, capability and service

@davidsprott Let's Kill the Confusion About Capabilities for Once and All!

There are several different reference models that attempt to answer such questions, at varying levels of detail and abstraction. Here are just a few of these models.

• ISEB Enterprise and Solution Architecture Reference Model (BCS Version 3.0 pdf)
• CBDI Service Architecture and Engineering Reference Framework (recently updated to include Cloud Computing)
• SOA Reference Model (OASIS pdf)

The Wikipedia page on Technical Architecture contains the following paragraph on Meta-Architecture, lifted practically word-for-word from a white paper on the Visual Architecting Process (Bredemeyer Consulting, pdf) by Ruth Malan and Dana Bredemeyer. Malan and Bredemeyer also appear to be behind the EWITA (Enterprise-Wide Information Technology Architecture) initiative.

"First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring."

Yawn. I can see that this kind of thing might be necessary for architecture management, especially across a large organization or sector. Tom Graves points out that we can view a reference model as a set of job descriptions. But explicitly allocating time to meta-architectural research??

My worry about meta-architecture is that it distracts from real architecture. If I have a lump of business activity, I'm not sure I understand it any better whether I label it as a function or a process or a capability or a service. What really helps me to understand this lump better, and to use that understanding in improving the business, is analysing how it varies by context (differentiation) and how it interacts with other lumps of business activity (integration). And it's more important to see whether a strategy or roadmap is any good than whether it's been correctly labelled. The challenge of architecture isn't classification, it is coordination and quality.

---

For my bootcamp next week, I don't want to spend any time on Functions versus Capabilities, Goals versus Objectives versus Principles, Strategies versus Roadmaps, and all that meta-architecture stuff. Some architecture courses seem to spend so much time on meta-architecture that they don't have any time left for real architecture. And one can waste a lot of time on the Internet trying to promote one's favourite definition of any of these terms. My winter's resolution - to keep out of these debates. (I may not always manage to do this.)


 book now  Business Architecture Bootcamp (November 22-23, 2011)
 book now  Workshop: Organizational Intelligence (November 24th, 2011)

Conceptual Modelling - Why Theory

@dougnewdick asks Why Bother With Concepts? In his answer, he quotes the Gang of Four song Why Theory. "Each day seems like a natural fact/but what we think changes how we act."

I think there is a critical difference between two interpretations of the term "Conceptual Architecture". I'd describe Doug's sample conceptual architecture as essentially a component architecture, which happens to be at the "conceptual" level of abstraction. In other words, it provides a conceptual understanding of how the components work together.

That's not at all the same as understanding how the concepts themselves work together, which is what I think one needs to satisfy the Gang of Four requirement for an architecture-of-concepts, and which would also be implied by Doug's reference to the Wikipedia article on Philosophical Analysis.

The Wikipedia article mentions critiques of the traditional approach to philosophical analysis by Quine and Wittgenstein. I have used some of their ideas - although with no claim to profundity - in my own approach to conceptual modelling. See for example my 1992 book on Information Modelling.

To take a concrete example, if we are going to build systems and management practices to anticipate competitor behaviour, it might help have to have a robust concept of COMPETITOR. I once worked with a company that thought it knew which its competitors were, and were quite indignant when a competitive threat appeared from an entirely different quarter. Traditional philosophical analysis implies you can fully characterize a concept like COMPETITOR in advance, but Wittgenstein and Quine teach us to be cautious of monothetic, appearently objective conceptual definitions.


One of the problems with conceptual models is that they are often too generic, and therefore insufficiently meaningful. Anyone who has ever been on a data modelling course can produce a model with CUSTOMER and ORDER and PRODUCT. But proper conceptual analysis entails taking concepts apart to understand how they work in a particular business context. Where do products come from, what does it mean to be a product, how do products evolve, what are the essential and non-essential differences between products? Why do we have this many products, and what are the forces that would result in increasing or decreasing the number of products? What does the business know about products, and what does the business want to know?

Doug's post was prompted by Peter Bakker's post Factual Architecture, which expressed a concern that concepts can be too abstract and unverifiable – failing to connect with audiences, failing to connect with reality. The way that some architects try to verify concepts is to demonstrate how the concepts could be represented in some technical system - but I prefer to encourage stakeholders to verify concepts in the business domain itself. This leads me to a slightly different notion of Factual Architecture, which would provide an empirical business context in which the business concepts and knowledge can be grounded.

Is this really the way it is? Or a contract in our mutual interest?