Friday, May 24, 2013

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 sometimes they 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.

These and related issues were discussed at a public meeting Perspectives on Enterprise Architecture and Systems Thinking, in Central London, June 14th 2013. For my own presentation slides, subsequent notes and links to reports by other participants, see Schism and Doubt (July 2013).

Thursday, May 16, 2013

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/

Friday, May 03, 2013

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. There are many valid uses for these models, including heat-mapping.

One such 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.

In the early 2000s, I started working on an alternative approach to capability modelling in collaboration with the CBDi Forum. This approach, which is loosely aligned with Stafford Beer's Viable Systems Model, concentrates on understanding the dependencies between core capabilities, and the role of key management capabilities such as coordination and intelligence. One of the key drivers for this work was the belief that a network view of capabilities provided a good starting point for developing a shared service architecture (both business and IT). This topic has gone off the radar lately, but I think it remains important. 


Denise Cook, Business-Capability Mapping: Staying Ahead of the Joneses (MSDN March 2007)

Ulrich Homann, Jon Tobey, From Capabilities to Services: Moving from a Business Architecture to an IT Implementation (MSDN April 2006)

Ric Merrifield, Rethink (FT Prentice Hall 2009) (pdf intro)

Ric Merrifield and Jon Tobey, Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion (MSDN May 2006)

Ric Merrifield, Jack Calhoun and Dennis Stevens, The Next Revolution in Productivity (Harvard Business Review, June 2008) (pdf)

Martin Sykes and Brad Clayton, Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture (Microsoft Architecture Journal, June 2009)

Richard Veryard, Business Modelling for SOA - Capabilities and Events (CBDI Journal January 2006), Capability Dependency (CBDI Journal May 2007)

Richard Veryard, Six Viewpoints of Business Architecture (LeanPub 2012)

Related posts: IBM's Component Business Model (March 2005), Merging Capability Modelling with Process Modelling (April 2008), Business Capability Modelling (March 2009), Organizing Business Capabilities (February 2012)


Updated 31 July 2014