Richard Veryard on Architecture

June 2013 Events

2013-05-16T18:48:00.002+01:00

One seminar (free) and several workshops (pay).

Perspectives on Enterprise Architecture and Systems Thinking (EAST)

14 June 2013, Central London

The meeting is intended for experienced practitioners of Enterprise Architecture (EA) and/or Systems Thinking (ST), with an interest in the practical application of new ideas. Speakers to include Carl Bate, Steve Brewis, Patrick Hoverstadt, and Richard Veryard.

For more details and booking, please click here.
http://eastperspectives.eventbrite.co.uk

Business Architecture Workshop

(3-5 June 2013, Middlesex)

Problem-solving workshops, using a series of architectural viewpoints to solve business problems.
This is a series of three separate but related practical workshops, focused on (i) Modelling Business Operations, (ii) Modelling Business Organization and (iii) Managing Business Process Transformation respectively. The workshops provide delegates the opportunity to address a series of practical business challenges, using six different viewpoints. These are organized as three separate days from which participants can choose to attend one, three two or all three days as per according to their requirements.

In association with Unicom UK.
For more details and booking, please click here.
http://businessarchitecture.eventbrite.co.uk/

Business Awareness Workshop

(6 June 2013, Middlesex)

This workshop is an excellent primer for IT specialists seeking to gain a better understanding of their business and those looking to move into Business Analysis and Enterprise Architecture roles.

In association with Unicom UK.
For more details and booking, please click here.
http://businessawareness.eventbrite.co.uk/

Organizational Intelligence Workshop

(7 June 2013, Middlesex)

Explores a range of practical opportunities for holistically increasing the intelligence of your own organization and its ecosystem.

In association with Unicom UK.
For more details and booking, please click here.
http://orgintelligence.eventbrite.co.uk/

Not your grandpa's functional decomposition

2013-05-03T17:38:00.001+01:00

Is there a difference between function and capability? You can find endless debate about this on the Internet (yawn). One of the reasons business architects often prefer the word capability is that the word function can become extremely overloaded - sometimes equivalent to organizational unit, sometimes equivalent to long-running process, sometimes equivalent to purpose. Whereas the word capability seems to focus our attention more clearly on the WHAT rather than the HOW or WHO or WHEN or WHERE or WHY.

But even when people insist that a capability is not the same as a function, they still seem to use the same approach for identifying and modelling capabilities as was once popular for functions. So they draw capability models as simple hierarchies, either as trees or as boxes within boxes.

One approach to capability modelling was popularized by Ric Merrifield and others at Microsoft in the mid 2000s. The methodology was originally called Motion, then Motion Lite, and is now known as Microsoft Services Business Architecture. It includes a Business Dependency Network diagram, but this is used to show the dependencies between the business architecture and IT, rather than the dependencies within the business. In fact, it looks remarkably similar to IBM's Business Component Model.

Despite the limitations of a hierarchical methodology, there are some useful guidelines on separating WHAT from HOW, and on the segue from capability to service, as well as a wealth of examples.

For a more sophisticated approach to capability modelling, please see my eBook Six Viewpoints of Business Architecture. Or attend my Business Architecture workshop.

Read more »

From information architecture to evidence-based practice

2013-04-20T10:09:00.000+01:00

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

Why information architecture needs systems thinking

2013-04-18T11:51:00.001+01:00

If a factory is torn down but the rationality which produced it is left standing, then that rationality will simply produce another factory. If a revolution destroys a government, but the systematic patterns of thought that produced that government are left intact, then those patterns will repeat themselves ... There’s so much talk about the system. And so little understanding.

Source: Robert Pirsig, Zen and the Art of Motorcycle Maintenance, 1974

We who labor at the crossroads of structure and behavior have learned the hard way that content management is far messier than garbage collection and “the system always kicks back.”

Source: Peter Morville, Editorial: The System of Information Architecture (Journal of Information Architecture. Vol. 3, No. 2., 2012)

Churchman’s interest in computing reaches extensively beyond the metaphor of inquiring systems. He addresses many issues with the state of MIS research of his time, including the tendency of IS researchers to focus on “safe” issues such as “structure of files, retrieval techniques, automatic abstracting, and the like” (Churchman 1968, p.111). He indicates that the majority of such research is not consistent with the systems approach as it focuses on transactions rather than the true goals or benefit of the system. Churchman is also quite visionary as he predicts the ubiquitous role of computers in everyday life. With the ability to “find facts” readily, Churchman predicted that information systems will actually work to reinforce a user’s Weltanschauung (world-view), as the user would screen information based on his Weltanschauung. In order to expand use MIS to expand the user’s view to one that is more holistic, Churchman envisioned a “deadly enemy” proposal for the design of an information system. The main role of this deadly enemy is for the system to propose information results based on assumptions that are opposite of the user’s information request, thereby revealing to the user his fundamental assumptions and at the same time questioning them (Churchman 1968, p. 122-123).

Source: Nicholas Berente, C West Churchman: Champion of the Systems Approach quoting Churchman, C.W. (1968) The Systems Approach, Dell Publishing Co.

See also Kristo Ivanov, The systems approach to design, and inquiring information systems (2001)

Business Architecture and Related Domains

2013-04-15T14:58:00.000+01:00

The following post is an extract from my draft eBook Business Architecture Viewpoints, available from @Leanpub

There are some things I don't regard as part of the Business Architecture but as part of some other domain.

One reason for these exclusions is that am trying to avoid scope-creep - putting everything into the Business Architecture that has (or should have) a good link to business. I regard it as the task of Enterprise Architecture to coordinate between Business Architecture, Solution Architecture, Technology Architecture and whatever other domains the enterprise might need.

Which is why I am reluctant to add a Technology View to the Business Architecture. I am also unwilling to extend the Motivation View to include business case, because I regard the business case (despite its name) as belonging to the Solution Architecture. Documents are also part of the Solution Architecture.

Solution Architecture

Key Elements: Business Case (for Solution), Solution, System (including both Sociotechnical System and Software Application), Transformation, Use Case, Workflow.

Note that the Solution domain covers the whole sociotechnical solution space, not just the software application.

Note also that some frameworks (notably RM-ODP) define an enterprise viewpoint covering the purpose, scope and policies of a system. Because of the specific reference to a system, I do not regard the RM-ODP notion of enterprise viewpoint as equivalent to Business Architecture. It could be understood either as a business-oriented viewpoint within the Solution Architecture or as a mapping between the Business Architecture and the Solution Architecture.

Technology Architecture

Key Elements: Business Case (for Infrastructure or Product or Technology), Technical Commodity/Service, Technical Device/Mechanism

Within the Technology Architecture, there is a clear distinction between the abstract technology (for example "middleware", "SOA") and a specific technical product or platform (for example "IBM Websphere"). There is also a distinction between the technology-as-built and the technology-in-use.

Development Architecture

Key Elements: Project, Requirement, Development Lifecycle

Tom Mochal defines development architecture in a broad sense to include three major areas:

* The development life cycle and processes used to build business applications

* The application models that show the appropriate technical design that will best fit the business requirements

* The inventory and categorization of the business applications that exist within the organization today.

Physical Architecture / Environment

Key Elements: Building, Location, Equipment

Many IT people use such terms as Physical Architecture or Environment to refer to computer hardware. But I'm using the term to refer to all aspects of the physical environment, such as office buildings and physical equipment.

Where does Location belong? Traditionally this is regarded as part of the Business Architecture, but I believe it belongs somewhere else, along with buildings and working space and the kind of architecture associated with Le Corbusier and Frank Lloyd Wright. Ideally I'd want to call this the Physical Architecture, which would include a Geographical View or what Stewart Brand calls Site. I'd also include something I call Consilience.

Of course, location doesn't disappear in a global organization, but it doesn't dominate business processes in the way it once did, and is often merely a cost factor or speed factor. It is not geographical distance that matters any more, but abstract notions of distance, including commercial, semantic and cultural distance.

Design Choice and Iteration

2013-04-12T00:16:00.001+01:00

There are two misleading ideas (espoused theories) about how architects and designers make decisions.

According to classical decision theory (Herbert Simon), one or more designers develops a series of alternative options, working collaboratively or in competition, and then the design team or the client selects the one that best fits the requirements. This approach may not yield a perfect solution (optimizing) but hopefully produces a good enough solution (satisficing).

Although this approach is used in some design fields, it is unusual in the enterprise space for a designer or design team to produce more than one solution. In the event that the first option is not good enough, the design protocol allows for something called iteration, which seems to repeat certain design steps until a good enough solution is produced.

But in this context the word iteration is misleading. In computer science, the word simply means repeating an action until some condition is met. It is not always possible to determine in advance whether a given iteration will ever terminate - this is known as the Halting Problem.

In design, however, the word iteration seems to refer to something more like backtracking - undoing or discarding some work and trying something different. Designers are generally not taught to backtrack properly. Instead, they learn to avoid backtracking at all costs, and the little backtracking loop on the design protocol comes to be regarded as a safety feature one hopes never to use. (Unless you can blame someone else for changing the requirements or constraints.)

Furthermore, backtracking is popularly seen as a sign of design inexperience or incompetence, and designers who fail to produce a good enough design at the first attempt may try to conceal this fact. Consequently any backtracking that does occur tends to lack visibility and transparency, and hardly any useful learning takes place.

This suppression of backtracking may be one of the reasons why we are surrounded by designs and architectures that aren't very good.

See also Meaning of Iteration (Sept 2012)

Enterprise as a ... System

2013-04-10T19:26:00.001+01:00

Notwithstanding the earnest way some people use the phrase "enterprise-as-a-system", I don't see any great significance in regarding an enterprise or organization as a system.

Indeed, given the very broad way people commonly use the word "system", it is difficult to think of anyway to regard an enterprise other than as some kind of system. A machine or complicated technological assembly is a system; a human activity or social unit is a system; an abstract legal or procedural process is a system. All of the chapters in Gareth Morgan's book Images of Organization represent organizations as different kinds of system. And even if we don't regard an enterprise as quite the same as an organization, what could an enterprise possibly be, from anyone's perspective, other than some kind of system?

And many popular architecture frameworks claim to regard an enterprise as a system. For example

TOGAF considers the enterprise as a system (TOGAF9, Chapter 2)
Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems. (TOGAF9 Chapter 6)

Elsewhere in TOGAF however, as well as in ArchiMate, we can find reference to systems OR organizations, which suggests that they do not regard the enterprise as a system.

Some people claim to regard the enterprise as a system, and then offer a layered schema with System Layer near the bottom. This represents a shift in the use of the word "system".

However, when people use the phrase "enterprise-as-a-system", they may well have a particular kind of system in mind. Here are some examples.

Enterprise as a sociotechnical system

Fred Emery, Characteristics of Sociotechnical Systems (1972)
Edin Mustajbegovic, Idealised design for changing socio-technical systems (December 2012)
Linked-In discussion (Jan 2013 onwards)

Enterprise as a socio-cultural—techno-economic system

James Lapalme, Three Schools of Enterprise Architecture (2011)

Enterprise as a human activity system

Enterprise as a self-organizing system

Egon Noe and Hugo Fjelsted Alrøe, Farm Enterprises as Self-Organizing Systems (International Journal of Sociology of Agriculture and Food 2004)

Enterprise as an open or closed system

Fred Emery and Eric Trist, SocioTechnical Systems (1960)

Clearly it is the adjective that helps to make this phrase meaningful.

See also

Alan Hakimi, Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System (Feb 2013)

Linked-In Discussion Enterprises *NOT AS* Systems (April 2013 onwards)

Multi-Sided Platform Strategies

2013-04-08T13:52:00.001+01:00

A multi-sided platform business has the following characteristic features.

1. The platform serves two or more distinct categories of customer. For example, a credit card platform serves both cardholders and merchants. For example, a heterosexual dating agency serves both men and women.

2. The platform provides a mechanism for connecting customers from different categories. The credit card increases the potential interaction between cardholders and merchants, as well as processing the transactions. And the dating agency brings men and women together.

3. The value of the platform to one category of customers depends on the quantity and quality of the other categories. For example, the value of a credit card to the cardholder depends on the number of merchants that accept the card. Meanwhile, the value of the card to the merchant depends on the number of cardholders.

Under certain circumstances, it might be possible to build one side of the platform first. For example, if you had some brilliant idea for a entirely new kind of credit card, and had a lot of funding and a persuasive sales team, you might conceivably be able to recruit a large number of merchants into the scheme before you had any cardholders at all. Or imagine persuading a group of men to invest all their spare time for two years building a nightclub that would (when finished) attract the hottest women in the city. But this strategy requires a considerable degree of confidence and trust. So in practice it usually makes sense to build up both sides at the same time.

There are various strategies that can be used to create a multi-sided platform. Sometimes it is possible to start small. When Frank McNamara created Diners Club in 1950, he started in a small geographical area (Manhatten), with 14 merchants and a few hundred cardholders. Within a year, he had 300 merchants and 40,000 cardholders.

When American Express wished to enter the market in 1958, it needed to create something quickly that could compete with Diners Club. One way to do this was to acquire and consolidate some existing schemes. But the key element to the American Express's success was a marquee strategy - recruiting the most desirable customers (e.g. business travellers on expense accounts) and the most desirable merchants (e.g. high status hotels, restaurants and stores).

A marquee strategy depends on a degree of exclusivity, real or imagined. In a multi-sided market, you don't gain directly from the number of people on your own side, since they may be competing with you for the attention of the people on the other side.

American Express is now much larger than Diners Club. So much for first-mover advantage then. The most desirable customers are not necessarily the ones with the greatest willingness to experiment with a novel platform. Novel platforms tend to attract early adopters and low-value customers (AltaVista, MySpace, OnSale). Once the platform concept is understood, a new entrant may be more successful in recruiting the high-value and mainstream customers (Google, Facebook, eBay).

Among users of Facebook and Twitter, a gulf is emerging between celebrities and other users. Facebook is currently experimenting with charging a fee for ordinary users to send messages to celebrities. According to the Independent, Facebook plans to keep this money itself. Presumably the only benefit to the celebrity is helping to filter incoming messages. And of course many celebrities are now dependent on Facebook and Twitter for maintaining their public profile, so they are not able to walk away.

The growing distinction between different categories of user marks a transition from same-side network effects (which assume a single category of user) into a multi-sided platform. Linked-In is another platform that is making this transition. Linked-In gets much of its revenue from the recruitment business, so it is essentially a market-making platform. Whereas Facebook and Twitter remain largely audience-making platforms.

(For the distinction between market-making and audience-making platforms, as well as a third category of demand-coordination platforms, see David S Evans.)

I shall be talking at the IASA UK Architecture Summit on 26th April on Architecting the Multi-Sided Business. There is more extensive coverage in my Business Architecture Workshop. Please contact me if you have any practical challenges in this area.

Pieter Ballon, Platform Types and Gatekeeper Roles: the Case of the Mobile Communications Industry (2009)

Mark Bonchek and Sangeet Paul Choudary, Three Elements of a Successful Platform Strategy (HBR Blog Network Jan 2013)

David S. Evans, Managing the Maze of Multisided Markets (Strategy+Business Fall 2003)

David S. Evans, The Antitrust Economics of Multi-Sided Platform Markets (Yale Journal on Regulation, 2003)

David S. Evans and Richard Schmalensee, Failure to Launch: Critical Mass in Platform Businesses (Sept 2010)

Thomas Eisenmann, Geoffrey Parker, and Marshall W. Van Alstyne, Strategies for Two-Sided Markets (HBR October 2006)

James Legge, Facebook now charges you for messages sent to celebrities and people you aren't friends with (Independent 7 April 2013)

Lisa O'Carroll, Facebook starts charging users up to £11 to contact celebrities (Guardian 8 April 2013)

Geoffrey Parker and Marshall Van Alstyne, A Digital Postal Platform: Definitions and a Roadmap (MIT Jan 2012)

Richard Veryard, The Component-Based Business: Plug and Play (Springer 2001)

Understanding LinkedIn Business Model (BMI Matters May 2012)

Three Notions of Maturity

2013-03-30T13:41:00.000Z

Many enterprise architecture frameworks contain some notion of maturity, usually with some kind of nod in the direction of the SEI CMMI maturity model. I'm puzzled about this, because these notions of maturity don't much resemble the SEI's notion and sometimes have a completely different set of levels.

The SEI has produced several different maturity models, but they are all presented in terms of the maturity of capability or process - doing the right things right according to a standardized schema of What The Right Things Are. Applying a process-oriented notion of maturity to EA can only really refer to maturity of the EA process. But I think it is much more relevant to think about EA maturity of the organization as a whole, which calls for an outcome-oriented notion of maturity (perhaps defined in terms of some kind of "alignment") that is closer to Richard Nolan's Stages of Growth model, where maturity is seen as a state of perfect alignment between the business and its information systems. (I know Nolan originally formulated his ideas in terms of IT, but then so did lots of people in the 1980s including Zachman.)

Maturity can also be defined in terms of an alignment between espoused theory (what you think you are supposed to be doing) and theory-in-use (what you are actually doing). Obviously this kind of alignment is not restricted to IT. Maturity doesn't just mean being better at achieving your goals, it also means having more realistic goals in the first place. Some people might think that innovation feeds upon the unrealistic ambitions of the immature, and that too much maturity (in this sense) could just result in middle-aged stagnation.

Meanwhile, some enterprise architecture frameworks contain notions of maturity that are defined not in terms of process but in terms of knowledge. At the Unicom EA Forum on 21st March 2013, Kevin Smith presented his new PETF framework for Enterprise Transformation, which defined four levels of maturity

Unconsciously incompetent
Consciously incompetent
Consciously competent
Unconsciously incompetent

Thus highest level of maturity is where the knowledge has been internalized. I think this notion of maturity looks much closer to Nonaka's SECI model or Boisot's I-Space, which both contain notions of internalization. Competence relative to one's competitors is always proprietary knowledge, while knowledge that is in the public domain cannot form the basis of competitive advantage.

In order to maintain competitive advantage, both models are essentially cyclic, so that one can cycle back from level 4 (unconscious competence) to level 1 (unconscious incompetence). In my summary last week, I invoked the Black-Belt-to-White-Belt metaphor: even the most experienced black belt needs to return to the basics, needs humility and the desire to learn, needs to always think like a beginner rather than strutting around arrogantly like an expert. Obviously there are circumstances in which an enterprise may need to cycle round from competence to incompetence, before attaining a higher level of competence. Sometimes transformation must take an enterprise out of its comfort zone.

Finally, I wonder whether "maturity" is the right word at all. It might be argued that different levels are suitable for different organizations, which is basically a form of contingency theory.

Instead of maturity, I prefer a notion of excellence that includes (1) selecting the appropriate approach for a particular situation/context, and then (2) carrying out this approach both effectively and cost-effectively. I think this notion of excellence is supported by business excellence frameworks such as Baldrige and the European Quality Award. These frameworks don't say HOW you should do anything, merely that you should know WHAT you are doing, and WHY, and WHETHER it is working, and that you should be constantly striving to improve those things that matter most. Hopefully this gets around the innovation/maturity paradox I mentioned earlier.

From Sedimented Principles to Enabling Prejudices

2013-03-29T10:08:00.000Z

I have often asserted (on this blog and elsewhere) that principles are over-rated as a driver for intelligent action. However, that doesn't mean principles are completely worthless. In this post, I wish to explore some of the ways in which principles may have some limited use within enterprise architecture.

I am going to identify four rough categories of principle. There may be other categories, and the categories may overlap.

1. Universal Truths
2. Governance
3. Style Preferences
4. Enabling Prejudices

This is a long post, and I think the final category is the most interesting one, so if you are short of time, please read that one first.

Read more »

Cloud and Continuity of Supply Risk

2013-03-18T12:10:00.000Z

@dougnewdick points out the risk of a company becoming over-dependent on Google. His particular example is prompted by Google's announcement that Google Reader will be discontinued.

I have previously commented on the subject of Creeping Business Dependency, the fact that many companies have allowed themselves to become dependent on a particular company, product or technology. Especially Google. If Google decides your website offends against some search engine rules, it is perfectly capable of making your website disappear from searches. (BMW disappeared from Google for three days in 2006 - see my post BMW Search Requests.) A company might well go bust before it could sort the problem out.

Of course, you can't avoid some dependencies, but I think it is important that any significant dependency should be clearly visible in the business architecture. (In general, business architects usually neglect this kind of dependency until I point out specific examples to them.)

When looking at this kind of dependency, it is important to remember the principles of asymmetry - the Product is not the Technology, and the Company is not the Product. There have been a few popular products and platforms whose owners lost interest - these included Bloglines (formerly owned by Ask) and Delicious (formerly owned by Yahoo) - but were revived under new ownership. Users of a popular platform may feel that a large user base provides grounds for optimism that someone will want to keep it going, even if the original owner doesn't wish to. However, there are many products and platforms that have not survived.

More fundamental is the question of the underlying technology. A few years ago, there was considerable confidence and investment in RSS and Atom feeds, and a number of products and platforms were developed to exploit this technology. If there is a healthy ecosystem of different products and platforms, with relatively low switching costs, it doesn't matter much if one product drops out. But if Google and others are losing interest in this technology, that's a much more fundamental problem for anyone who is heavily committed to it.

If Google stops providing a free service, those who really want it may have to pay to get a decent service elsewhere. But this alters the economics of the service ecosystem, with unpredictable consequences. Clearly there is a risk that the service you want (or the service you need your customers to use) is increasingly expensive, inconvenient and ultimately unavailable.

Doug Newdick, Cloud and Continuity of Supply Risk (March 2013)

Danish metamodels

2013-03-09T23:26:00.000Z

My Danish friends @gotze and @aojensen comment on the latest release of OIO EA, which is a national enterprise architecture framework and meta-model published by the Danish Government Agency for Digitization.

Both John and Anders feel that certain key artefacts have been placed at the wrong layer of abstraction. John writes

"In my view, Business Rules should not be located at the strategic level at all. I would argue that Business Rules primarily “belongs” to the Business sub-architecture domain."

What is the basis for this argument? Anders points out a consequence

"business rules are located in the government strategy layer and thus tightly coupled to the long term vision of the government agency"

"Business rules are operationalisations of the long term strategy and strategic intent.
Whilst the vision, mission, and purpose of the enterprise do not change very often (i.e. provide the best available services our citizens), the business rules and processes involved in realising this will definitely change."

and therefore

"Business rules belong in the business architecture."

Thus Anders is basing his argument on a statement about the frequency of certain classes of change.

This statement appears to be empirically testable, although I know from my own experience that it is a lot difficult than one might think to gather data to test this kind of statement.

Part of the problem of measuring rates of change is that we don't have a particularly robust theory of change in the first place. Let's look at an example. From time to time, perhaps every year, Steve Ballmer restates the vision of Microsoft. Obviously he doesn't use exactly the same words every year. And of course Microsoft-watchers will seek to interpret even the slightest change of wording or emphasis as a sign of a strategic change in direction. So even if Ballmer himself insists that the vision hasn't changed, we might not believe him. Looking back in time, we might find that major changes in direction had already been hinted at in previous years. So at what point does an apparently minor change in wording become a substantially new vision?

Conversely, when a company has been exposed as unethical, the CEO will go public with an apology and an assertion of a new ethical vision. (Recent example: Barclays Bank.) We might not believe him either.

In both cases, we will probably judge whether there is a new vision or not by observing whether the company behaviour and rules changes or not. (And this is not just external observers - Microsoft and Barclays employees and managers are also making these judgements.) So the rate of change of vision might be epistemologically indistinguishable from the rate of change of behaviour.

However, despite the difficulties in conceptualizing and measuring change, I think it does make sense to derive architectural layers from the idea that certain things have a characteristic rate of change, and that things with a different rate of change should be in different layers. This means that there is at least a possibility of subjecting an architecture to empirical evaluation. I have published this idea in articles for the CBDI Forum, and suggested that architectural theory needs to be based on the Pace Layering principle

In contrast, Anders' appeal to the IAF seems to be purely an argument from authority. The IAF establishes some "fundamental" categories, and so any framework that deviates from these categories must be wrong. I think this line of argumentation is weaker. Even though you may assert some attractive consequences of following IAF, I cannot see any reason for believing that these consequences follow only from IAF and not from any rival framework.

Frameworks and categories may be embedded in metamodels. But how do we know what is the basis for choosing between alternative metamodels?

John Gøtze, Metamodels (January 2013)
Anders Ø. Jensen, Enterprise Architecture and abstraction layers (February 2013)

Ethics, Barclays and totalitarianism (Catholic Commentary January 2013)
Barclays boss tells staff 'sign up to ethics or leave' (BBC News January 2013)
Did Barclays suffer an Ethics Meltdown? (CSR Zone, July 2012)
Sure Kamhunga, Barclays to re-examine its core values (October 2012)
Naven Johal, Barclay’s Does Something Right! (January 2013)

Updated 29 April 2013

Arguing with Mendeleev

2013-03-01T21:42:00.002Z

@JohnZachman insists that his classification scheme is fixed—it is not negotiable. Comparing his Zachman Framework with the periodic table originally developed by Dmitri Mendeleev, he says, "You can't argue with Mendeleev that he forgot a column in the periodic table".

Well, actually, you can. If you look at the Wikipedia article on the Periodic Table, you can see the difference between Mendeleev's original version and the modern version. Modern chemists now use a periodic table with 18 columns. As Wikipedia states, "Mendeleev's periodic table has since been expanded and refined with the discovery or synthesis of further new elements and the development of new theoretical models to explain chemical behavior."

What makes chemistry a science is precisely the fact that the periodic table is open to this kind of revision in the light of experimental discovery and improved theory. If the same isn't true for the Zachman Framework, then it can hardly claim to be a proper science.

Some observers have noted that early versions of the Zachman Framework had fewer columns, and see this as a sign that the number of columns may be variable and open to discovery. But the Zachmanites reject this; they say that the six columns have always existed, it was just that the early presentations didn't mention them all. "Humanity for the last 7,000 years has been able to work with what, how, who, where, when, and why." (This sounds like a Just-So-Story - "How the Enterprise Architect Got His Toolset")

Mr Zachman has a degree in chemistry, so he ought to understand what makes the Periodic table different from his own framework. However, some of his followers are less cautious in their claims. I found an article by one Sunil Dutt Jha, whose "proof" of the scientific nature of EA seemed to rely on two key facts (1) that Mandeleev transformed alchemy into chemistry by creating the periodic table, and (2) that the Zachman framework looks a bit like the periodic table, therefore (3) EA must be a science too.

An earlier version of this comment was posted on Linked-In Is it true to say that “Enterprise Architecture” is a scientific basis for creating, maintaining and running an Enterprise?

Erecting the Framework (Feb 2004) - John Zachman discussing his Zachman Framework for Enterprise Architecture in an interview with Dan Ruby

John P. Zachman, The Zachman Framework Evolution (2009-2011)

Sunil Dutt Jha, Biggest myth – “Enterprise Architecture is a discipline aimed at creating models” (January 2013)

See also

Richard Veryard, Satiable curtiosity (September 2009)

Alan Wall, Pattern Recognition and the Periodic Table (March 2013)

Link added 24 March 2013

Knowledge and Memory

2013-03-01T10:47:00.001Z

Once upon a time, people thought of an information model as defining the structure of the stuff you want to remember. Nowadays, this definition is too restrictive: it might possibly be adequate for a system/database designer, but is not adequate for an architect.

Here are three examples where my knowing and using information is not dependent on my remembering it.

1. I recently helped an SME with its PCI DSS submission. One of the critical points is that they avoid a lot of trouble by NEVER storing their customers' credit card details, merely transmitting these details directly to Barclaycard using a secure device. Clearly the credit card details are stored in various places elsewhere, but our systems don't store them anywhere, not even in cache.

2. When I did my driving test, many years ago, the Highway Code had a table of stopping distances that you were supposed to remember. I decided it would be easier to remember the formula and calculate as required. Obviously that's a design decision.

3. My computer remembers frequently used email addresses. But if I want to get back in touch with someone, I will use Linked-In or Google to find his current email address rather than use the one on my computer which may be out-of-date.

The system/database developer and the architect may use the same patterns for defining an entity or entity type, but they have different agendas, and therefore different success criteria. The architect may be less rigorous about some aspects, and needs to be more rigorous about some other aspects.

The system/database developer may see an entity as "something you need to remember etc.". An architect sees an entity as "something you need to exchange information about". The information model establishes a consistent basis for information exchange between people, systems, services, processes and organizations. I can only talk with you about customers, share your customer data, use your customer-related services, and so on, if either (a) you and I have the same understanding of CUSTOMER or (b) there is a mapping between your notion of CUSTOMER and mine. We can call this semantic interoperability.

This idea of semantic interoperability underlies the Open Group vision of Boundaryless Information Flow.

If you have a private list of customers on your laptop, then you can identify them in any adhoc manner you choose. But if you want to share the list with other people, the identity criteria become important.

So which entity types is the architect is most interested in? Primarily the ones that are referenced in the interfaces between systems and services. There are lots of other things that you might wish to remember, monitor and/or direct, but if they can be encapsulated inside some service or component they have no architectural significance. For example, the business needs to know the prevailing VAT rate; so you build a common VAT routine with the VAT rate hidden inside.

System Theory for Architects

2013-02-28T20:52:00.000Z

There is a growing interest among enterprise architects in systems theory or thinking. (In this context, the words "theory" and "thinking" seem to be for all intents and purposes interchangeable.) There are several possible reasons for this interest.

1. The idea that systems thinking provides some theoretical underpinning for enterprise architecture and/or systems architecture.

2. The idea that systems thinking is somehow complementary to enterprise architecture, and that there is some kind of synergy available from putting together concepts, techniques and practices from the two disciplines.

3. The idea that systems thinking and enterprise architecture are essentially doing the same things (modelling, abstraction, joined-up thinking, big picture, enterprise-as-system, etc etc)

4. The idea that systems thinking and enterprise architecture are rivals for our affections, and their respective champions are trying to show that one is more conceptually coherent, more broadly based, more solidly grounded, and even perhaps more useful, than the other.

Both Enterprise Architecture (EA) and Systems Thinking (ST) have some espoused theory - in other words, things that both practitioners and researchers believe to be true. There are many different schools of EA and ST, and each school has a different set of beliefs, as well as a different set of concepts. Indeed, different schools may have widely different notions of what an enterprise or system actually is.

But EA and ST are not just random collections of theory but practices, offering a range of practical tools and techniques. These practices are instrumental, by which I mean that they are used by practitioners in order to perform some function, as a means to some defined set of ends, delivering something of value for some stakeholders. There is considerable debate in both the EA community and in the ST community as to what these ends are, and for whom. For example, some may think that the primary task of EA or ST is to describe and specify stuff, or to deliver understanding and insight. Others may think that the primary task is to plan and manage some kinds of change.

Practitioners may explain what they do, and why they think it works, but we shouldn't always take these explanations at face value. Espoused theory may not reflect theory-in-use. Thus although an EA practitioner and an ST practitioner may use different concepts to explain what they do. and may appeal to different authorities, what they actually do in real situations might possibly turn out to be pretty similar. The real test of similarity or difference between EA and ST would be observing what they actually do, and comparing the concrete conclusions and recommendations they produce, rather than listening to their various reasons and rationalizations.

Besides conceptual differences, practitioners may adopt a range of different stances towards the problem space. The classic EA stance is a visionary one - formulating an optimistic vision or blueprint of some desired future state. Whereas the classic ST stance may be a more realistic one - identifying the difficulties and risks in some elaborate plan. We can map these two positions to the opposite poles identified in Albert Hirschman's book The Rhetoric of Reason.

On the one hand, an optimistic and progressive stance (EA-as-visionary)

Urgent action is necessary to avoid imminent danger ("The Imminent Danger")
All reforms work together and reinforce each other, rather than being competing ("The Synergy Illusion")
History Is on Our Side

On the other hand, a more conservative or reactionary stance (ST-as-realist)

Any purposive action to improve some feature of the political, social, or economic order only serves to exacerbate the condition one wishes to remedy. ("perversity thesis")
Attempts at social transformation will be unavailing, that they will simply fail to "make a dent." ("futility thesis")
The cost of the proposed change or reform is too high as it endangers some previous, precious accomplishment. ("jeopardy thesis")

From a conservative or reactionary stance, the optimistic stance of the EA-as-visionary seems naive and possibly dangerous. However, the reactionary stance is also problematic, and Hirschman regarded the standard reactionary objections to all proposals for change as stupefying, mechanical, hyperbolic, and often wrong. See Cass R. Sunstein, An Original Thinker of Our Time (New York Review, May 2013).

We may observe that EAs with a strong appreciation of systems thinking often adopt an EA-as-realist position. Meanwhile, these are not the only possible stances for EA or ST. A number of other possible stances were identified in a workshop at EAC2009. At the time, these were called archetypes, as in my post EA Archetypes (June 2009).

And there are undoubtedly different ST stances as well. A common stance within ST is the Critical Diagnostic: here's why this can never work. Applies both to AS-IS (explaining the dysfunctional behaviour of existing systems) and TO-BE (pointing out the flaws in proposed interventions). This is perhaps fairly close to the EA-as-Realist stance. Another common common stance within ST is the Critical Doctrine: here's why so-and-so's approach doesn't count as true Systems Thinking. Applied by nearly everyone against the Seddonites, and by the Checklanders against nearly everyone.

Undoubtedly the ability of EA and ST to work together depends (among other things) on the stances involved.

Meanwhile, those offering a conceptual unification between EA and ST either have a much harder challenge (if they wish to account for the detailed differences in outcomes between EA and ST practice) or a trivially easy challenge (if they confine themselves to asserting broad generalities and abstract principles).

See my previous post How to combine Enterprise Architecture with Systems Thinking (Jan 2011)

Updated 14 May 2013

Complexity is not a problem

2013-02-09T18:01:00.001Z

There is a common view in the enterprise architecture world that complexity is a big problem, perhaps the biggest problem, and that the primary task of enterprise architecture is to deal with this complexity.

"The most pressing problem of the organization is complexity. Complexity is the primary responsibility of the enterprise architect." (Roger Sessions, Controlling Complexity in Enterprise Architecture pdf June 2007)

"Enterprises are instances of complex adaptive systems having many interacting subcomponents whose interactions yield complex behaviors. Enterprise Architecture is a way of understanding and managing such complexity." (Beryl Bellman Managing Organizational Complexity pdf FEAC Oct 2009)

Indeed, I'm sure I've said things like this myself. But if complexity is a problem, whose problem is it? I am not seeing a huge rush of businessmen hiring enterprise architects just to deal with The Complexity Problem. Usually they have much more practical problems that they want addressing.

Read more »

The Calculus of Cost 2

2013-01-26T13:23:00.002Z

@remembermytweet and @tetradian explore the Types of Cost (Jan 2013).

Alex identifies a number of different types of cost, which as Tom points out are largely monetary costs. But what is a cost anyway?

An enterprise incurs a great deal of cost. and these can be broken down and classified in various ways. Accountants like to express all costs in monetary terms - so for example, human effort is translated into labour cost.

But that only works if the enterprise is directly paying for the labour, in the form of wages or contractor bills. Wasting the customers' time doesn't count as a direct cost to the enterprise, although it may well have an indirect cost in terms of customer complaints and lost revenue.

We might also think of anxiety as a cost. As Seth Godin comments in relation to the airline industry, "By assuming that their customer base prefers to save money, not anxiety, they create an anxiety-filled system." Eleven things organizations can learn from airports (Jan 2013). See also my post on Anxiety as a Cost (Jan 2013).

Even for direct labour, the human cost may not be fully reflected by the wages and monetary overheads associated with employment. Many employees do unpaid overtime and incur other personal costs, and this is only visible to the enterprise accountants when it results in high levels of sickness and staff turnover.

So we need to remember the difference between a real cost and its monetary measure.

Read more »

Managing Business Transformation

2013-01-23T12:30:00.003Z

Just putting together the material for my new workshop next week.

This is the third day of my Business Architecture series. The first two days cover the six business architecture viewpoints. The idea is that people can tale these separately or together.

Day One - Modelling Business Operations
Exploring process quality issues using the Activity Viewpoint, Knowledge (Information) Viewpoint and Motivation (Purpose) Viewpoint.

Day Two – Modelling Business Organization
Exploring business relationships and strategy, using the Capability Viewpoint, Responsibility (Organizational) Viewpoint and Cybernetic Viewpoint.

Day Three – Managing Business Transformation
Process guidelines and roadmap for business architects to analyse and manage structural change in large complex organizations.

Read more »

Business Network Optimization

2013-01-09T10:38:00.001Z

Some @ATKearney consultants have written an interesting article on Business Network Optimization

"Anyone thinking about rationalizing a network would naturally ask whether so many nodes are really necessary. Networks are a great deal more complicated than that, and managing them requires expansive strategic imagination."

A simplistic accountancy view of a network looks at the direct contribution of each node. From this viewpoint, some nodes may not produce enough direct value to justify their continued existence, and there will be calls for these nodes to be closed or merged with their neighbours.

For example, there are several proposals currently under consideration within the UK National Health Service to rationalize Accident and Emergency provision by closing some hospital departments and relocating staff. These proposals are based on arguments about the optimal size of an Accident and Emergency unit, and on claims that smaller units are unlikely to deliver value for money or clinical excellence.

Opponents of these closures point to the indirect effect of these closures, including the likely consequences on non-emergency healthcare services at those hospitals that will lack accident and emergency provision, as well as the wider social impact on the local community.

The example given in the A.T. Kearney article is the French postal service, and the authors assert the indirect value of the village post office, using an almost untranslatable French term l'animation du territoire, the "animation of the territory".

The Kearney article identifies three types of business network, which it calls Production, Service and Distribution, and eight elements of network management which must be optimized together. It calls these KNOTs, which stands for Kearney Network Optimization Tools, and asks us not to think of them as merely a laundry list of best practices used to build an optimal network.

The article illustrates the concept of indirect value in terms of the cross-over between physical and online retailing. If a customer views a product in a physical store and then orders it online, the physical store is providing some indirect value to the retail operation as a whole. It is therefore makes sense to optimize the entire online/offline network as a whole, rather than regarding them as two separate networks. See my post on Showrooming and Multi-sided Markets (December 2012).

Read more »

Business Architecture Training - January 2013

2013-01-04T13:51:00.002Z

The next public dates for my workshops with Unicom are as follows.

Business Awareness for IT Specialists (January 28th)
Business Architecture Series (January 29th-31st)
Organizational Intelligence in the Public Sector (February 1st)

Please tell them you saw it on my blog when you book. These workshops are also available inhouse.

Read more »

The Physical Environment and its Outcomes

2013-01-01T13:06:00.000Z

A dispute is currently raging between the UK Department for Education and the architecture profession. Famous architects such as Lord Rogers are demanding the right to design fancy schools, appealing to studies indicating that a well-designed environment can improve learning outcomes for schoolchildren. However, Michael Gove claims that school building costs can be reduced by 30% by reducing unnecessary space and eliminating "frills". A spokesman for the Department for Education said: "There is no convincing evidence that spending enormous sums of money on school buildings leads to increased attainment. An excellent curriculum, great leadership and inspirational teaching are the keys to driving up standards."

I haven't studied the detailed evidence myself, but I suspect the truth is somewhere between these two positions. The study identifies such factors as lighting, circulation, acoustics, individuality and colour. Politicians who spent their own childhood in stuffy or draughty classrooms with flickering flourescent lighting may imagine these factors to be character-building, but surely most people will think that children and teachers deserve a decent environment.

But surely a decent environment doesn't need to cost an extra 40%. Is white paint so much cheaper than a nice colour? Does poor lighting and inefficient air conditioning really save money? Or does the 30% saving really come from cramming more pupils into less space?

And to what extent is Lord Rogers's complaint really about these factors? Perhaps it is more about the architecture profession's desire to create exciting and iconic buildings, with lots of curves. Can a curve be cost-justified in terms of educational attainment? Conversely, is the banning of curves merely a symbolic gesture on Gove's part?

There are several problems with this kind of debate. Firstly, the people who have the greatest knowledge and expertise are seen as having a vested interest in expensive solutions. Secondly, other stakeholders sceptical that the expense can be justified (in terms of ROI) and tending to regard good architecture (whatever that means) as an expensive luxury. Thirdly, a tiny amount of genuine evidence gets stretched very thinly, through rival interpretations and extrapolations and opinions. And finally, the complex relationship between cost and benefit gets overlaid with politically motivated simplicities.

Well, that's architecture for you.

Read more »

Enterprise Architecture Forum - Spring 2013

2012-12-28T14:51:00.000Z

Unicom is planning another Enterprise Architecture Forum in London on March 21st. These generally attract a good audience of senior IT management from blue chip organizations. At the previous Forum in September, we had case studies from finance, oil and higher education. Anyone wishing to present a case study at the next event, please contact me or Unicom.

We are also planning an Organizational Intelligence Forum, possibly on April 25th to coincide with the Performance Management Forum.

Those outside the UK may wish to plan a trip to London to coincide with these events.

These events are part-funded by commercial sponsorship and vendor exhibitions. Please contact me or Unicom for a vendor information pack.

How to describe organization structure - Matrix versus Lattice

2012-12-20T22:26:00.000Z

It bothers me that the way enterprise architects talk about organization structure is so imprecise. Take for example "lattice management".

There are lots of consultants and business school pundits talking about "lattice management structure", as a quick Internet search will confirm, and a few business organizations appear to have adopted some form of lattice structure.

I was in a discussion where someone declared that lattice management was just the same as matrix management. Given the optimistic vagueness with which management gurus peddle their thinking, and given their propensity to attach new labels to second-hand concepts, it is hard to be certain about this. However, there do seem to be some important differences between matrix management and lattice management.

Matrix management often looks like an intersection between two or more hierarchies - so you report up one management ladder for certain aspects of your work, and up another management ladder for certain other aspects of your work, thus solving some problems with the simple hierarchy. (Opponents of matrix management argue that it introduces more new problems than it solves.) Whereas lattice management is being described in terms of horizontal and diagonal flows, as well as horizontal and diagonal career moves. Is that the same? Who knows what these descriptions really mean?

According to some accounts of lattice management, there aren't any bosses.

http://www.metafilter.com/105524/How-dont-use-the-Bword-applies-in-latticestructure-management

My first mentor in data modelling, Raimo Rikkilae, taught me that every question had three possible answers: zero, one and many. Thus there are three possible answers to the question "How many bosses do you have?"

One	Hierarchy
Many	Matrix
Zero	Lattice

Each of these structures offers a different (imperfect) solution to the problem of accountability. In a lattice organization, one is primarily accountable to the customer. This relates to what my friend Philip Boxer calls East-West Dominance. See also his post on Architectures that integrate differentiated behaviors, where he indicates the limitations of matrix and the potential of lattice.

The example of Lattice Management that everyone cites is W.L. Gore. Many people complain that this isn't a perfect implementation of the Lattice concept. But then I've never seen an organization that implements the Hierarchy or Matrix concept perfectly either.

You might also complain that a singular example is a bit problematic. There are other singular organizations that attract a lot of attention, like Semco. Incidentally, according to some sources, Semco adopted a lattice structure in the mid 1980s, but has since moved to something even sexier.

But the management literature is teeming with singular or extreme examples. Amazon whenever the platform business is discussed. Shell whenever scenario planning is discussed. Apple, Toyota, and so on. If we were to ban singular examples, much of the management literature would disappear.

There may be some extremists who believe that a lattice management structure is suitable for every organization, although we might reasonably be sceptical of such a claim in the absence of much practical evidence. A more moderate (and more plausible) position is that many organizations could benefit from a lattice structure. So we might ask why don't MORE business organizations adopt a lattice management structure, and what inhibits organizations from adopting more innovative structures that might benefit them.

One likely explanation is that there are some stakeholders who strongly (if covertly) oppose such structural change, perhaps because their own personal power base depends on traditional lines of authority.

Another explanation is that there are some aspects of organizational structure that are so deeply embedded that they are hard to change, even when all stakeholders are willing to change.

In general, there are some kinds of structural change that a given organization is capable of adopting, and other kinds of structural change that would be very difficult if not impossible. This is undoubtedly something that business architects need to get a handle on.

Cathy Benko, Molly Anderson and Suzanne Vickberg, The Corporate Lattice, A strategic response to the changing world of work (Deloitte Review)

Cathy Benko and Andrew Liakopoulos, The Corporate Lattice (Talent Management, Jan 2011)

Cathleen Benko and Molly Anderson, The Lattice That Has Replaced The Corporate Ladder (Forbes March 2011)

Gary Hamel, Innovation Democracy: W.L. Gore's Original Management Model (Management Innovation eXchange, December 2010)

How "don't use the B-word" applies in lattice-structure management (MetaFilter, July 2011)

Marie Wiere, The Pros and Cons of a Hierarchy Free (Lattice) Organization Structure (May 2012)

Design for Regulation

2012-12-13T23:10:00.000Z

One source of complexity in organizational design is the requirement for various forms of regulation and governance. This requirement results in significant levels of bureaucracy and management overhead, as seen across much of the public sector as well as in many large commercial organizations.

It is tempting to think that much of this regulation and governance is redundant, and that such organizations would be far more efficient and effective if these layers of bureaucracy were eliminated. Of course that will sometimes be true, but it would be architecturally wrong to eliminate any specific regulatory mechanism without understanding the purpose and systemic effects of this mechanism.

In general system terms, some form of regulation may be required to maintain integrity of structure and behaviour. The architect needs to understand the abstract need for regulation, without prejudging any specific mechanism or institutional solution. This understanding calls for the Cybernetic Viewpoint.

The Cybernetic Viewpoint allows us to consider the existence, purpose and style of regulation, while deferring the question of responsibility for regulation and its technical mechanisms.

There is a considerable debate about the proper style of regulation. There are many voices speaking for principles-based or performance-based or risk-based regulation, typically contrasted with rules-based or process-based regulation. The need for precise specification and enforcement in a given situation may depend on the degree of trust.

The existence of some form of regulation may be inferred from some form of regularity in the structure and behaviour of a system, even if we don't always know the precise mechanism that produces this regularity. This inference may follow Stafford Beer's POSIWID principle - the Purpose Of a System Is What It Does.

Aside from the style of regulation, there is even greater debate as to the responsibility for regulation. There are emergent forms of regulation (such as market forces or consumer choice), collaborative forms (such as industry self-regulation), and institutional forms (such as independent regulatory bodies). We can identify four main categories as follows. (The labels for these categories are copied from the System-of-Systems world.)

Directed regulation - central regulation by a single regulatory authority

Acknowledged regulation - where there are multiple aspects of regulation handled by specialist regulatory bodies.

Collaborative regulation - where regulation is distributed around the ecosystem, such as self-regulation

Virtual regulation - where a regulatory effect is produced by crowd behaviour, such as market forces

People often have strong preferences between these categories, partly based on political affiliation, and partly based on the degree of trust in the players.

To sum up, architects need to think about regulation both in abstract terms (where market forces, self-regulation and statutory procedures may be regarded as alternative and potentially interchangeable solutions to a common regulatory requirement) and in specific terms (where the implementation of a given regulatory instrument may have a significant impact on system and organization design).

John Kay, Regulation by Rules or Regulation by Values (Feb 2000)

Arnold Kling, Why We Need Principles-Based Regulation (American Enterprise Institute, May 2012) via EconLog

James Surowiecki, Parsing Paulson (New Yorker, April 2008)

Robert Teitelman, The paradoxes of rules-based regulation (Deal Economy, Sept 2011)

Co-Production of Strategy and Execution

2012-12-09T14:32:00.001Z

#antifragile In my post Structure Follows Strategy?, I discussed the reciprocal relationship between strategy and structure, and discussed my friend Patrick Hoverstadt's mission to connect enterprise architects with the strategy processes in an enterprise.

My thoughts about strategy are influenced by Mintzberg, who sees strategy formulation as an emergent process of trial and error that takes place during implementation. A company may start with a broad-brush deliberate strategy, but this strategy often overlooks some significant issues and risks.

These weaknesses need to be addressed as part of the execution of the strategy. Thus a more complete and correct strategy emerges out of the execution process.

Senior management sometimes take a long time to recognize and acknowledge the fact that the defacto (emergent) strategy is now better than the original (deliberate) strategy. And in some companies the original strategy is so bad, and the senior management so pig-headed, that there is little chance of a more sensible strategy emerging.

In order to see strategy and execution as co-evolving, we need to link both strategy and execution to outcomes. If the outcomes turn out unsatisfactory, it is surely a subjective judgement whether this is blamed on weak strategy or weak execution. And if the overall outcomes turn out to be satisfactory then we may suppose that any weakness in strategy was compensated by excellent execution, and any weakness in execution was compensated by brilliant strategy.

This of course depends on our notion of excellence. Some people might think that perfect execution means doing exactly what it says in the strategy, no more or less. Alternatively, we might define excellence in terms of achieving the best possible outcomes, thus excellent execution may need to depart from the official strategy if that's what it takes.

Which brings me to Nassim Nicholas Taleb's notion of antifragility. If fragility means that something is harmed when bad things happen, antifragility means that something becomes better or stronger when bad things happen.

So let me try to apply this notion to the current discussion. A fragile strategy is one that would fail if there are any deviations in execution. A robust strategy is one that would be unaffected by the quality of the execution. And an antifragile strategy is one that would grow better with deviations in execution.

Partly based on my contributions to a Linked-In discussion I wonder what the EA team is doing? (One person has deleted his contributions, so the discussion as a whole no longer makes much sense.) See also Fragile Strategy or Fragile Execution? via Storify.

Carole Cadwalladr, Nassim Taleb: my rules for life (The Observer, 24 Nov 2012)

John Crace, Antifragile by Nassim Nicholas Taleb – digested read (The Guardian, 2 Dec 2012)

David Runciman, Antifragile: How to Live in a World We Don't Understand by Nassim Nicholas Taleb – review (The Guardian, 21 Nov 2012)