Enterprise Architecture

Architecture is defined by the IEEE as “The fundamental organisation of a system embodied in its
components, their relationships to each other, and to the environment, and the principles guiding its
design and evolution “(IEEE, 2000). It is often divided up into multiple disciplines such as business,
technical, software, and the overarching umbrella of Enterprise Architecture.

In 1995 The Open Group developed a framework (The Open Group Architecture Framework – TOGAF)
that pulled all the disciplines together. This framework is marketed as a tool that can be used by
organisations to create their own architecture framework customised to their business or organisation.
The core part of the framework is the architecture development method (ADM) which is represented
graphically in figure 4. As the diagram illustrates there are 10 phases. Central to the ADM – as the
diagram shows – are requirements. These feed into every other phase, allowing them to be refined and
sometimes making a case for iteration within the phases.

The preliminary phase is concerned with identifying stakeholders, discerning the overarching drivers
and agreeing the need for change. The second phase, the architecture vision, positions the new
solution or architecture within the business and/or organisation structure, it sets the scope and creates
a high-level proposal to be agreed and approved by stakeholders. The architecture vision phase often
produces a roadmap that sets the direction for the development.

The third phase (B) is business architecture where a business architect or analyst will work with
stakeholders and users - usually in a series of workshops – to gather and refine requirements. This
phase concentrates on changes to processes, organisations and locations caused by the new project.

The next phase (phase C) looks at the information systems aspect of the project – it is mostly focused
on the data and applications affected by the design – including the need for new data and applications
and their design. This phase is often driven by solution and data architects and/or analysts.

Phase D is concerned with the technology architecture –that is the domain which includes platforms,
technical principles, compatibility with existing technology solutions and so on. It is often driven by
technical or infrastructure architects and analysts – cloud architects are often involved in modern
designs as well.
Page 1 of 3

University of Essex Online Page 1 of 3

Some providers refer to this collection of domains as POLDAT (process, organisation, location, data,
applications and technology). These phases may be iterative depending on the SDLC methodology
chosen – for example in agile methodologies each phase may produce a model or design that is
reviewed with users and refined as part of the cycle.

Phase E is the opportunities and solution phase. Although previous phases may have delivered
demonstration models and/or designs this phase sees the first working models. These bring together
requirements, feedback and lessons learned from the previous phases to deliver a target architecture.
In many cases this phase identifies opportunities to implement managed change via a series of
transition architectures which lead to the eventual target. Often the main output of this phase is an
implementation plan with milestones that identify the transition architectures. Sometimes this phase can
trigger an iteration back into phases B-D to look at the reuse of data, applications and/ or platforms.

Phase F is concerned with migration planning - I.e., how do we deliver/ deploy the new system(s) in the
least disruptive way possible? How do we transition users onto the new system? What about training,
migrating existing data, dual running, and so on? All these questions must be answered before any live
deployments can be attempted.

Phase G is implementation governance. This usually involves the project/ program manager and the
lead architect in equal parts. The project manager is responsible for planning and scheduling, the
architect is responsible for ensuring that the implementations comply with the designs as well as with
standards and principles – which includes those mandated by legislation, existing principles within the
organisation and those agreed as part of the architecture vision.

The final phase in the ADM is phase H – architecture change management. In many ways this is one of
the most important phases and the success of the overall project is often decided by how well this is
implemented. Many enterprise organisations set up an architecture change board that consists of
senior stakeholders, the programme manager and the lead (or enterprise) architect. It is responsible for
reviewing issues and challenges and deciding how they can be addressed and how it might affect the
original architecture. Sometimes challenges encountered can lead to a new requirement which means
the whole cycle runs again to produce a modified or supplementary solution.

Page 2 of 3

University of Essex Online Page 2 of 3

One of the major criticisms of the TOGAF approach was its lack of emphasis on security. This was
addressed in 2011 when TOGAF and SABSA (the Sherwood Applied Business Security Architecture)
published a whitepaper that detailed how the frameworks could be integrated (TOGAF-SABSA, 2011).
A schematic of the integration is shown in figure which illustrates where the SABSA security phases fit
into the TOGAF ADM.

As discussed above, architecture and the SDLC are intrinsically linked. For example, if a waterfall
approach is adopted then the phases would align with the stages of the waterfall model and each
phase/ stage would require sign off before continuing.

As discussed previously, the use of an agile approach may lead to an iterative approach to each phase,
and an object-oriented approach may require that a model is produced as one of the artifacts of the
design phases.

Figure 5 (taken from Pillai (2017)) shows a typical – but very simple - architecture for a web application.
It shows the use of several patterns including client-server (I.e., the user interface is separate from the
system that processes the data), multi-tier (the web application consists of three layers or tiers –
application, cache/ load-balancer, and database) and ETL (extraction, transformation and load - a
mechanism for transferring data between often incompatible systems). Design patterns exist in both the
architectural (I.e., design) and software (I.e., implementation) domains and they provide templates or
blueprints that help provide solutions – or at least starting points – to a problem. This is another
architectural principle – design reuse (also known as don’t reinvent the wheel).

The architecture, as discussed previously, will also drive the decisions about the tools and the
technologies selected. For example, the web application can be created using many different
languages (ASP.Net, PHP, Ruby, Python, etc), but if the business has existing Python systems and
employs a staff of experienced Python programmers then it is sensible to assume that Python would be
the preferred tool to use. The same argument would apply to the caching/ load balancing server and
the database.

Page 3 of 3

University of Essex Online Page 3 of 3