Towards a whole-enterprise architecture standard – Summary

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 a brief summary of the previous six-part series on proposals towards an enterprise-architecture framework and standard for whole-of-enterprise architecture.

Overview

Some of the themes we need to cover in considering the practice of whole-enterprise architecture would include:

We need a new core that fully understands enterprise-architecture, not just beyond IT, but all the way out to the whole-enterprise, at any scope, any scale.
We need a new architecture-development method that can work with any architecture context, again at any scope and scale.
We need a new set of content-frameworks that can self-extend to cover any required architecture-context.
We need new toolsets to support new context-adaptive EA practices.
We need new EA training and education to support all of these new functions and requirements.

(More details in the ‘Introduction‘ post.)

Core concepts

Core concepts for whole-enterprise architecture would include:

Purpose of whole-enterprise architecture: Continually enhance effectiveness across any or all of the respective enterprise.
Definition of ‘enterprise’: A human construct – a ‘bold endeavour’ – around which motivation and action may coalesce. (The term ‘enterprise’ may be used to denote a large commercial organisation, but that usage represents only one very small subset of human enterprises.)
Scope of whole-enterprise architecture: Any or all of the scope of the respective enterprise, including any subset and/or relevant intersection-supersets shared with other enterprises, and at any or all levels from most-abstract (enterprise-vision) to most-concrete (deployment, operations and action-records).
Content in scope for whole-enterprise architecture: The scope may or will include services implemented by any combination of people, machines and IT, using any requisite types of resources.
Core activities of whole-enterprise architecture: Identify and act on means to link people and/or systems together to enhance enterprise effectiveness in the required aspects of the shared-enterprise.
Core focus of activities: Context-first, not content-first. The first focus should always be on understanding the context, in respect of business drivers and desired business outcomes.

(More details and underlying rationale in the ‘Core concepts‘ post.)

Method

Any method to support whole-enterprise architecture would need to be based on the criteria that would include:

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.
Human-oriented focus: We define ‘enterprise’ as ‘a bold endeavour’ – an inherently human construct. 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: Conflict and ‘Storming’ between stakeholders, and about matters of design, intent and more, is acknowledged as inevitable and necessary. 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.
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.
Architecture and governance: Governance is an essential aspect of architecture-development, design, implementation and deployment. The architecture-method needs to embed and apply change-governance, to guide all of the stages throughout the change-lifecycle and beyond.
Closure and continuous learning: On completion of an iteration, the method needs to support assessment of benefits-realisation – to link back to the original purpose of the iteration – and 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. The method must therefore be able to support recursive-nesting and 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.- and hence must not embed any ‘hard-wired’ requirement for an assumed mandatory start-point for exploration.
Applicability and usability: One of the core concepts of whole-enterprise architecture is that architecture is everyone’s responsibility. The method there 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.
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 governance, historical-analysis, simulation-development, cross-domain review and more.

A suggested metamethod to address all of these needs, based on the Five Element model, could be summarised visually as follows:

(More details and underlying rationale in the ‘Core method‘ post.)

Frameworks, content and add-in methods

One of the challenges for whole-enterprise architecture is that it will need to be able to use or support a potential near-infinity of context-specific frameworks and methods. Criteria to address this challenge include:

Scope of content-frameworks and context-specific methods [‘content’]: The required overall scope for content for whole-enterprise architecture will be every aspect of every possible enterprise. It is not feasible to attempt to cover this by a single, predefined, all-encompassing package of content.
Relationship between content and metamethod: A metamethod for whole-enterprise architecture will need to be minimalist, context-agnostic and content-neutral. In practice, it will usually need to be linked to context-specific content (frameworks and methods) to make it directly usable and applicable for any given specific context.
Linking content to metamethod: Content (context-specific frames and methods) may be attached to and detached from the metamethod as ‘plug-ins’, according to the needs and scope of the respective context.
Applicability of content within the metamethod: A simple mechanism such as a system of tagging should used to identify the applicable scope of recommended-usage and validity for each plug-in frame or method.
Guidance on usage of content: No specific usage-guidance is or can be provided within the metaframework, other than for the basic usage of the metamethod itself. Instead:
- Every content-item is a ‘plug-in’ to the metaframework and metamethod.
- Treating context-specific content-items as plug-ins in effect enables infinite scope for the framework and method.
- A simple mechanism such as tagging to identify the types of scope and context for which each plug-in content-item would validly apply would also make it relatively simple to identify overlaps and gaps in coverage for a given context.
- Tag-sets used to identify scope and suchlike would themselves be plug-ins – hence the overall set of tags available for use within the framework is itself extensible to near-infinity. Some kind of community-based repository would probably be required to list and maintain governance of shared or standard tags.

(More details and underlying rationale in the ‘Content-frameworks and add-in methods‘ post.)

Practices and toolsets

When it comes to putting this into practice, some of the criteria would include:

Scope of practice: The practice of whole-enterprise-architecture may address any business-question applicable within any or all of the entirety of a chosen shared-enterprise.
Nature of practice: Practice should be based on the fractal, recursive metamethod outlined under ‘Method‘ above, optionally using other content-frames and plug-in methods as guided by the metaframework outlined under ‘Frameworks, content and add-in methods‘ above, and in accordance and alignment with the core-concepts outlined under ‘Core-concepts‘ above.
‘Start Anywhere’ principle: If the enterprise is ‘an ecosystem with a purpose’, then we can start anywhere, because by definition everything in that enterprise is interlinked with and interdependent on everything else within that enterprise.
‘No Endpoint’ principle: A counterpoint to the ‘Start Anywhere’ principle, there is no start-point to the enterprise and its architecture, therefore also no explicit end-point: every end-point is a choice.
‘Usefulness’ principle: The key practical constraint on any item of architecture-work is its usefulness – that it contributes usefully to the overall architecture within a reasonable expenditure of effort and time. Each item of architecture-work should address a specific business-question, indicating its scope, scale, success-criteria and suchlike. Timescales for such work may vary from minutes to years, dependent on complexity and need.
‘Hologram’ principle: Any enterprise-architecture work would reflect the interlinks and interdependencies of ‘the enterprise as ecosystem’ – creating a ‘hologram’ of the enterprise in which each new item of work will also add in some way to the detail of the descriptions of every part of the enterprise.The architecture-hologram should be able to support any type of view or sub-model of any aspect of the enterprise, to the available level of detail currently available within the hologram-model.
‘Dynamics’ principle: Whole-enterprise architecture takes place within a context that is inherently complex in many different ways, all undergoing continual dynamic change, at many different, interleaving rates of change. In such a reality, it is essential to work with such inherent dynamic-instability, rather than pretend that it does not exist.
Nature of required skills: Whole-enterprise architecture is dependent on cross-disciplinary generalism. Since everyone is responsible for the architecture of their enterprise, everyone will need some awareness of the architecture and how best to support it within their everyday work.
Role of maturity-model: Given the complexities of the work, a maturity-model may be useful to assist in guiding priorities for architecture-work, and also to assist in skills-development by prioritising work in terms of likely development of architecture-skill over time.
Role of toolsets: The architecture-metamethod expects and requires some kind of repository within which to store information, both to guide the work and to record details arising from the work.

(More details and underlying rationale in the ‘Practices and toolsets‘ post.)

Training and education

Key criteria for training and education in whole-enterprise architecture would include:

Purpose of training and education: Whole-enterprise architecture is a skills-based discipline. Core skills include generalism, ability to work with deep-abstracts and bridging between domains, and facilitation and other so-called ‘soft-skills’.
Nature of training and education: The primary focus will be on working with any given context as a whole, and to maintain explicit balance between content and context. A key theme will be that “everywhere and nowhere is ‘the centre of the architecture’, all at the same time”, bridging across all domains in the context, from big-picture to fine-detail, and from strategy to design, implementation, operation, analytics, decommission, re-strategy and redesign.
Nature of required skills and experience to be developed: Core skills would include: whole-of-context sensemaking, systems-thinking and context-space mapping; bidirectional abstraction and instantiation via metaframeworks, metamethods, metatools etc; facilitation, soft-skills and presentation-skills; skills in ‘translation’ between domains, and ‘learning to learn’.
Delivery of training and education: Delivery would take at least three distinct forms: classroom-based training or online text-based self-training, working from predefined texts; on-the-job mentoring; and peer-based community support.
Identification of skill-levels and needs for further training or education: Skill-levels, training-needs and transitions should be identified at distinct levels, such as Foundation, for trainee or non-architecture specialist; Entrant, for first-level apprentice; Qualified, for full apprentice; Professional, for full journeyman; and Master Professional, for consultant-level.
Engagement of recruiters and the broader business-community: Extensive engagement will be needed with recruiters, and with the broader business-community, to ensure that the role, skills, competencies and skill-levels of whole-enterprise architects and whole-enterprise architecture are properly understood, and that recruiting and hiring or contract processes properly reflect this understanding.

(More details and underlying rationale in the ‘Training and education‘ post.)

See also the post ‘Towards a whole-enterprise architecture standard – Worked-example‘ for a full worked-example on applying the method to a real-world business-question around so-called ‘Bimodal-IT’.