Enterprise Architecture: Is it broken?
Jason Bloomberg suggests that Enterprise Architecture is broken in Forbes Magazine. Peter Harrad examines the issues in a little more detail, and in a less simplistic fashion. Five years ago, Dion Hinchcliffe made the same criticism in a much more thoughtful and analytical way. Several well-known Enterprise Architects have observed the failures of initiatives, or programmes labelled as “Enterprise Architecture” including Sally Bean in Beyond Alignment and Doucet, Gøtze, Saha and Bernard in Coherency Management and in their Journal of EA articles.
So, is the discipline or practice (or both) of Enterprise Architecture broken?
Well, first, the question is simplistic and naïve. It is like asking whether Project Management, Engineering or Medicine or (general) Management or Art is broken. The answer to “Is X broken?” for any X is “Depends on what you mean by X and ’broken’”.
The notion of “broken” implies a certain mechanistic way of thinking – thinking of the activity or action like a machine that either performs its function efficiently and effectively or not (and no grey area or partial effectiveness in between). It also implies a clear and unambiguous (non-fuzzy) idea of what X is – that everyone agrees as the ‘right’ concept of X. Clocks and other machines may be broken – and effectively useless for their intended function – but a discipline of practice?
The discipline of Enterprise Architecture is about producing holistic, integrated conceptual models that advise an enterprise manager about courses of action to take – not any particular prescription for action.
But human enterprises are not machines – including the enterprises like doing Enterprise Architecture. And human social systems are not machine-like and are not categorically either broken or functional. It is not that black-and-white. That is why the question is simplistic.
Rather, social systems, ways of thinking, methodologies, modes of expression – and people intensive systems -generally are effective or ineffective, and efficient or inefficient, to some degree. They may be more or less appropriate and useful in any particular situation – the extent to which they are depends on that situation.
Hence, the question “Is it broken?” when applied to such people-intensive systems is naïve – it is unaware of the reality and complexity of the situation.
Enterprise Architecture, is itself, a complex collection of interrelated methods and practices woven together in a theoretical framework of how enterprises work and change in response to changes in their environment. Each practice or method is, by itself, contingently more or less effective in the context of the enterprise being changed. Further, the effectiveness and efficiency of the complex methods and practices as a whole is dependent on the situation.
We call “scientific” any methods and frameworks of theory that are effective in enabling people to understand things. Those that are effective in changing the world – and proven (tested) to be safe and reliable – we call “engineering”.
To believe that there is a prescriptive universal practice that will simply and straightforwardly add value to any enterprise is to be so enthralled by mechanistic thinking and credulous as to buy “Consultant Dr. Alfredo Pirelli’s Patent Organisational Medicine” . Guaranteed to cure all known organisational ills and restore any commercial organisation to profitability and industrial leadership – or so says the hyperbole. There is no shortage of “consultancies” wanting to sell their particular brand of patented methodological cure-all – which is obviously superior to all other brands, right? The buyers are naïve to the point of credulity.
Given that Enterprise Architecture, as a discipline, spans a wide range of methods, and that it is applied contingently in a wide variety of highly variable enterprise or organisational situations – facing a wide variety of differing problems or differently-perceived problems – it is immediately obvious that there is no single course of action, no ante post prescriptive sequence of steps that will always make large strides towards a better situation. Any methodology, which suggests or even overtly asserts that there is, has to be suspect. The discipline of Enterprise Architecture is about producing holistic, integrated conceptual models that advise an enterprise manager about courses of action to take – not any particular prescription for action.
Given the range of modelling methods, the number of problem-aspects that may be addressed and the range of entities that may be integrated – organisations, capabilities, processes, technological elements etc. – the number of potential models that could be produced is very large indeed. Therefore, experience, skill and judgement must be employed by the Enterprise Architecture team to judge which models, addressing which problems and in what ways are most valuable.
An effective Enterprise Architecture practice makes cold, hard judgements as to the return-on-investment of the models it might produce. It doesn’t waste its time on models that will have no effect on managerial actions, or that do not address the significant problems – be they documentary models, or based in fancy modelling software and repositories.
An effective Enterprise practice would not produce models nobody wanted – or that power-wielding stakeholders could not understand – and certainly not because some method or ‘methodology’ arbitrarily and situation-unaware says it should. Real, effective enterprise architects are very far from the “Red Stapler Guy” – doing nobody-knows-what, for nobody-knows-who and nobody-knows-why.
For this reason, enterprise architects need to be highly educated – familiar with academic theory underpinning a number of ways of looking at organisations – and very experienced. They are then able to take an eclectic and adaptable, multimethodological but pragmatic approach towards model-informed organisational change. They adapt the frameworks and methods to the situation, as appropriate, in order to produce an effective response by the organisation to the challenges it faces. Far from being driven by the prescriptions of any particular ‘frameworks’, effective enterprise architects are able to take methods from several, adapt them to the enterprise and integrate them into a unique practice tailored to the enterprise and its problem context.
An effective Enterprise Architecture practice makes cold, hard judgements as to the return-on-investment of the models it might produce.
If, however, enterprise architects are not the slaves-to-the-framework that Bloomberg suggests, neither are all frameworks ‘broken’ in the way he suggests. The reductive problem-solving he describes is characteristic of reductive, positivistic frameworks.
This approach has been singularly successful in developing scientific understanding of a wide range of phenomena over the past three hundred years – but it has its limitations. Frameworks that have this reductive positivistic style, when applied to enterprises – human organisations – are all variations on the theme of traditional systems engineering. They view enterprises as machines – sometimes highly complex machines, with millions of parts – but fully deterministic and predictable.
But there are frameworks that take emergent phenomena seriously – and assume that there are behaviours that cannot be understood through an examination of constituent parts. They take a more ‘organismic’ perspective. In the Systems Thinking tradition, Soft Systems and Critical Systems are two categories that do not adhere to the mechanistic thinking of Bloomberg’s reductive frameworks. General Systems Theory was developed by a biologist, and there are several non-mechanistic ‘frameworks’ from Organisational Design and cultural analysis – that the well-educated enterprise architect will be aware of and able to apply – alongside the reductive frameworks.
So it is not Enterprise Architecture, as a discipline, per se, that is broken – it is Enterprise Architecture when managed in a mechanistic, reductive, functional worldview. It is this worldview that treats Enterprise Architecture as a model- or document-factory, applying production-line thinking to the creation of theories about the enterprise, that is broken. It is this worldview that has long been criticised for its naivety – including in Enterprise Architecture / Enterprise Engineering circles. See, for example, Chapter 2 of Jan Hoogervorst’s “Enterprise Governance and Enterprise Engineering”.
According to Hoogervorst, “Enterprise Engineering aims to comprehend enterprise complexity – and thereby master it – and can be seen as a developing discipline – domain of knowledge, concepts, theory and associated methodology – for analysing, designing and creating enterprises. …Two important concepts underpin Enterprise Engineering: Enterprise Ontology and Enterprise Architecture. … Enterprise Architecture is a crucial concept in this respect and provides normative guidance for design, in order for the enterprise to operate as a unified and integrated whole, whereby various enterprise objectives must be satisfied.”
It is not Enterprise Architecture per se that is broken – as a discipline, it couldn’t be – but the style of management that restricts it to a mechanistic worldview – that de-scopes the practice to looking only at the material aspects of an enterprise in an ante post prescribed, and proscribed, way. Is this the real reason why some enterprises fail to benefit from such an obviously beneficial professional practice? Not a reference to any real person, or organisation, dead or alive, but to a well-known fashionable charlatan in fiction – a purveyor of “piss and ink”.