Benefits Led Enterprise Architecture Method (BLEAM)

To overcome these issues Enterprise Architects has developed an agile and benefits led approach to delivering enterprise architecture. Our agile enterprise architecture method and framework is based on TOGAF^TM and provides a collection of best practices, standards, tools, processes, and templates to assist in the creation of the Enterprise Architecture.

BLEAM’s scope is broader than most other Enterprise Architecture frameworks as it covers the traditional Enterprise Architecture methodology scope, as well as organisation and environment aspects of performing Enterprise Architecture. BLEAM can accept bottom-up input into it, as well as top-down, where necessary. This allows the very realistic physical constraints that an organisation may operate under to be considered for both current-state and future state modelling.

Agile TOGAF^TM – Our Own Home Grown Method – We as expert Enterprise Architecture practitioners believe that TOGAF^TM should be applied in an iterative value adding agile manner and not as a long time consuming waterfall model

In detailed practice, the underlying model for the ADM is Agile, not Waterfall. The actual sequence of activities and architecture-development is not fixed, and each of the phases shown in the large-scale cycle will be made up of many smaller projects and sub-projects, often running in parallel. These small-scale iterations of the cycle may last only days, or even hours, but are still subject to the same overall governance. These small-scale cycles all conform to the same overall pattern. (In effect, the large-scale ‘crop-circle’ diagram is a special case of this pattern, as are each of the individual phases, including the Preliminary phase.) The steps are summarised in the simplified ‘crop-circle’ diagram.

The cycle begins by defining the business-purpose, time-horizons (as-is versus to-be), scope (business, information, technology, security, process etc) and required model-types for the iteration (Phase A). The architecture assesses the architecture for the scope at the given main time-horizon, usually the ‘to-be’ state (Phase B). In most cases this will be followed by an equivalent assessment at one or more comparison time-horizons, usually the ‘as-is’ and optionally any intermediate stages (Phase C). To complete the architecture analysis, a gap-analysis is performed to derive change-requirements, such as for a road-map from ‘as-is’ to ‘to-be’ (Phase D).

In many of these small-scale cycles, the nominal task may be complete at this point, updating the architectures for later re-use. But if system-changes are required, the architecture-team will be engaged in providing guidance to projects, working with solution-architects (Phase E), system-designers (Phase F) and project-managers (Phase G). In every cycle, at every scale, each iteration should end with a benefits-realisation/lessons-learned review (Phase H).

The boundaries between phases in the cycle provide reference-points for governance and review. Each cycle is carried out for a specific business purpose, to deliver specific business value, and since all cycles follow the same pattern and use the same models, metamodels and repositories, each also adds to the growing knowledge-base of re-usable architectural information.

Architecture cycles will often be nested inside each other, to support the various sections of larger-scale projects, but the Agile nature of the cycle enables rapid return of business-usable results, usually in days or weeks at most.

A true whole-of-enterprise scope is too large to tackle in one go, so the architecture needs to be developed iteratively, with each step constrained within the specific scope of a single business-issue or change-project. This works because the underlying base-metamodel, beneath the standard TOGAF^TM metamodel, is capable of a true enterprise-wide coverage. This also makes better business sense, because the architecture-iteration can deliver immediate return, and its value increases as each project leverages the knowledge and lessons learned from previous architecture-cycles.

The architecture is never ‘complete’: instead, it grows and changes with each iteration, creating a richer and more valuable view of the enterprise as a whole.

Agile ADM Phase A – establish iteration scope

This phase is the start-point of a regular architectural-services cycle, to identify the purpose, scope, context and time-horizons for the current iteration. Typical steps include the following:

A1 – Establish the business-purpose and scope of the cycle
A2 – Review applicable Architecture Principles, policies etc
A3 – Identify business goals and strategic drivers
A4 – Establish the architecture-framework scope of the cycle
A5 – Identify additional stakeholders, concerns and requirements
A6 – Identify additional constraints
AX – Secure approval for Statement of Architecture Work

Agile ADM Phase B – assess context at primary time-horizon

This phase establishes the architectural context for the scope specified in Phase A of this cycle at the main time-horizon in focus (usually the probable and/or intended future context or ‘to-be’). Typical steps include the following:

B1 – Identify available architecture-description for primary time-horizon
B2 – Select reference-models, views and viewpoints
B3 – Create and update context architecture models for this time-horizon
B4 – Review architecture for this time-horizon against qualitative criteria
B5 – Finalise building-blocks for the architectural scope
BX – Conduct checkpoint-review for stakeholders

Agile ADM Phase C – assess context at comparison time-horizon(s)

This phase establishes the probable and/or intended future context for the scope and each comparison time-horizon (usually the current-state or ‘as-is’, and any intermediate points) as specified in Phase A of this cycle. The steps in Phase C are almost identical to those in Phase B: the only difference should be that the architecture developed would apply to the respective time-horizon rather than the current ‘primary’ view. All steps other than CX, the final stakeholder-review, should be repeated for each time-horizon in scope. The review should cover all comparison-architectures developed in this Phase:

C1 – Identify available architecture-description for comparison time-horizon
C2 – Select reference-models, views and viewpoints
C3 – Create and update context architecture models for this time-horizon
C4 – Review architecture for this time-horizon against qualitative criteria
C5 – Finalise building-blocks for the architectural scope
CX – Conduct checkpoint-review for stakeholders

Agile ADM Phase D – derive change-requirements

This phase establishes the gap between the current ‘as-is’ context and the probable and/or intended future ‘to-be’ context(s) for the scope and time-horizon(s) specified in Phase A of this architectural cycle. All steps other than DX, the final stakeholder review, should be repeated for each time-horizon in scope. The review should compare the primary (usually ‘to-be’) architecture from Phase B to all comparison-architectures (usually ‘as-is’ and intermediates) developed in Phase C:

D1 – Construct and validate matrix of ‘as-is’ to ‘to-be’ architectures
D2 – Derive change-requirements from validated matrix
D3 – Review requirements against existing dispensations
D4 – Review requirements against qualitative criteria
DX – Conduct checkpoint-review for stakeholders

Agile ADM Phase E – design solutions

During this phase the architecture unit will provide technical and other support to assist the sponsor in selecting appropriate options to resolve the gap between the ‘as-is’ and the one or more ‘to-be’ architectures for the context. Note that the key responsibility for decisions on solution designs rests with the sponsor, not the architecture unit. Typical steps include:

E1 – Review gap-analysis and requirements from Phase D
E2 – Identify business drivers and constraints for implementation
E3 – Brainstorm technical requirements from functional perspective
E4 – Brainstorm co-existence and interoperability requirements
E5 – Perform architecture re-assessment and gap analysis
E6 – Develop preliminary solution designs
E7 – Identify major work packages or projects
EX – Conduct stakeholder review of solution designs

Agile ADM Phase F – plan migration

During Phase F the architecture unit provides support to assist sponsor and programme-management in developing plans to implement the proposed solution designs. The key responsibility for such decisions rests with the sponsor and programme management body, not the architecture unit.

In practice, enterprise-architecture in Phase F has more of a ‘watching brief’ than an active role, so the key steps here would depend on broader governance procedures for detail-level project-, programme- and change-management. The TOGAF^TMADM suggests that typical steps would include:

F1 – Prioritise projects
F2 – Estimate resource requirements and availability
F3 – Perform cost/benefit assessment of the various migration projects
F4 – Perform risk assessment
F5 – Generate timelined implementation roadmap
F6 – Document the Migration Plan
FX – Conduct stakeholder review of project- or migration-plan

Agile ADM Phase G – guide implementation

During this phase the architecture unit provides support to sponsor and programme-management, to attain and maintain architecture-compliance during implementation of solutions from Phase E, in accord with project- or migration-plans from Phase F. Overall governance for the project(s) under review remains with the respective project- or programme-management body.

The steps in this phase depend on the requirements and number of ‘gateways’ in the respective governance methodology. All steps other than GX, the final stakeholder-review, should be repeated for each gateway. The review should assess architecture issues arising from all gateways for the plan, as per the scope for the architecture-cycle. Typical steps include:

G1 – Review Architecture Compliance Statement
G2 – Assess impact on overall architecture
G3 – Respond to Architecture Compliance Statement
GX – Conduct stakeholder architectural review of plan-implementation

Agile ADM Phase H – review lessons-learned

During this phase the architecture unit reviews the results of the iteration in terms of benefits achieved for the business, and implications and impact on overall future architecture. This will often result in updates or additions to the set of primitives, models, metamodels, Building Blocks and other content in the Enterprise Continuum; to requirements, standards and other decisions; to content within the shared glossary and thesaurus; and entries in the issues- and risks-registers. (Note that since many iterations may be happening in parallel and at different speeds, it is often simplest to execute some parts of this phase at regular intervals – typically weekly or monthly – rather than at the end of each iteration.) Typical steps include:

H1 – Assess results from the architecture-cycle
H2 – Monitor changes in business and technology environment
H3 – Assess potential changes to framework, methodology etc
H4 – Assess requirements and options for architecture change
HX – Conduct review by architecture governance-body

The TOGAF^TM metamodel describes business-level abstractions or real-world items such as Business Objective, Technology Infrastructure Service or Information System Physical component. Beneath this is a base-metamodel defining a complete set of ‘primitives’ that fit together as an almost infinite variety of ‘composites’. These can describe not only the standard TOGAF^TM objects, but any possible entity within the enterprise context, including people, buildings, vehicles and machines. This capability is not available in standard IT-oriented frameworks such as Zachman, but becomes essential whenever the architecture scope needs to extend into areas outside of the IT domain – such as in transitions between IT-based and manual processes, or assessments of the physical layout and management of large data-centres and the like. (See p. for further detail.)