How to combine Enterprise Architecture with Systems Thinking

#entarch #systemsthinking A great discussion yesterday between some systems thinkers from SCiO and some enterprise architects. This post is not a record of the meeting, but contains some of my thoughts following the meeting.

Does it make sense to combine EA and ST to create something we might call EAST?
Let me address this question in terms of the five perspectives outlined in my previous posts.

EAST as instrument	Use ST to improve EA. Use EA to improve ST. Or create a composite instrument using elements of EA and ST.
EAST as discourse	Either find the intersection between EA and ST - common concepts and principles. Or find the union between EA and ST - complementary concepts and principles.
EAST as community	Encourage EA people to become part of the ST community, or vice versa. And/or facilitate collaboration between EA people and ST people.
EAST as knowledge	Use ST to investigate and critique EA. Use EA to investigate and critique ST.
EAST as trade or service	Use EA as a platform for introducing ST into organizations. Use ST as a platform for introducing EA into organizations (perhaps at a different level).

All of these combinations are theoretically possible. It is possible to take any two or more disciplines and create an arbitrary hybrid, as long as you have pretty weak standards of coherence and usefulness. Weak coherence may be an essential step for early innovation, but shouldn't be an excuse for intellectual laziness. Gartner is currently pushing a specific hybrid, based on combining EA with design thinking together with some ecological ideas (panarchy), but I haven't seen any practical results yet. See my post on Hybrid Thinking and my note on Methodological Syncretism.

The practical question is how any such possible combinations can be grounded in practical work, rather than being merely abstract combinations of ideas and slideware. So the next task for the EAST group is to find some practical business problems to work on together.

What is Wrong with Enterprise Architecture?

#entarch In my previous post, What is Enterprise Architecture (not again)? I identified five interlinked perspectives on the nature of Enterprise Architecture. There is a different class of critique that applies to each perspective.

EA as instrument	Questions of effectiveness - does it work? Efficiency, reliability, etc.  Does the instrument have requisite variety?
EA as discourse	Questions of relevance and coherence - does it make sense?
EA as community	Questions of politics and affiliation and development - is there a collective character and intelligence, how does this coalition of supposedly like-minded people create and re-create itself?
EA as knowledge	Questions of validity (epistemology) - to what extent are these knowledge claims grounded in practical experience?
EA as trade or service	Questions of economic and ethical viability - who creates value for whom, who demands what from whom, governance.

I think there are problems for EA from all five perspectives. While these problems are undoubtedly interconnected, they are logically distinct.

This set of problems produces a number of observable consequences.

• Crisis of confidence - EA practitioners not being sure of their value to the enterprise
• Credibility - People outside EA not having a clear understanding of the value of EA
• Failure of leadership - lots of self-appointed experts trying to impress their followers with grandiose abstractions, complicated schemas and random theories
• Existential  angst - lots of pointless and empty discussions

What is Enterprise Architecture (not again)?

Prelude

Let's start with the tweets.

@RSessions: Enterprise Architecture is a tool, not a solution. 
@Cybersal: I agree EA is not a solution; however I prefer to characterise it as a discipline or a practice. A tool seems too mechanistic. 
@leodesousa: I agree it is a discipline/practice that should be embedded into existing processes like proj mgmt, chg mgmt, stratplan
@richardveryard: If we understand #entarch as a means-to-an-end, then the word "instrument" is better than the word "tool". 
@ironick: How about EA is a process? That's how #GartnerEA defines it. 
@RSessions: A process is reproducible. I know very few (only one, actually) EA methodologies that strive for reproducibility. 
@enectoux: EA is a complete discipline and mindset. It has many frameworkS, processeS, methodS, practiceS, toolS… 
@RSessions: Tool" is really a metaphor. The point is that effective use of EA requires training. Just buying "EA" doesn't buy you anything.
@leodesousa: #entarch is not something you buy rather something that is invested in as an ongoing practice

I'm sorry if I missed anyone, but this kind of debate could go on for ever ...

---

Fugue

So here's my take. There are (at least) five perspectives of what enterprise architecture is.

1. EA as instrument. It's something that is used as a means-to-an-end. (Like a tool, but more general and perhaps less mechanistic than a tool.) It is wielded with such-and-such intentions to produce or maintain such-and-such outcomes. If you don't have these intentions, or you don't believe EA can produce these outcomes, then you shouldn't be doing EA at all.

2. EA as discourse. It is a language (way of talking) that expresses (and focuses attention upon) a particular set of concerns and issues. This is what establishes a certain agenda for EA, and helps to differentiate EA from various other practices (such as programme management or requirements engineering or risk management) which might appear to address much of the same problem space.

3. EA as community (of practice). There is a large number of individuals and organizations that identify themselves as part of this community, including several groups and organizations that claim to represent this community and its interests. In practice, EA can be regarded as the totality of what the EA community does in the name of EA.

4. EA as body of knowledge. Among other things, EA bodies of knowledge include various prescribed processes, but it is important to distinguish between the espoused processes (what the book says you should do) and the processes-in-use (what the community actually practises).

5. EA as trade or profession. Enterprise architecture provides a set of paid-for services to the enterprise, or to senior business managers, or to some other individual and collective stakeholders. (Payment can be in the form of salary or consultancy contract.) The commercial viability of EA and the careers of EA specialists depend on a sustainable demand for these services.


There are significant issues for EA from each of these perspectives, which I talk about in my next post What's Wrong with Enterprise Architecture?

Executives who outsource too much

#entarch @Cybersal found a useful article in MIT Sloan Management Review What Happens When You Outsource Too Much? by Francesco Zirpoli and Markus C. Becker (December 2010).

In my view, the title of the article doesn't do justice to the content. There has been endless discussion on how-much outsourcing. Here is a small selection.

"Globalization has led corporations to outsource too much of their work and, more important, their intellectual capital. This has created a worldwide level of interdependency that increasingly threatens to disrupt supply lines and markets at times of earthquakes, explosions, terrorist acts, and other disasters in one part of the world." Has Globalization Reached Its Peak? (James Heskett, HBR, April 2006)

"Outsourcing is one of the quickest, easiest, and most inexpensive ways to hire help and get things done faster." Coaching Women - How to Outsource Tasks Without Losing Control (Zenobia Garrison, Oct 2010)

"You don’t want to outsource too much." Why Outsourcing Can Work (Cormac Foster, Dell, October 2010).

According to most of these accounts, the trick is to outsource only those activities that have certain properties.

• "primarily non-strategic activities"
• "the tasks that you despise or take up too much of your time"
• "don’t fix what isn’t broken"

To my mind, this is a programme management approach to outsourcing - classifying each business activity separately, and deciding its fate accordingly. In contrast, a truly architectural approach to outsourcing would look at the effect of outsourcing on the relationships between activities, not just on the activities in isolation. This is what I find new and interesting about the Sloan paper; here are some key quotes from it, which may help me to reinforce Sally's recommendation.

"By 2005, top management realized that pushing outsourcing deep into the product development process had seriously altered the technical heart of the company."

"There is an important difference between integrating physical systems and integrating the performance of such systems."

"Managers need to have detailed knowledge and understanding of how subsystems interact within the products to achieve different outcomes. ... Knowledge of underlying components is essential for identifying the consequences of different trade-offs and making the best decisions regarding overall product performance. Component-specific knowledge is key to architectural knowledge."

"Managing outsourcing by relying on the modularization of the product can have fundamental flaws. Modular product architecture may make good sense for dealing with physical integration, but it is not adequate for resolving issues of performance." (We might say the same about the modularization of the business process.)

"Combining knowledge requires a deep understanding of knowledge, rather than just information scanning or exposure."