Towards Next Practice EA

A few weeks ago, @Cybersal and I met with @snowded to talk about enterprise architecture. He showed us a graph of the Complex Space, whose two dimensions were Evidence and Consensus. Dave has since posted a version of this graph on his blog.

Source: Dave Snowden, Cognitive Edge April 2013
Used with permission

At present, I believe there are two main clusters of Enterprise Architecture practice:

Mainstream EA. This is where TOGAF and Zachman and all the other popular frameworks sit. These frameworks are largely based on a 1980s view of enterprise and IT, contain apparently inflexible classification schemes, and are strongly aligned to the commercial interests of the large software companies and system integrators (IBM, Cap-Gemini, and the rest). These frameworks sit in the top left corner of Snowden's chart, with a high level of consensus and a very weak evidence-base.

If we look at Mainstream EA in terms of Boisot's I-Space, I would suggest these frameworks 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. From time to time, practitioners may well be able to do some useful work, and they may even be persuaded that their success is a consequence of using these frameworks. But it is also possible that these occasional successes are despite the framework and not because of it.

Next Practice EA, with a smaller but growing number of practitioners and researchers proposing radical alternatives to Mainstream EA. This community includes some well-placed industry analysts (such as Nick Gall of Gartner) as well as a significant number of independent consultants. Many of these alternatives involve hybrids of EA with some other discipline, such as Systems Thinking or Design Thinking. However, the evidence base for these hybrids is if anything even weaker than for Mainstream EA frameworks, and there is no consensus whatsoever. Few if any of these hybrids have been tested in full, and they often appear to consist of little more than a bricolage of ill-assorted concepts and techniques, which I call Methodological Syncretism.

What would it take for Next Practice EA to develop either sufficient evidence or sufficient consensus to represent a serious challenge to Mainstream EA? It seems to me that the answer lies at the Concrete, Undiffused, Uncodified corner of the I-Space cube. What I have found highly frustrating in many discussions with both enterprise architects and systems thinkers is an apparent belief in the absolute virtues of abstraction. So instead of discussing concrete business problems, we find ourselves discussing generic categories of business problem. Many of the discussants either don't appreciate the difference between "Cost Saving" and "Cost Saving at Smartchester College", or they think that discussing the general category is more intellectually respectable than discussing a specific case.

There is of course a reason why discussing specific cases is treated with disdain in some quarters, which has to do with the way cases are used in some business schools, notably Harvard Business School. There are two ways to explore a specific case. In the Harvard approach, as I understand it, students are presented with cases which they need to "solve", using a light sprinkling of theoretical concepts. You use the theory if it works; if it doesn't, you ignore it. This approach isn't designed to produce a deeper understanding either of the cases or the underlying theory. The alternative (which I prefer) is a much more reflective and reflexive approach, where you use the case as an instrument to understand and test and refine the underlying theory. The aim is to end up with a rich and specific narrative that is both empirically and theoretically grounded. Only when we have a sufficient number of these narratives do we begin, with great caution, to generalize from them. But that's a lot harder and more time-consuming than putting together a blog or presentation full of post-modern cleverness. (Okay, I can be as guilty of this as anyone else.)

---

This is an extract from my draft eBook Towards Next Practice Enterprise Architecture, available from LeanPub.

There will be an opportunity to discuss these and related issues at a public meeting Perspectives on Enterprise Architecture and Systems Thinking, in Central London, June 14th 2013. Attendance is free, but advanced booking is required.

June 2013 Events

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

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.

From information architecture to evidence-based practice

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

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

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

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

to be continued ...

---

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

Why information architecture needs systems thinking

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

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

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

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.

• Archimate Chapter 3
• TOGAF Chapter 3

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

• Stevens Institute of Technology
• Product Introduction Process Simulation in the Extended Enterprise (PIPSEE) (1997-2001)  

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

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

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

1. Unconsciously incompetent
2. Consciously incompetent
3. Consciously competent
4. 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.