EA/ST Meeting Report October 2014

Perspectives on Enterprise Architecture and Systems Thinking

Unfortunately, I missed this month's EA/ST group meeting on Tuesday 21st October. But the presentations by @KlausØstergaard, @kvistgaard, @PhilipHellyer and @tetradian are now available.

• Klaus Østergaard, Value in Utilizing Systemic Thinking in the Field of Enterprise Architecture and Vice Versa (DropBox link)

• Ivo Velitchkov, Language & Metalanguage for Enterprise Architecture http://www.slideshare.net/kvistgaard/language-and-metalanguage-for-enterprise-architecture

• Philip Hellyer, Navigating Barriers (DropBox link)

• Tom Graves, Bridging Enterprise Architecture and Systems Thinking: http://www.slideshare.net/tetradian/bridging-enterprisearchitecture-and-systemsthinking

---

Language and Meta-language for Enterprise Architecture from Ivo Velitchkov

Bridging enterprise-architecture and systems-thinking from Tetradian Consulting

The Enterprise Architect of Hamelyn

Stakeholder Concern	Enterprise Focus	Project Focus
The city of Hamelyn is plagued with rats.	This indicates a serious problem with the “Public Health and Hygiene” capability.	We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
The Pied Piper gets rid of the rats.	Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem.	Project successful.
The Pied Piper is too expensive.	We need a careful transition plan while we build an in-house capability.	Let us immediately renegotiate our contract with the vendor.
The Pied Piper gets rid of the children.	It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes.	!*!?**!
Which Role?	Enterprise Architect? Strategic Procurement?	Solution Architect? Tactical Procurement?

See also my article “Requirements Engineering as if Stakeholders Mattered” (Requirenautics Quarterly, Issue 29, August 2003, pdf)

Three Notions of Maturity

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 unbounded vision and ambition of the immature, and that too much maturity (in this sense) could just result in negativity and middle-aged stagnation. See my note on EA Archetypes (EA-as-visionary, EA-as-realist).

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, whose four levels of maturity are based on the Four Stages of Competence.

1. Unconsciously incompetent
2. Consciously incompetent
3. Consciously competent
4. Unconsciously competent

Thus the 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. I-Space also contains the insight that "intellectual property" doesn't last for ever, because all useful knowledge eventually becomes public knowledge. Competence relative to one's competitors is always based on proprietary knowledge, while knowledge that is in the public domain cannot form the basis of competitive advantage.

Meanwhile I'm uncomfortable with the notion of unconscious competence for another reason: in a dynamic world it can quickly develop into complacency and arrogance. Whatever happened to continuous learning and improvement?

In order to maintain competitive advantage, both SECI and I-Space are essentially cyclic models, 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 is sometimes argued that different levels of maturity are suitable for different organizations, which is basically a form of contingency theory. In other words, some organizations never need to be fully mature.

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.

---

Scroll down for discussion with Len Fehskens.

Related post: From Enabling Prejudices to Sedimented Principles (March 2013)


Thanks to Len Fehskens (in comments below) for pointing out the original source of the Four Stages of Competence.

Post last updated 31 August 2018

From Sedimented Principles to Enabling Prejudices

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.

---

Universal truths. This kind of principle is something one has to accept and believe, because the evidence in its support is overwhelming. For example, all computers of a given construction must obey certain logical principles, as rigorously proven by Gödel, Turing, Church, von Neumann, and others.

(There aren't many universal truths in the enterprise architecture domain, and the word "proven" is widely abused to mean "something that everyone believes" or "something that nobody has convincingly disproved" or "something that is vaguely associated with a bit of maths or science". I'm not impressed by "proofs" that haven't been published anywhere, are based on wishful thinking and received wisdom, or turn out to prove something fairly trivial.)


Governance. An enterprise or ecosystem may be regulated by governing principles, which are essentially high level rules or policies controlling the structure and behaviour, and constraining certain classes of decision. For example, an enterprise software architecture may be based on certain global principles about accessibility or security, which ultimately link to some specific outcome.

Some EA frameworks arrange principles, policies and rules into a pseudo-hierarchy, but the dividing line between principles and policies can be pretty arbitrary.

Governing principles may be reinforced by standards, but usually the principle is broader than simply conforming to the standard. For example, a principle of accessibility may reference various accessibility standards, but software designers may be expected to strive for enhanced accessibility beyond the minimum standards.


Style. An enterprise or ecosystem may have some stylistic preferences. For example, applications within the Apple ecosystem tend to have a predictable look and feel. In some areas, these stylistic preferences may be elevated to the status of principles.

Some people think that all systems within an enterprise or ecosystem should have a common look and feel. This is a bit like insisting that all the rooms in your house should be painted the same colour, from the kitchen to the bedrooms. Feng Shui practitioners preach the opposite idea; they say that a building should have different zones, with different "look and feel". They then have some complicated rules associating different colours with different compass points, which we don't need to go into here.

In some cases, there are strong reasons for making systems look and feel different. When a pilot is flying a plane, it's probably not a good idea for the flight controls to operate in the same way as the accounting system she uses on the ground for submitting her expenses. A system may even have a different look and feel according to context, thus a database operator may be presented with a different interface when working with the live database, forcing her to slow down and consider every action twice.

In other areas, differences between systems are annoying and may increase levels of error. On Apple computers, and inside some applications, command-D means Duplicate. On Windows, command-D means Delete. I'm sure I'm not the only one who gets these mixed up, and I am grateful that the Windows command at least has a Confirm/Cancel step. In some other systems, the Delete function wipes the file immediately, which is tough if you're used to a Confirm/Cancel/Restore. Other stylistic differences may make navigation harder. For example, regular users of Microsoft Office may detect some minor style differences between the different applications. Just because you've used a particular function in Word doesn't mean you can find it in Excel or Powerpoint. Perhaps it's there, but hidden under a different name in a different submenu. Of course, Microsoft has cleaned up many of these style differences over the years, but perhaps inevitably some remain.

Style often originates with arbitrary choices or one person's aesthetic preferences. Someone once thought it would be a good idea to have X for cut and V for paste, but it could equally have been two other letters. But nowadays users are so accustomed to X and V for cut and paste, that it would be perverse for a designer to use any other letters.

Overarching stylistic rules and guidelines may be presented as local principles, valid for a particular suite of applications. They represent a set of often originally arbitrary choices and preferences, which have been adopted by or imposed onto a community of designers.

I see a subtle difference between style principles and governance principles, and one clue is the nature of the argument that emerges when people don't want to follow them. Style arguments tend to be presented in aesthetic terms - the old design is old-fashioned, younger users want something cool, etc, etc. Governance arguments are presented in terms of outcomes - this would not produce the outcomes we want, or has some other side-effect.


Finally, I get to what is possibly the most controversial one.

Enabling Prejudices. One of the key insights of the early work on Design Thinking (Bryan Lawson, Peter Rowe) was the importance of heuristics, or what Rowe (following Gadamer) calls enabling prejudices, which will hopefully get us to a good-enough solution more quickly. 

As Christopher Alexander notes:

At the moment when a person is faced with an act of design, he does not have time to think about it from scratch. The Timeless Way of Building p 204

We always approach a problem with a set of prejudices or prejudgements. Depending on the situation, these may either help us to solve the problem more quickly (enabling), or may lead us astray (disabling). The acid test of a set of heuristics or design principles is that they are mostly enabling most of the time.

Perhaps one important difference between education and training is that good education encourages the students to think more deeply, whereas good training teaches students to solve problems more quickly. (Or reliably or effectively, or some other adverb.) Thus training initiates and indoctrinates the students into a set of enabling prejudices, which will give them greater practical power.

Inexperienced practitioners may rely heavily on the principles they were taught in training, or have learned from books. As practitioners gain experience, their prejudices may become more refined, more personalized, and more deeply embedded. A lot of the principles articulated for enterprise architecture reflect this kind of enabling prejudice.

Obviously there is nothing wrong with an enabling prejudice when it is correct. A basketball coach might have a reasonable expectation that tall people are generally better at basketball than short people. But in an ideal world, a good basketball coach would be open-minded enough to notice a shorter player who is exceptionally good. It would be doubly stupid to impose a minimum height rule, firstly because you might exclude a really good player, and secondly because you will never get any feedback to tell you to revise the rule.

Now here's the twist. Many enterprise architecture frameworks suggest that practitioners should agree a common set of principles. But here's a contrary thought. Maybe a healthy enterprise or ecosystem encourages diversity of prejudice. (The shorter guy only needs one basketball coach to spot his talent and potential.) If we all have different approaches to problem-solving, then we are collectively more likely to find good solutions to difficult problems, and more likely to spot possible pitfalls. The value of diversity applies both when we are collaborating and when we are competing. Whereas a community with a single (attenuated) set of enabling prejudices would lack resilience, forming a dangerous form of intellectual monoculture.


Some might complain that allowing heuristic variation introduces fragmentation, inconsistency and incoherence into the enterprise or ecosystem, but I think that's incorrect. As I see it, maintaining integrity and consistency is the job of the governance and style principles. The heuristics (enabling prejudices) perform an entirely different job, and I think it is wrong to try standardizing and enforcing them in the same way as the other principles.

---

Christopher Alexander, The Timeless Way of Building (New York: Oxford University Press, 1979)

Dan Klyn, Skirmishing With Ill-Defined and Wicked Problems (TUG, 5 July 2013) - review of Rowe

Bryan Lawson, How Designers Think (1980, 4th edition 2005)

Peter Rowe, Design Thinking (MIT Press 1987)

Stanford Encyclopedia of Philosophy: Gadamer and the Positivity of Prejudice


Related posts: What's wrong with principles (Feb 2010), What's wrong with principles 2 (July 2010), The Power of Principles - Not (Jan 2011),  From Enabling Prejudices to Sedimented Principles (March 2013)

Updated 11 November 2018

Danish metamodels

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

System Theory for Architects

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

Special Powers of the Architect - Abstraction

Does the Enterprise Architect have special powers?

---

One idea is that the intrinsic essence of an enterprise architect is to think about abstraction. (By the way, abstraction seems to be a category that can only be defined polythetically; it appears to have many characteristic features, but we seem to be unable to work out any defining features.)

Suppose that the use of an enterprise architect (if any) is to solve practical business problems. For this purpose, enterprise architects are interchangeable with systems thinkers, just as Jaffa Cakes are interchangeable with Fig Rolls. For a large tea party or enterprise transformation programme, we might have a plate containing Jaffa Cakes and Fig Rolls and various other cakes and biscuits.

But presumably that's not the only thing that an enterprise architect is good for.

So one theory-practice question is this. What are the essential things that an enterprise architect brings to solving practical problems? If it is abstraction, what special powers (if any) does this give to the practising enterprise architect? And what are the essential things that a systems thinker brings to solving practical problems?

Abstraction is associated with a number of myths and pitfalls

• The myth that radical structural and behavioural change can and should be driven by a few simple and powerful ideas. On the misuse of general principles (Jan 2012)

• Valuing abstraction and adaptability above everything else. Avoiding thinking about mundane technology when building pure business models. IT Innovation at Small Bakery (April 2009)

• The relationship between the general and the specific is poorly supported by the prevailing tools and methods, which often reduce the question to simplistic abstraction hierarchies. TOGAF 9 - Enterprise Continuum (Feb 2009).  Instead of generalizing everything as much as possible, architects need to reason explicitly about system structure and dynamics - cohesion and coupling, composition and decomposition, change and emergence. They need to understand granularity and stratification as active choices, rather than text-book patterns. Architecture and Abstraction (May 2004)

• Mainstream EA frameworks typically appear as premature codifications of ungrounded abstractions. The attempted diffusion of these codified abstractions is then ineffectual, because these ungrounded categories lack any relevance to real business challenges. ... So instead of discussing concrete business problems, we find ourselves discussing generic categories of business problem. Towards Next Practice EA (May 2013) 

See also

• Special Powers of the Architect - Getting The Big Picture (Dec 2010)
• Special Powers of the Architect - Judgment (January 2012)

Updated 26 October 2016

The Five Essential Metrics for Managing EA

In November 2009, @Forrester Research published a report by Jeff Scott with Alex Cullen, Mimi An. Cost $499. Five Essential Metrics for Managing EA.

"Enterprise architects frequently ask what metrics they should use to demonstrate EA's progress and value to the organization. CIOs want to know what they are getting for their investment in EA, and EAs see metrics as an important tool for promoting their value. Yet establishing meaningful metrics remains challenging. Today, most EA teams report only on internal-activity-based metrics. The key to success is choosing a small number of metrics that provide a balanced view of EA's performance to EA stakeholders and the EA team. Every EA team should measure five metrics: strategy momentum, financial impact, customer satisfaction, skills and capability growth, and process improvement."

(Note the assumption that it is the CIO to whom EA is accountable.)

Forrester analyst Tim DeGennaro now predicts "they’re going to kill off the usual EA metrics" (Five Predictions For EA Practices In 2013 January 2013)

"Our data shows that standard EA metrics (maturity, perception, value, etc.) are less and less likely to actually be used, even though they’re an extremely popular topic of conversation. A recent experience of mine confirmed that even when trapped in a room for a few hours, not even industry peers can agree on a set of common metrics. Powerful metrics are too company- and initiative-specific to standardize. And in the end, the usual metrics might become irrelevant."

See also John Spacey, 7 Key Enterprise Architecture Metrics (Simplicable, April 2011)



Updated 20 February 2016

Generalists versus specialists

#entarch Following a series of blogposts from @tetradian under the general heading "No Jobs for Generalists", @ruthmalan chips in to ask whether the labels "generalist" and "specialist" represent useful stereotypes, or whether they merely reflect another one of those "petty antagonisms".

Tom Graves, No Jobs for Generalists (August 2012)
Ruth Malan, A Trace in the Sand (August 2012)

In places, Tom's description does imply a dichotomy between generalist and specialist, which could well lead to antagonism between job roles (where "antagonism" probably means mutual incomprehension and discomfort and maybe schismogenesis rather than outright hostility). Elsewhere he talks about "specialist-generalists", but I think it may be more correct to think of the relationship between generalist and specialist as a dialectic one.
  
How exactly does the specialist/generalist dialectic work? I found an interesting framework by Gillian Stamp, in a book by Elliott Jaques and others. Levels of Abstraction in Logic and Human Action (1978).


Mode One: Proceduralists or Pragmatic Specialists (competent, persistent, attention to detail)

Mode Two: Practitioners or Pragmatic Generalists (good at organizing both their own work and that of others)

Mode Three: System Setters or Theoretical Generalists (good at gathering and organizing quantities of information, good planning ability)

Mode Four: Structuralists or Theoretical Specialists (intellectually very able, subtle, creative and very self-contained in their work)

Mode Five: Originators (poor at routine work, usually taking an original approach to a problem even when this may not be appropriate)

In this framework, generalists are not at the highest level of abstraction, but sit in the middle.

The popular EA frameworks (such as TOGAF) seem designed to support Mode Three. But there may be many enterprise architects whose personal inclination may be more towards Mode Four or Five; and it may be awkward for them to pretend to be in Mode Three in order to sell EA services to managers who are in Mode One and Two.

This might go some way to explaining some of the difficulties addressed in Tom's blog.

In a Jaquesian management hierarchy, higher levels of management (and higher status) is associated with higher cognitive ability, which Jaques associated with levels of abstraction as well as longer time horizon. Superficially, this seems to provide a theoretical justification for the old civil service idea that generalists (people with university degrees in ancient Greek) should manage specialists (people with university degrees in science and engineering) - although the old civil service way of implementing this idea reflected a rather perverse interpretation of the generalist/specialist dichotomy, since it is unlikely that one's abstract cognitive ability depends solely on the subjects studied at university.

Within large organizations, people often aspire to more general roles than they currently occupy. There are two distinct reasons for this. One is that people may develop more abstract capability as they mature; the other is that the more general roles are perceived as carrying higher status. Companies often designate selected employees as "high-fliers", and move them rapidly around to prevent them becoming bogged down in any particular specialism. However, it has often been observed that people drift upward until they reach a level at which they are no longer competent. (This is known as the Peter Principle.)

In a Jaquesian hierarchy, the management function needs to be at a higher level of abstraction than the function being managed. New employees and external consultants are generally subject to closer levels of supervision than long-serving employees, whose actual work (defacto job) is often much more interesting and varied than the official job description. From an HR perspective, it makes perfect sense to recruit specialists and allow deserving employees (if they wish) to grow into the more sprawling (and ill-defined) generalist roles. And from an outsourcing perspective, it makes perfect sense to subcontract the (more easily specified) specialist work and retain a smaller inhouse staff of generalists to make sure it all fits together.

But the idea that any old generalist can perform an abstract architectural role - especially architectural control over a complex procurement environment - seems troubling. Is Mode Three good enough?

Where were the architects at RBS?

#entarch Some interesting architectural implications of the recent embarrassing failure of banking systems at RBS-NatWest Bank, which has caused financial stress and distress for millions of customers.

A banking software expert quoted in the Guardian offered an interesting architectural analogy.

"Banking systems are like a huge game of Jenga [the tower game played with interlaced blocks of wood]. Two unrelated transactions might not look related now, but 500,000 transactions from now they might have a huge relation. So everything needs to be processed in order."

This analogy suggests that the problem is one of architectural knowledge and governance. This is always a problem for any large and complex enterprise, but outsourcing typically amplifies such problems. From the press reports, it seems that the implementation of the RBS-NatWest application architecture has been delegated to a bunch of relatively inexperienced Indians with little knowledge of the RBS-NatWest business.

The finger of blame is being pointed to CA-7, which I understand to be a middleware product responsible for the orchestration of complex batch runs. As recently as February, there were job adverts in Inda urgently seeking people with CA-7 experience for the RBS contract.

Distributes or centralize job submission, management and monitoring as you choose and simplify job management by automating as much as possible and provides a simple-to-use interface to manage your environment. CA 7® Workload Automation is a mainframe-hosted, fully-integrated workload automation engine that coordinates and executes job schedules and event triggers across the enterprise.

http://www.ca.com/us/products/detail/ca-7-workload-automation.aspx


The Guardian continues

It seems whoever made the update to CA-7 managed to delete or corrupt the files which hold the schedule for the overnight jobs, so they did not run, or ran incorrectly.

ComputerWorld quotes an RBS spokesman.

The focus right now is on fixing the problem, which was triggered during a software system upgrade.

and BBC's Robert Peston adds

the software update that went so badly wrong last Tuesday night was fairly quickly identified and patched by Royal Bank; it is the absence of a contingency plan to deal with the knock-ons from the initial computer failure that many will see as deeply troubling

I presume that CA-7 expertise involves the ability to create and maintain these control files. But these control files essentially contain executable metadata that describe how the applications must be joined up, which must ultimately be based on a rigorous view of the application architecture - in other words, a model of the application layer.

In my discussion of business capabilities, I have always said that the most troublesome capabilities (and the ones overlooked by most business analysts) are the coordination capabilities, and these are the ones that need the most care when outsourcing. The RBS-NatWest incident illustrates this point.

@davidsprott uses the incident to illustrate the need for application modernization. But was the problem in the core application systems, or was it in the platform layer?  

To the extent that application coordination is being managed via CA-7, it looks suspiciously as if the model of the application layer was embedded in the platform layer, and managed as if it was merely technical infrastructure. This suggests a fundamental architectural flaw in RBS systems - a failure to maintain a clean separation of concerns between the application layer and the platform layer.

This is one of the reasons why enterprise architecture is important. With clean separation and robust interfaces between the architectural layers (business, application, platform), we can carry out modernization, innovation and continuous change in each layer separately. This follows the principle of pace layering, based on the notion that each layer has a different characteristic rate of change. Without clean separation between layers, the layers shear apart, resulting in misalignment and system failure. And as @davidsprott points out, service enabling has exactly this (layer separation) outcome.

Conclusions

• It's risky outsourcing the core systems unless the architecture is clearly understood and controlled.
• Good outsourcing‬ requires a good service architecture, which may include business, app and/or platform services.
• Modernization requires good architecture.
• In complex systems of systems, coordination is a core business capability. Outsource with extreme caution.

---

Charles Arthur, How NatWest's IT meltdown developed (Guardian 25 June 2012)

Anh Nguyen, CA 'helps' RBS resolve tech problem that led to massive outage (ComputerWorld 25 June 2012)

Robert Peston, Is outsourcing the cause of RBS debacle? (BBC News 25 June 2012)

David Sprott, RBS Crash - Management Prefer Offshoring to Modernization? (25 June 2012)

See also Architecture as Jenga (September 2012)

Twin-Track Architecture

#entarch This post follows discussions with Graham Berrisford of Avancier about the relationship between Enterprise Architecture (EA) and Solution Architecture (SA).

---

What seems to make sense is to describe EA/SA as a twin-track process (similar to the twin-track process that aligns service development with solution development in SOA).

Twin-track is essentially an abstract process pattern, used to align two activity streams at different levels of granularity. As far I recall, I first encountered it in the Select Perspective methodology, described in two books by my friend and former colleague Paul Allen. The CBDI SAE methodology also uses the twin-track approach.

In SOA, there is a stream of activity to produce and maintain services, and another stream of activity to use these services to build solutions. These two streams need to be connected but not synchronized. The two tracks may be separated organizationally - split into different teams or org units, or even separate companies - provided that there are suitable governance mechanisms for allocating resources and responsibilities, and resolving issues. People may specialize in one or other stream.

A twin-track processes doesn't assume either top-down or bottom-up. In some cases, you could start with the solution requirements and then specify the desired services (top-down). In other cases, you could start with a set of available services, and then assemble these into solutions (bottom-up). In practice, the twin-track approach accommodates a mixture of top-down and bottom-up. The important point however is that the two have to be connected at a series of touch-points.

We can now describe the relationship between enterprise architecture and solution architecture in similar terms. If solution architecture is disconnected from enterprise architecture, then the solution architects are likely to produce point solutions instead of enterprise solutions. Conversely if enterprise architecture is disconnected from solution architecture, then it is likely to produce grand, simplistic and ultimately unimplementable schemes. Again, we don't have to assume that either EA or SA is dominant, but that they work together towards common goals.

---

For other posts on twin-track: browse, subscribe. 

EA Forum Report

#entarch A packed room in Central London Thursday for the EA Forum, and lively discussion through the day. Some of the presentations are now available online.

---

Martin Owen and Jamie Knowles (Corso) Strategic Planning for IT: Creating a Framework to Embrace Market and Business Driven Change

Harmen van den Berg (BiZZdesign), ArchiMate 2.0: Modeling Enterprise Architecture aligned with TOGAF

David Twaddell (BCS EA SG) The Professionalisation of Enterprise Architecture (slideshare)

Tom Gilb, Real Architecture: Engineering? or Pompous Bull***? (pdf)


Richard Veryard, Architecture-Led Procurement (slideshare)


David Hunt, Case study – Enterprise Architecture at Lloyds Banking Group

Philip W. Veasey, The Architectural Challenges of NHS Reorganization - An Independent View (slideshare)

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.

 

See also Value Proposition for Enterprise Architecture (June 2009), Special Powers of the Architect (2010-2013)

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

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.

Dimensions of EA maturity 2

#entarch @Cybersal asked me to expand on my previous post on three dimensions of EA maturity.

Instrumentality

This is about regarding EA as a tool, a means to some ends. What outcomes are expected from EA?

For example, do we regard EA as a planning tool, a coordination and governance tool, or an asset management tool? Or some combination of these?

Agency

This is about the power and responsibility of EA as a function. What tasks are delegated to EA, and by whom? How is EA held accountable for a given set of outcomes?

For example, does EA play an advisory role or gatekeeper role? Does EA report to the CIO or the CEO?

Scope

How large is the system for which EA is accountable? What issues and concerns are a legitimate part of the EA agenda? Is EA restricted to formal IT systems, does it include informal IT systems (such as social networking), or does it also include business and organization issues? In other words, does Enterprise Architecture really mean Enterprise IT Architecture or Enterprise Data Architecture? 


And does EA include ways of understanding the enterprise as a complex and dynamic human activity system, not merely as a fixed array of automated and bureaucratic functions?

---

In What is Enterprise Architecture? and What's Wrong With Enterprise Architecture?, I analysed EA from five perspectives, but not all these perspectives are relevant to understanding EA maturity. The three dimensions I'm defining here can be mapped as a rough simplification from these five perspectives for maturity purposes. When people (including myself) talk about Next Generation EA, this usually means some shift in one or more of these three dimensions.

Found in Translation

Vaughan Merlyn explains Why the Notion of the IT Organization is Deeply Flawed!

"Having an IT organization that translates business requirements into IT specifications and solutions is always, at best, a flawed approach" [via Ross Jimenez]

Gartner's definition of enterprise architecture is also based on the concept of translation

"EA is the process of translating business vision and strategy into effective enterprise change." [via Nick Gall]

But we know that translation is prone to error (as Carl Bate and Nigel Green demonstrate in their book Lost in Translation) and indeterminacy (Quine).

*****

Deloitte Consulting uses the term "Lost in Translation" to market its enterprise architecture practice,
illustrated with what appears to be a Chinese version of the Zachman framework.

"Many IT infrastructures are set up without a common language in place that cuts across different enterprises, making it difficult for strategic decisions to be effectively translated into the organization’s technology foundation. That’s where enterprise architecture (EA) can make a difference."

"Deloitte has access to a full range of capabilities in consulting, tax, audit and finance worldwide. This broad range of capabilities allows us to provide services to assist with any enterprise architecture challenge."

But just because a large service firm has access to a broad range of different capabilities, it doesn't automatically follow that these capabilities are joined up, or that the firm is able to translate effectively between different professional disciplines. See my post From 'Organizational Intelligence' to 'Ability to Execute'.

Dimensions of EA maturity

@gotze (John Gøtze) kindly sent me a copy of his 2010 paper Architecting the Firm (written with Pat Turner and Peter Bernus). My interest had been stimulated by Anders Jensen, who described the paper as follows in his blog on the Thinking Enterprise.

It has been a healthy evolution for EA to question its IT heritage and adopt a broader perspective of how commercial enterprises navigate and gravitate in their respective marketplaces. This healthy evolution has particularly been articulated by Turner, Gotze, and Bernus (2010) in their paper Architecting the Firm: Coherency and Consistency in Managing the Enterprise, which argues the key role of architecture in executive management.

The paper offers four interesting EA archetypes, which are presented as a maturity model. As I see it, the four archetypes described in the paper differ along three orthogonal dimensions: instrumentality, agency and scope.

• The first archetype ("Foundation") could be described as Invisible EA. In what sense is EA going on at all? Even the "struggle for existence" is largely invisible.

• The second archetype ("Extended") describes EA in instrumental terms - as an instrument for managing assets.

• The third archetype ("Embedded") describes EA in terms of agency - with EA taking authority and responsibility for certain things.

• The fourth archetype ("Balanced") goes back to describing EA in instrumental terms  - but with a much broader scope of application.

However, there seems to be little evidence of a development path passing through these four archetypes in irreversible sequence, nor any reason to suppose this particular development path to be either optimal or unavoidable. For my part, I prefer not to call this kind of thing a maturity model at all. In my post on SOA maturity models, I pointed out a key difference between an evolution roadmap (which says what you can do immediately and what you may defer) and a maturity model (which says what you can't do until). A roadmap is enabling and encouraging; a maturity model is parental.



Reading the paper, I wondered how the evolution of EA within one enterprise (possibly via these four archetypes) might relate to the evolution of EA itself (into Next Generation EA). The paper outlines "the vision of the right information for the right people at the right time ... coherency of information flow". But this doesn't exactly sound like EA questioning its IT heritage does it?

---

See also More on the Dimensions of EA Maturity (November 2011), in which I expand on instrumentality, agency and scope.

Towards a VPEC-T analysis of Google

#entarch Enterprise architects need to understand values and policies. VPEC-T is an approach that is particularly useful for situations where there are multiple conflicting values and policies, or multiple interpretations of What-Is-Going-On.

In this post, I want to look at Google. Can we infer its values and policies from its observed behaviour (over time).


We may start by asking what events we think Google is paying attention to. Here are some of the events that are available to Google.

1. You search for "XYZ"
2. You skip over the first few items, and click on the third item on the second page.
3. You look at a webpage and then come back to continue your search.
4  You rephrase and clarify your enquiry.

Google is pretty coy on its exact use of these events, but most Google-watchers assume that these events have an influence on its search algorithms and/or its advertising algorithms. In other words, we may presume that Google is generating valuable content from these events.

Google has indulged in a wide range of initiatives over the years, many of which have no obvious line to revenue. But all of them have the potential to generate vast amounts of rich content - much of it related to the observed behaviour of internet users. On this interpretation of Google's strategy, initiatives are dropped, not because they fail to generate revenue but because they fail to generate enough of the desired kind of content. Google is betting its future on building and maintaining this content through powerful positive feedback.

Google's strategy is therefore surprisingly traditional - it involves capturing some territory and defending it against its competitors. Here's an example - Google provides the Android platform to mobile device manufacturers. When Motorola wanted to use Skyhook's voice recognition instead of Google's, Google forced it to fall into line. Daniel Soar argues that this was not because Google executives feared losing revenue but because they feared losing access to an important source of content. As Soar puts it, "Google faced the unfamiliar problem of the negative feedback loop: the fewer people that used its product, the less information it would have and the worse the product would get." (Google has since bought out Motorola Mobility, which presumably resolves some of the trust issues as well.)

Daniel Soar, You can't get away from Google, London Review of Books, Vol 33 No 19, 6 October 2011


Can we understand Google's phenomenal collection and use of data as an example of organizational intelligence? Google is certainly seeking to differentiate each Internet user's experience, as well as integrate across multiple domains (web browsing, email, blogging, voice, video, satnav, and so on). Google already has an army of brilliant engineers as well as an alarmingly large carbon footprint. There is lots of evidence of Google's integrating these resources into one of the most innovative sociotechnical systems on the planet.

(By the way, when I asked Google itself about its carbon footprint, it recommended I look at a recent story in the Guardian (8 September 2011). I can see that Google has been asked this question many times before, because it pops up so quickly as an expected search term. But why should I trust Google's recommendation, and how can I ever discover what newspapers would be recommended to a browser with a different browsing history to mine?)

But a lot of this learning looks suspiciously like first-order learning. So the content gets better, based on better capture of events, but to what extent is there any systematic evolution of policies or questioning of values? There may well be some second-order or third-order learning, but it's not easy to see from the outside. There is also an important question about the relationship between Google's own ability to learn from its accumulated content, and Google's ability or willingness to provide a rich platform for learning by others in its ecosystem - in other words, a broader notion of collective intelligence.

I wonder if there are any lessons for other organizations? Sometimes firms like Amazon, Apple, Facebook and Google (Eric Schmidt's Gang of Four) seem pretty far removed from most other organizations, but their platform strategies and operating patterns will surely become increasingly relevant in other sectors. A traditional retailer may now collect and analyse a much larger quantity of data about its customers' behaviour than ever before, even if this is still several orders of magnitude less than what Google does. A traditional telecoms or media company may now see itself as a platform business in a multisided market. Therefore instead of seeing Eric Schmidt's Gang of Four as impossibly remote and mysterious organizations, populated by unbelievably talented and creative engineers, we should start to think of them as harbingers of the enterprise of the future.



See also my post Google as a Platform (not)

---

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