1. Introduction

Enterprise architecture is what you do for the sake of strategic goals to do with enterprise integrity and flexibility. Solution architecture is what you do to ensure programmes and projects succeed.

TOGAF is for “architecting the enterprise” at a strategic level. AM is for “architecting a solution” at a more tactical project level. TOGAF certification is fine and helpful. But most architects need to work at or with solution architecture, and produce project-ready architectures.

You need to supplement enterprise architecture with a solution architecture process. AM was designed to work with TOGAF and explain Business, Data, Applications and Technology Architecture deliverables in more detail than TOGAF does.

1.1 Customising TOGAF for solution architecture

The table below lists the phases of the TOGAF process, which is called ADM.

The phases of ADM
Preliminary phase: Architecture framework and principles
A Architecture Vision	Requirements Management
B Business Architecture
C Information System Architecture
D Technology Architecture
E Opportunities and Solutions
F Migration Planning
G Implementation Governance
H Architecture Change Management

ADM is centred on defining the three architecture domains highlighted in bold. Each domain is defined at two states - the baseline (current) and target states. ADM starts with a preliminary phase in which architecture processes and deliverables are customised to fit the circumstances.

In practice, architects tend to customize ADM in ways like these:

· Start change management (H) and governance (G) earlier.

· Run change and requirements management together, alongside development.

· Consider opportunities before E, during target architecture definition.

· Identify projects after E, after defining a workable architecture migration path.

The table below presents the result of customizing ADM in these ways.

ADM phases after some customisation
Preliminary phase: Architecture framework and principles
A Architecture Vision	Requirements Management Change Management Governance
B Business Architecture
C Information System Architecture
D Technology Architecture
E/F Migration and Project Planning

A little more customization results in the nine-step process outlined below, and described in more detail thereafter.

Enterprise architecture is strategic. An enterprise-level plan rarely provides enough detail initiate a solution development project. The enterprise may invite IT services providers to bid for the work to deliver a specific solution. At this point, a solution architect enters the scene. He/she must review and elaborate part of an enterprise architect’s plan enough to enable delivery of a solution via a programme or project.

The table below is intended to suggest the solution architect’s solution is tactical, but is influenced by input from a more strategic enterprise architecture.

An architecture process map
Enterprise architecture		Change management
Governance	Solution architecture
	Solution implementation

Could a solution architect use the ADM process for solution architecture? Yes, if ADM is customized enough. This guide outlines a nine-step solution architecture process that can be viewed as a customization of ADM.

ADM for enterprise architecture	AM for solution architecture
A Architecture Vision	1 Identify architecture precursors 2 Scope the architecture work
B Business Architecture C Information System Architecture D Technology Architecture E Opportunities and Solutions	3 Understand the baseline architecture 4 Review non-functional criteria 5 Outline the target architecture – and evaluate 6 Select and manage suppliers
F Migration Planning	7 Plan the migration 8 Hand over to construction
G Implementation Governance H Architecture Change Management	9 Manage the architected system

Could an enterprise architect use the AM process for enterprise architecture? Yes, if AM is customised enough. So “you” in the following sections is the solution architect, but we add some of the spin that is needed at the higher level of enterprise architecture.

AM written mostly for solution architects. AM reflects a broad consensus among these kinds of architect about architecture description and management. AM has both the practical detail and the flexibility that these kinds of architect need.

Many architects ask to be given deliverable descriptions and examples. Relatively few are keen to be given a process. Most will follow a process only if it is simple and natural, or forced on them.

The process in this guide is designed to be a simple and natural best-practice process that most architects will happily adopt for its own sake.

Solution architecture process

Evaluation

1 Identify architecture precursors

2 Scope the architecture work

3 Understand the baseline architecture

4 Review non-functional criteria

5 Outline the target architecture

6 Select suppliers

7 Plan the architecture migration

8 Hand over to construction

9 Manage the architected system

Initial risk assessment

Initial scope and value assessment

Constraint and opportunity assessment

Non-functional risk assessment

Target architecture review

Supplier dependency risk assessment

ROI assessment

Project initiation review

Architecture governance reviews

Each step finishes with evaluation. Some of these evaluations may lead to a stop/go back/go decision. A go back decision means returning to whatever previous step needs rework.

There is more on the theme of iterative architecture development in the associated training, and in section on iterative architecture development at the end of this guide.

1.2 An architecture development hierarchy

An architecture framework provides a structure and guidance that architects can use in their work. It gives you a high-level picture that helps you scope work to be done. Each section guides what to do and to document. It connects separate activities and deliverables into a coherent whole.

Architects should customize any given framework to suit the work at hand. However, the framework should remain reasonably stable for one pass through the architecture development process.

Architecture definition is an iterative and recursive activity. Architecture development can be presented as a three-pass process.

1. The enterprise architect’s migration plan (or road map) identifies a number of projects. A supplier is invited to execute a project - or bid to do that.

2. The solution architect develops the Solution architecture in sufficient detail for the project to be costed, risk assured, planned and resourced.

3. The Solution to be built is handed over to a project team for completion and delivery through some kind of SDLC (system/solution/software development life cycle).

The table below shows these three levels of process, and two ancillary processes at either side, for governance and change management, which run in parallel.

An architecture process map
Enterprise architecture		Change management
Governance	Solution architecture
	Solution implementation

An architecture develops iteratively from enterprise level, through Solution architecture to solution development. The outputs from one pass are the inputs to the next. Inputs can be revised during a pass, then output to become fresh inputs to the next pass.

A solution outline fleshes out part of an enterprise architect’s plan. A solution architecture may be considered complete when it contains enough information for an IS/IT change project to be scheduled, staffed and run. But the architecture will be iteratively refined throughout the life cycle of the consequent development project.

Architecture descriptions can develop at several levels of abstraction at once. At the top, enterprise architects are defining general principles and standards, and broad brush solutions. In the middle, solution architects are scoping and planning individual programmes and projects. Within each project, architects are bottoming out the architecture for developers, and maintaining it in the light of feedback from experience.

The distribution of work between the three levels will vary enormously in different enterprises and different programmes of work.

1.3 Iterative solution architecture development

This guide contains a nine-step process, presented under the headings of SIMPL. The graphic below gives an idea of how the process can proceed in iterations from precursors to construction and delivery.

Phases and Activities of Solution Architecture
*Architect the solution*				*Implement the architecture*
DISCOVER	VISION	OUTLINE	COMMIT	DELIVER	MONITOR
Stakeholders Goals Principles Visions Strategies Enterprise or system scope Non-functional requirements Legislation Options and risks Business case	Review all inputs Understand the baseline Review qualitative criteria Outline target architecture	Review all inputs Detail target architecture Select suppliers Outline the migration	Review all inputs Complete target architecture Manage suppliers Plan the migration	Architecture Implementation Management Software project processes	Architecture of the Operational System
	Test against qualitative criteria Analyse gaps and impacts Review with stakeholders	Test against qualitative criteria Analyse gaps and impacts Review with stakeholders	Test against qualitative criteria Analyse gaps and impacts Review with stakeholders Hand over to construction
	Manage changes to the requirements and the solution

The following sections describe the process in a traditional sequential fashion. In practice, the process should be applied iteratively, and some parallelism of activities is expected.

2. Step 1: Identify architecture precursors

The guide to precursors details the terms and concepts this section.

2.1 Identify and manage stakeholders

It is wise to start by identifying sponsors and other stakeholders. Thereafter, throughout the process, you should manage those stakeholders. Our guide to stakeholder management elaborates on this.

2.2 Identify any aims and directives

The inputs usually include high level aims, directives, visions and plans, and perhaps more detailed versions of them.

Aims	Directives
Goals	Principles
Objectives	Policies
Requirements	Business rules

2.3 Identify any solution visions and plans

Solution architecture work is usually driven by the need to solve a specific problem. It may arise from a higher level solution visions. An invitation to initiate (or tender for) a solution development project usually provides a great deal of detail, too much in some areas and too little in other areas.

Solution descriptions	Plans
Solution vision	Strategies
Solution outline	Programme plans
Solution to be built	Project plans

2.4 Identify any standards and other constraints

Solution architects are often constrained by standards from various sources, included principles and standards set by enterprise architects. You’ll need to consider any reusable assets that the enterprise maintains. The table below illustrates shared and reusable assets (in a virtual repository called the “enterprise continuum”).

Enterprise Continuum

Foundation

Generic, horizontal, infrastructure building blocks and services

Common System

Patterns or structures for assembling building blocks and services

Industry

Business domain/vertical

(Retail, Banking, Telecoms)

Organisation

Enterprise-specific (Tesco, HBOS, Orange)

Architecture continuum

e.g. TRM (Technical Reference Model)

SIB (Standards Information Base)

e.g. application integration patterns such as the III-RM.

e.g. Function, Data and Process models

e.g. Bespoke application specifications

Solution continuum

Strategic products

Product assemblies

(Email system, Security system)

e.g. COTS Packages

Bespoke solutions

And this table lists a few more things to look for.

Current systems problems. Standards. Reference models. Partner preferences. Tools to be used.

Similar work done in the past. Cost constraints. Time constraints. The stage reached: decisions already made. The degree of authority and freedom you have. Risks, assumptions, issues and dependencies: including. parallel activities that affect you.

2.5 Identify any requirements (focus on NFRS)

Focus on non-functional requirements. Ensure legislative requirements are understood.

2.6 Initial option and risk assessment

A stock trading system moving £100M/day. A SME dealing with auto-parts. A government department logging claims for grants from farmers. They are all different.

It is usual, at least at the solution vision stage, to describe two or more options. Options may be compared at several stages and at several levels of design. The choice between options can be guided by gap analysis, cost-benefit analysis, risk analysis and trade-off analysis.

See the guidance at the end of the next step for further details of these activities.

2.7 Notes for enterprise architects

Enterprise architecture is often driven by the need to improve the timeliness, cost or quality of IS/IT work in general. It aims to make IS/IT systems more interoperable and more flexible. This usually means imposing a common approach on IS/IT developments. It involves sharing data, processes, principles and standards. And it involves governing the implementation of whatever is shared.

3. Step 2: Scope the architecture work

3.1 Scope the enterprise or system

Scope is not a simple or singular concept. You can and should scope the enterprise or system (the one to be described or defined) in several ways.

The principal documents or descriptions used to define scope are:

· Goal and requirement catalogues

· Context diagrams, with input and output definitions

· Component and data structures.

· Process flow models, business scenarios, use cases.

Sometimes, these are provided as inputs (see previous step and the guide to inputs). Sometimes you need to start developing such documentation as a way to clarify the inputs, and define the vision of what is to be done.

The guide to scoping a system focuses on the use of context diagrams. Other guides to business, data and applications architecture description define views and models that may be used to define scope. This work is completed in later steps.

3.2 Define the architecture focus

Define the level of architecture granularity

Define domains or facets of architecture (use the BAF).

3.3 Define the architect team

Define the architect goals, roles and skills. Select team members.

3.4 Define the architecture framework

You cannot use the same architecture framework in the same way in every circumstance. No framework can guarantee the nature or quality of the inputs you are given. What already exists and what has already been done will vary widely. The nature of the problem domain may range from off-line batch processing on a main frame computer to display of a graphical user interface on a hand-held computer. You may need to select between alternative techniques for achieving similar results. When working for a consultancy, you will often need to match your process to that of the customer you work with.

So, while AM is a ‘best fit’ for a reasonably wide range of circumstances, you must and will customize the processes and the deliverables according to your circumstances.

3.4.1 Define the architecture process

This guide has already presented the nine-step process used in AM as though it were a customization of ADM. You may in turn customize AM

3.4.2 Define the architecture objects and models

Outputs:

· Models and views to be drawn

· Assumptions made

· Constraints that apply.

The process involves:

· Selecting the appropriate models and views

· Recording assumptions

· Deciding what constraints apply.

Connect to the business audience: Always begin with some business context. It is wise to plan to model some business scenarios before scoping an IS/IT solution.

Use a deliverable framework (like the BAF) to help ensure the selected views and models are comprehensive enough to cover the scope of the solution to be defined.

3.4.3 Define the architecture deliverable framework

The AM deliverable framework (the BAF) is published on the associated web site. The BAF grew by customisation of an older deliverable framework (POLDAT) used in the Catalyst methodology. You may in turn customise the BAF to suit your circumstances. See the guide to scoping architecture deliverables for further discussion.

3.5 Initial scope and value assessment

A stock trading system moving £100M/day. A SME dealing with auto-parts. A government department logging claims for grants from farmers. They are all different.

3.5.1 Gap analysis (options)

Generally, a technique for comparing two similar lists or structures. It can be used to compare two optional solutions, and identify gaps in one or both. It helps if the two options are presented under the same structure as each other, or a more general structure.

3.5.2 Cost-benefit analysis

Simply, an assessment of the costs and the benefits of a course of action and/or a proposed system. Costs must include both development costs and operational costs.

3.5.3 Risk analysis

Analysis of vulnerabilities that threaten the ability of a target system to meet requirements, especially non-functional requirements, including security. Risk analysis is needed before architecture definition starts in earnest, and then several times later in the process, and at several levels of design.

The risk assessment leads to control objectives. The control objectives can be decomposed into finer grained requirements for each layer of the architecture - business/organisational, data/apps, infrastructure.

Analyse the threats and vulnerabilities that limits the ability of a target system to meet non-functional requirements. This can lead to analysis of trade-offs between design options.

Consider security especially. Security requirements need to be stated and analyzed just as much as any other functional requirement. Security functionality should be tested.

3.5.4 Trade-off analysis

A technique for analysing target system options and the trade offs between them. Published and promoted by the SEI..

4. Step 3: Define the baseline architecture

The baseline is the current, or as-is situation. You’ll want to identify components in the baseline architecture (perhaps documented in an enterprise asset repository) that are candidates for use in the target architecture.

4.1 Understand the baseline

The solution architect must understand the current or baseline architecture. However, it may be documented already. And if it is not documented, the solution architect will only document as much as is needed to plot the migration path to the required or target architecture.

Analyse the current (as-is) situation with reference to perspectives and concerns in the BAF. Extend the existing architecture documentation if need be, using the same techniques and artifacts you will use for the target architecture.

4.1.1 Understand the baseline business architecture

Define only in so far as it is necessary to understand how to move to the target.

4.1.2 Understand the baseline data architecture

Define only in so far as it is necessary to understand how to move to the target.

4.1.3 Understand the baseline applications architecture

Define only in so far as it is necessary to understand how to move to the target.

4.1.4 Understand the baseline infrastructure architecture

Define only in so far as it is necessary to understand how to move to the target.

4.1.5 Understand the baseline architecture principles

4.2 Look for reuse

Identify components, services and principles of relevance to the target architecture. If you can define the baseline and target architectures in a similar way, then you will find it easier to compare them and perform gap analysis.

4.3 Constraint and opportunity assessment

Assess the constraints and opportunities that the baseline architecture presents. Most obviously, can you use the current infrastructure for new applications?

4.4 Notes for enterprise architects

The enterprise architect must grapple with the enterprise’s architecture as it is. It may contain scores of key business processes, hundreds of databases, and possibly thousands of applications.

4.4.1 IT portfolio analysis

A primary goal of the enterprise architect should be to manage the enterprise’s portfolio of IS/IT assets so as to ensure they are effective (support the business) and cost efficient compared with alternatives. This implies doing some IT portfolio analysis to record IS/IT assets in a register, asses the costs and benefits of each asset. An obvious goal is to cut costs by removing redundancy.

A guide to IT portfolio analysis is under preparation. This section makes some basic points.

The IT operations department have probably already record a register of hardware assets. If not, make sure they do. Ideally, you can link the IT asset register to a register of IS assets.

It is less common to find IS development/maintenance departments have recorded what applications the enterprise owns. Enterprises face two difficulties in application portfolio analysis:

· 1) there are hundreds or thousands of applications and

· 2) Application costs and benefits are obscure.

To rationalise 1, you must tackle 2. How to start?

List the most essential applications, the ones that people use, along with financial measures that the directors of the business will recognize as meaningful and useful (cost to buy or build, cost to run and maintain per month, benefit). You may begin by recording application costs and benefits as low/medium/high/very high, and then refine what these mean in terms of numbers as the asset register grows and is refined.

Measuring the benefits of an application is difficult. Some have used application size (measured in function points) as a proxy for application value. You have to develop measures more meaningful to your enterprise. One way to understand the value of an application is to register which business processes require it. So you may extend your asset register to record which applications are needed by which business processes and vice-versa. Another way is to turn it off!

You may go on to refine your application asset register in other ways. For example, you might distinguish data stores and components from applications, and identify the technologies the applications require. The table below shows a meta model of the facts that you might record in a modest application asset register.

Term	Relates to	Term
Application	Required by	Business Process
Application	Reads/writes	Data Store
Application	Contains	Component
Application	Requires	Technology

More complex meta models are discussed in other guides. The more sophisticated your application asset register, the wider the range of IS/IT elements recorded in it, the more it turns into a full-scale enterprise architecture repository.

4.4.2 Build an architecture repository

The primary goal at this step of the method is to define the IS and IT elements (at least at a coarse-grained level) that support the current business processes and organisation of an enterprise, with a view to defining a better target architecture.

Using a repository can help you define the baseline architecture in a similar way to the target architecture. But don’t go overboard. Build your repository iteratively. Focus right now on the parts of the baseline affected by change requests and/or a target architecture vision.

If you go down the path of defining and maintaining a full-scale enterprise architecture repository, then you should try to arrange it so that you can generate an asset register (suitable for discussion with a CFO) as an extract from the enterprise architecture repository.

Other guides explore what it means to document an architecture description and to build a repository. They explain why there is no single enterprise architecture meta model that works for all situations, and you have to customize any given meta model to fit your needs.

5. Step 4: Review non-functional criteria

Other guides cover NFR definition, and design for NFRs, at some length.

5.1 Set targets

Don’t expect whoever has gone before you to be completers. A solution architect rarely starts with as much as a list of use cases for a new system, or convincing NFRs and SLAs.

Set targets that are realistic - truly necessary and probably achievable. Some NFRs (non-functional requirements) are critical, can mean the difference between success and failure of a project at testing time. And if something goes wrong during operation, it may cost millions of dollars. Others are much less important.

5.2 Define measures with flexibility

Define how the targets will be measured. Adjust targets with a level - a % of cases that must meet the target, and periods when the targets will be relaxed.

5.3 Non-functional risk assessment

Consider the Trade Off Analysis method promoted by the SEI.

5.4 Notes for enterprise architects

As an enterprise architect, you aren’t concerned so much with the non-functional requirements of a specific system as with the general requirements and SLAs that commonly apply to many systems. You should classify your applications.

E.g.

· Enterprise OLTP applications

· Business intelligence / management information systems

· Departmental applications

· Single-user applications.

Then define, for your enterprise, the typical non-functional requirements for each, with a view to creating categories of applications that can share a common IT infrastructure.

6. Step 5: Define the target architecture

Several of our guides are concerned with defining a target architecture. This section offers a general process that can be reused (with variations) in business architecture, data architecture and applications architecture. Our process for technology architecture is rather more specific to that domain..

6.1 Define the business architecture

Define the enterprise, the business systems

Define business processes

Decompose the processes to the level of use cases or automated services

Design for human and organisational security

6.2 Define the data architecture

Maintain a data dictionary

Define data in storage

Define data in motion

Define data qualities

Design for data security

6.3 Define the applications architecture

Define applications architecture.

Define application integration strategy

Define how components will interact: component interfaces, component interoperation paradigms, component connection patterns and relevant design patterns.

Choose appropriate middleware.

Design for application security.

6.4 Solution design for NFRs

See the distinct guide to this.

6.5 Define the infrastructure architecture

Define the necessary computers.

Define the necessary networks.

Define intermediate servers.

Define protocols.

Design the infrastructure architecture configuration.

Design for infrastructure security .

6.6 Report target architecture

Outputs:

· A target architecture specified in terms of component specifications

· A list of all the components to be used

· Diagrams showing relationships between components

· A list of all the standards to be followed.

Recycle: Place anything of benefit to the wider enterprise in the enterprise architecture repository. Consider abstracting from the solution specification up to a more reusable architectural level specification.

At some point in the process, every perspective has to be considered, and every component specification has to be detailed. But you should minimise the scale and complexity of an architecture description by judicious use of abstraction. See the guide to architecture documents and repositories for more advice on documentation.

6.7 Target architecture review

Confirm the target meets the needs

Outputs:

· Revisions to the previous documentation

· Stakeholder sign off

Process:

· Circulation and review of target architecture deliverables

· Assessment of non-functional prototype and paper models

· Stakeholder sign offs

Consider all stakeholders and concerns: including Hardware, Networks, Operations or Service Management, Data Management, Security, Performance.

Validate: Defining business scenarios and use cases is one way to test the completeness and applicability of the target architecture and its components.

6.8 General advice

Generalising from the specific items above, the target architecture is described in the terms of

· Required services

· Components designed to deliver those services

· Structures in which the components are related

· For each component, a definition of its rationale, interfaces and standards it conforms to

· Definitions of processes that connect components

The architecture description process involves:

· Defining components at a manageable level of granularity

· Defining inter dependencies between components

· Ensuring interoperability between the various components chosen.

The enterprise architect’s goals are more strategic: to develop a target IS and IT architecture that fits the business strategy of the enterprise, and enables business agility. So a target enterprise architecture description tends to feature generalizations and coarse-grained components.

The solution architect’s goals are more tactical: to develop the target architecture for a specific solution that will work, to manage the risks, and sell a solution. So a target solution architecture tends to be more specific, more detailed, and feature finer-grained components.

Keep it as real as possible: Yes, you should look for component reuse, you should look at any isolated component with view to how it may be reused or integrated with other components in a future architecture. But compromises must be made. Looking for reuse encourages abstraction and idealisation. A degree of idealisation can help, but not too much. Your target architecture definition should contain standards and components that can and will be realized in the solutions to be built. Try to close any gap between the person who defines an ideal business process, and the person who has to detail it, and assign steps to the actors and components that execute it. Try to close any gap between the person who defines ideal data entity and the person who has to detail it in a database schema. Try to close any gap between the person who defines an ideal business function, and the person who has to turn it into a business unit, give it a mission statement, assign a manager, recruit employees, and give them procedures to follow.

7. Step 6: Select and manage suppliers

A supplier is a person or organization due to supply some software, hardware or IS/IT service that is required to design, build or operate a system. In fact any party who is due (according to the plan) to make a contribution to the deliverable may be regarded as a supplier. But normally, the term supplier is limited to external agencies, remote organisations, from which products and services are purchased via a contract.

7.1 Select suppliers

Your relationship with suppliers (of hardware, software, infrastructure, or operational support) can start with supplier selection in architecture definition and continue during a programme or project into supplier management.

In the earlier stages you may be involved in:

· A due diligence exercise, to evaluate the capability and stability of the organisation before a contract is signed.

· Discussions and meetings with suppliers to resolve problems and handle changes requested by either side.

In all such relationships, the roles, responsibilities and interfaces should be clearly defined. You should create a contract covering these things.

7.2 Manage suppliers

Suppliers require ongoing management. Most of the management techniques that apply to internal management are relevant. However, the remoteness of suppliers and 3^rd parties can mean you don’t know so well what progress they are making, or don’t get to hear of difficulties until too late. So, often, management of suppliers can assume a special significance.

An integration manager or contract manager or project manager may be responsible for the progress of the sub-contractor. However, you may well have some responsibility for managing some of the risks (the threats to time, cost and delivery quality) that dependence on suppliers and 3^rd parties bring. You may have to:

· monitor the organization’s progress against plans

· test the qualities of deliverables

· discuss and meet with suppliers to resolve problems and handle changes requested by either side.

Usually there will be a contract covering the roles, responsibilities and interfaces. But also usually, there will be some aspects that are unclear or undefined in the contract, needing attention as work proceeds. Read the contract. Refine it if need be.

7.3 Supplier dependency risk assessment

8. Step 7: Plan the architecture migration

The guide to planning of migration provides a management framework for the work involved. It is designed to work within the management of structure of PRINCE2.

8.1 Perform gap analysis

Any change implies two architecture states: a baseline (current, as-is) architecture and a target (required, to-be) architecture.

Compare the building blocks or services of a baseline system with those of a target system; and use the results of this analysis to inform programme planning.

8.2 Plan the migration path

Architects are expected to deliver a time-sequenced migration path that shows how the baseline architecture changes into the target architecture.

Define a progressive series of architectures describing different states of an enterprise or system, from baseline to target.

The enterprise architect is concerned that a relatively strategic migration path should implement common standards and principles. The solution architect is concerned that a relatively tactical migration path should deliver the required solution on time and to budget.

8.3 Complete the RAID catalogue

A catalogue of risks, assumptions, issues and dependencies, maintained separately from requirements and from solution documentation. Cf. Risk Register in PRINCE2.

Note especially all dependencies of a project upon an external actor or deliverable, not under the management of the project manager.

8.4 Help managers to convert migration path into a plan

Use the migration path to inform the IS and IT budget, the motivation for IS and IT investments and programme/project plans.

Engage the programme/project management body. Add timescales, and perhaps some idea of costs and resources to the migration path. Use critical path analysis and/or PERT network techniques to create a roadmap.

Assist managers in planning and various other aspects of management.

· Scoping work to be done

· Estimates: size, complexity, costing and pricing

· Schedules: plans and resources

· Risk management

· Approach: method and tools.

Analyse solution risks and options

8.5 Refine and review the business case

Having clarified the work to be done, you should revisit the return on investment. Use the migration path to inform the IS and IT budget, the motivation for IS and IT investments.

9. Step 8: Hand over to construction

An architect describes a system at a level of abstraction, the architecture description is prepared before construction. At some point, the architect must hand over the description to a team that does more the detailed work need to build the system.

9.1 Hand over meetings

The Solution architecture process comes to a halt when the programme or project gets the go ahead and the solution to be built is handed over to the team that will build the solution via the chosen SDLC.

It is important that the architects are involved and all hand over activities are done face-to-face, with extensive discussion of what the documentation means.

9.2 Project initiation review

The project manager will produce some kind of project initiation document. This should be reviewed by the architect.

9.3 Notes for enterprise architects

The enterprise architect development process leads to the requirement for projects – or leads to guidance that independently planned projects must take on board. For each project, the enterprise architect should hand over to a solution architect to complete a solution that is ready to be built.

However, enterprise architecture is ongoing. The enterprise architect continues refining strategies, principles, standards and plans – while solution architects are working on solutions and supporting projects.

Note again that the work of enterprise architects overlaps with the work of solution architects. So enterprise and solution architects must work together to agree compromises and evolve the enterprise architecture. Hence, in addition to the generic architecture development process described so far, there is a need for architecture governance and change management processes. These are discussed briefly in the following section.

10. Step 9: Manage the architected system

This section contains only brief notes. The table below is intended to indicate that architecture development sits inside a framework of related processes.

An architecture process map
Enterprise architecture development		Change management
Governance	Solution architecture
	Solution implementation

10.1 Implement the architecture (solution development)

The solution to be built usually changes as a solution is developed. The development team may maintain the solution architecture description at a summary level, or develop it into a full architecture definition that covers everything the developers need (the main addition being development guidelines).

Of course, for any project involving software development, some kind of SDLC (software development life cycle) will be used, and architects have to work with whatever process is adopted.

It has been said that successful software project management is based on not so much on the SDLC as on:

· sizing, estimating,

· schedule planning, staffing, budgeting,

· tracking, measurement, quality control.

· change control.

Of these, change control can be the most important. But change control doesn’t mean preventing changes.

10.2 Govern the architecture

At one level, governance is merely part of directing a project. But higher level governance can cut across and through lower-level management activities. Governance is notoriously difficult – it is commonly reported as the biggest challenge facing enterprise architects.

The table below is intended to indicate that governance of the enterprise architecture cascades down through governance of solution architecture work to governance of specific application implementation projects.

The goal is to monitor and control the implementation at a lower level of principles and standards (including shared data and shared processes) that have been agreed at a higher level. The goal is not only to impose principles and standards, but also to collect feedback that helps to improve them.

10.3 Manage change to the architecture

The table is intended to indicate that changes to the enterprise architecture cascade down to become changes to the solution architectures of specific applications/projects.

Make sure your manager defines your role in change management. Among the activities listed in the distinct guide, an architect is likely to be responsible for “analyze change request” and “plan change”. You may also play a role as change manager and/or change builder.

10.4 Manage the architecture in operations

Finally, the architect may still be involved when the system goes live, and may work with IT operations people to resolve problems that arise.

The guide to architecture management elaborates on points made in this section; it is designed to work with PRINCE2.

11. Iterative enterprise architecture

Enterprise architecture efforts can go wrong in several ways. There is a place for the enterprise architecture who acts as librarian, but beware of documenting everything and doing nothing. There is a place for enforcing a gung ho IT strategy, but beware imposing a relatively costly and complex standard infrastructure o solutions that would better be kept simple, and perhaps stand alone.

Beware above all that stuff happens. The wider and longer the architecture development, the more likely that long-term targets will be undermined by change. An enterprise architect may reasonably expect that:

· The enterprise or unit business strategy will change yearly

· The IT strategy will have to change with overall strategy, or be weak

· Other divisional strategies will be out of date, or also subject to rapid change

· The business architecture will change each quarter

· The IS architecture will change each month with the acquisition and divestment of business units and/or systems (or even more quickly during a MDM/SOA/ESB programme).

The best you can hope is that the IT infrastructure architecture won't change significantly more than once in 3 years. So. plan iteratively, because change will happen. In an iterative approach, consistency of principles matters more than consistency of strategy. Don't plan in detail for a long-term future you may never reach. EA is not a one-off - it is a journey that never ends.

The table below shows the highly iterative approach proposed by Nic Harvard.

Step	E.g.
Start with one of the business objectives.	Grow sales.
Look in your business architecture for barriers and opportunities. Plan to remove them, work around them or take advantage of them.	Grow customer base.
Do something positive towards the business objective.	Acquire some competitors.
Look in your IS architecture for barriers and opportunities. Plan IS developments that will remove them, work around them or take advantage of them.	Integrate each acquired business's CRM data within 4 months.
Look in your IT architecture for barriers and opportunities. Plan IT developments that will remove them or work around them. The important thing is to make sure the infrastructure isn't toxic to your principles.	Don't invest in a monolithic ERP that cannot be unbundled. Don't roll out a single-domain AD where security and compartmentalisation is crucial - you need to the ability to quickly migrate a unit in or out of your network.
Start again.