TheFivePillarsOfEnterpriseArchitecture

The Five Pillars of Enterprise Architecture

There are five features or aspects of enterprise architecture
practice that need to be present for it to be successful.

Many organisations have struggled to unlock the significant potential value that Enterprise Architecture offers. In principle, the practice of Enterprise Architecture offers the possibility of effective enterprise-wide coordination of change – leading more rapidly to efficient and effective execution of the organisation’s strategy for the enterprise.

In principle, the benefits of a coherent enterprise, whose evolution is consciously directed through the medium of models, are immense and far outweigh the costs of carrying out the practice. So if the in-principle net benefits (the excess of benefits over costs) are so large, why is the in-practice realisation of the net benefits so difficult to manage?

The “common pitfalls” type of analysis, such as Gartner’s “10 Pitfalls” – are useful – it is always good to avoid mistakes – but this sort of principle-practice question cries out for a “Critical Success Factors” type analysis. Some of them are the obvious counters to the mistakes: the pitfall of “Insufficient Stakeholder Support” is the obvious reciprocal counterpart of the success factor of having (powerful) stakeholder support.

On the basis of academic theory and real-world experience, I would assert that there are five features or aspects of enterprise architecture practice that need to be present for it to be successful – for it to add real value to the enterprise. These are the five pillars of Enterprise Architecture.

Pillar 1: A Widely-shared Knowledge-Base

The knowledge-base – covering not general knowledge but specific knowledge of the enterprise, its context and their co-evolution – is the central subject-matter of Enterprise Architecture.

The knowledge-base must have two intrinsic features and one extrinsic: it must be holistic and coherent (intrinsic) and it must be widely-used (extrinsic) – by every section of the enterprise.

____________________________________________________________

Featured Course

TOGAF® 9

 

 ____________________________________________________________

Holistic means the knowledge-base must cover all important aspects of the enterprise and coherent means that any two knowledge items or models in the knowledge-base must be consistent with each other. For example, the market-segmentation model of a commercial enterprise must be consistent with the process models of the customer, client and other stakeholder engagement processes.

This must be the case even when the models are produced by different sections of the enterprise which do not have extensive internal communications. For this reason, wide stakeholder validation and verification of the elements of the knowedge-base is necessary.

This then imbues the knowledge-base with authority and allows it to drive the coordination of change-actions across the enterprise – that is projects and programmes people propose must be aligned to the vision and direction set out in the knowledge-base. It is this authority that drives the need for validation and verification across the entire enterprise – and therefore drives the demand for wide stakeholder support; without it, the views represented will be too narrow and not a derived consensus.

Formal models bring syntactic rigour to the knowledge-base, but are still open to semantic interpretive flexibility – which requires words in documents forming a narrative line, a story, to resolve.

The knowledge-base may be documentary – as Scott Bernard assumes in his “Introduction to Enterprise Architecture” – or may incorporate formal models – as most modelling languages assume – but most likely it incorporates both.

Formal models bring syntactic rigour to the knowledge-base, but are still open to semantic interpretive flexibility – which requires words in documents forming a narrative line, a story, to resolve. Formal models may also lack comprehensibility by having their meaning obscured by the grammar of the modelling languages employed. This damages their credibility and relevance with stakeholders, meaning the models are less likely to be used to direct actions in the development of the enterprise (thus defeating their purpose).

For this reason simple, less formal tailored diagrammatic ‘Views’ are better than formal models for presentation to stakeholder groups during decision-making processes.

The primary part of the knowledge-base is the knowledge of what the future, better-performing enterprise looks like – the Target Architecture. Second comes the knowledge – the know-how – of how to get there: the Roadmaps. The Target and the Roadmaps together form an expression of the strategy for the enterprise – though, perhaps, in a little more actionable detail than typically emerges from strategy formulation. The roadmaps in turn depend on where you are starting from – so the Knowledge-base must incorporate sufficient – but only sufficient – knowledge of the Current Architecture of the enterprise.

Pillar 2: A Shared Theoretical Basis

For many people, “theory” means “impractical”; but this is just plain wrong – a misunderstanding of what “theory” means.

Theory is the basis for action – and good theory means effective action; poor theory results in action that is ineffective or inefficient or both. When “practical” is used in opposition to “theoretical”, this is often an excuse for the use of bad theory, or theory based on common prejudices and intuitive assumptions (which is sometimes called “no theory” but is really bad theory).

With good theory, you literally know what you are doing; with bad theory, you do not. So, if your intention is to use the knowledge-base of enterprise architecture to realise a better-performing enterprise, it had better be based on good theory – and good theory shared across and common to all the stakeholders in the enterprise. This is necessary so that they all understand and are committed to the development of the enterprise – and its context – and coordinate their actions to achieve it.

The portfolio of established theory from which an enterprise carves out its own tailored synthesis, depends very much on the education of its personnel and stakeholders.

The theoretical basis may incorporate elements from a diverse range of sources – and include well-established theories of enterprise development such as Greiner’s Growth Phase Model, Porter’s “Value Chain” logistical model and taxonomy, Kotter’s Change Model, Teece’s Dynamic Capabilities Theory and Giddens’ Structuration Theory.

Important sources of theory for Enterprise Architecture are Business/Management Theory, Organisation Theory, Technology Management and Innovation Theory and the Social Sciences.

The portfolio of established theory from which an enterprise carves out its own tailored synthesis, depends very much on the education of its personnel and stakeholders. Better educated people can together synthesise a better theoretical basis to understand the enterprise in which they are involved and its context – and therefore take more effective action.

This is the reason why it is necessary to have the Enterprise Architecture practice staffed with well-educated people – people who, as a minimum should have some reasonable level (e.g. a degree or postgraduate diploma) of business/management/organisation education.

The knowledge-management mechanism of the “Reference Model”, which is developed in some Enterprise Architecture frameworks, is a means by which external theories, knowledge developed beyond the boundaries of the enterprise, are incorporated into the enterprise’s theory basis.

Central to this synthesis is enterprise ontology – a system of concepts about what an enterprise is, what it consists of, what parts and properties it has and how they relate to each other and how the complex evolves over time in a changing environment.

General theories and models from different sources, internal and external to the enterprise, may be integrated into the synthesis if they are based on a consistent ontology. Each of the so-called Enterprise Architecture frameworks – at last count, over 40 of them – represents a limited general theoretical synthesis from a particular viewpoint and ontology.

None of them is very complete or comprehensive (for example, none of them, as far as I am aware, makes reference to an enterprise lifecycle model similar to Greiner’s or Nolan’s or suggests any taxonomy of enterprises). Several are exclusionist and isolationist (denying the utility or correctness of other frameworks, models and theories) and some of them are excessively focused on models or on one particular technology to the neglect of the enterprise reality[1].

Pillar 3: A Common Methodology

A shared theoretical basis is a good start – at least everyone is then using more or less the same concepts and language – but it is not enough. Methodology is based in theory, and is the collection of methods of analysis – as a precursor to action – that are justifiably applicable.

But theory does not tell individuals or groups which methods to apply and how. Any two people, or groups of people, will have different perceptions of the problem-situation and different views about what methods to apply and models to build, as well as the precise content of those models.

If, however, all the methods are drawn from a common methodology with is itself based on a shared theory-base, the models produced will be syntactically and semantically coherent with each other and with earlier-produced models. The proactive decisions about which models supply most value in addressing a given problem, or set of problems, is then a separate prioritisation/resource-utilisation issue (subject to a cost-risk-benefit analysis).

A common fault of frameworks is to assume that the process is linear – that is each stage follows in sequence and is not repeated or the flow of activity reversed – when in general it is not linear but co-evolutionary and emergent.

Some Enterprise Architecture frameworks have an explicit, detailed exposition of methodology (and methods), others are more implicit – and assume the practitioner can explicate methods from theory. An explicit and detailed exposition would include a Metamodel, a Content Model and a Process Model – for the enterprise architecture practice and its products.

The Metamodel should be derived from the enterprise ontology, and basically, specifies how the concepts of the ontology, as applied to a specific situation, are represented in the models and their representations. The Metamodel is the basis of the modelling conventions used in the methodology.

The Content Model for the enterprise architecture products is the explicit specification of the form of the products and an intensive definition of their content. The Content Model may also specify a taxonomy of models that may be produced – such as the two-dimensional taxonomy central to the Zachman framework.

The Process Model describes the stages and sequences in which the methods of the methodology are used, including logical dependencies between methods and products. A common fault of frameworks is to assume that the process is linear – that is each stage follows in sequence and is not repeated or the flow of activity reversed – when in general it is not linear but co-evolutionary and emergent.

Applying a common methodology in a consistent fashion, based on a shared theoretical base, ensures that the right enterprise architecture products are produced – and that those produced by different groups and at different times form a coherent whole.

Enterprise Architecture, as a discipline, is lucky in that exactly the same methods and techniques that it applies to improve the performance of other enterprises, it can reflexively apply to itself: that is an Enterprise Architecture practice can and should architect and re-architect itself.

Pillar 4: An Integrated Governance System

Pillars 1-3 are critical factors just to begin having a quality enterprise architecture practice. Even together, however, they are not sufficient to ensure an organisation will get good value from the practice.

The reason is that even if a coherent holistic model of the enterprise and its desired evolution towards a better target state are produced, it is far from certain this (expensively acquired) knowledge will be used to direct and inform change actions in the enterprise. Some management, particularly political ones, prefer “flying by the seat of their pants” to rational analysis for their decision-making – a culture we can justifiably label as “pants”![2].

The pillar that ensures the benefits of Enterprise Architecture are actually realised is the fourth pillar: integrated governance. This integrated governance is ably described by Jan Hoogervorst in “Enterprise Governance and Enterprise Engineering”.

It is “integrated” since the models and knowledge base of EA are integrated into the other governance, compliance and decision-regulating systems of the enterprise. As Hoogervorst points out, the more progressive enterprises these days assume that critical review of strategy and strategy execution, not just regulatory compliance, is within the remit of governance.

In my view, the most important plank of this governance integration is that between Programme Management – as the organisational structure and function regulating change projects – and Enterprise Architecture. This then effectively forms the triumvirate for effective and efficient strategy execution – as described by Matin Op ‘t Land in “Enterprise Architecture: Creating Value by Informed Governance”.

Pillar 5: Methods for Continual Practice Improvement

Finally, nobody gets anything moderately complex and difficult “right first time” – even the best managers and executives must learn from experience to improve their performance – and that of the enterprises they influence.

Any serious practice, therefore, must have systematic methods of reflection and critical evaluation – such that it can “do it better the next time”. This is sometimes referred to as “reflective practice” and sometimes as “continual improvement” or “continuous improvement”.

Enterprise Architecture, as a discipline, is lucky in that exactly the same methods and techniques that it applies to improve the performance of other enterprises, it can reflexively apply to itself: that is an Enterprise Architecture practice can and should architect and re-architect itself.

This is true bootstrapping self-improvement – and if done consistently and continually will ensure that the benefits of and return-on-investment in Enterprise Architecture practice are maximised over the medium term – as well as those of any wider enterprise. Like all critical review type methods, this should feature input from a diverse range of stakeholders and should apply clear, pre-defined criteria for evaluation. Benchmarking tools, continual improvement process models, and maturity models – such as the EA2MM – help to make such a critical review process more objective – leading to more accurate diagnosis and better, faster improvement.

I have outlined what are, in my view, the five pillars – critical success factors – for an effective enterprise architecture practice. If any one of these pillars is absent, or below-par, it is likely that the enterprise will struggle to obtain value from the practice. Even a small deficiency in one pillar – say, in governance – could lead to a significant shortfall from the massive potential benefits available. So if your enterprise has an existing Enterprise Architecture practice, or one is being contemplated, how does it measure up against these five pillars? Will you get good value?

Don’t just like this – share it!

Sign up to our newsletter for free

[1] This leads some enterprise architects to even deny the reality of architecture beyond the model – ie that the only architecture is the model. This idea seems incoherent (nonsensical) to me – how can there be a structured model that asserts its own accuracy without a structured reality which the model reflects (is isomorphic to)? So I have little patience with the idea that architecture refers to only models – and enterprise architecture only to software-based models. There is a real-world.

[2] Sorry, English pun. In modern English idiom the epithet “pants” is sometimes used to mean bog-standard, low-quality, old-fashioned, distasteful rubbish. “Pants” in British English is more-or-less the same as the US English “shorts” and the “pants” US English speakers use for aviation are called trousers in British English.

Pillar of autumn photo courtesy Katy [email protected]





There are no comments

Add yours

x
freshmail.com powered your email marketing