Been having a fairly intense (but good 🙂 ) discussion on the LinkedIn Enterprise Architecture group, about standard economics and its impact on enterprise architecture. This is one of the many side-threads popping up off Kevin Smith’s now long-running discussion on “EA is not the glue between IT and ‘The Business’, EA is the glue between strategy and execution”. I don’t know whether this set of posts from various participants will make much sense to anyone else, but it seems worthwhile to post it where others can see it if they wish.
(Note that I’ve done a small amount of editing of the original posts by trimming and snipping [‘…’] and, in one case, concatenating posts from the same person. I believe I’ve kept the sense intact in each case, but if not, please let me know straight away? Thanks.)
For me, in this case, the start-point was a post by Harold ‘Hal’ Stull:
When in doubt I always think Econ 101. An organization manages three resources (capital, labor, and material) to produce a product. If a customer pays more for the product more than the value of the resources consumed, the company shows a profit for its risk and will continue operating. As an architect of any kind, I have to discover the “Who, what, when, how, where, and why” of the client’s operation and add something that may possibly increase the perceived value of the product to his customer or reduce the resources needed to produce it.
I also try to stay away from absolutes: Truth, Best, Optimum, Consistent, etc. I can do a whole lot with organizational and interface symantics. I would never say “ontology” in front of a client, but being able to work with higher abstractions helps me choose and squeeze value from tool kits. (But I see there is another thread for that topic).
As you’d probably guess, given some of the other posts on this weblog (such as ‘Economics: the worst term-hijack ever?’), I kind of jumped at Hal’s comment about “When in doubt I always think Econ 101.”:
Hmm. That assumes that ‘Econ 101’ makes sense and works in the real world, which it doesn’t. That’s the problem.
You say: “An organization manages three resources (capital, labor, and material) to produce a product.”
The answer would be “Sort-of…”. More accurately, Econ 101 treats all of those items (including non-financial capital, such as conceptual and/or social capital) as ‘possessable objects’ that are the ‘property’ or ‘possession’ of an individual or of an organisation-as-corporate-person. Unfortunately this would take a long post to explain, but in essence the ‘possession’-based concept of economics is a parasitic overlay on the actual economy, which operates on mutual-responsibility rather than possession. The quickest summary is that Econ 101 is inherently dysfunctional and inherently unsustainable: so if we’re to build an enterprise-architecture that will work for an organisation, we need to focus on the responsibility-based economy behind the possession-based delusions of Econ 101, and not allow ourselves to be distracted by those delusions.
To give one very quick example, most conventional ‘business-models’ that I’ve seen assume a very simple Econ 101 market-sequence of:
attention (via advertising) > transaction (via sales) > profit
For enterprise-architecture, we need to deal with a much broader range (e.g. including non-active stakeholders [e.g. government, community, non-clients] and also anti-clients and others who are active participants but who are not involved in sales-transactions), and a much more complex market-sequence, such as:
reputation > trust > respect > attention > conversation > relationship > transaction [ > profit] > reputation > …
We also need to understand that ‘the enterprise’ is not the same as ‘the organisation’: an organisation is bounded by rules, roles and responsibilities (e.g. legal responsibilities), whereas an enterprise is bounded by vision, values and commitments (see my presentation ‘What is an enterprise?‘)
True, an organisation is a type of enterprise, but for most enterprise-architecture the relevant enterprise is typically at least three steps larger in scope than that of the organisation in scope. (We develop an architecture about an enterprise for an organisation.)
Using the assumptions of Econ 101 will guarantee that we will deliver an ‘enterprise’-architecture that will fail in the longer term. To build an architecture that works, we must think wider than that.
Like perhaps most business-oriented architects, Harold was clearly doubtful:
I’m a practical guy. “Econ 101” is a paradigm I use for analysis. It fits the way businesses operate and helps ground clients in terms they understand. …
I can use analysis patterns like “Econ 101” and others to check the Business Plan for completeness and consistency. Does that mean that “Econ 101” is true, right or real? No, it’s just useful.
JD Beckingham jojned in with a similar comment that suggested that, as in another lengthy discussion on values-architecture that I’d had on LinkedIn some months back, he thought I was somehow arguing for what a more equitable economics or suchlike, and wanting to impose that view on business-organisations:
Normative economic philosophy is a fascinating topic for discussion and speculation. (Wikipedia – “Normative economics is that part of economics that expresses value judgments (normative judgments) about economic fairness or what the economy ought to be like”)
I have to do the best I can for my employers and clients in an economic milieu which is grounded in free-enterprise economic competition. In order to survive and prosper they need to create sustainable competitive advantage by all the means available to them.
As an EA working within the context of the existing competitive economic milieu, I need to understand how best to advise on effective business strategy; and how to create the business architectures, technology architectures, and enterprise cultures necessary sustainable competitive advantage.
Guess that makes me ‘practical guy’ and an adherent to Econ 101.
To me, that reference to ‘normative economic philosophy’ indicated that he’d missed the point completely – after all, I’m an architect, not a politician! – and that we need to keep the focus on the architecture:
Why on earth do you think I’m talking about ‘normative economic philosophy’ when I say that Econ101 doesn’t work? (This isn’t the first time this has happened – I remember I ran into a similar loop with Cliff Berg and others a while back.)
I’m not saying Econ101 is ‘bad’ or ‘good’ (i.e. value-judgements), I’m saying it doesn’t work. Yes, it has its own logic: but as with all (or most?) formal theory, its logic is based on a series of assumptions (‘premises’), and for the purposes of its reasoning, it must assume that those premises are correct. “Given those assumptions, then this must be true”, etc etc. But it cannot test those assumptions within itself – that’s the nature of logic. (If you do try to use a logical model in bootstrap fashion to test its own assumptions, what you get is the fundamental logic-error of circular-reasoning – which is very common in e.g. IT-centric ‘enterprise’-architectures.)
To test Econ101 in the real world, we first have to put aside the assumption that it is ‘the truth’, and then look very carefully at the context of those assumptions. I’m not going to go into detail (“hooray!”, they say? 🙂 ), but in essence it turns out that its assumptions only work – in other words, give meaningful, complete and valid predictions – in a very narrow subset of a possession-based economy, which itself is a subset of the actual economy, which in turn is easiest understood as based on mutual interlocking responsibilities. In other words, Econ101 is a term-hijack – much like IT-centric ‘enterprise’-architecture is a term-hijack.
We here all know the dangers of building an architecture for an entire enterprise that assumes that the IT is the sole reason for that enterprise to exist: well, it’s the exact same that happens when you build an enterprise model on Econ101. It’s wrong – very wrong – but only in the sense that it doesn’t work.
Econ101 is a subset of a subset pretending that it’s the whole: there’s no way that it can possibly work well. You can only make it seem to work by shoving everything not-Econ101 into a ‘it doesn’t matter therefore it doesn’t exist’ basket – much like most so-called ‘business-architecture’ is treated in IT-centric ‘enterprise’-architecture. (In economics, the technical term for this is ‘externalities’.) Again as with IT-centric architecture, it”s a crude kludge that’s sort-of worked up until now, which is why many folks delude themselves into thinking that it works. But the catch, right now, is that there are a whole bunch of reasons why this is starting to fall apart, not just in the wider societal context but within organisations and their business-models as well. (Details available if you want them, but probably best not here? 🙂 ) Which means that we have to design our enterprise-architectures on the knowledge that Econ101 doesn’t work.
That’s what I’d aimed to explain with the difference between the two views of the ‘market sequence’, for example. Econ101 shows an oversimplified subset that shows where the direct profit-figures come from. But if you design based on that subset (as many people do) you end up with something that doesn’t work, but have no means to explain why. To design something that does work, you need to understand the whole market-sequence – even though the visible parts of your design may in practice act only on the Econ101 subset.
Yes, I’m ‘a practical guy’ too: and it’s true that most people believe (or want to believe?) that Econ101 works, even though we know it doesn’t. So we do exactly what we’ve always done: we lie. 🙂 Or rather, we give those clients a palatable subset of the truth, something that ‘makes sense’ etc – just like we’ve always done with all the other parts of the architecture. (For example, don’t show executives a bunch of BPMN diagrams if you don’t want to be laughed out of the room…) But we don’t make the mistake of believing that that subset is the whole truth of the architecture.
That’s all that I’m saying: nothing more ‘normative’ than that – okay?
Whilst I was writing that post, Ron Segal posted another comment, essentially lining up with Hal and JD on the ‘practical guy’ theme:
Hal, your description of the use of Econ 101makes sense to me, particularly having been involved in startups, where the initial concern is simply to get the lights switched on. Reminds me of the scenario experiment we ran in another discussion, where we were trying to get a consensus on the ‘core’ scope of business architecture, which was based around identifying the chapter headings of a startup manual for a car hire business.
And Hal did at least leave us with: ‘Does that mean that “Econ 101” is true, right or real? No, it’s just useful.’ Which might also be interpreted as your ‘crude kludge’.
To me, yes, this is all well and good, but it still misses the point about the dangers of relying too much on the ‘Economics 101’ paradigm, and that although on the surface we may have to pretend that we’ve held to that paradigm, beneath the surface the architecture must be based on something more real:
This is actually a really good illustration of the difference between business-architecture and (whole-of)-enterprise-architecture, and why it’s essential not to treat them as the same.
In a business-architecture we probably do need to assume (or pretend, rather) that Econ101 is correct and complete, because that’s the basis on which most of the business operates. Hence, to use Hal’s example, we model in terms of capital, material and labour.
(To go back to another long-running discussion with Cliff Berg and others, here we would probably also have to pretend that the only reason that that business exists is to provide returns to its stockholders. It’s really important, even in business-architecture, to recognise that it is only a pretence, a delusion, and to remember to build the architecture in accordance with the more nuanced reality that does work, e.g. around enterprise-scope vision and values rather than solely on organisation-centric business-imperatives.)
But at the enterprise-architecture level – in other words, the architecture of the entirety of the context in which the business operates – Econ101 does not work: its assumptions are based on a subset of a subset of a functioning economy. For example, Econ101 assumes that everything can be described in monetary terms; at the enterprise-level it’s really obvious that we can’t – and if we do attempt to do so, we again create a model that has all sorts of ‘inexplicable’ problems that seemingly cannot be resolved, because the drivers for those problems are actually outside of the scope of Econ101’s assumptions. It’s only possible to make Econ101 seem to work if we run it as a pyramid-game, a Ponzi-scheme – and the blunt fact is that although that’s how it’s been run for the past five thousand years or so, we ran out of room at the base of the pyramid somewhen in the mid-20th century, and right now the whole thing is coming apart at the seams. Enterprise-architectures that fail to take these kinds of facts into account cannot work, certainly in the longer term: it’s as simple as that.
Okay, we now come back to the architecture of ‘the business of the business’ – business-models and org-structures and so on. Almost all business-folk believe in Econ101: to be blunt, it’s essentially a form of religion, held together by faith rather than fact. (I’m not knocking religion – it has a really important social function – but an insistence on faith over fact is not a good basis for a functional economy…) Our enterprise-architecture shows us that Econ101 doesn’t work in the real world: but business-architectures operate mostly in the imaginary world of business anyway. So, to again put it bluntly, we lie: we provide a bowdlerised, more-palatable version of the facts to keep them happy. We show them all of the linkages that satisfy all of the Econ101 assumptions – and we make sure that we satisfy all of those assumptions, too. But in the background, we actually build an architecture based on what works – not on Econ101.
Like IT-architecture, or data-architecture, or security-architecture, or process-architecture, business-architecture is just one more subset of enterprise-architecture, one more set of views into the ‘holograph’ that is the whole-of-enterprise architecture. The business-architecture describes the architecture of the business of the business; yet it only exists in the context of the enterprise-architecture, just as the business itself only exists within the context of a much broader extended-enterprise.
Anyway, that’s it for now, though no doubt this particular debate will ‘run and run’, as they usually do. 🙂 Hope it’s of some use to someone – comments/suggestions, perhaps?