Blog Posts Enterprise Architecture (EA)

Towards a whole-enterprise architecture standard – 3: Method

Blog: Tom Graves / Tetradian

For a viable enterprise ­architecture [EA], now and into the future, we need frameworks, methods and tools that can support the EA discipline’s needs.

This is Part 3 of a six-part series on proposals towards an enterprise-architecture framework and standard for whole-of-enterprise architecture:

  1. Introduction
  2. Core concepts
  3. Core method
  4. Content-frameworks and add-in methods
  5. Practices and toolsets
  6. Training and education

This part explores ideas and concepts for a core method for whole-enterprise architecture, and the implied support required within frameworks and methods.


The methods we use at present for mainstream ‘enterprise’-architecture are kinda complicated, we might say? In a sense, they probably need to be, to find the right balance between Waterfall and Agile and the like, within a largely predefined scope, usually centred around some form of IT, and usually centred around the ‘business’-level to ‘logical’ level in that model layers of abstraction in the previous post.

But as we move towards whole-enterprise architecture, we need architecture-methods that can self-adapt for any scope, any scale, any level, any domains, any forms of implementation – and that’s a whole new ball-game…

When we look in more depth at the context for whole-enterprise architecture, it soon becomes clear that it’s built on top of a web of inherent conflicts and trade-offs, including:

On top of that, to quote Tim Manning on Agile Development:

Design is not a linear process. At the start of a design, it is rare for all the requirements to be known, least fully understood. Design requires a period of discovery and iteration, which incorporates learning, experimentation and even (early) failure. Design, by its very nature, is an emergent process.

The emergent nature of design requires a non-linear approach to development.

Which means that the methods we need for the kind of architecture-work we’re facing now and, even more, into the future, will need not only to work well with any scope, any scale and so on, but must have deep support for non-linearity built right into the core – yet in a way that fully supports formal rigour and discipline as well.

To be blunt, of the very few current ‘EA’-frameworks that provide a method at all, probably none are anywhere near competent for this task. If we’re going to satisfy those requirements, it seems pretty certain that we need to go right back to first principles, and start again from scratch.

But where do we start?

Enterprise-architecture is deeply engaged in continual improvement within the organisation and enterprise, so one place to start could be with the classic PDCA-loop – Plan, Do, Check, Act:

And it’s not that far different from what we have in EA already. For example, the TOGAF ADM (Architecture Development Method is in effect a variant of a PDCA-loop: the ADM Phases B-D are sort-of equivalent to the PDCA Plan phase, ADM Phases E-G the Do phase, ADM H a rather incomplete Check phase, and ADM Phase A a largely-hardwired Act phase. So with some significant but doable amendments, it might at first seem as if we could perhaps hack something like the TOGAF ADM to do the job we need here.

Yet the reality is that PDCA doesn’t go anything like far enough for what we need. In particular, it doesn’t really touch all that much on the human aspects of change – and EA is a discipline that’s often been described as ‘relentlessly political’, so the human-factors are kinda important here…

Hence a perhaps better place to start would be with what a generation of designers now would describe as ‘the Squiggle‘ – a visual map of the inherent-uncertainty in the design-process:

It starts with the initial seed of the idea – the purpose of the design-project. There’s then a wild swirl of uncertainty, iterating back-and-forth across many different options, opinions and more, before slowly settling out towards a distinct plan for action, and then putting that action into concrete form in real-world practice.

Given that, there’s a lot of immediate similarity with Bruce Tuckman’s classic Group Dynamics project-group development and project-lifecycle sequenceForming, Storming, Norming, Performing. The model provides further clarity on what happens in the Squiggle sequence, by including strong emphasis on the importance of the human-oriented Storming phase – in fact includes clear warnings about the very real risks that arise from attempting to bypass that phase, as tends to happen with unaware usage of a PDCA-type model. And it also adds an optional extra phase – Adjourning – that focusses on benefits-realisation and lessons-learned from the previous work in that project-sequence. This then connects back to the purpose from the initial Forming phase – converting the original linear sequence into an iterative loop. If we’re willing to accept a project-like concept of EA-activity – whether in linear form, or as an iterative loop – then the Tuckman model fits well, especially when we connect it with the visual map of the Squiggle:

For many of us, though, describing everything in EA as a project would not seem right. After all, one of the key concerns for EA is that it needs to be understood as a business-capability in its own right, rather than just ‘some stuff we might use within projects’. And timescales for EA-activities can vary enormously, from mere hours to multiple years and more. To resolve this, we can usefully turns to a much older version of the same kind of pattern, namely the classical Chinese Five ElementsWood, Fire, Earth, Metal, Water. What this adds to the picture is fractality – the same pattern repeating indefinitely in self-similar ways, but also optionally nesting in recursive fashion, to any depth, any scale. And with perhaps more business-oriented labels for the phases, it gives us an overall structure for a method that matches well enough with the way that we actually work in EA and related disciplines:

[image: five-elements-as-purpose-etc]

In which case, we’ll use this as a proposed method for our framework for whole-enterprise architecture – and expand on how this would work in practice in the following ‘Application’ section.

But even given a structure for method, what do we actually do? What would guide choices about what architecture-issues to tackle, and when? One suggestion here is a maturity-model that I’ve used for some years, loosely modelled in the well-known CMMI structure, but with an emphasis less on the ‘maturity-levels’ currently achieved, but more on the steps that we need to take to move from one maturity-level to the next:

Each of the steps presents and makes use of what are actually quite different theories of the enterprise:

Those ‘theories of the enterprise well with the decision-tactics outlined in the SCAN framework for sensemaking and decision-making:

And with the ‘perspectives-set that we saw in the previous part of this series:

The architecture-development is not literally step-by-step in that sequence: step-by-step is what we’d prefer to do, and should do wherever practicable, but Reality Department so often gets in the way towards that ideal! What the model does warn us, though, is that activities for each step in effect depend on completion of the respective parts of the ‘previous’ step(s): hence each time that we do have to do things out of step, we’re creating technical-debt – literal or metaphoric – that we’ll have to come back to and clean up again later.

(For a more detailed overview of the maturity-model, see the slidedeck ‘Stepping-stones of enterprise-architecture‘ on Slideshare.)

 There’s a vast amount more that we could add to this, of course – but that’s probably enough for us to outline a first cut for a whole-enterprise architecture metamethod.


From the above, we can derive suggested text for the ‘Methods’ section of a possible future standard for whole-enterprise architecture. Some of the graphics above might also be included along with the text.

Role of method: The purpose and role of the method is to support iterative sensemaking and decision-making within architecture-development for any or all of an entire enterprise or beyond.

– Scope of method: The method must be able to self-adapt to any scope, any scale, any level, any domains, any forms of implementation, and for any architectural-type purpose within the respective enterprise. In part, this means that there needs to be a distinct phase within the method to identify the scope and purpose of the current iteration of the method.

– Human-oriented focus: We define ‘enterprise’ as ‘a bold endeavour’ – an inherently human construct. Everything else in the enterprise – content, implementation, whatever – is subordinate to this human need and drive. In part, this means that there need to be distinct and explicit elements within the method that work with and acknowledge human feelings as well as functional system-behaviours and outcomes.

– Explicit support for conflict-resolution: One consequence of a human-orientation for the method is a necessary acknowledgement of the inevitability of conflict and ‘Storming’ between stakeholders, and about matters of design, intent and more. In part, this means that there need to be explicit elements within the method that identify, work with and provide resolution for such conflicts.

– Support for any architectural-content: The method must to be able to work with and adapt to any architectural context and need. As a result, it must be able to support any type of implementation-content, at any level of detail. (This is in sharp contrast to many current ‘EA’-frameworks, which prioritise IT over everything else, and often render ‘invisible’ many other types of architectural elements.) This requirement for content-adaptability would typically be supported by content-specific ‘plug-ins’. (More detail on this in Part 4 of this series.)

– Context-first, not content-first: Because the method needs to be able to work with any type of implementation-content, it must itself be content-agnostic. We might describe this as ‘context-first, not content-first’. (This is in sharp contrast to most current ‘EA’-frameworks, most of which prioritise content over context, and often assert or assume – such as via the ‘BDAT-stack‘ – that every context will always need an IT-based ‘solution’.)

– Architecture and governance: Governance is an essential aspect of architecture-development, design, implementaition and deployment. In part, this means that the architecture-method needs to embed and apply change-governance, to guide all of the stages throughout the change-lifecycle and beyond. Since these will changes will have differing types and levels of complexity, lifecycle and other factors, this will necessitate support for a range of governance-types – from ‘waterfall’ to ‘agile’ and more – this implies that governance-support within the method would more take the form of ‘metagovernance’, from which any required form of governance could be derived.

– Closure and continuous learning: The method, on completion of an iteration, needs to support assessment of benefits-realisation – to link back to the original purpose of the iteration – lessons-learned – to drive continual-learning and overall situational-awareness.

– Support for fractality: The method needs to be able to support architectural-explorations across any scope, scale, domain and more. Such explorations will often occur as a result of questions arising from within other currently-active explorations, giving rise to a concept of recursive-nesting or fractality of architecture-iterations. The method must therefore be able to support fractality of itself within itself, to any required depth of nesting.

‘Start-anywhere’ principle: The method needs to be able to ‘start-anywhere’, apply to anything, any scope, any level and so on. This means that the method must not embed any ‘hard-wired’ requirement for an assumed mandatory start-point for exploration. (This is in sharp contrast to most current ‘EA’-frameworks’, which typically assume or demand a whole-organisation or whole-of-domain scope and start-point.)

– Applicability and usability: One of the core concepts of whole-enterprise architecture is that architecture is everyone’s responsibility – not solely the province of those who describe themselves as ‘architects’. Because of this, the method needs to be usable by anyone, to any required level of complexity: it must be simple enough to be usable by an inexperienced trainee in frontline-operations, yet also be powerful enough to satisfy any professional needs. The most probable means to accommodate these requirements is a combination of a conceptually-simple frame, coupled with the power provided by fractality and by content-plugins, as described earlier above.

Implied need for architecture-repository: The probable phased nature of the method, and the required support for fractality and for lessons-learned and suchlike, implies a need for some kind of shared-repository to store information for use and re-use in other phases and iterations, and for historical-analysis, simulation-development, cross-domain review and more. This hypothetical repository may take any appropriate form, from handwritten notes to photographs of whiteboard-sessions to full purpose-built toolsets and more. (More on this in Part 5 of this series.)

From this, and from the descriptions in the Rationale section above, we could propose a method based on the Five Elements model, which we could summarise visually as follows:

Or, in terms of transitions between the respective phases of the method:

We could summarise the simplest level of the steps or phases as follows:

– 1: Purpose [‘Forming’; Why]: Identify the underlying reason and scope for the session.

– 2: People [‘Storming’; Who]: Identify the people-issues in context of the session.

– 3: Preparation [‘Norming’; How]: Prepare for action to address the needs in context of the session.

– 4: Process [‘Performing’; Where / When / With-what]: Enact the intended action to address the needs of the question for this session.

– 5: Performance [‘Adjourning’; Success]: Close the session, and prepare for any succeeding sessions.

– Support for fractality and non-linearity: Note that the method / pattern is recursive and fractal, and optionally non-linear:

– Session duration and complexity: Sessions may be of any duration, nested to any depth as required. At its most minimalistic, a session might literally last a matter of seconds, using the Five Elements tag-lines as a quick real-time checklist. At a much larger scale, a nominal session could be the approximate equivalent of a multi-year TOGAF8-style IT-landscape rationalisation, containing a multitude of nested child-sessions within the overall architecture-development session, all of the sessions using the same Five Element pattern. Complexity of a session is largely a matter of choice and professional judgement, dependent on the requirements of the Purpose-question, the scope of stakeholders, the frames used in preparation, and the type of architectural action undertaken: again, this may be anywhere from minimalist to a massive multi-disciplinary project or programme of work. The key point here is that neither duration nor complexity are hardwired into any part of the Five Elements pattern: they are derived from how the pattern is used, not from the pattern itself.

The above provides a quick overview of a fully-fractal method that we could use for sensemaking, decision-making and architecture-development in a whole-enterprise architecture. (I do know that it’s not complete enough for any kind of standards-proposal! – this is really little more than a strawman to use as a base for further discussion, exploration and critique.)

We’ll move on now to explore some ideas about how we could link specific content – or, more often, information about content – to the method, to guide architecture, design, implementation and real-world deployment.

In the meantime, any further comments so far?

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples