What is a framework?

The term "framework" is much abused. Here's a statement picked at random from the Internet:

"By bringing these key aspects together on a process-oriented strategy, organizations are able to acquire agility and improve the ability to engage on a much more effective way. This translates into a solid, resilient and innovative framework that drives the ability to continuously improve and assure sustainability."

Does that actually mean anything? What does it take for a "framework" to be simultaneously solid and resilient, let alone innovative?

If you take a random set of concepts - social, mobile, analytics, cloud, internet of things - you can string the initial letters into a slightly suggestive acronym - SMACIT. But have you got a framework?

And if you take a random set of ideas and arrange them artistically, you can create a nice diagram. But have you got a framework, or is this just Methodology by PowerPoint?

Most diagrams are just lists in boxes circles and hexagons arranged to imply the geometry contains some relevant information - and obscure the arbitrary selection of item in the list.

— ricphillips (@ricphillips) February 27, 2019

Meanwhile, Cameron Tokinwise notes a tendency to force-fit frameworks into a neat pattern.

how many otherwise useful conceptual frameworks have weak extra terms/components added so that the whole can then can be turned into a 2x2, or circle with 6, 8 or 12 segments, or comply with the rule of 3?

The fallacy of pathetic formalism

— cameron tonkinwise (@camerontw) April 12, 2021

I just did an image search for "framework" on Google. Here are the top ten examples. Pretty typical of the genre.

In 1987, John Zachman published an article in the IBM Systems Journal, entitled "A Framework for Information Systems Architecture", hypothesizing a set of architectural representations for information systems, arranged in a table. The international standard ISO/IEC 42010 defines an architectural framework as any set of architectural descriptions or viewpoints satisfying certain conditions, and the Zachman Framework is usually cited as a canonical example of this, along with RM/ODP and a selection of AFs (MOD, DOD, TOG, etc.). 

But there are a lot of so-called frameworks that don't satisfy this definition. Sometimes there is just a fancy diagram, which makes less sense the more you look at it. Let's look at the top example more closely.

The webpage asserts that "the summary graphic illustrates the main relationships between each heading and relevant sub-headings". Sorry, it doesn't. What does this tell me about the relationship between Knowledge and Governance? If Advocacy is about promoting things, does that mean that Knowledge is about preventing things? And if Prevent, Protect and Promote are verbs, does this mean that People is also a verb? I'm sure there is a great deal of insight and good intentions behind this diagram, but the diagram itself owes more to graphic design than systems thinking. All I can see in this "systems framework" is (1) some objectives (2) a summary diagram and (3) a list. If that's really all there is, I can't see how such a framework "can be used as a flexible assessment, planning and evaluation tool for policy-making".

For clarification, I think there is an important difference between a framework and a lens. A lens provides a viewpoint - a set of things that someone thinks you should pay attention to - but its value doesn't depend on its containing everything. VPEC-T is a great lens, but is Wikipedia right in characterizing as a thinking framework?

---

Commonwealth Health Hub, A systems framework for healthy policy (31 October 2016)

Filipe Janela, The 3 cornerstones of digital transformation (Processware, 30 June 2017)

Anders Jensen-Waud, On Enterprise Taxonomy Completeness (9 April 2010)

John Zachman, A Framework for Information Systems Architecture (IBM Systems Journal, Vol 26 No 3, 1987).

Wikipedia: ISO/IEC 42010, VPEC-T

Related posts: What's Missing from VPEC-T (September 2009), Evolving the Enterprise Architecture Body of Knowledge (October 2012), Arguing with Mendeleev (March 2013)


Updated 28 February 2019, 12 April 2021
Added tweets by @ricphillips and @camerontonkinwise. See discussion following. I also remembered an old discussion with Anders Jensen-Ward.

Enterprise Architecture as Science?

It is common to describe Enterprise Architecture as a science. Here are a few examples.

• ... the evolving science of Enterprise Architecture ... (Center for Enterprise Architecture, Penn State University)

• We see enterprise architecture (EA) as a scientific sub-discipline both of computer science and business management. The twice mentioned word “science” here emphasizes our certainty that EA is an exact discipline able to produce precise approaches and solutions. Wolf Rivkin, Enterprise Architecture and the Elegant Enterprise (Architecture and Governance 5-3)

• At iCMG, we have proven beyond doubt that “Enterprise Architecture is a scientific basis for creating, maintaining and running an Enterprise". Sunil Dutt Jha, Biggest myth - “Enterprise Architecture is a discipline aimed at creating models” (Architecture World, January 2013)

A few years ago, I discussed this question with @RSessions

• Is Enterprise Architecture a Science? (July 2009)
• Is Enterprise Architecture a Science (2)? (November 2009)

Roger is one of the few people I know who is seriously committed to empirical investigation of EA. I believe he shares my view that much EA falls woefully short of anything like scientific method. To my eye, many knowledge-claims within the EA world look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

But why does it matter anyway? Why would people be so keen to claim EA as a science? Here is what Foucault had to say to those who wished to claim Marxism (or psychoanalysis) as a science.

"When I see you trying to prove that Marxism is a science, to tell the truth, I do not really see you trying to demonstrate once and for all that Marxism has a rational structure and that its propositions are therefore the products of verification procedures. I see you, first and foremost, doing something different. I see you connecting the Marxist discourse, and I see you assigning to those who speak that discourse the power-effects that the West has, ever since the Middle Ages, ascribed to a science and reserved for those who speak a scientific discourse." Michel Foucault, Society Must be Defended: Lectures at the Collège de France, 1975-76 (English translation by David Macey, 2003)

In other words, claiming EA as a science is not about the rational basis for its knowledge-claims but about its authority, or what Foucault (in David Macey's translation) calls Power-Effects. Thus instead of claiming EA as a science, one might follow Gartner in claiming EA as a discipline.

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. EA is used to steer decision making toward the evolution of the future state architecture. (Gartner website, retrieved 17 August 2013)

Foucault characterizes a discipline in terms of the selection, normalization, hierarchicalization and centralization of knowledge. We can surely recognize these processes in the formation and maintenance of EA frameworks such as TOGAF and PEAF, as well as various attempts to construct Bodies of Knowledge. Foucault notes that "the progress of reason" necessitates "the disciplinarization of polymorphous and heterogeneous knowledge". This might lead us to expect some institutional resistance to heterodox ideas, as well as the marginalization of "amateur scholars".

Foucault is interested in ways that people and organizations can respond to disruptive forces large and small, from "great radical ruptures, massive binary divisions" to "mobile and transitory points of resistance, producing cleavages in a society that shift about, fracturing unities and effecting regroupings".

Just as the network of power relations ends by forming a dense web that passes through apparatuses and institutions, without being exactly localized in them, so too the swarm of points of resistance traverses social stratifications and individual unities. And it is doubtless the strategic codification of these points of resistance that makes a revolution possible. [Michel Foucault, History of Sexuality Vol 1.]

Gartner's notion of EA-as-discipline seems quite consistent with this. It is focused on mobilizing the response to disruptive forces (for which Gartner uses the rather strange word "nexus"). EA gains its power from a kind of strategic codification (or discursive practice), allowing the enterprise to "harness the nexus", thereby "revolutionizing business and society, disrupting old business models and creating new leaders". (Gartner website, retrieved 17 August 2013)

---

Update

@tetradian commented on the dangers of spurious 'authority' - 'spurious' in sense of claiming an aura of 'authority' when there's none to be had (b/c it isn't 'science' anyway)

I agree that claims of scientific status or method in the EA world are generally spurious. But there are other ways of asserting authority. For me, the key question is why (and on what grounds) should anyone trust the pronouncements of EA. It is not just about danger versus safety, but about authority versus authenticity.

Danish metamodels

My Danish friends @gotze and @aojensen comment on the latest release of OIO EA, which is a national enterprise architecture framework and meta-model published by the Danish Government Agency for Digitization.

Both John and Anders feel that certain key artefacts have been placed at the wrong layer of abstraction. John writes

"In my view, Business Rules should not be located at the strategic level at all. I would argue that Business Rules primarily “belongs” to the Business sub-architecture domain."

What is the basis for this argument? Anders points out a consequence

"business rules are located in the government strategy layer and thus tightly coupled to the long term vision of the government agency"

"Business rules are operationalisations of the long term strategy and strategic intent.
Whilst the vision, mission, and purpose of the enterprise do not change very often (i.e. provide the best available services our citizens), the business rules and processes involved in realising this will definitely change."

and therefore

"Business rules belong in the business architecture."

Thus Anders is basing his argument on a statement about the frequency of certain classes of change.

This statement appears to be empirically testable, although I know from my own experience that it is a lot difficult than one might think to gather data to test this kind of statement.

Part of the problem of measuring rates of change is that we don't have a particularly robust theory of change in the first place. Let's look at an example. From time to time, perhaps every year, Steve Ballmer restates the vision of Microsoft. Obviously he doesn't use exactly the same words every year. And of course Microsoft-watchers will seek to interpret even the slightest change of wording or emphasis as a sign of a strategic change in direction. So even if Ballmer himself insists that the vision hasn't changed, we might not believe him. Looking back in time, we might find that major changes in direction had already been hinted at in previous years. So at what point does an apparently minor change in wording become a substantially new vision?

Conversely, when a company has been exposed as unethical, the CEO will go public with an apology and an assertion of a new ethical vision. (Recent example: Barclays Bank.) We might not believe him either.

In both cases, we will probably judge whether there is a new vision or not by observing whether the company behaviour and rules changes or not. (And this is not just external observers - Microsoft and Barclays employees and managers are also making these judgements.) So the rate of change of vision might be epistemologically indistinguishable from the rate of change of behaviour.

However, despite the difficulties in conceptualizing and measuring change, I think it does make sense to derive architectural layers from the idea that certain things have a characteristic rate of change, and that things with a different rate of change should be in different layers. This means that there is at least a possibility of subjecting an architecture to empirical evaluation. I have published this idea in articles for the CBDI Forum, and suggested that architectural theory needs to be based on the Pace Layering principle

In contrast, Anders' appeal to the IAF seems to be purely an argument from authority. The IAF establishes some "fundamental" categories, and so any framework that deviates from these categories must be wrong. I think this line of argumentation is weaker. Even though you may assert some attractive consequences of following IAF, I cannot see any reason for believing that these consequences follow only from IAF and not from any rival framework.

Frameworks and categories may be embedded in metamodels. But how do we know what is the basis for choosing between alternative metamodels?


John Gøtze, Metamodels (January 2013)
Anders Ø. Jensen, Enterprise Architecture and abstraction layers (February 2013)

Ethics, Barclays and totalitarianism (Catholic Commentary January 2013)
Barclays boss tells staff 'sign up to ethics or leave' (BBC News January 2013)
Did Barclays suffer an Ethics Meltdown? (CSR Zone, July 2012)
Sure Kamhunga, Barclays to re-examine its core values (October 2012)
Naven Johal, Barclay’s Does Something Right! (January 2013)

Updated 29 April 2013

Arguing with Mendeleev

@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

Evolving the Enterprise Architecture Body of Knowledge

#entarch #EABOK There is a considerable "body of knowledge" in the enterprise architecture world. Among other things, this includes

• Founding documents that everyone references, such as Zachman's 1987 paper for the IBM Systems Journal, and the MIT book on Enterprise Architecture as Strategy.

• Various summaries and guides to the body of knowledge. Mitre produced a guide to the (evolving) EA body of knowledge around 2004 (known as EABOK), and there is a bunch of people currently trying to produce a new version of the EABOK. The BCS has published a Reference Model for Enterprise and Solution Architecture, which it uses as the basis for its architecture certification.

• Some standards, such as ISO/IEC 42010 and RM/ODP.

• Various frameworks that package this knowledge into some kind of semi-formal structure, such as TOGAF and DODAF/MODAF, as well as the Zachman framework. The Federal EA framework is incorporated into US law via the Clinger-Cohen Act.

• Various tools that encapsulate portions of this knowledge.

• Some attempts to formalize and ground this knowledge. There is some interesting work in the defence community to produce an EA ontology (MODEM) to replace the existing MODAF/DODAF metamodel. Meanwhile, there is a growing academic literature, much of it from the Netherlands for some reason.

• Huge amounts of commentary and proposed additions/revision by individual authors and bloggers. There is also a considerable admixture of insight and obfuscation from the large consultancies and analyst firms.

The body of knowledge as a whole can be understood as a set of definitions ("this is what we shall call a business function"), assertions and observations ("loosely coupled structures are more flexible"), instructions/injunctions ("always agree your principles before planning your systems"), and examples (mostly artificial or anecdotal), together with a bunch of rather spurious or irrelevant claims ("this is a mathematically proven technique", "this classification was invented by the ancient Greeks", "this is what everybody means by 'complexity' "). The body of knowledge also relies significantly on some terms that usually remain undefined, such as "alignment".

This body of knowledge as a whole has been subject to a number of criticisms.

• It is incomplete, inconsistent, imprecise, muddled, simplistic.

• It is impractical, fails to deliver value, not fit for purpose (however that purpose may be understood).

• It carries a hidden ideological agenda (which conveniently suits the commercial interests of the large software and IT services companies).

• It lacks a proper base of empirical evidence - much of the knowledge is received wisdom and rehashed fragments from other sources.

• It relies on "subject matter experts", who often have no experience or training in knowledge research and are merely trading their own preconceptions.

In response to these perceived flaws in the collective body of knowledge, many EA practitioners espouse a personal body of knowledge, which is smaller and hopefully more consistent than the conventional/collective body of knowledge. This personal body of knowledge is often presented explicitly as an alternative to the conventional body of knowledge, for example rants against TOGAF or Zachman. However, personal bodies of knowledge are not immune from the same criticisms, and often suffer from methodological syncretism.



How has the collective body of knowledge been developed and validated? Typically a combination of the following

• This is what everybody knows.
• This is what every good architect knows.
• Here's an interesting new idea, so let's bung it in somewhere.
• Our customers like it, so it must be right.
• This bit of TOGAF is obviously rubbish, so let's chuck it away and put something else in its place.

Imre Lakatos said that a research programme can be progressive or degenerative. A progressive research programme is one that enhances the explanatory or predictive power of a body of knowledge. (For example, the development of new medical knowledge is progressive if and only if it clearly contributes to more effective healthcare.) A degenerative research programme is one that merely adjusts the body of knowledge to explain away inconvenient results. (Hubert Dreyfus has argued that AI was a degenerative research programme, because it ran into unexpected problems it could not solve.) I have frequently observed that much of EA looks more like mediaeval scholasticism (taxonomy for the sake of taxonomy) than modern science.

I know that some of the readers of this blog aspire to push forward the EA body of knowledge in various ways, including the next version of TOGAF and the replacement EABOK - so my challenge to you guys is this: How are you making sure that your work is progressive and evidence-based?


Further discussion in comments below ...

---

Related posts

Methodological Syncretism (December 2010), Arguing with Mendeleev (March 2013), From Information Architecture to Evidence-Based Practice (April 2013), Towards Next Practice EA (May 2013), Enterprise Architecture as Science (August 2013), What is a Framework (February 2019)

eBook: Towards Next Generation Enterprise Architecture


Links added 2 February 2019

Is there a place for LOCATION in Business Architecture?

#bizarch #entarch Most enterprise architecture frameworks put LOCATION into the business architecture domain. So am I merely being contrarian when I ask whether it really belongs there?

My first point is that some IT people may regard the business architecture domain as a dumping ground for anything that doesn't belong anywhere else. For example, TOGAF 9.1 includes a skills matrix and set of job descriptions in the business architecture (Chapter 8), and I found a framework called Lite EA that includes staff demographics. There is perhaps an idea that the business architecture includes all non-IT aspects of the solution architecture, including physical processes as well as human activity.

My second point is that business architecture doesn't just mean a complete collection of business-oriented IT requirements. Maybe some of the staff work from home on Fridays, and this has some important implications for IT systems and infrastructure, including security. However, people sometimes working from home does not affect the structure and behaviour of the business, so it's not really business architecture.

My third point is that a lot of these frameworks have evolved from earlier work, dating from an era when geography was (a) more significant and (b) more straightforward.

My fourth point is that there are some aspects of geography that may be indirectly relevant to business architecture. For example, the concept of jurisdiction - which set of laws and taxes apply to a given asset or transaction - although large firms employ armies of lawyers and accountants to quibble such matters. And many organizations define responsibilities semi-geographically - for example, which country manager or regional manager owns a given asset or transaction. However, these are often complicated by cross-border arrangements, especially between global enterprises, and cannot be automatically derived from geographical location. Even if we are interested in geography in the business architecture domain, it serves primarily as a classification rather than a set of elements.

My final point is that physical location belongs to an entirely different domain, which I want to call Physical Architecture, which might include office facilities, storage facilities, transport links, and suchlike. These are clearly necessary for the implementation of a particular solution to a geographically distributed business process, just as the computing and communication facilities are, but they aren't part of the business architecture.

---

This post has prompted two questions on Twitter.

Eric Stephens asked Are locations/buildings just tech? My answer: pretty much, yes. Le Corbusier said that a house was a machine for living in.

Alex Matthews asked Are you also going to separate time as a domain? My answer: I see neither time nor space as architectural domains, but as dimensions affecting one or more architectural domains. Clearly time affects several domains. The argument here is whether the business architecture domain is significantly affected by the spatial dimension. I don't think it is.

Frameworks and skills

Here's an interesting comment from a newsgroup

"More seriously, this is an areas rife with confusing and badly understood terminology - I should know, I've been using it for a couple of decades. In context I was referring to the bits and pieces bought for ASTOR, but in reality the actual system (or should that be system of systems ?) goes far wider. This is why the MoD have bought into MODAF so heavily, unluckily they lack staff with the intellectual horsepower or systems engineering / architecting skills to use it properly." [July 2009]

In other words, the outcome isn't solely determined by the framework, but depends on a combination of framework and skill. Some frameworks may demand greater architectural skill than others.

The Kipling-Zachman Lens

The Kipling-Zachman lens from Richard Veryard