@JohnZachman insists that his classification scheme is fixed—it is not negotiable. Comparing his Zachman Framework with the periodic table originally developed by Dmitri Mendeleev, he says, "You can't argue with Mendeleev that he forgot a column in the periodic table".
Well, actually, you can. If you look at the Wikipedia article on the Periodic Table, you can see the difference between Mendeleev's original version and the modern version. Chemists nowadays use a periodic table with 18 columns. As Wikipedia states, "Mendeleev's periodic table has since been expanded and refined with the discovery or synthesis of further new elements and the development of new theoretical models to explain chemical behavior."
That's what makes chemistry a true science - the fact that the periodic table is open to this kind of revision in the light of experimental discovery and improved theory. If the same isn't true for the Zachman Framework, then it can hardly claim to be a proper science.
Some observers have noted that early versions of the Zachman Framework had fewer columns, and see this as a sign that the number of columns may be variable and open to discovery. They also interpret the word "extending" in Zachman's 1992 paper (with John Sowa) as an acknowledgement that the framework has evolved. But the Zachmanites reject this: they say that the six columns have always existed, it was just that the early presentations didn't mention them all.
"Humanity for the last 7,000 years has been able to work with what, how, who, where, when, and why." (This sounds like a Just-So-Story - "How the Enterprise Architect Got His Toolset".) Questions that require more than one word in the English language (such as How Much and For Whom) can be discounted. (Graeme Simsion made this point in 2004, and this may have been what prompted Scott Ambler to add a cost column to his extended framework.)
Mr Zachman has a degree in chemistry, so he ought to understand what makes the periodic table different from his own framework. However, some of his followers are less cautious in their claims. I found an article by one Sunil Dutt Jha, whose "proof" of the scientific nature of EA seemed to rely on two key facts (1) that Mendeleev transformed alchemy into chemistry by creating the periodic table, and (2) that the Zachman framework looks a bit like the periodic table, therefore (3) EA must be a science too.
An earlier version of this comment was posted on Linked-In Is it true to say that “Enterprise Architecture” is a scientific basis for creating, maintaining and running an Enterprise?
Scott Ambler, Enterprise Agile: Extending the Zachman Framework (undated)
Philip Boxer, Modelling Structure-Determining Processes (19 December 2006)
Sunil Dutt Jha, Biggest myth – “Enterprise Architecture is a discipline aimed at creating models” (January 2013)
Graeme Simsion, What's wrong with the Zachman framework? (TDAN, January 2005)
John Sowa and John Zachman, Extending and formalizing the framework for information systems architecture (IBM Systems Journal Vol 31 No 3, 1992)
Ivo Velitchkov, Frameworks and Rigour (3 March 2013)
Alan Wall, Pattern Recognition and the Periodic Table (March 2013)
John P. Zachman, The Zachman Framework Evolution (2009-2011)
Erecting the Framework (Feb 2004) - John Zachman discussing his Zachman Framework for Enterprise Architecture in an interview with Dan Ruby
Related posts and presentations
For Whom (November 2006), The Kipling-Zachman lens (June 2009), Deconstructing the Grammar of Business (June 2009), Satiable curtiosity (September 2009), Evolving the Enterprise Architecture Body of Knowledge (October 2012), Enterprise Architecture as Science (August 2013), What is a Framework (February 2019)
eBook: Towards Next Generation Enterprise Architecture
Updated 04 May 2019
Showing posts with label EA theory. Show all posts
Showing posts with label EA theory. Show all posts
Friday, March 01, 2013
Thursday, February 28, 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)
On the other hand, a more conservative or reactionary stance (ST-as-realist)
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
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
Friday, September 09, 2011
The Topography of Enterprise Architecture
A lot of the terminology of enterprise architecture depends on some basic categories and distinctions, which help to define the dimensions for various schemas and frameworks.
- Top-down / Bottom-up
- Ideal / Real
- Abstract / Concrete
- Espoused / In-Use
But the meaning of these terms depends on your perspective. See for example my previous post What Does "Top-Down" Mean?
One popular categorical distinction is between “ideal” and “real”, with a progressive series of intermediate states. This category implies a process known as “realization” moving from the “ideal” towards the “real” (for which the Zachmanites prefer the mediaeval word “reification”), and a contrary process known as “idealization” moving from the “real” towards the “ideal”.
(The Zachmanites claim that this distinction derives from some unnamed ancient Greek philosophers, but I have not been able to verify this claim. The earliest sources I can find for this notion are mediaeval Christian and Arabic philosophers such as Ibn Arabi and Ockham, although there may be some hints in Plotinus. What Plato and Aristotle talked about was Form and Matter, and although Form is often translated as Idea, that's not exactly the same.)
But it is interesting to see exactly what people regard as more “real”. For example, many people seem to think that the technology model is more “real” than the business model. In other words, a pattern of magnetic dots on a physical data storage device counts as more “real” than the flesh-and-blood customer that this pattern of dots represents. Such a technologically based notion of “reality” may be useful for some purposes, but it is inescapably a technological perspective. And no EA framework that uncritically adopts a technologically based notion of “reality” can claim to be free of a technological bias.
Stanford Encyclopedia of Philosophy: Form vs Matter
For more on reification, see my post Deconstructing the Grammar of Business (June 2009)
Updated May 2024 to insert reference to Plotinus
Tuesday, June 28, 2011
The Sage Kings of Antiquity
The ancient Chinese philosopher Mozi (Mo Tzu) identified three criteria for judging a theory
Enterprise architecture frameworks can and should be judged against the second and third of Mozi's criteria, and I should certainly like to see more effort and rigour in presenting the evidence to support a wide range of so-called principles and methods.
But what about Mozi's first criterion? Much of the current thinking and practice of enterprise architects can be traced back to a bunch of methodology gurus from the 1980s. A complete list would be impossible, but it would include people like Tom de Marco, Clive Finkelstein, Michael Jackson, James Martin and Ed Yourdon, and with John Zachman just gettting in at the end of the decade. (I think Zachman has more in common with these methodology gurus than with the OO/Patterns gurus - Booch, Jacobson, Rumbaugh, Wirfs-Brock et al - who followed them.)
The term
Why should 21st century enterprise architects care what the sage kings of methodological antiquity thought about enterprise systems? Firstly because the sage kings have given us a huge legacy of principles and practices, much of which are still in use today. Secondly because some of the assumptions made by the sage kings may now look obsolescent, not just because of technology change but because of emerging ideas of complex systems organization and management, and we need to critically review and refresh our principles and practices to ensure we are not still bound by these assumptions. And thirdly because there may be some principles and practices that have fallen into disuse and deserve to be revived.
Given that the empirical evidence for enterprise architecture is fairly weak, anecdotal and inconclusive, we are still more dependent than we might like on the authority of experts - whether this be semi-anonymous committees (such as TOGAF) or famous consultants (such as Zachman). And are the experts consciously or unconsciously recycling the wisdom of the sage kings?
So how much difference is there between today's enterprise architecture frameworks and the structured enterprise methodologies of the 1980s, such as information engineering? And how confident are we that we have kept the good bits and discarded the bad bits?
Declaration: I worked for James Martin Associates from 1986 onwards.
Mo Tzu: Basic Writings. Translated by Burton Watson (New York: Columbia University Press, 1963)
Nikos Salingaros, What Ancient Chinese Philosopher Mo-Tzu Can Teach Designers Today (Metropolis, 20 June 2016)
Internet Encyclopedia of Philosophy: Mozi
Stanford Encyclopedia of Philosophy: Mohism
Wikipedia: Mozi
Links added 19 February 2020
- Origin - reference to the sage kings of antiquity
- Validity - reference to the evidence (
the eyes and ears of the people
) - Applicability - whether it brings benefit to the enterprise and the people
three-prong method.
Enterprise architecture frameworks can and should be judged against the second and third of Mozi's criteria, and I should certainly like to see more effort and rigour in presenting the evidence to support a wide range of so-called principles and methods.
But what about Mozi's first criterion? Much of the current thinking and practice of enterprise architects can be traced back to a bunch of methodology gurus from the 1980s. A complete list would be impossible, but it would include people like Tom de Marco, Clive Finkelstein, Michael Jackson, James Martin and Ed Yourdon, and with John Zachman just gettting in at the end of the decade. (I think Zachman has more in common with these methodology gurus than with the OO/Patterns gurus - Booch, Jacobson, Rumbaugh, Wirfs-Brock et al - who followed them.)
The term
enterprise architecturewasn't used in the 1980s, and appears to have been coined by Steven Spewak in the early 1990s. In those days, people generally talked about Business Systems Planning (BSP) and Information Systems Planning (ISP), and a lot of the early thinking came out of IBM (where both James Martin and John Zachman had worked). Information Systems Planning was the top level of the Information Engineering pyramid, produced by Finkelstein, Martin and others.
Why should 21st century enterprise architects care what the sage kings of methodological antiquity thought about enterprise systems? Firstly because the sage kings have given us a huge legacy of principles and practices, much of which are still in use today. Secondly because some of the assumptions made by the sage kings may now look obsolescent, not just because of technology change but because of emerging ideas of complex systems organization and management, and we need to critically review and refresh our principles and practices to ensure we are not still bound by these assumptions. And thirdly because there may be some principles and practices that have fallen into disuse and deserve to be revived.
Given that the empirical evidence for enterprise architecture is fairly weak, anecdotal and inconclusive, we are still more dependent than we might like on the authority of experts - whether this be semi-anonymous committees (such as TOGAF) or famous consultants (such as Zachman). And are the experts consciously or unconsciously recycling the wisdom of the sage kings?
So how much difference is there between today's enterprise architecture frameworks and the structured enterprise methodologies of the 1980s, such as information engineering? And how confident are we that we have kept the good bits and discarded the bad bits?
Declaration: I worked for James Martin Associates from 1986 onwards.
Mo Tzu: Basic Writings. Translated by Burton Watson (New York: Columbia University Press, 1963)
Nikos Salingaros, What Ancient Chinese Philosopher Mo-Tzu Can Teach Designers Today (Metropolis, 20 June 2016)
Internet Encyclopedia of Philosophy: Mozi
Stanford Encyclopedia of Philosophy: Mohism
Wikipedia: Mozi
Links added 19 February 2020
Friday, February 25, 2011
Modernism and Enterprise Architecture
Underlying conventional enterprise architecture theory and practice are some implicit assumptions that could be loosely characterized as modernist. Several people are offering more or less radical departures from conventional enterprise architecture, which could be loosely characterized as post-modern.
Aspects of Modernism
This emphasis on balance is completely absent from the modernist functionalist aesthetic, which seems to assume that if you take care of the parts and connect them together properly, the whole will look after itself.
The IT modernists (such as James Martin) told us to concentrate on Commodity (roughly translated as functional requirements), because Firmness (reliability and other non-functional) could be handled by technical design and innovation, and Delight could be handled by user design specialists (ha!). For his part, Zachman has said nothing to indicate that he doesn't fully share this mindset, and his interpretation of the "classical" is conceptually and metaphysically flawed. We may note that most of the notations favoured by enterprise architects (IDEF, UML, ArchiMate) concentrate on the functional.
In our time, it is of course Alexander and Salingaros who represent the return to balance and order, as the title of Alexander's masterwork indicates, although I suspect they would not take kindly to being labelled as neo-classical.
Meanwhile, an emphasis on self-organization and heroic agility can be seen as echoing some of the romantic aesthetic. After all, the post-modern aesthetic often combines elements of the neo-classical with elements of the neo-romantic.
In response to the perceived limitations of the modernist approach to enterprise architecture, various thinkers are looking into other disciplines for ideas that can be imported into enterprise architecture.
have I missed anything?
The challenge here is two-fold. Firstly, how can a heterogeneous selection of ideas from different sources be combined into a coherent approach? Secondly, what kind of practical hands-on research (reflective practice) is needed to turn interesting speculation into grounded and credible knowledge?
Philip Boxer et al, Asymmetric Leadership
Dave Duggal and William Malyk, Putting Work in Context for Enterprise Agility (December 2010)
Nicholas Gall (Gartner), Panarchitecture: Architecting a Network of Resilient Renewal (January 2011)
Nigel Green, A new context for EA: The Enterprise: An ecosystem of values and value (Sept 2010)
Dion Hinchcliffe, Post-Modern Enterprise Architecture: Service-Oriented, Agile, Decentralized (April 2005). Pragmatic new models for enterprise architecture take shape (August 2009)
Anders Jensen-Ward, Pondering a new model of architecture and postmodern complexity: Deleuze’s rhizome as the substitute for architectural layers and control. (June/July 2010) via Tom Graves. On management and systems (Aug 2009) On architecture and strategy (Aug 2009) Architectural control as a management paradox (Jan 2011), Rhizome: On Dilemmas in Enterprise Architecture Planning (April 2011)
@rlimbanda To understand human systems based on postmodern natural architecture and the transformation of 21st century social enterprise. // And to understand and share the things that make us human #thoozd (December 2009) via Tom Graves
Hubert Maturana, Metadesign (1997)
Neil McBride, Rachel Lander and Steve McRobb, Postmodernist Business Information Management 1997 (HTML, PDF)
See my previous post on Adaptation and Adaptability
See Linked-In discussion "Is Enterprise Architecture (and IT in general) trapped in the psychological prison of Modernity?" from January 2011 onwards
Updated October 21, 2012
Some links corrected 19 February 2020. Some remaining broken links under investigation - please help.
Aspects of Modernism
- Fordism- Simple decomposition of responsibility, authority, expertise and work (RAEW)
- Functionalism -
Form follows function
- Linear Explanation - Simple association between cause and effect – e.g. process improvement
- Cartesian Theatre - Unified representation of what is going on (WIGO)
- Central Planning - Unified decision-making
- Unified Value System - Complete and consistent set of shared goals and objectives on behalf of
The Enterprise
- Ultimate Solution - Converging towards an ideal set of systems, perfectly aligned to
The Business
Limitations of Modernism
- Difficulties handling complexity, emergence and self-organization.
- Lack of agility, flexibility, evolution.
- Constrains organizational learning.
- No explicit treatment of holistic architectural properties such as balance and harmony.
- No room for pluralism and human values.
Towards Postmodernism
Obviously the labels "classical" and "modernist" can mean different things, but I associate the classical approach to architecture with Vitruvius - Firmness, Commodity and Delight - and I see the essential characteristics of the classical aesthetic as an emphasis on balance, harmony and order.This emphasis on balance is completely absent from the modernist functionalist aesthetic, which seems to assume that if you take care of the parts and connect them together properly, the whole will look after itself.
The IT modernists (such as James Martin) told us to concentrate on Commodity (roughly translated as functional requirements), because Firmness (reliability and other non-functional) could be handled by technical design and innovation, and Delight could be handled by user design specialists (ha!). For his part, Zachman has said nothing to indicate that he doesn't fully share this mindset, and his interpretation of the "classical" is conceptually and metaphysically flawed. We may note that most of the notations favoured by enterprise architects (IDEF, UML, ArchiMate) concentrate on the functional.
In our time, it is of course Alexander and Salingaros who represent the return to balance and order, as the title of Alexander's masterwork indicates, although I suspect they would not take kindly to being labelled as neo-classical.
Meanwhile, an emphasis on self-organization and heroic agility can be seen as echoing some of the romantic aesthetic. After all, the post-modern aesthetic often combines elements of the neo-classical with elements of the neo-romantic.
Exploration of New Ideas
In response to the perceived limitations of the modernist approach to enterprise architecture, various thinkers are looking into other disciplines for ideas that can be imported into enterprise architecture.
| Systems Thinking | Holism and Emergence Viable Systems Model (VSM) Wicked problems Dissipative Structures (Prigonine via @empiricator) |
| Design Thinking and Urbanism | Creativity Organic planning Metadesign Pace layering Post-modernism |
| Organization Theory | Loosely coupled systems Self-organizing systems |
| Ecological Thinking | Panarchy Evolutionary change |
| Complexity Theory | Anticipative Systems Complex Adaptive Systems Dynamics of Strategy (I-Space, Cynefin) |
have I missed anything?
The challenge here is two-fold. Firstly, how can a heterogeneous selection of ideas from different sources be combined into a coherent approach? Secondly, what kind of practical hands-on research (reflective practice) is needed to turn interesting speculation into grounded and credible knowledge?
Some Post-Modern and Other Approaches to EA
I don't know how many of the following approaches can be properly described as postmodern, but they all represent various attempts to break free from the limitations of modernism.Philip Boxer et al, Asymmetric Leadership
Dave Duggal and William Malyk, Putting Work in Context for Enterprise Agility (December 2010)
Nicholas Gall (Gartner), Panarchitecture: Architecting a Network of Resilient Renewal (January 2011)
Nigel Green, A new context for EA: The Enterprise: An ecosystem of values and value (Sept 2010)
Dion Hinchcliffe, Post-Modern Enterprise Architecture: Service-Oriented, Agile, Decentralized (April 2005). Pragmatic new models for enterprise architecture take shape (August 2009)
Anders Jensen-Ward, Pondering a new model of architecture and postmodern complexity: Deleuze’s rhizome as the substitute for architectural layers and control. (June/July 2010) via Tom Graves. On management and systems (Aug 2009) On architecture and strategy (Aug 2009) Architectural control as a management paradox (Jan 2011), Rhizome: On Dilemmas in Enterprise Architecture Planning (April 2011)
@rlimbanda To understand human systems based on postmodern natural architecture and the transformation of 21st century social enterprise. // And to understand and share the things that make us human #thoozd (December 2009) via Tom Graves
Further reading
Max Boisot and Bill McKelvey, Complexity Science-A Bridge Between Modernist and Postmodernist Perspectives (2008)Hubert Maturana, Metadesign (1997)
Neil McBride, Rachel Lander and Steve McRobb, Postmodernist Business Information Management 1997 (HTML, PDF)
See my previous post on Adaptation and Adaptability
See Linked-In discussion "Is Enterprise Architecture (and IT in general) trapped in the psychological prison of Modernity?" from January 2011 onwards
Updated October 21, 2012
Some links corrected 19 February 2020. Some remaining broken links under investigation - please help.
Wednesday, December 15, 2010
An Architectural History of Social Networking
@ruskin147 is in California to meet the networking pioneers, including Stewart Brand.
In 1985, Stewart Brand was one of the founders of an online community called the Well. As Rory reports, the Well provided "inspiring stories of the power of online communication, as its members used its forums to share their lives, their thoughts, and their passions - whether it be for obscure technology questions or discussions about the meaning of life".
In 1994, Brand wrote a brilliant and controversial book about architecture, How Buildings Change, which among other things contained a theory about evolutionary change in complex systems based on earlier work by the architect Frank Duffy and the ecologist Robert O'Neill. The theory was then known as Shearing Layers; Brand now prefers to call it Pace Layering. If there is a difference between the two, Shearing Layers is primarily a descriptive theory about how change happens in complex systems, while Pace Layering is primarily an architectural principle for the design of resilient systems of systems.
In the original Shearing Layers theory, the slowest-moving layer is known as Site. In the context of physical buildings, this is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context outlast generations of ephemeral buildings [via Wikipedia].
An interesting question for Brand then is whether social networking continues to occupy the same "Site" as early initiatives such as the Well. In other words, the boundaries and context outlasting generations of ephemeral technology.
Brand told Rory that he saw some of the same principles in Facebook that had governed The Well: "I'm really impressed at a lot of the instincts that Zuckerberg has had. Taking non-anonymity as an absolutely fundamental value of his company and thereby beating off the competition. A Facebook identity is one of the most valuable things his company offers. The lack of anonymity is what gives it value." [Friendster, Facebook and the Well]
But that's not quite the same as asserting a historical path from the Well to the present day. The critical question here is not how aware Zuckerberg and his associates were with the history of social networking, but to what extent this history directly or indirectly influenced their actions and choices. For example, our collective understanding of "anonymity" is coloured by the past couple of decades of internet and pre-internet activity. Zadie Smith (a near contemporary of Zuckerberg at Harvard) talks about Zuckerberg's idea about what a person is, or should be, and worries that her own idea of personhood is nostalgic, irrational, inaccurate [New York Review, 25 Nov 2010]. And of course ironic.
Where exactly did Zuckerberg's idea of personhood come from? There may be a sense in which echoes of the Well may persist in Facebook through the way such concepts are understood and managed. And although we wouldn't necessarily take Brand's opinion of this at face value (or for that matter Zuckerberg's) there can be few people whose opinion would be so interesting and well-informed.
See also
Roger Hudson, The Evolving Web - A Pace Layering view of the development of the Web and the W3C (March 2008)
Howard Silverman, Panarchy and Pace in the Big Back Loop (originally published on People and Place, March 2009, republished on Solving for Pattern, Oct 2012)
Matt Webb et al, Twitter thread discussing the provenance of the Shearing Layers concept (April 2021)
I have written several other posts on this blog discussing various aspects and applications of pacelayering.
Links updated 11 January 2018, 23 April 2021. Inserted reference to O'Neill.
Saturday, October 30, 2010
Organizations as Brains
This post is based on Chapter 3 of Gareth Morgan's classic book Images of Organization (Sage 1986), which opens with the following question: "Is it possible to design organizations so that they have the capacity to be as flexible, resilient, and inventive as the functioning of a brain?"
To start with, Morgan makes two important distinctions. The first distinction is between two different notions of rationality, and the second involves two contrasting uses of the "brain" metaphor.
Mechanistic or bureaucratic organizations rely on what Morgan (following Karl Mannheim) calls "instrumental rationality", where people are valued for their ability to fit in and contribute to the efficient operation of a predetermined structure. Morgan contrasts this with "substantial rationality", where elements of organization are able to question the appropriateness of what they are doing and to modify their action to take account of new situations. Morgan states that the human brain possesses higher degrees of substantial rationality than any man-made system. (pp78-79)
Morgan also observes a common trend to use the term "brain" metaphorically to refer to a centralized planning or management function within an organization, the brain "of" the firm. Instead, Morgan wants to talk about brain-like capabilities distributed throughout the organization, the brain "as" the firm. Using the brain metaphor in this way leads to two important ideas. Firstly, that organizations are information processing systems, potentially capable of learning to learn. And secondly, that organizations may be holographic systems, in the sense that any part represents and can stand in for the whole. (p 80)
The first of these two ideas, organizations as information processing systems, goes back to the work of James March and Herbert Simon in the 1940s and 1950s. Simon's theory of decision-making leads us to understand organizations as kinds of institutionalized brains that fragment, routinize and bound the decision-making process in order to make it manageable. (p 81) According to this theory, the organization chart does not merely define a structure of work activity, it also creates a structure of attention, interpretation and decision-making. (p 81) Later organization design theorists such as Jay Galbraith showed how this kind of decision-making structure coped with uncertainty and information overload, either by reducing the need for information or by increasing the capacity to process information. (pp 82-83)
Nowadays, of course, much of this information processing capacity is provided by man-made systems. Writing in the mid 1980s, Morgan could already see the emergence of the virtual organization, embedded not in human activity but in computer networks. If it wasn't already, the organization-as-brain is now indisputably a sociotechnical system. The really big question, Morgan asks, is whether such organizations will also become more intelligent. (p84)
The problem here is that man-made systems (bureaucratic as well as automatic) tend towards instrumental rationality rather than substantial rationality. Such systems can produce goal-directed behaviour under four conditions. (p87)
To start with, Morgan makes two important distinctions. The first distinction is between two different notions of rationality, and the second involves two contrasting uses of the "brain" metaphor.
Mechanistic or bureaucratic organizations rely on what Morgan (following Karl Mannheim) calls "instrumental rationality", where people are valued for their ability to fit in and contribute to the efficient operation of a predetermined structure. Morgan contrasts this with "substantial rationality", where elements of organization are able to question the appropriateness of what they are doing and to modify their action to take account of new situations. Morgan states that the human brain possesses higher degrees of substantial rationality than any man-made system. (pp78-79)
Morgan also observes a common trend to use the term "brain" metaphorically to refer to a centralized planning or management function within an organization, the brain "of" the firm. Instead, Morgan wants to talk about brain-like capabilities distributed throughout the organization, the brain "as" the firm. Using the brain metaphor in this way leads to two important ideas. Firstly, that organizations are information processing systems, potentially capable of learning to learn. And secondly, that organizations may be holographic systems, in the sense that any part represents and can stand in for the whole. (p 80)
The first of these two ideas, organizations as information processing systems, goes back to the work of James March and Herbert Simon in the 1940s and 1950s. Simon's theory of decision-making leads us to understand organizations as kinds of institutionalized brains that fragment, routinize and bound the decision-making process in order to make it manageable. (p 81) According to this theory, the organization chart does not merely define a structure of work activity, it also creates a structure of attention, interpretation and decision-making. (p 81) Later organization design theorists such as Jay Galbraith showed how this kind of decision-making structure coped with uncertainty and information overload, either by reducing the need for information or by increasing the capacity to process information. (pp 82-83)
Nowadays, of course, much of this information processing capacity is provided by man-made systems. Writing in the mid 1980s, Morgan could already see the emergence of the virtual organization, embedded not in human activity but in computer networks. If it wasn't already, the organization-as-brain is now indisputably a sociotechnical system. The really big question, Morgan asks, is whether such organizations will also become more intelligent. (p84)
The problem here is that man-made systems (bureaucratic as well as automatic) tend towards instrumental rationality rather than substantial rationality. Such systems can produce goal-directed behaviour under four conditions. (p87)
- The capacity to sense, monitor and scan significant aspects of their environment
- The ability to relate this information to the operating norms that guide system behaviour
- Ability to detect significant deviations from these norms
- Ability to initiate corrective action when discrepancies are detected.
- Division of responsibilities cause a fragmentation of knowledge and attention.
- Bureaucratic accountability and asymmetric information produce ethical problems such as deception. (This is a form of the principal-agent problem.)
- Organizations also suffer from various forms of collective self-deception, resulting in a gap between "espoused theory" and "theory-in-use".
- Encourage and value openness and reflectivity. Accept error and uncertainty.
- Recognize the importance of exploring different viewpoints.
- Avoid imposing structures of action. Allow intelligence and direction to emerge.
- Create organizational structures and principles that help implement these principles.
- Redundancy of function - each individual or team has a broader range of knowledge and skills than is required for the immediate task-at-hand, thus building flexibility into the organization.
- Requisite variety - the internal diversity must match the challenges posed by the environment. All elements of an organization should embody critical dimensions of the environment.
- Minimal critical specification - allow each system to find its own form.
- Learning to learn - use autonomous intelligence and emergent connectivity to find novel and progressive solutions to complex problems.
- The realities of power and control. (p 108)
- The inertia stemming from existing assumptions and beliefs. (p 109)
Saturday, October 23, 2010
Enterprise Structure
#entarch There are some critical structural issues for business organizations, which have critical implications for IT architecture, including generating new requirements for management information systems and collaboration platforms. However, these structural issues arise not from technology alone but from the structural complexity of markets and the business environment, and from the need to manage a complex organization as a viable and dynamic sociotechnical system.
It is perhaps curious that enterprise architects, even those who insist that EA is not just about IT, should be so quick to frame all structural issues in terms of IT architecture. The industry analyst firm Forrester got some stick recently for a list of "Top Ten Issues" that were all technologically oriented.
To understand the complex structural issues of business organizations, we need to look beyond the methods and models derived from computer science and database theory, and draw from such disciplines as systems thinking and management cybernetics. Here are some of the (overlapping) structural themes I have been looking at.
It's not easy to get one's head around some of these structural themes in the abstract, so I'm going to try and produce a series of concrete vignettes showing how these themes play out in specific industry sectors.
It is perhaps curious that enterprise architects, even those who insist that EA is not just about IT, should be so quick to frame all structural issues in terms of IT architecture. The industry analyst firm Forrester got some stick recently for a list of "Top Ten Issues" that were all technologically oriented.
To understand the complex structural issues of business organizations, we need to look beyond the methods and models derived from computer science and database theory, and draw from such disciplines as systems thinking and management cybernetics. Here are some of the (overlapping) structural themes I have been looking at.
- Asymmetrical demand
- Business as a platform
- Coupling (the enterprise as a loosely coupled network of sociotechnical components and services - as in my book on the Component-Based Business)
- Differentiation and integration
- Edge organization
- Enterprise tempo (different activities with different characteristic tempi)
- Ethical dilemmas (conflicts of interest, moral hazard)
- Multi-sided markets (different stakeholder classes with complementary demands)
- Organizational intelligence
- Viability (command and control, VSM)
It's not easy to get one's head around some of these structural themes in the abstract, so I'm going to try and produce a series of concrete vignettes showing how these themes play out in specific industry sectors.
Saturday, May 15, 2010
Differentiation and Integration 2
In my previous post on Differentiation and Integration, I mentioned the Operating Model propounded by Jeanne W. Ross, Peter Weill and David C. Robertson in their book Enterprise Architecture as Strategy (Harvard Business School Press 2006). I shall continue to refer to this book as RWR.
The publisher offers a pdf extract from the book, in which you will see the following diagram, depicting what RWR call a “traditional” approach to IT solutions. (It's a secure pdf, so I've had to scan my library copy instead.)
According to RWR, the “traditional” approach is characterized as follows
Sounds like there is “good integration” and “bad integration”. Which brings us to the squiggles in the diagram. RWR appear to have adopted a notation in which “good integration” is denoted by straight lines and “bad integration” is denoted by squiggly lines. As far as I am aware, this notation has not been not formally defined, and is therefore purely a rhetorical device.
While I accept the need for enterprise architecture to create a powerful strategic narrative, I fear that these rhetorical devices permit and even encourage a kind of woolly uncritical thinking, which is not capable of dealing with the real challenges of enterprise strategy, and could easily be dismissed as intellectually lightweight by sharp CEOs presented with this kind of stuff. Vague diagrams with undefined notation are no substitute for proper analysis.
It doesn't matter how often the three characteristics identified by RWR above are found together, the key question is whether it is possible and practical to separate them. Is data sharing (as RWR believe) the only way to achieve “good integration”, or are (as I believe) other aspects of integration (coordination, organizational intelligence) more strategically important?
Furthermore, both questions seem to be questions of degree ("to what extent") rather than questions of kind (either/or) - so where are the examples of companies whose rightful place is half-way along the path, rather than at one or other extreme?
I find this statement puzzling, because there is no obvious connection between the two dimensions of the operating model identified by RWR (viz standardization and integration qua data sharing) and the idea of competitive differentiation.
There are methods that focus on identifying which business processes will distinguish a company from its competitors, such as the method developed by my former CBDI colleagues out of the ideas of Geoffrey Moore (see my post Tesco Outsources Core ECommerce) but this is not the same as the RWR method.
“A strategic partnership forces a shared-services mentality, requiring business leaders to come to agreement on which services will be provided centrally and which will be provided locally.” (RWR p148)
The decision of which services will be provided centrally or locally is a matter of standardization, and therefore an aspect of enterprise-architecture-as-strategy.
The publisher offers a pdf extract from the book, in which you will see the following diagram, depicting what RWR call a “traditional” approach to IT solutions. (It's a secure pdf, so I've had to scan my library copy instead.)
According to RWR, the “traditional” approach is characterized as follows
- Each strategic initiative results in a separate IT solution, each implemented on a different technology, producing a set of silos.
- The company’s data is patchy, error-prone, and not up-to-date.
- Companies often extract from silos to aggregate data from multiple systems in a data warehouse; but the warehouse is useful only as a reference – it does not offer real-time data across applications.
Sounds like there is “good integration” and “bad integration”. Which brings us to the squiggles in the diagram. RWR appear to have adopted a notation in which “good integration” is denoted by straight lines and “bad integration” is denoted by squiggly lines. As far as I am aware, this notation has not been not formally defined, and is therefore purely a rhetorical device.
While I accept the need for enterprise architecture to create a powerful strategic narrative, I fear that these rhetorical devices permit and even encourage a kind of woolly uncritical thinking, which is not capable of dealing with the real challenges of enterprise strategy, and could easily be dismissed as intellectually lightweight by sharp CEOs presented with this kind of stuff. Vague diagrams with undefined notation are no substitute for proper analysis.
It doesn't matter how often the three characteristics identified by RWR above are found together, the key question is whether it is possible and practical to separate them. Is data sharing (as RWR believe) the only way to achieve “good integration”, or are (as I believe) other aspects of integration (coordination, organizational intelligence) more strategically important?
Contingency Theory
RWR identify two key questions for determining your organization’s strategy.- To determine your organization’s integration requirements, ask yourself to what extent the successful completion of one business unit’s transactions is dependent on the availability, accuracy and timeliness of other business units’ data. (RWR p30)
- To determine your organization’s standardization requirements, ask yourself to what extent the company benefits by having business units run their operations in the same way. (RWR p30)
Furthermore, both questions seem to be questions of degree ("to what extent") rather than questions of kind (either/or) - so where are the examples of companies whose rightful place is half-way along the path, rather than at one or other extreme?
Differentiation
RWR then introduce the notion of strategic differentiation. "The operating model concept requires that management put a stake in the ground and declare which business processes will distinguish a company from its competitors." (RWR p43).I find this statement puzzling, because there is no obvious connection between the two dimensions of the operating model identified by RWR (viz standardization and integration qua data sharing) and the idea of competitive differentiation.
There are methods that focus on identifying which business processes will distinguish a company from its competitors, such as the method developed by my former CBDI colleagues out of the ideas of Geoffrey Moore (see my post Tesco Outsources Core ECommerce) but this is not the same as the RWR method.
Shared Services
One way of achieving some kinds of standardization is through shared infrastructure. When talking about shared services, RWR implicitly shift the scope of “the enterprise” from a single organization to a partnership ecosystem.“A strategic partnership forces a shared-services mentality, requiring business leaders to come to agreement on which services will be provided centrally and which will be provided locally.” (RWR p148)
The decision of which services will be provided centrally or locally is a matter of standardization, and therefore an aspect of enterprise-architecture-as-strategy.
Enterprise Architecture as Quantitative Practice
What I find troubling in many popular accounts of enterprise architecture, including RWR, is the apparent disregard for economics. RWR talk glibly about the costs and benefits of standardization, but they are not willing to explore the economies and diseconomies of scale, or the distribution of fixed and variable costs, and there isn't much meaningful quantification. Handwaving as strategy?Monday, May 10, 2010
Differentiation and Integration
In my post on Business Design Choices, I suggested that the real challenge for business architecture was to appreciate the economic and social impact of structure. I identified some advanced business design choices where business architecture has a useful role to play, and where some IT people might have some relevant aptitude. In this post, I am going to expand on one of these.
Where does standardization make sense, and where should requisite variety be deployed? This question goes back to the work of Lawrence and Lorsch (L2), and has recently been rediscovered (in slightly different terms) by Ross, Weill and Robertson (RWR).
In their book Enterprise Architecture as Strategy, RWR define something they call an Operating Model, with two independent dimensions, business process standardization and integration. "Although we often think of standardization and integration as two sides of the same coin, they impose different demands. Executives need to recognize standardization and integration as two separate decisions." (p27)
Many people in the IT world take for granted that standardization (reduction in variety) is a good thing. RWR acknowledge the benefits of standardization not only in terms of throughput and efficiency, but also predictability. However, they point out the potential downside of standardization both as a state (standardized processes limit local innovation) and as a state-change (politically difficult and expensive to rip out and replace perfectly good and occasionally superior systems and processes).
Integration, which RWR define primarily in terms of data sharing, is also assumed to be a good thing. RWR identify the benefits of integration in terms of efficiency, coordination, transparency and agility, and acknowledge the challenge of integration as a state-change in terms of "difficult, time-consuming decisions".
The two dimensions of standardization and integration produce a two-by-two matrix as follows.
Operating Model Quadrants (Adapted by Clive Finkelstein from Figure 2.3 of “Enterprise Architecture as Strategy”) - Source The Enterprise Newsletter #38.
Although RWR are careful to present a contingency theory of enterprise strategy, in which any of these four operating models may be strategically valid, the conventional rhetoric of the two-by-two matrix places the preferred strategy into the top right quadrant - thus Unification. Many enterprise architects from a traditional IT background may feel most comfortable with the Unification quadrant. (There may be a process of idealization here - see Schwartz.) Indeed, RWR go on to present an Enterprise Architecture Maturity Model, which starts with the easy bits of enterprise architecture (where things are already Unified) and ends with the challenging bits (where things are or should be Diversified).
L2 also identify two dimensions, which they call differentiation and integration. They tend to see increasing differentiation as a healthy response to increasing opportunity and complexity - a growing organization in a growing market - "faster change and greater heterogeneity" (p 235). Differentiation is not merely a difference in working practices, but includes at its core "the difference in cognitive and emotional orientation among managers in different functional departments" (p11).
Integration is then the administrative response to this increasing differentiation - how to maintain the overall coherence and viability of the enterprise as a whole. Integration is defined as "the quality of the state of collaboration that exists among departments that are required to achieve unity of effort by the demands of the environment" (p11). The topic of integration covers both the organizational state and the mechanisms to produce and support this state. For L2, the challenges of integration are not primarily IT related (data sharing) but personal and political (conflict resolution).
L2 don't offer a two-by-two matrix of Differentiation and Integration in their 1967 book (I guess the two-by-two matrix hadn't then established itself as an essential consultancy tool), but if they did then presumably the top-right quadrant would be High Differentiation, High Integration. This very roughly corresponds to what RWR call Coordination.
But in any case, a two-by-two matrix would be misleading. The point isn't to choose whether you have differentiation and integration or not; the point is to determine how much and what kinds of differentiation and integration you need. L2 are explicit in their support of contingency theory (different strategies being appropriate for different organizations depending on environmental factors). The more complex and dynamic the environment, the greater the need for differentiation and integration.
If we are to take business architecture seriously as a discipline, then this kind of question is clearly central. In his post on Contingency Theory and Enterprise Architecture, Andy Blumenthal argues that contingency theory entails keeping your options open, but sometimes it just means making appropriate strategic choices. If the slogan "enterprise architecture as strategy" is to mean anything at all, then surely this is what it means.
Lawrence, P., and Lorsch, J., "Differentiation and Integration in Complex Organizations" Administrative Science Quarterly 12, (1967), 1-30. (see summary here)
Paul R. Lawrence and Jay W. Lorsch, Organization and Environment, Managing Differentiation and Integration. Harvard University 1967.
Jeanne W. Ross, Peter Weill and David C. Robertson, Enterprise Architecture as Strategy. Harvard Business School Press 2006.
Howard S. Schwartz, Narcissistic Process and Corporate Decay – The Theory of the Organizational Ideal. 1990. See his paper On the Psychodynamics of Organizational Disaster (Columbia Journal of World Business, Spring 1987) See also Joe Bormel's blogpost on Narcissism, Oxygen and HCIT Vision (June 2009).
Related posts
Business Design Choices (January 2010)
EA Effectiveness and Process Standardization (August 2012)
Where does standardization make sense, and where should requisite variety be deployed? This question goes back to the work of Lawrence and Lorsch (L2), and has recently been rediscovered (in slightly different terms) by Ross, Weill and Robertson (RWR).
In their book Enterprise Architecture as Strategy, RWR define something they call an Operating Model, with two independent dimensions, business process standardization and integration. "Although we often think of standardization and integration as two sides of the same coin, they impose different demands. Executives need to recognize standardization and integration as two separate decisions." (p27)
Many people in the IT world take for granted that standardization (reduction in variety) is a good thing. RWR acknowledge the benefits of standardization not only in terms of throughput and efficiency, but also predictability. However, they point out the potential downside of standardization both as a state (standardized processes limit local innovation) and as a state-change (politically difficult and expensive to rip out and replace perfectly good and occasionally superior systems and processes).
Integration, which RWR define primarily in terms of data sharing, is also assumed to be a good thing. RWR identify the benefits of integration in terms of efficiency, coordination, transparency and agility, and acknowledge the challenge of integration as a state-change in terms of "difficult, time-consuming decisions".
The two dimensions of standardization and integration produce a two-by-two matrix as follows.
Operating Model Quadrants (Adapted by Clive Finkelstein from Figure 2.3 of “Enterprise Architecture as Strategy”) - Source The Enterprise Newsletter #38.
Although RWR are careful to present a contingency theory of enterprise strategy, in which any of these four operating models may be strategically valid, the conventional rhetoric of the two-by-two matrix places the preferred strategy into the top right quadrant - thus Unification. Many enterprise architects from a traditional IT background may feel most comfortable with the Unification quadrant. (There may be a process of idealization here - see Schwartz.) Indeed, RWR go on to present an Enterprise Architecture Maturity Model, which starts with the easy bits of enterprise architecture (where things are already Unified) and ends with the challenging bits (where things are or should be Diversified).
L2 also identify two dimensions, which they call differentiation and integration. They tend to see increasing differentiation as a healthy response to increasing opportunity and complexity - a growing organization in a growing market - "faster change and greater heterogeneity" (p 235). Differentiation is not merely a difference in working practices, but includes at its core "the difference in cognitive and emotional orientation among managers in different functional departments" (p11).
Integration is then the administrative response to this increasing differentiation - how to maintain the overall coherence and viability of the enterprise as a whole. Integration is defined as "the quality of the state of collaboration that exists among departments that are required to achieve unity of effort by the demands of the environment" (p11). The topic of integration covers both the organizational state and the mechanisms to produce and support this state. For L2, the challenges of integration are not primarily IT related (data sharing) but personal and political (conflict resolution).
L2 don't offer a two-by-two matrix of Differentiation and Integration in their 1967 book (I guess the two-by-two matrix hadn't then established itself as an essential consultancy tool), but if they did then presumably the top-right quadrant would be High Differentiation, High Integration. This very roughly corresponds to what RWR call Coordination.
But in any case, a two-by-two matrix would be misleading. The point isn't to choose whether you have differentiation and integration or not; the point is to determine how much and what kinds of differentiation and integration you need. L2 are explicit in their support of contingency theory (different strategies being appropriate for different organizations depending on environmental factors). The more complex and dynamic the environment, the greater the need for differentiation and integration.
If we are to take business architecture seriously as a discipline, then this kind of question is clearly central. In his post on Contingency Theory and Enterprise Architecture, Andy Blumenthal argues that contingency theory entails keeping your options open, but sometimes it just means making appropriate strategic choices. If the slogan "enterprise architecture as strategy" is to mean anything at all, then surely this is what it means.
Lawrence, P., and Lorsch, J., "Differentiation and Integration in Complex Organizations" Administrative Science Quarterly 12, (1967), 1-30. (see summary here)
Paul R. Lawrence and Jay W. Lorsch, Organization and Environment, Managing Differentiation and Integration. Harvard University 1967.
Jeanne W. Ross, Peter Weill and David C. Robertson, Enterprise Architecture as Strategy. Harvard Business School Press 2006.
Howard S. Schwartz, Narcissistic Process and Corporate Decay – The Theory of the Organizational Ideal. 1990. See his paper On the Psychodynamics of Organizational Disaster (Columbia Journal of World Business, Spring 1987) See also Joe Bormel's blogpost on Narcissism, Oxygen and HCIT Vision (June 2009).
Related posts
Business Design Choices (January 2010)
EA Effectiveness and Process Standardization (August 2012)
Saturday, November 28, 2009
Is Enterprise Architecture a Science? Part 2
@RSessions was in London this week, so I sat down with him to continue our previous discussion Is Enterprise Architecture a Science?
The first question to address is - which enterprise architecture are we talking about? I think we both agree that there are some activities within the EA world that look more like religion or mediaeval scholastic philosophy than empirically verifiable science.
For example, in his post What's Right with the Zachman Framework, Grant Czerepak states that "the architectural metaphor conceals what the six perspectives are actually about: Entities, Relationships, Attributes, Constraints, Definitions and Manipulations". And referring to the Kipling-Zachman lens, Grant claims that "the interrogatives have a foundation that goes back over three thousand years across every human culture". In a separate post, he says It's not Aristotle's fault, it's your fault. See my post Arguing with Mendeleev (March 2013).
Lots of EA frameworks are essentially abstract classification schemes that start from an abstract ontological argument ("obviously all businesses are made of objects" or "obviously all processes are made up of nouns and verbs") and make assertions that are not amenable to empirical verification.
Roger's SIP methodology is at least based on an empirically testable (and quantified) hypothesis. That a system of systems with such-and-such measurable structural qualities (in terms of Roger's definition of complexity) will have such-and-such predictable costs. So this provides the basis for a scientifically-grounded engineering practice. I think SIP methodology has a reasonable claim to be scientifically grounded: it can be evaluated not just on whether its prescriptions are practical, cost-effective and useful, but also whether its predictions are true. (Incidentally, I think it would be interesting to compare SIP with Christopher Alexander's early book Notes on the Synthesis of Form. This contains detailed and mathematically grounded work on architectural complexity: although the software gurus who developed structured methods in the 1970s were aware of Alexander's book, they left out most of the difficult detail.)
I think there is a further step before EA could ever dream of becoming a fully empirical science, and this would involve large-scale collection and analysis of empirical data, so that there would be a closed loop between theory and practice, connecting structure and value. In order to achieve this, we should need the active participation of some of the more powerful players in the EA game - the large consultancies and above all the key government agencies that govern IT expenditure. (You know who you are.) At the moment, there is little sign that these organizations are seriously interested in any game-changing innovation. (Roger and I should be delighted to talk to representatives of these organizations, please contact us.)
The first question to address is - which enterprise architecture are we talking about? I think we both agree that there are some activities within the EA world that look more like religion or mediaeval scholastic philosophy than empirically verifiable science.
For example, in his post What's Right with the Zachman Framework, Grant Czerepak states that "the architectural metaphor conceals what the six perspectives are actually about: Entities, Relationships, Attributes, Constraints, Definitions and Manipulations". And referring to the Kipling-Zachman lens, Grant claims that "the interrogatives have a foundation that goes back over three thousand years across every human culture". In a separate post, he says It's not Aristotle's fault, it's your fault. See my post Arguing with Mendeleev (March 2013).
Lots of EA frameworks are essentially abstract classification schemes that start from an abstract ontological argument ("obviously all businesses are made of objects" or "obviously all processes are made up of nouns and verbs") and make assertions that are not amenable to empirical verification.
Roger's SIP methodology is at least based on an empirically testable (and quantified) hypothesis. That a system of systems with such-and-such measurable structural qualities (in terms of Roger's definition of complexity) will have such-and-such predictable costs. So this provides the basis for a scientifically-grounded engineering practice. I think SIP methodology has a reasonable claim to be scientifically grounded: it can be evaluated not just on whether its prescriptions are practical, cost-effective and useful, but also whether its predictions are true. (Incidentally, I think it would be interesting to compare SIP with Christopher Alexander's early book Notes on the Synthesis of Form. This contains detailed and mathematically grounded work on architectural complexity: although the software gurus who developed structured methods in the 1970s were aware of Alexander's book, they left out most of the difficult detail.)
I think there is a further step before EA could ever dream of becoming a fully empirical science, and this would involve large-scale collection and analysis of empirical data, so that there would be a closed loop between theory and practice, connecting structure and value. In order to achieve this, we should need the active participation of some of the more powerful players in the EA game - the large consultancies and above all the key government agencies that govern IT expenditure. (You know who you are.) At the moment, there is little sign that these organizations are seriously interested in any game-changing innovation. (Roger and I should be delighted to talk to representatives of these organizations, please contact us.)
Tuesday, October 21, 2008
Timeless Way 2
Excellent report from James Governor (Redmonk) on SAP's view of Timeless Software, and I am very glad to see Stewart Brand's work getting wider exposure. See also Nick Hortovanyi.
But I am puzzled at SAP's use of the word "timeless". This was apparently introduced by SAP CTO Vishal Sikka (via Mark Finnern) Vishal explains it further in the comments to James's blog.
Note also this quote from Barry Boehm's magisterial View of 20th and 21st Century Software Engineering (pdf) (via Andrew Newman)
This is certainly consistent with material that has been coming out of SAP for many years about the stratification of business. See my review of Shai Agassi's talk on Achieving Enterprise Agility from 2004. At that time, Shai was talking about some really interesting ideas in this area that I wasn't hearing from any of the other major vendors. It is good to see that SAP is still pushing some of these ideas.
But I am puzzled at SAP's use of the word "timeless". This was apparently introduced by SAP CTO Vishal Sikka (via Mark Finnern) Vishal explains it further in the comments to James's blog.
"I have indeed coined the phrase timeless software to refer to our strategy of continuously evolving our software ... [and allowing for] constant and furious change across all layers of the technology stack."What is timeless here is not the software itself but the process of continuous evolution. I have previously used the term "timeless software" to mean something closer to the original work of Christopher Alexander on the Timeless Way of Building. (See posts by Dion Hinchcliffe and myself from March 2006 )
Note also this quote from Barry Boehm's magisterial View of 20th and 21st Century Software Engineering (pdf) (via Andrew Newman)
The theory underlying software process models needs to evolve from purely reductionist “modern” world views (universal, general, timeless, written) to a synthesis of these and situational “postmodern” world views (particular, local, timely, oral)In other words, Boehm is contrasting the timeless and the situated, and calling for a synthesis of both. I think the Brand notion of shearing layers (or pace layering as he is now calling it) allows us to get the best of both worlds - BOTH timeless AND situated. The "timeless" has a very slow pace of change, while the "situated" is much more dynamic. See my post on Lightweight Enterprise.
This is certainly consistent with material that has been coming out of SAP for many years about the stratification of business. See my review of Shai Agassi's talk on Achieving Enterprise Agility from 2004. At that time, Shai was talking about some really interesting ideas in this area that I wasn't hearing from any of the other major vendors. It is good to see that SAP is still pushing some of these ideas.
Footnote
As my regular readers will know, I've been talking about Brand's book for many years, and I note the emergence of the term pace layering for Brand's principle that stratification should be based on the differential rate of change. See Long Now Blog. I previously referred to this principle as "shearing layers", but this refers to what happens when this principle is not followed.Friday, January 05, 2007
SOA Algebra
How do we reason about services and SOA? In particular, how do we reason about composition and decomposition?
One important type of reasoning involves the ability to think numerically. For example:
Algebra is the branch of mathematics that deals with structure, relation and quantity. The word Al-Jabr is the arabic for reunion - in other words composition. This is therefore the form of reasoning that formalizes and quantifies the composition and decomposition of separate elements. Algebra tells us when it is safe to use addition and multiplication, and when we need something more sophisticated.
For example, if artefact A is composed from components {A1, A2, ..., An}, then the reliability of A is some algebraic function of the reliability of the components A1 to An. Conversely, if you have a requirement for a given level of reliability, you need some algebraic function to decompose this requirement into an equivalent set of sub-requirements.
In an earlier post on Reliability and Availability, I took issue with a vendor white paper, which assumed that all you have to do is multiply the parts to get the whole. This is obviously only true if you make some fairly simplistic assumptions about the composition structure, and is not true in the general case.
Meanwhile, Jeff Schneider takes issue with a confusing formula of SOA costs proposed by Dave Linthicum, which apparently involves adding different kinds of complexity.
If people are getting into these difficulties, where is the SOA algebra to haul them back onto solid ground? I spoke to a friendly professor (Bashar Nuseibeh), who advised me that the formal theory of composition is not advanced enough to support precise quantification. He referred me to some of the work he has been doing with Michael Jackson and others on formalizing composition.
But if I can't have precise, I'll settle for approximate. Surely anything would be better than the algebraic fallacies and muddle currently in circulation?
R. Laney, L. Barroca, M. Jackson, and B. Nuseibeh , Composing Requirements Using Problem Frames , Proceedings of 12th IEEE International Requirements Engineering Conference (RE'04), Kyoto, Japan, 6-10 September 2004 (PDF).
Wikipedia: Algebra
One important type of reasoning involves the ability to think numerically. For example:
- If service A costs $x to maintain, and service B costs $y to maintain, how much does it cost to maintain A+B?
- If service A has an availability of 95%, and service B has an availability of 98%, what is the availability of A+B?
Algebra is the branch of mathematics that deals with structure, relation and quantity. The word Al-Jabr is the arabic for reunion - in other words composition. This is therefore the form of reasoning that formalizes and quantifies the composition and decomposition of separate elements. Algebra tells us when it is safe to use addition and multiplication, and when we need something more sophisticated.
For example, if artefact A is composed from components {A1, A2, ..., An}, then the reliability of A is some algebraic function of the reliability of the components A1 to An. Conversely, if you have a requirement for a given level of reliability, you need some algebraic function to decompose this requirement into an equivalent set of sub-requirements.
In an earlier post on Reliability and Availability, I took issue with a vendor white paper, which assumed that all you have to do is multiply the parts to get the whole. This is obviously only true if you make some fairly simplistic assumptions about the composition structure, and is not true in the general case.
Meanwhile, Jeff Schneider takes issue with a confusing formula of SOA costs proposed by Dave Linthicum, which apparently involves adding different kinds of complexity.
If people are getting into these difficulties, where is the SOA algebra to haul them back onto solid ground? I spoke to a friendly professor (Bashar Nuseibeh), who advised me that the formal theory of composition is not advanced enough to support precise quantification. He referred me to some of the work he has been doing with Michael Jackson and others on formalizing composition.
But if I can't have precise, I'll settle for approximate. Surely anything would be better than the algebraic fallacies and muddle currently in circulation?
R. Laney, L. Barroca, M. Jackson, and B. Nuseibeh , Composing Requirements Using Problem Frames , Proceedings of 12th IEEE International Requirements Engineering Conference (RE'04), Kyoto, Japan, 6-10 September 2004 (PDF).
Wikipedia: Algebra
Subscribe to:
Posts (Atom)