Enterprise Continuum v1C

Enterprise Continuum
Contents:
Architecture & Architects
Architecture Frameworks & methodologies
ISO/IEC 42010 (ANSI/IEEE 1471)
Zachman framework
Introduction to TOGAF
Architecture Modelling languages & techniques
Use Case
Stakeholder Analysis
Value Chain Analysis
Top Down Bottom Up
Functional & Non-functional requirements
CRUD matrix
Changes
List of standards
Migration Planning
Implementation Management
Governance & Control
Enterprise Continuum V1.1 Page 1

Architecture & Architects
What is an “Enterprise”?
An Enterprise is often described as a “big and complex business” while, in fact, enterprises do not have
to that big, it does give a good idea about how the term is perceived. Perhaps a better way to try and
define an Enterprise is to consider it as “a collection of organisations which establish an area of
common activities and resources so that they can achieve a common goal or goals”.
Organisations can mean many things: Segments, Business or Organisational Units, or Cost Centres for
example. Organisations may be one business or a collection of businesses. Enterprises can be long
term and strategic (such as the historic collaboration between Canon and Hewlett Packard which led to
the HP Laserjet series of printers), or short term and tactical (such as a small retail organisation with
expansion plans that works closely with several key suppliers in a mutually beneficial relationship). The
common area can even be found inside a single organisation if it is large enough.
Enterprises are co-operative endeavours, each organisation will set its own objectives and have its
own structure of management. The fact that these disparate businesses have chosen to work with each
other in pursuit of a common goal does not mean that there is no political conflict. The way an Enterprise
is put together and managed is something that needs to be understood by any aspiring Enterprise
Architect (EA).
What is “Architecture”?
Architecture has a specific meaning for EAs as you would suspect. EAs talk about “defining the
Architecture” or “Governing the Architecture”, or “Implementing the Architecture” etc. So what do they
mean by this term? Architecture is simply, the process for documenting and describing an Enterprise or
part of it. The BCS Reference Model provides two definitions:
1: documentation describing the structure (components) and behaviour (processes) of a

system. A detailed plan of the system to guide its implementation.
2: the process for describing the architecture of a system to meet given requirements and under
given constraints.
So if we want to understand how our Enterprise is put together we need architecture and guess who
creates this architecture?
The role of (IT) Architect

Yes – it’s the IT Architect (it is not advisable just to use the term Architect as
this has a special meaning and people will ask you to design their
extensions). In IT we need several types of IT Architect whose interest
ranges from coarse-grained or high level to fine-grained or detailed – this is
often called Granularity. Usually the narrower the scope of the architect the
finer grained the vision can be. The BCS reference model distinguishes
three levels of architecture granularity
 Enterprise level (includes domain level)
 Solution level
 Software level

General IT Architect Responsibilities
All IT Architects have the following responsibilities according to the BCS Reference Guide:
 Holistic understanding of business and technical goals

 Holistic understanding of business and technical environment
 Broad technical knowledge – including current trends
 Broad methodology knowledge
 Analysis of requirements and problems
 Innovation
 Leadership
 Stakeholder management
 Communication, political and soft skills
 Awareness of project management and commercial risks and issues
Source: BCS Reference Model
In addition each level of Architect has their own specific responsibilities which we shall be looking into
next.
What is Enterprise Architecture?

Enterprise Architecture is the highest of all the three levels. It stretches across the whole Business
looking long into the future. Strategy is a key focus of this architecture and this is what it documents and
models.
What is an Enterprise Architect?

The role of an EA is also obviously long term and strategic. The EA should link into the highest levels of
the business, thoroughly understand the strategic direction of the Enterprise and the drivers behind it
and should be capable of modelling, documenting and describing the Business in a way readily
understandable to its leaders. The EA should interface with peer specialists such as the PPMO (Project
& Programme Management team) and Service Delivery (aka ITIL) so that together they can assist in
delivering the Business Vision as expressed by the Corporate Leaders. Here is how they could interact:
An EA needs a wide and eclectic knowledge of everything IT. Databases, Networks, Software,
everything. The need is to be able to understand what the various specialists (in the “lower” layers) are
talking about. Have a look at this advert for an Enterprise Architect posted on a job site – it gives a good
idea of why EAs are so special:

The EA needs to be able to understand (and be understood by Business) but also feel at home with
other IT Architects and IT technical people.
As well as the general responsibilities described earlier, the BCS Reference Model lists these additional
responsibilities for the Enterprise Architect:
 Improved alignment of business and IT

 Improved IT cost-effectiveness
 Business agility
 Technical agility
 Long term planning: enablement of strategically beneficial IS/IT work
 Vendor and technology independence (portability)
 De-duplication of applications and technologies
 Interoperability of applications and technologies
 Simpler systems and systems management
 Improved procurement

Why does a business want an Enterprise Architect?
The usual reason is that the Business needs someone to get them from the Baseline to the Target
state. The Baseline state is how the business is now, the Target is what the business needs to become
if it is to be capable of meeting the vision laid down by Business Leaders. An example of a Business
nd
Vision could be “In five years’ time we want our business to be the 2 largest supplier of white goods, on
th
line, in the South of England”. At the moment this company is ranked 7 . To achieve the vision the
company will have to change – more depots will be needed, a more robust web site, a bigger sales team.
The Target will paint a picture of how the business needs to expand, and in what way, to meet the new
demand.
BCS consider that the EA plays an essential part in:
 Identifying the current IT/IS Baseline

 Identifying & describing the future IS/IT Target state
 Identifying the differences between the two
 Assisting with planning and governing the change to move from Baseline to Target
All businesses need coherent planning (an example of non-coherent planning is digging up the road
one week to lay electric cables and then digging it up again the following week to lay phone lines). The
practice of Enterprise Architecture supports structured and coherent planning within complex business
systems such as Enterprises. The EA does not act alone but can call in and co-ordinate the skills and
efforts of other IT Architects and experts such as Solution Architects and Domain Architects.
Scope of the brief

Enterprise Architecture sprang out of the IT industry however there are those who feel that the
Enterprise Architect should concern themselves with the wider implications of transforming an
Enterprise to meet a vision. In the industry most businesses expect the EA to be IT/IS focussed and
concentrate on making sure that the computer network (in its widest sense) supports the vision. The
latter view is the one supported by the Enterprise & Solution Architecture syllabus.
Architecture Domains
Enterprise Architecture covers a wide area of interests. When examining a business, or part of it, it is
often useful to work with a partial representation of the whole. Hiding or masking areas not of interest at
the time can bring clarity and focus to the architecture endeavour. These portions of the whole
Enterprise are called Architecture Domains and the people who understand and work with them are
known as Domain Architects.
Primary domains
Depending on who you talk to there are three or four major or primary domains (and a few “lesser”
domains which I will mention later). Both TOGAF and BCS agree on the number “4” so I will follow their
lead were possible. TOGAF & BCS do use slightly different names however so I will list them both here:
Business architecture: The structure and behaviour of a business system (not necessarily
related to computers). Covers business goals, business functions or capabilities, business
processes and roles etc. Business functions and business processes are often mapped to the
applications and data they need.
Data architecture: The data structures used by a business and/or its applications.
Descriptions of data in storage and data in motion. Descriptions of data stores, data groups and
data items. Mappings of those data artefacts to data qualities, applications, locations etc.

Applications or Application/Integration architecture: The structure and behaviour of
applications used in a business, focused on how they interact with each other and with users.
Focused on the data consumed and produced by applications rather than their internal
structure. In application portfolio management, the applications are usually mapped to business
functions and to application platform technologies.
Technical or Infrastructure architecture: The structure and behaviour of the technology
infrastructure. Covers the client and server nodes of the hardware configuration, the
infrastructure applications that run on them, the infrastructure services they offer to applications,
the protocols and networks that connect applications and nodes.
The reason why some people say there are three primary domains is that they lump Data & Application
together as IS (or Information Systems). Here is a slightly different view of what the domains are about:
Business Application/ Data/ Technology/

Integration Information Infrastructure
Business Enterprise Data architecture Servers

requirements applications Data integration Desktop
Business rules Integration Data management O/S
Organisational components Data quality Networks
structure(s) Custom Data delivery Middleware
Business applications architecture DB infrastructure
processes Services definition Business Security
Mission/ Vision Process alignment intelligence Physical Storage
Services/ Event Enterprise & housing
architectures reporting
Corporate
performance mgt
Data modelling
Content
management
Domain Architects cluster tightly under the Enterprise Architect. They work closely together
Architecture Domain Hierarchy

Although shown vertically under the Enterprise Architect in one of my
previous diagrams it is often better to think of the Architecture Domains
as being arranged in a layered hierarchy with the Infrastructure domain
at the bottom and Business at the top. Bottom layers act as a platform
to the next layer up and provide services.

Solution Architecture
The Solution Architect (SA) is the “fixer” the person who turns a specification into something that can be
implemented. The Enterprise & Domain Architects may identify the need for a Database and go on
further to specify some requirements of their Database (reliability, throughput, security etc) but it is the
Solution Architect who tells them “You want Oracle 11 mate” or similar. The Solution Architect is often
more closely involved with planning the actual implementation of the Arcitecture than the other
Architects and will often work alongside the Project and Programme Managers. If the EA is strategic
then the SA is essentially tactical
According to the BCS Reference Model as well as the general responsibilities discussed earlier the
following are specific responsibilities for the Solutions Architect:
 Timeliness of IS/IT project deliverables

 Cost of IS/IT project deliverables
 Quality of IS/IT project deliverables
 Solution-level risk identification and mitigation
 Application integration and data integrity
 Conformance of solution to non-functional and audit requirements
 Conformance of solution to principles, standards, legislation
 Effective interaction between managers and technicians
 Governance of detailed design to architecture principles and standards
Software Architect
The Software Architect is very much a detail person. They will often work with one application
understanding and modelling the internal structure and modules that a complex application uses (think
of SAP for example). Two complex applications that really need an expert software person on the team
are ERP (&/or SCM) & CRM systems.
Enterprise Resource Planning (ERP)

ERP is the planning of how enterprise resources (materials, employees, customers, etc.) are acquired
and moved from one state to another (eg manufactured, ordered and delivered)
An ERP system is a operational and business support system that maintains (ideally in a single
database) the data needed for some or all of Manufacturing, Supply Chain Management, Financials,
Projects, Human Resources, Customer Relationship Management, Data Warehouse and Management
Information.
Supply Chain Management System (SCM)

Supply chain management (SCM) is the oversight of materials, information, and finances as they move
in a process from supplier to manufacturer to wholesaler to retailer to consumer. Supply chain
management involves coordinating and integrating these flows both within and among companies. It is
said that the ultimate goal of any effective supply chain management system is to reduce inventory (with
the assumption that products are available when needed). SCM is similar to, and can be incorporated
into ERP
Customer relationship management (CRM)

CRM is the development and maintenance of mutually beneficial long-term relationships with
customers. It helps with some or all of the following: attracting customers, transacting business with
customers, servicing and supporting customer, enhancing customer relationships.
A CRM system is a business support system that helps this relationship management.

Summary of main architect roles
As a summary – this is how the BCS reference model describes the main IT Architecture roles:
Role What it does

Enterprise Defines principles, policies and plans that cover several solutions to several business
architect problems. Strategic long term view
Solution Describes the structure of solution to a business problem, which may include several
architect applications and technologies. Tactical view.
Software Describes how a single application is built from software modules, at a fine-grained
architect level.
Other Domains
As I said, there are several other domains sometimes mentioned. Here are a few of them:
 Information architecture
 Information systems architecture.
 Security architecture

Architectural Frameworks & Methodologies
An Architecture Framework describes how the Enterprise Architect (and associates) develop the target
architecture and help with planning & governing the implementation projects necessary. The framework
should provide a common language and a useful toolset that all actors in the work can use. Amongst
other things the framework needs to cover the following:
 Stakeholder analysis
 Scope
 Requirements
 Constraints
 Transition planning (positioning the Enterprise from Baseline to Target perhaps via an
Intermediate state)
 Governance (both implementation projects and architecture definition)
 A methodology lifecycle
There are lots of frameworks out in the world the most well-known is TOGAF however other names
which crop up are:
 The Zachman Framework for Enterprise Architectures (not really an Architectural Framework
many say but usually considered the starting point)
 The Open Group Architecture Framework (TOGAF)
 Federal Enterprise Architecture (FEA)
 Gartner Architecture Framework (GAF)
 ISO/IEC 42010 (also not really a framework actually a standard for one)
We will look at TOGAF, ISO/IEC 42010 & Zachman later in these notes but for now let’s look into what
a methodology is.
Methodology: the Architectural Cycle

How do you change the World? One step at a time! Ah, but you need to take the steps in the right order
otherwise you will veer off at a tangent. How do you know what direction to take? You need a vision of
the destination. Anyway, so much for philosophy anyone who has run a project knows that there is an
order to do things if you want to be successful. Follow the order and you get a successful outcome, if not
then not. For example this is a quick list of the order of things you need to do in any project:
 Set up Governance and planning bodies (the planning body is the project management team)
 Understand exactly what needs to be achieved
 Plan & cost the project
 Run the plan adapting as circumstances dictate
 Create the deliverables and test them to ascertain that them meet the customer’s requirements
 Tidy up loose ends, identify & record lessons, attend the post project party
This is the methodology or lifecycle or a project, each bullet point could be considered a phase or
process. Enterprise Architecture involve running projects so part of a good Architecture Framework
should be a description of the phases of the lifecycle or process and identification of the tasks needed to
perform each phase successfully.

Generic Architectural Cycle
Here is a generic Architectural life cycle which I will use in these notes
The life cycle breaks down this way:
Vision
This is the flash point or instigation or the cycle. It is the recognition that there is a need for the
Enterprise to change.
This is when the Enterprise Architecture team (doers) and the Architecture Governance Board (decision
makers) are formed. The scope of the work is determined and the Vision (what the expected end state
of the change is) decided. The work to be carried out in the Architecture Definition and Migration
Planning sections is planned (and if necessary a Business Case justifying this work is produced)
Architecture Definition
The EA and the Domain Architects roll up their collective sleeves and get to work understanding the
current state of the Enterprise (or rather the bits they are interested in this time). Once they understand
the Baseline they describe the Target state which is how the business needs to be to deliver on the
vision. Once both states are described it becomes possible for the team to perform a Gap Analysis
identifying the difference between the two states (illustrating what needs to change).
The Architecture Definition provides Architecture Descriptions which in this context refers to the act of
describing the structure and behaviour of an enterprise or system. An Architecture Description is
supposed to be more than just a model it should be a “comprehensive knowledge structure” (BCS
Reference Model). Many Architecture Frameworks stop at the Architecture Description stage handing
over all responsibility for implementation to other specialist. Some (such as TOGAF and our example)
continue the cycle into planning and oversight although they acknowledge that the EA’s input is usually
minor (perhaps a watching brief).
Migration planning
Now that the team knows what needs to be done the next step is to plan how to do it. Migration planning
involves Solution Architects and Programme & Project Managers working with the EA to produce a
programme of architecture implementation projects which, if sanctioned by the business, will transform
it into the shape needed to support the vision. The implementation projects should have Business
Cases written for them so that the Business Leaders can determine whether they should be authorised
to start.
Once this stage is completed the EA’s responsibilities are almost concluded.

Implementation Governance
The implementation projects run under the guidance of project and programme managers leaving the
EA to sit back and make sure that they are on track to deliver the requirements agreed when they
started. To ensure this is the case, the EA conducts audits and project reviews on behalf of the AGB.
The EA also accepts Requests For Changes (proposals to change what has been agreed) and Risks
(threats to the project/programme). The EA usually forwards these to the AGB for a decision and
passes the response back down.
Architecture Governance
This is the preserve of the Architecture Governance Board (or Governance Board or Architecture
Board). The AGB is formed of senior Business managers who usually have authority for the
organisations or business areas within the Enterprise which will be changed by this architectural work.
The AGB is appointed right at the beginning of the cycle (Vision in our example) then deploy when the
Architecture definition starts.
Architecture Repository
All the work performed by the Enterprise Architecture team, all their models and artefacts etc need to be
stored somewhere. Enterprise Architects tend to use the term Architecture Repository for this. The
BCS definition of an Architecture Repository is:
 An information base used by architects

 A system that holds and manages all the meta data that describes an enterprise and its
information systems
There are many ways of categorising the Architecture Repository. TOGAF & Zachman, for example,
use a tabular system (a grid composed of columns and rows).
ISO/IEC 42010
ISO/IEC/IEEE 42010:2011 is an ISO standard describing best practice to create Architectural
Descriptions of software intensive systems (Architectural Descriptions were described above). It started
life as ANSI1471 and is also known as IEEE1471. Whatever you call it, the standard addresses the
creation, analysis and sustainment of architectures of systems through the use of architecture
descriptions.
A conceptual model of architecture description is established and the required contents of an
architecture description are specified.
Amongst other things, the standard covers
 Architecture viewpoints
 Architecture frameworks
Architecture description languages are introduced for codifying conventions and common practices of
architecture description.

Architecture descriptions
I have already introduced Architectural Descriptions however there is a little
more to know about them.
For a start Architecture Descriptions are composed of smaller objects –
Artifacts and Entities
Entities
At the lowest level are Architecture Entities. These are the basic Building
Blocks of any Architecture Description being a single describable
component. If you think of an entity as something that is treated as a black
box you will not go far wrong. If I was making an Architecture Description of
my kitchen for example an entity could be “Washing Machine” or “Cooker” or
“Fridge”. I know what these things do and can describe what they need to be
for me to consider them as satisfactory (for example I can state the
dimensions and connections that a washing machine needs to conform to if it
is to fit in my kitchen); if the Washing Machine goes wrong I can replace it with another that conforms to
my idea of what a good washing Machine is (that’s after I’ve removed all the dog hairs from the filter
anyway!). Sometimes entities are split into sub-entities it depends on how much detail is needed in the
description, for example my washing machine could be sub-divided into “motor”, “pump”, “controller” etc.
Entities are usually associated with a particular domain. Often an entity is defined with a standard
template.
Artifacts
Are used to describe entities and the relationships between them. In a way, artifacts are models. For
example a plan of my kitchen could be considered an artefact as it shows were all the appliances are
located. Artifacts can be built up out of other artifacts as well (like a plan of my house).
Typically, entities are combined in lists (or catalogues), matrixes, or diagrams. Below is a common
artefact – a principles catalogue:

Mapping
Some types of artifacts are used for Mapping. This is the process of linking entities or items in different
structures together, examples could be:
 organisation unit to business function

 business function to application
 application to platform technology
 data entity to business function
 data entity to data store
 data entity to data quality
This can be used for such things as gap or impact analysis, requirements traceability, or cluster/affinity
analysis.
Not only artefacts can perform mapping, views can also perform this task
Deliverables
Anything output from an architecture project is considered to be an architecture deliverable
Architecture Description, Artifacts, and entities are all examples of deliverables.
Views & Viewpoints

Views and viewpoints are used a great deal
in Enterprise Architecture. They allow us to
understand and satisfy stakeholder’s
information needs. ISO/IEC 42010 has a
definition for both of these as you would
expect.
Viewpoint
The ISO definition of a viewpoint is: ““what
views of the same kind look like… a schema
or template… describing the purpose and
intended audience of the view”
A viewpoint identifies the information that a stakeholder needs to be provided with by the EA. It should
also define how that information is formatted and how and when it should be delivered.
It is a good idea to store old viewpoints for reuse by architects in the same organisation.
View
The ISO definition of a view is: “a representation of a whole system from the perspective of a related
set of concerns, to demonstrate to one or more stakeholders that their concerns are addressed in the
design of the system.”
Views are decomposable; An EA creates views by joining together artifacts (which can be used in other
views).
Views are instances of a particular viewpoint that is a viewpoint is a question and the view the answer.
As we have seen, a viewpoint defines a view’s scope (the concerns which need to be addressed). As a
stakeholders set of concerns rarely changes a viewpoint is comparatively stable however the same
cannot be said for its associated view – as the data changes the EA needs to make sure the view is also
refreshed.

Zachman framework
The Zachman Framework was developed by John Zachman who at the time was an IBM researcher.
As I have said, the Zachman Framework is not really an Enterprise Architecture framework it is probably
best regarded as a classification tool used in the field of Enterprise Architecture. Technically, a
classification is not real but helps us understand reality. For example a stamp collector could classify
stamps by colour another might categorise them by age. While the stamps themselves are real the
categories are not – they have been “imposed” on the real things so that the people interested in them
can gain a better understanding (in our example the two collectors wanted to understand their
collections from different directions).
Each stage usually is dealt with by different people with different skills, information needs, and outlooks
(rather like our two stamp collectors). As the work is passed over at the end of a stage a handover is
needed between the current group and the new owners.
Zachman came to realise that, as each stage of the cycle was inhabited by a different sets of people
with different needs and outlooks, the concept of thinking of the business as a single system
architecture was not as helpful as considering it as a collection of layered set of architectures.
In 1987, John Zachman published a different approach to the elements of system development. Instead
of representing the process as a series of steps, he organized it around the points of view taken by the
various stakeholder groups whom he arranged into six levels:
Group Example member Viewpoint

Planner Someone with a high level understanding Contextual
of an industry (or part of it). Has the long External Requirements and Drivers,
term view & broad picture of the business Business function modelling
Business The business people who run the Conceptual
Owner organisation Business Process Models, Business
function allocation, Elimination of
function overlap and ambiguity
Designer A systems analyst who wants to Logical
represent the business in a disciplined Logical system models, Project
form Management, Requirements definition
Builder A designer, who applies specific Physical design
technologies to solve the problems of the Physical (technology) models,
business Technology management, Solution
definition & development
Integrator/ The actual builder of the system (takes As built (actual implemented solution)
Implementer the design and makes it work) Configuration Management, Deployment
User The people who work in the system Functioning network

Functioning Enterprise, Operations
management, Evaluation

Zachman developed a 6x6 grid (the Zachman Framework) as “A logical structure for classifying and
organising the descriptive representations of an Enterprise that are significant to managers and to
developers of Enterprise systems.”
The 6 rows cover each of the perspectives (stakeholder groups and architecture viewpoints) outlined
above. They move through levels of idealisation-realisation from highest level context to operational
systems (Scope, Enterprise Model, System Model etc) however the rows should not be interpreted as
levels of decomposition
The 6 columns are primarily analysis questions (What?, How?, When? etc) the focus of these shifts
depending on who is asking the question (ie the row) they can also be seen as architecture domains
and are often re-titled as data, function, network (or Locations), people, time and motivation respectively.
These represent different areas of interest for each perspective.
Each row in the data column addresses understanding of, and dealing with the enterprise’s data. Row
one shows a list of items that concern the company. As you move down the matrix, you move to
progressively more rigorous descriptions of the data. Not only are the descriptions more detailed, they
are from the differing perspectives of the owner, designer, builder, operator, etc.
The rows of the function column describe the process of translating the mission of the enterprise into
successively more detailed definitions of its operations. As you move down the rows, the business
processes become more defined, until eventually executable code for the system can be produced.
The Network/ locations column is concerned with the geographic distribution of the enterprise’s
activities. Any enterprise which operates from two or more physical locations, will eventually need to
deal with intra-office communication, networking, networking protocols, etc. Similar to other columns,
moving down through the rows, shows the various perspectives and detailed definitions of
communications plans, and networking infrastructure needed to accomplish the communications
facilities a business would need to effectively operate their information systems in a geographically
distributed way.

Column four, represents the ‘who’ or the people affected by any information system. At a high level, this
is the various departments which will interface with an information system, but as you descend through
the rows, a more detailed description of who needs what for their particular job become apparent. The
final goal of this work is a system developed with the specific needs of the users in mind, and a set of
users trained in the operation of the system.
The Time column, details the ‘when’ of the system. A high level view of this column describes the
business events, but as the definitions become more detailed, definitions of particular functions and the
circumstances under which they should or should not be invoked become available. It is difficult to
describe this column in isolation, as it defines constraints on the various functions and processes
defined on other columns.
Finally the Motivation column addresses the ‘why’ of the system. Zachman describes this column as
“concerning the translation of business goals and strategies into specific ends and means”. At a high
level, strategic business goals are defined, and as more detail is added to the lower rows, specific
business rules emerge, which can be enforced through system business logic.

TOGAF
Introduction
Developed and maintained by members of The Open Group, The Open Group Architecture Framework
(TOGAF) is probably the most popular and highly used Architecture Framework in use today. TOGAF
includes a detailed methodology called the Architecture Development Method (ADM) and a set of
supporting tools, techniques and artefacts. TOGAF is designed to be customised and will work
alongside other frameworks such as Service Management and Project & Programme Management.
TOGAF may be used freely by any organisation wishing to develop an enterprise architecture.
History
TOGAF Version 1 (1995) was based on the Technical Architecture Framework for Information
Management (TAFIM), developed by the US Department of Defense (DoD).
The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building
on the TAFIM, which itself was the result of many years of development effort and many millions of
dollars of US Government investment.
Starting from this sound foundation, the members of The Open Group Architecture Forum have
developed successive versions of TOGAF and published each one on The Open Group public web site
The current version is TOGAF Version 9.1
ADM Cycle – the heart of TOGAF
The Architecture Development Method is the core of TOGAF.

As you would expect it is a step by step process which
explains how to develop an Architecture Definition then create
programme of works (the Implementation & Migration plan)
for implementing Enterprise change and provide
Implementation Governance of the said projects.
An iterative cycle of eight phases (centred round

requirements managements) with an additional phase
(Preliminary) tacked on at the beginning to get everybody
started. TOGAF focusses on the work of the EA; Solution
Architects play a big part in phases E and F as do Programme
Managers however they are rarely mentioned in the official
documentation.

How the cycle operates
Here is a quick diagram followed by a short explanation.
The ADM cycle starts with getting the right people together, that is those that have the technical ability to
perform an Architecture definition and senior managers who will support and direct them. A Request
for Architecture Work will be produced defining what the Technical Team (lead by Enterprise
Architects) is being asked to undertake.
If all is well then the cycle starts and the Phase A gets underway. Here the technical team plan how they
will undertake the Architectural Definition and Architecture Implementation planning parts of the cycle.
This is documented in the Statement of Architecture Work. The Enterprise & Domain Architects
commence to beaver away (phases B-D) moving through the four primary domains modelling the
baseline and desired target states of each and performing gap analysis.
In Phase E they construct an outline Roadmap (or schedule of projects showing how the Enterprise
could be transformed to meet its business needs.
In Phase F the outline Roadmap and its supporting Implementation & Migration Plan is costed and if
acceptable to senior managed finalised.
In Phase G the Implementation & Migration Plan is handed over to the Programme Managers to run
with the EA auditing the projects to make sure they stay honest and remain on track to meet
requirements.
The AGB are put together in the preliminary phase but move into Phase H after the Request for
Architecture Work has been approved. They perform oversight and governance of the Enterprise and
other Architects who have been involved doing the technical work. They consider Request For Changes
and other issues and risks.

Request for Architecture Work & Statement of Architecture Work
The Request for Architecture Work marks the start of a TOGAF ADM cycle in earnest. It is sent by the
project sponsor and gives the EA team the basic understanding that they require to start planning the
work.
Typical contents of the Request for Architecture Work are:
 Organisation Sponsors
 Organisation’s mission statement
 Business goals and changes
 Strategic plans of the business
 Time limits
 Changes in the business environment
 Organizational constraints
 Budget information, financial constraints
 External constraints, business constraints
 Current business system description
 Current architecture/IT system description
 Description of developing organization
 Description of resources developing organization has available
In Phase A the EA Team plans how they will perform the work which will create a programme of work to
make the necessary change. This information is contained in the Statement of Architecture Work.
The aim of the Statement of Architecture Work (SAW) is to act as a “control pack” for the Architecture
definition project.
That is the work needed to identify what needs to be changed and plan a programme of works to
implement that change.
Typical sections of a SAW are:
 Architecture project request and background

 Architecture project description and scope
 Change of scope procedures
 Risk procedures
 Periodic reports
 Roles, responsibilities and deliverables
 Acceptance criteria and procedures
 Architecture project plan and schedule
 Approvals
The ADM cycle is iterative

It is possible to cycle through phases or groups of phases
several times looping back as needed
The most common loops are illustrated on the diagram to
the right.
Quite often we get to the end of Phase F and present to the
AGB only to find that they have changed their minds and
back we go to Phase B to run through again.

How the Architects work in the ADM cycle
The cycle calls on the skills of all the architects as it progresses. The EA has a high level co-ordination
role as they have the long term strategic view necessary
Summary of TOGAF phases
Phase What it does ….

Preliminary Instigates the ADM
 Team set up
Enterprise  Governance & oversight set up
Architecture  Principles embraced
Capability
 The Request for Architecture Work is created (stating what Senior
Getting the team Stakeholders want the Team to accomplish)
together
A: Architecture  The start of the cycle!

Vision  Plans the work (Architecture Definition & Implementation planning)
 Creates the Architecture Vision (an explanation of how the transformed
Project Enterprise would look and why that would be a good thing)
Establishment  Performs a high level gap analysis between the baseline & target states
Enterprise  Performs stakeholder engagement & assesses capability of the Enterprise to
Capability do the work and accept the change and creates a Communication Plan
 Creates Statement of Work as a “response” to the Request for Architecture
work. The Statement of Work includes the plan to get to Phase F and all the
other project governance products necessary
B-D:  The Architectural Vision (the high level description of the gap that needs to
Business, IS, be closed) is looked at in more detail across the four domains
Technology  B: Business
Architectures  C: Application & Data
 D: Technology
Detailed Domain  A detailed Baseline & Target architecture is described
Definition
 The gaps between the two are identified
 Potential ways of bridging the gaps found and functional specifications
(Architecture Building Bocks) drawn up

E & F:  E & F concern themselves with how the gaps identified in B, C & D are to be
Opportunities & plugged.
Solutions  A combined Gap Analysis is performed
Migration  The best ABBs selected from the candidates discovered in Phases B-D are
Planning selected and converted into Vendor Specifications (Solution Building Blocks)
 A programme of works to implement the SBBs (the Roadmap) is created and
forms part of the Implementation & Migration plan
Planning the  Liaises with programme management team who will perform the
change implementation
G:  The delivery projects are underway but the EA still needs to keep an eye on
Implementation them
Governance  In phase G, Architectural Contracts are issued (to define and start the
Oversight & control projects)
of implementation  Audit the projects
projects  Handle change requests and other issues
H:  Home of the Architecture Governance Board (a group of senior business

Architecture managers drawn from the areas of the Enterprise to be impacted by this
Change cycle of the ADM)
Management  Highest authority for risk & change inside the ADM
 Scope is all of the ADM cycle
Architecture
Governance
Risk & Change
control
Requirements  Stores requirements
Management  Feeds them into the other phases as necessary (where they can be modified,
added to or removed)
 Collects them up at the end of the phase
 Performs impact assessments when requirements change

An example of the ADM Cycle
Preliminary Phase
You work for a business (an Enterprise) which makes scented candles. Traditionally you sell your
products from a string of shops but now your Managing Director (MD) has come up with the proposal to
start selling your products on the internet. As an Enterprise Architect (EA) your job is to:
1. Model how the business is now (baseline)

2. Model how the business will need to change to meet the MD’s requirements (target)
3. Work out the gap (what needs to change)
4. Then plan a programme of works to accomplish the change (hopefully you will get others to run
the projects implementing the change)
As a start you need to do the following:

 Get a team of experts together who can help you with the work (EA team)
 Make sure the EA team is capable of the work asked of them
 Set up a governance structure so that Senior Management have confidence that the EA work is
being completed satisfactorily
 Identify the business rules that the changes will need to conform to (the Principles)
At this point you update the Project Sponsor and create a summary of what the project is about (this is
the “Request for Architecture Work”) TOGAF states this is prepared by the Project Sponsor by the way.
Phase A: Architecture Vision

Having reached an outline agreement on what should be done, and having formed a team the next
phase is to establish the Architecture project.
You need to perform a rigorous stakeholder analysis and work out how you are going to engage with
major stakeholders. This will result in a Communications Plan.
In conjunction with Business leaders you will create the Architecture Vision which will describe the
eventual benefits of the change once it is implemented and how the transformed business will look.
You will need to scope the project and identify if the business has the capability to implement the
change and make use of it afterwards. For example does our IT dept have the necessary skills to build
a web site and will our customers use it once it is available?
You will draft a Project Plan, for the cycle and incorporate this into the Statement of Architecture Work.
You will create a container to hold the outcomes of your investigation, primarily the gap analysis of the
work; this will evolve as you investigate the changes necessary and is called the Architecture Definition
Document.
Finally you will also complete the Statement of Architecture Work which defines what you will do and
how the work will be controlled.

Phase B: Business Architecture
You sit down through numerous meetings with your business people and identify a business process
that your company can use to handle on-line sales (order taking, order fulfilment etc.). You break down
the process by dividing it into packets of functionality called “Building Blocks” (BBs). For example your
web server is a BB, as is your delivery organisation and the member of staff who assembles the order.
You illustrate how your BBs interact together by combining them into diagrams (pictures), catalogues
(lists) and matrices (showing relationships); you can use these to illustrate to stakeholders how they
work together. You end up with a model showing how your internet shop works from the business
process perspective. You will have identified the BBs that exist (we have people who assemble and
pack already) and what you need (we will need a process to handle order delivery) and what the
differences are – the gaps. You will identify possible ways of filling the gap (we could use a contract
packing company or take on extra staff for example).
Phase C: Information Systems Architecture

The next step is to build on the new business process identified in the Business Architecture to model
how the information System needs to change to accommodate it. Information Systems is usually split
into two parts (or architectures): Data Architecture and Applications Architecture:
The Data Architecture: describes what kind of data you need to take care of for your online
shop capability. Customer data, product data, payment data, shipping data, product pictures,
and ingredient lists, etc.
It also describes where the data comes from, where it flows to, who needs what data when and
so on. We see two types of data here: Structured data (what you'd place into a database) and
unstructured data (i.e.: flat files).
The Applications Architecture: describes what applications you need to handle your data:
Web portals, CRM applications, supply chain management applications, shipping and tracking
applications, order management applications, payment processing applications, candle
personalisation and mixing order processing applications etc.
More diagrams, more catalogues and more matrices are created to describe this stage of
building your on-line shop.
Phase D: Technology Architecture

The next step is to translate the Information Systems architecture into a Technology architecture. This is
when we describe what systems are needed and where. We map the application BBs and data BBs to
systems, the networks they are located on, which servers are connected how at what locations, etc.
At this point the function model of how our business must change and the gap between the present (the
baseline architecture) and the future (the target architecture) is complete. However the job is not
finished yet, we only know about the required functionality necessary to provide an on-line shop. The
functionality needs to be translated into something that can do the job.

Phase E: Opportunities and Solutions
The BBs identified in phases A – D were all generic in as much as they only described the functionality
needed (“we need a database server for this”). A database server is a database server, no matter if it
stores Candle types or Battleship specifications. The same can be said for a file server, a firewall or a
router. A business process to take an order at this stage does not differentiate if the order is for a candle
or a battleship. The BBs we have used are called Architecture Building Blocks (ABBs) to identify that
they only cover functionality. We have concentrated on functionality at the beginning of the ADM phase
to avoid clouding our vision with specific details. In phase E this stops and we need to consider actual
physical products. We select the ABBs to use (previous phases may have given us several alternative
ABBs for example or database could be on a workstation or a server or even on a card index!) then
convert them into Solution Building Blocks (SBBs) by making them Vendor aware.
So in Phase E we will move from the ABB of “Database”, for example, to the SBB of an “Oracle 11i
database running on a SPARC SuperCluster”.
Having this information allows us to start combining SBBs into work packages (for example server +
installation + configuration) and link the work packages into projects (e.g. data centre project) and time
lining them on the Road Map which forms an essential part of the draft Implementation & Migration
Plan.
We need to understand the capability of the Enterprise to both implement the change and to use the
changes in business so we perform a Business Transformation Readiness Assessment to gain this
understanding. The output from the BTRA will influence the number of transitions we will need to meet
our objectives plus identify possible mitigation activities to be worked into the projects on our Road Map.
Phase F: Migration Planning

This is where the Implementation & Migration Plan is finalised and an agreement is given by the senior
stakeholders that the implementation projects should go ahead. All the projects are costed and risked.
Suppliers are found and agreement is reached on delivery details, costs, timescales and escalation &
control. The delivery of the projects is not part of the EA brief (as opposed to governance) so hopefully
this task is given over to your Project Managers. You write a Lessons Learned Report about the
architecture definition part of the cycle and go off to plan something else
Phase G: Implementation Governance:

In this phase you provide oversight of your Project Managers, you conduct compliance assessments to
make sure the implementation projects are meeting your requirements and handle any Request For
Changes (RFCs) that the projects generate passing up to phase H as appropriate.
Phase H: Architecture Change Management

This is where the Architectural Governance Board (your boss) sits. The AGB keeps an eye on you to
make sure that you are conducting EA correctly and makes decisions on Requests For Change passed
to them. RFCs can come from a project (via Phase G), from the Architecture Development phases (B-D),
Transition Planning (E & F) or from the Enterprise itself.

The Enterprise Continuum
All the work products such as artefacts, plans, building blocks etc used by a framework need to be held
somewhere. In Enterprise Architect circles this is often called a Repository. Repositories (storage)
need to be organised (otherwise you can’t find anything). Showing how the models and artefacts can be
arranged is done in TOGAF by means of the Enterprise Continuum.
The Enterprise Continuum is a structure for the TOGAF architecture description documentation and
acts as a classification scheme. It consists of a 4x4 table or grid
The 4 rows represent levels of idealisation

The 4 columns represent generalisation-specialisation, ranging from universal to bespoke or uniquely
configured:
Column Focus
Foundation Generic: structures and items that are universal
Common Structures (composed of foundation items) that are used across most business
systems domains
Industry Structures and items used by Enterprises in one business domain (say Telecoms or
Banking)
Organisation Specific to one business: Structures and items specific or bespoke to a single
enterprise

TOGAF reference models
TOGAF provides two reference models to help practitioners begin to model and understand their
Enterprise, the Technical Reference Model (TRM) and the Integrated Information Infrastructure
Model (III-RM) both sit in the Architecture row of the TOGAF Enterprise Continuum
Both Reference Models have two main components:

 A taxonomy that defines terminology and provides a coherent description of the components
and conceptual structure of an information system
 An graphic that provide a visual representation as an aid to understanding
Technical Reference Model (TRM)

A Foundation Architecture (sits on the left of the Architecture Continuum), the
TRM provides a model and a taxonomy of generic platform services
Typically, a structure of components, services, processes or data entities.
Sometimes for a specific industry or business domain.
A kind of design pattern
The TRM is so abstract that just about any business or Enterprise can be
modelled by it. It is useful as when starting to do Enterprise modelling,
people can use the TRM as a guide to get them started in creating their own
more specific model.
Integrated Information Infrastructure Model (III-RM)

The III-RM is one column up from the TRM in the
Architecture row. It provides a model for business
applications and infrastructure applications with the
objective of showing how the vision of
Boundaryless Information Flow™ could be
achieved. This vision of the Open Group aims at
performing something laudable in an Enterprise
namely “only needing to input data once with it
being then available to everyone who has a
business justification”. I think there is no need to
explain why this would be such a good thing!
The Open Group took the TRM and expanded it to

show what was needed for Boundaryless
Information Flow to work in a business. As you
would suspect there is a great need for converters, brokering, and gateways.

Architecture models and languages
We talk a lot about Enterprise Architects modelling a business or system so perhaps we should look into
this area a little more closely
What is a model?
A model is a simplified description of something (or part of something), it provides a limited
representation of entities and events in the real world (in this case typically Enterprise based systems).
Being simplified it can mask out complexity and parts of the whole that would distract often providing
clarity of understanding to answer specific concerns or questions (you can draw the link between this
and views/viewpoints yourself).
Instead of model Enterprise Architects often use the terms artefact or view however recall that artefacts
(and views) are composed themselves of artefacts so sometimes a model is a little more complex
consisting of a number of artefacts and the mappings between them.
Do not think we are talking Airfix kits or Lego bricks here – in Enterprise Architecture models etc are
usually abstractions drawn as diagrams or matrixes.
Idealisation hierarchy
Models are a form of Idealisation and exist in a hierarchy moving
from high level conceptual through logical models to end up with
physical models
Often a good set of tools is helpful moving up and down this stack
and this is where MDA (Model Driven Architecture) can help out.
MDA is promoted by the Object Management Group. The idea is to
encourage vendors to develop tools that help transform models
between the layers going down (forward engineering) or going up
(reverse engineering) as we move between a conceptual model to
a logical model, and a logical model to a physical model.

Abstraction and related terms
(Definitions in this section quoted from the BCS Reference Framework)
When used as a technical term, Abstraction means some form of simplification or high level view
(modelling is a form of abstraction if you think about it)
BCS define Abstraction two ways:
1. 1: A process of composition, generalisation or idealisation by which shorter and more

general descriptions are produced from longer, more detailed and more specific
descriptions.
2. 2: A simplified description of a system that is made by the process at definition 1.
As we have seen there are several layers of abstraction from the highest conceptual view down to
physical models. The TOGAF Continuum can be viewed as a series of abstracted layers (the Zachman
cannot).
Usually the higher more abstract layers cover more scope than the detailed layers below them. EA’s
usually work with the highest levels of abstraction leaving the detail to other specialists. Obviously there
is an opposite process to Abstraction; this opposite is the process of adding more detail or becoming
more specific.
Abstraction is a tool that every architect must be able to use. Enterprise architects work with the highest
abstractions.
There are a number of terms associated with the term Abstraction and the BCS syllabus offers a precise
definition of each which I have assembled into table on the next page:

Abstraction terms Opposite …
Composition Decomposition
1: the assembly of parts into a whole; The opposite of composition.
Or 2: the organisation of units under a manager or Division of one composite or aggregate
owner; Or 3: the encapsulation of content inside a component or process into several
shell. components or processes. The conventional
The result is some kind of aggregate or composite advice is that it is difficult to maintain the
component or process. A composite contains its integrity of a hierarchical structure that is
components in some sense. decomposed more the three or four levels (or
more than a thousand elements) from the
A description made with reference to a whole,
top.
manager or shell is more abstract than one that
refers to its parts, units or content. Enterprise
architects tend to work with coarse-grained
components
Generalisation Specialisation
Abstraction from several specific components or The opposite of generalisation; the
processes into a more generic component or elaboration or division of a general
process. A generalisation contains only the common component or process into one or more
features of its specialisations. Enterprise architects specific components or processes. A
look to re-use generic components and services specialisation contains its generalisation in
some sense.
Idealisation Realisation
1: A kind of generalisation that produces a logical The opposite of idealisation; leads to the
description of a physical component or process. instantiation of physical materials. It can be
Reverse engineering to produce a description that viewed as forward engineering, as a
can be presented as the requirement for the real progression from requirement to solution
thing.
2: The separation of an interface from the
component(s) that realise the interface.
Enterprise architects define logical components and
services
How do we model? There are a number of Modelling Techniques and Modelling Languages that an
EA needs to be aware of – we will discuss these next.

System modelling techniques
System modelling techniques mostly developed because of software architects need to define software
architectures. There are two groups Structured and UML (Unified Modelling Language)
Examples of modelling languages are:
 Process models
 Data models
 Context diagrams
 Use case diagrams
 Data flow diagrams
 Interaction/sequence diagrams
I’ll give you a rundown of them now …
System modelling languages

A modelling language is defined by the BCS as “A standard that defines box shapes and line symbols
for drawing node-arc diagrams to represent relationships between things”. There are a three languages
that you should know about:
 Integration DEFinition (IDEF) language

 Unified Modelling Language (UML)
 ArchiMate
System objects have both behaviour (they do things) and state (they know things or they can be in one
of a number of positions). The behaviour and state of some objects can be incredibly complicated, so
complex in fact that developers can have difficulty understanding them. By providing a standard,
pictorial description of behaviour and/or state, system modelling languages help provide clarity and
understanding.
Integration DEFinition (IDEF) language

(http://www.idef.com/idef0.htm)
Overview
IDEF (for Integrated Definition) is a group of modelling methods that can be used to describe operations
in an enterprise. IDEF was created by the United States Air Force and is now being developed by
Knowledge Based Systems
IDEFØ is a method designed to model the decisions, actions, and activities of an organization or system.
IDEFØ was derived from a well-established graphical language, the Structured Analysis and Design
Technique (SADT). Effective IDEFØ models help to organize the analysis of a system and to promote
good communication between the analyst and the customer. IDEFØ is useful in establishing the scope
of an analysis, especially for a functional analysis. As a communication tool, IDEFØ enhances domain
expert involvement and consensus decision-making through simplified graphical devices. As an
analysis tool, IDEFØ assists the modeller in identifying what functions are performed, what is needed to
perform those functions, what the current system does right, and what the current system does wrong.
Thus, IDEFØ models are often created as one of the first tasks of a system development effort.
In December 1993, the Computer Systems Laboratory of the National Institute of Standards and
Technology (NIST) released IDEFØ as a standard for Function Modelling in FIPS Publication 183.

IDEFØ Concepts
The IDEFØ method has basic concepts that address each of the needs previously discussed. The basic
IDEFØ concepts include the following.
Cell Modelling Graphic Representation

The "box and arrow" graphics of an IDEFØ diagram show the
function as a box and the interfaces to or from the function as
arrows entering or leaving the box. To express functions, boxes
operate simultaneously with other boxes, with the interface
arrows "constraining" when and how operations are triggered and
controlled. The basic syntax for an IDEFØ model is shown in the
figure opposite.
IDEFØ Box and Arrow Graphics
Communication
IDEFØ concepts designed to enhance communication include the following:
 Diagrams based on simple box and arrow graphics.

 English text labels to describe boxes and arrows and glossary and text to define the precise
meanings of diagram elements.
 The gradual exposition of detail featuring a hierarchical structure, with the major functions at the
top and with successive levels of sub functions revealing well-bounded detail breakout.
 A "node chart" that provides a quick index for locating details within the hierarchic structure of
diagrams.
 The limitation of detail to no more than six sub functions on each successive function.
Rigor and Precision

The rules of IDEFØ require sufficient rigor and precision to satisfy needs without overly constraining the
analyst. IDEFØ rules include the following:
 Control of the details communicated at each level (three to six function boxes at each level of a
decomposition).
 Bounded Context (no omissions or additional out-of-scope detail).
 Diagram Interface Connectivity (Node numbers, Box numbers, C-numbers, and Detail
Reference Expression).
 Data Structure Connectivity (ICOM codes and the use of parentheses).
 Unique Labels and Titles (no duplicated names).
 Syntax Rules for Graphics (boxes and arrows).
 Data Arrow Branch Constraint (labels for constraining the data flow on branches).
 Input versus Control Separation (a rule for determining the role of data).
 Data Arrow Label Requirements (minimum labelling rules).
 Minimum Control of Function (all functions require at least one control).
 Purpose and Viewpoint (all models have a purpose and viewpoint statement).

Methodology
Step-by-step procedures are provided for modelling, review, and integration tasks.
Organization versus Function

The separation of organization from the function is included in the purpose of the model and carried out
by the selection of functions and interface names during model development. This concept is taught in
the IDEFØ course, and the continual review of these concepts during model development ensures that
organizational viewpoints are avoided.
Sequence and Timing Independence

Applying the IDEFØ method results in an organised representation of the activities and the important
relations between these activities in a nontemporal fashion. IDEFØ does not support the specification of
a recipe or process. Such detailed descriptions of the specific logic or timing associated with the
activities requires the IDEF3 Process Description Capture Method.
Strengths and Weaknesses of IDEFØ

The primary strength of IDEFØ is that the method has proven effective in detailing the system activities
for function modelling, the original structured analysis communication goal for IDEFØ. Activities can be
described by their inputs, outputs, controls, and mechanisms (ICOMs). Additionally, the description of
the activities of a system can be easily refined into greater and greater detail until the model is as
descriptive as necessary for the decision-making task at hand. In fact, one of the observed problems
with IDEFØ models is that they often are so concise that they are understandable only if the reader is a
domain expert or has participated in the model development. The hierarchical nature of IDEFØ
facilitates the ability to construct (AS-IS) models that have a top-down representation and interpretation,
but which are based on a bottom-up analysis process. Beginning with raw data (generally interview
results with domain experts), the modeller starts grouping together activities that are closely related or
functionally similar. Through this grouping process, the hierarchy emerges. If an enterprise's functional
architecture is being designed (often referred to as TO-BE modelling), top-down construction is usually
more appropriate. Beginning with the top-most activity, the TO-BE enterprise can be described via a
logical decomposition. The process can be continued recursively to the desired level of detail. When an
existing enterprise is being analysed and modelled (often referred to as AS-IS modelling), observed
activities can be described and then combined into a higher level activity. This process also continues
until the highest level activity has been described.
One problem with IDEFØ is the tendency of IDEFØ models to be interpreted as representing a
sequence of activities. While IDEFØ is not intended to be used for modelling activity sequences, it is
easy to do so. The activities may be placed in a left to right sequence within a decomposition and
connected with the flows. It is natural to order the activities left to right because, if one activity outputs a
concept that is used as input by another activity, drawing the activity boxes and concept connections is
clearer. Thus, without intent, activity sequencing can be imbedded in the IDEFØ model. In cases where
activity sequences are not included in the model, readers of the model may be tempted to add such an
interpretation. This anomalous situation could be considered a weakness of IDEFØ. However, to
correct it would result in the corruption of the basic principles on which IDEFØ is based and hence
would lose the proven benefits of the method. The abstraction away from timing, sequencing, and
decision logic allows concision in an IDEFØ model. However, such abstraction also contributes to
comprehension difficulties among readers outside the domain. This particular problem has been
addressed by the IDEF3 method.

Unified Modelling Language (UML)
UML- Unified Modelling Language is a modelling language designed initially to provide a standard way
of visualising a system, primarily aimed at software design.
Developed during 1994-96, it was adopted in 1997 by the Object Management Group (OMG) and has
been controlled by them ever since. In 2000 it was accepted by ISO as an International standard and
has been regularly revised, the last formally released revision being 2.4.1 in 2011.
UML is not a development method in itself but was designed to be compatible with the leading Object
Oriented software design methods.
UML Classes
In UML Classes are used to represent Objects. An
Object can be anything having properties and
responsibility.
The UML symbol for a Class is a rectangle which is
divided into four parts:
 Class name
 Class attributes
 operations performed by the class.
 (optional ) shows any additional components
A Component is used to represent any part of a system for which UML diagrams are made

Structural and Behavioural Diagrams
A diagram is graphical representation of part of a model. Models therefore, are typically made up of
many diagrams. UML has 2 main classes of diagrams, structural and behavioural. The diagram
below shows the different classes of UML 2 diagrams:
Structural Diagrams – depict what must be present in a system being modelled. A component diagram
is an example of a structural diagram.
Here is an example of a very basic component diagram, depicting something that you may have learned
in a science lesson at school.
In this example each component (cloud, air, lake) is a complicated subsystem that connects with
another component by producing a requirement (condensation, precipitation, evaporation) needed by
another component..

Behavioral Diagrams – emphasise what must happen in a system being modelled.
A state machine diagram is a common example of a behavioral diagram and models the behaviour of
an object. To understand complex classes better, particularly those that act in different manners
depending on their state, you should develop one or more UML 2 state machine diagrams (formerly
called state chart diagrams in UML 1.x) describing how their instances work. A State Machine Diagram
specifies the sequence of states that object goes through during its lifetime in response to events.
Here is an example of a basic state machine diagram depicting the states and events relating to a
door
The states of the door are depicted in the oblong boxes. The door can be in one of three states: Opened,
Closed or Locked
It can respond to the events: Open, Close, Lock and Unlock
Not all events are valid in all states ie if a door is open you cannot lock it until you close it.
Some events can also have conditions applied to them ie when transitioning from open to closed state,
we can apply a ‘guard condition’ that will not let us close the door if the doorway is not empty (doorway
->isempty)

ArchiMate
Is a system modelling language supported and developed by the Open
Group seen by them as complimentary to TOGAF
Archimate is similar to UML and other modelling languages and is

designed to support the visualisation, description, and analysis of
architecture within and between business domains. It offers a common
language allowing description of the operation and construction of
business processes, informational flows, IT systems, technical
architecture and organisation structures.
Archimate was developed in the Netherlands between 2002 and 2004,
it’s ownership and stewardship being transferred to the Open Group in
2008. It is now managed by the Archimate Forum, which is part of The
Open Group. Archimate 1.0 standard was published in 2009 and the
latest version 2.1 was released in 2013.
Layers
In Archimate the architecture is divided into 3 layers: business, application and technology.
Business Layer – consists of business processes, services, functions and events of business units. It
offers products and services which are realized in the organization by business processes performed by
actors and roles.
Application Layer – consists of software applications that provide services to support the business
Technology Layer – consists of hardware and communication infrastructure components that provide
infrastructural services that support the application layer.
The general structure of models within each layer is similar, using similar concepts and relationships,
although the exact nature and detail will vary.

Within each layer are 3 main elements:
 active structure elements – subjects that are performing behaviour

 behaviour elements – units of activity performed by active structure elements
 passive structure elements – objects on which the behaviour is being performed
.
The diagram above also includes
 a service element – a unit of functionality that a system exposes whilst hiding its internal
operations
 an interface element – a point of access where one or more services are made available to the
environment
In addition to these basic elements, Archimate also includes a motivation extension that allows
modelling of concepts such as goal, principle and requirement. This element permits describing the
context or reason lying behind the architecture of an enterprise.

Use Case
Use Cases
A use case (literally a “Case of Use”) is a methodology used in system analysis to identify, clarify, and
organise system requirements. A Use Case describes how an Actor uses a System (usually to support
an OPOPOT business process step). A use case provides context for understanding system
development requirements and thereby provide the analysis necessary in finding out the functional
requirements of a software system. By ‘use’ we refer to how an actor (a person, system or computer)
may need to use a system in order to carry out an objective or set of objectives.
The use case is made up of a set of possible sequences of interactions between systems and users in
a particular environment and related to a particular goal. It consists of a group of elements (for example,
classes and interfaces) that can be used together in a way that will have an effect larger than the sum of
the separate elements combined. The use case should contain all system activities that have
significance to the users.
A Use Case usually has one main path and several alternative (or exception) paths. The details of each
step (including any automated services invoked) may be documented separately from the use case
itself.
A use case can be text based (Use Case Description) or visual in the form of a (Use Case Diagram).
Use cases can be employed during several stages of software development, such as planning system
requirements, validating design, testing software, and creating an outline for online help and user
manuals.
Benefits of Use Cases

Use Cases are valuable as they attempt to describe a system from the external usage viewpoint, rather
than from developer's perspective.
Use cases are useful because they help explain how the system should behave and in the process, they
also help brainstorm what could go wrong. They provide a list of goals and this list can be used to
establish the cost and complexity of the system. Project teams can then negotiate which functions
become requirements and are built.
What Use Cases Include

 Who is using the system
 What the user wants to do
 The user's goal
 The steps the user takes to accomplish a particular task
 How the system should respond to an action
What Use Cases Do NOT Include

 Implementation-specific language
 Details about the user interfaces or screens.

Elements of a Use Case
Depending on how in depth and complexity that is needed, a use case describes a combination of the
following elements:
 Actor – anyone or anything that performs a behaviour (who is using the system)
 Stakeholder – someone or something with vested interests in the behaviour of the system
under discussion
 Primary Actor – stakeholder who initiates an interaction with the system to achieve a goal
 Preconditions – what must be true or happen before and after the use case runs.
 Triggers – this is the event that causes the use case to be initiated.
 Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
 Alternative paths [Alternative Flow] – these paths are a variation on the main theme. These
exceptions are what happen when things go wrong at the system level.
How to write a Use Case

Write the steps in a use case in an easy-to-understand narrative. Kenworthy (1997) outlines the
following steps:
1. Identify who is going to be using the system.

2. Pick one of those users.
3. Define what that user wants to do on the system (each thing the user does on the site becomes
a use case)
4. For each use case, decide on the normal course of events when that user is using the site.
5. Describe the basic course in the description for the use case. Describe it in terms of what the
user does and what the system does in response that the user should be aware of.
6. When the basic course is described, consider alternate courses of events and add those to
"extend" the use case.
7. Look for commonalities among the use cases. Extract these and note them as common course
use cases.
8. Repeat the steps 2 through 7 for all other users.

Use Case diagrams
A use case diagram is a kind of Unified Modelling Language (UML) diagram defined by Object
Management Group (OMG), created for use case analysis. Use case diagrams provide visual
representations of the use cases and provide for easier understanding and stakeholder engagement.
Common symbols in Use Case Diagrams are:
Use case diagram provides a graphical overview of goals (represented by use cases) users
(represented by actors) want to achieve by using the system (represented by system boundary but is
often left out in the diagram).
The main purpose of modelling with a use case diagram is to establish a solid foundation of the system
by identifying what the users want. Based on the result of analysis you can move forward to study how
to fulfil those user needs.
Here is an example of a use case diagram, depicting how actors may use the system to carry out their
objectives which in this instance are to:
 Sell a holiday by placing an advert

 Accept the advert onto a Holiday Booking web site
 Book a holiday and an excursion
In the above example, we identify that the Customer requires to system to Select (a) Holiday, Book
(a) Holiday and Book (an) Excursion. The Holiday company (User) needs to Place (an) Advert and
the Web Admin needs to Insert (the) Advert onto the web site.

Use Case names
Use cases are named with verb or verb + noun phrase. The name is usually short yet descriptive
enough to describe a user objective. It is advisable to use concrete and specific verbs and nouns to
avoid ambiguity. Verbs like 'do' and 'perform' and nouns like 'data' and 'information' should be avoided
whenever possible.
A User performs a use case to achieve an observable goal. Take the online hotel reservation system as
an example. "Make reservation" is undoubtedly a use case as this describes what a user wants to
achieve with the system. The function of looking up a hotel on an online map can also be what a user
needs. However, it is not a use case because it is only a part of the reservation process instead of an
objective.
Some analysts try to make use of use case to describe user interface requirements (e.g. support
multiple look & feel), performance requirements (e.g. load in background), deployment arrangement
(e.g. ready server) and even implementation level (internal) requirements (e.g. construct database). All
these are wrong and will not help you in identifying the objectives user want to achieve, thus the
functions the system should deliver.
Use Case descriptions

Use case descriptions often provide more detail into the relationships between an actor and a system
than Use Case Diagrams
Use case descriptions provide a list of steps which depict interactions between user and a system. Use
case descriptions aim at depicting the main path which yields the desired outcome, but also identify
where there may be exceptions to the rule and alternate outcomes to a process
Here is an example Use Case Description for making a reservation:
.
USE-CASE: MAKE ONLINE RESERVATION
BRIEF THIS EVENT ENABLES THE USERS OF THE SYSTEM TO MAKE AND RECORD A
DESCRIPTION: RESERVATION BY ENTERING THEIR PERSONAL DETAILS AND VACATION DETAILS.
THE SYSTEM WILL CHECK ON ROOM AVAILABILITY, RECORD THE RESERVATION
DETAILS AND DISPLAY THE CUSTOMERS TOTAL PAY.
TRIGGER: CUSTOMER INQUIRY TO MAKE RESERVATION
ACTOR/S: CUSTOMER
RELATED <INCLUDE>CHECK ROOM AVAILABILITY
USECASE/S:
PRE OPEN MAIN PAGE OF SITE, ENTER VALID PERSONAL DETAILS AND PAYMENT
CONDITION: DETAILS
POST DISPLAY RESERVATION SUCCESSFULLY COMPLETE MESSAGE, STORE
CONDITION: RESERVATION AND CUSTOMER DETAILS TO DATABASE, ASSIGN A UNIQUE
RESERVATION CODE, DISPLAY UNIQUE RESERVATION CODE

MAIN FLOW: ACTOR SYSTEM
1.OPENS MAIN PAGE AND SELECT 1.1VERIFY REQUEST, OPEN RESERVATION
RESERVATION LINK PAGE AND DISPLAY RESERVATION FORM
2.FILL RESERVATION
FORM(NAME,SURNAME,ADDRESS,
PHONENO,VACATION DATES, ROOM
TYPE, NO OF PEOPLE)
3.SUBMIT FORM
3.1CHECK FOR DATA VALIDITY
3.2CHECK ROOM AVAILABILITY
ACCORDING TO VACATION DATES, ROOM
TYPE, NO OF PEOPLE
3.3DISPLAY CONFIRMATION PAGE WITH
RESERVATION DETAILS AND TOTAL PAY
AMOUNT
4.1DISPLAY PAYMENT OPRIONS PAGE
4.SELECT CONFIRM LINK
5.SELECT SUITABLE PAYMENT
OPTIONS AND SUBMIT 5.1DISPLAY PAYMENT DETAILS FORM
6.ENTER PAYMENT DETAILS (CREDIT
CARD NO, NAME, SURNAME, 6.1VERIFY PAYMENT DETAILS
ADDRESS…) 6.2DISPLAY PAYMENT DETAILS FOR
CONFIRMATION
7.CONFIRM PAYMENT DETAILS 7.1STORE RESERVATION DETAILS AND
PAYMENT DETAILS TO DB WITH UNIQUE
RESERVATION CODE
7.2DISPLAY RESERVATION SUCCESS.
COMPLETE MSG. AND UNIQUE
RESERVATION CODE
EXCEPTION 3.2 IF FORM FIELD ARE LEFT BLANK
CONDITIONS: THEN RE-DISPLAY FORM WITH (*) SIGN AND DISPLAY INFO. MESSAGE
3.2 IF INVALID DATA ENTERED
THEN RE-DISPLAY FORM WITH INVALID DATA MESSAGE
3.3 IF NO ROOM AVAILABLE ACCORDING TO VACATION DETAILS
THEN RE-DISPLAY FORM TO SELECT ANOTHER ROOM TYPE
3.3 IF NON OF THE ROOM TYPES AVAILABLE
THEN DISPLAY HOTEL ROOM UNAVAILABILITY MESSAGE AND RE-DISPLAY
FORM FOR USER TO SELECT DIFFERENT VACATION DATES
6.2 IF INVALID PAYMENT DETAILS ENTERED, THEN RE-DISPLAY PAYMENT FORM
WITH INVALID DATA MESSAGE

Stakeholder Analysis
Basic terminology
Stakeholders Person or role with power over and/or interest in work to be done or its deliverables
A person who has one or more concerns about the system to be built (because they
own it, manage it, use it or other reason).
Concerns Something that a stakeholder needs to know about a system

A general kind of requirement (e.g. availability, usability) that is important to one or
more stakeholders in the system, and determines the acceptability of the system to
those stakeholders.
A concern may be addressed in several view points
View point A collection of concerns
View The information provided by the EA to satisfy the questions of a View point
Introduction
Formal architecture is typically introduced to an organisation because key people (stakeholders) have
concerns about the ‘ad-hoc’ nature of IT Systems development and the lack of alignment between
business needs and the technology that is introduced. Concern is used in a technical not colloquial
sense to describe what interests a stakeholder. The role of the architect is to address these concerns,
by identifying and refining the requirements that the stakeholders have, developing views of the
architecture that show how the concerns and the requirements are going to be addressed, and by
showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of
different stakeholders. Without the architecture, it is unlikely that all the concerns and requirements will
be considered and met.
Definition of Stakeholders
There are many definitions of what a stakeholder is. Below two of these definitions have been listed:
“Anyone who has an interest in, or may be affected by, the issue under consideration.”
(British Computer Society)
“An individual, team or organisation (or classes thereof) with interests in, or concerns relative to,
the outcomes of the architecture. Different stakeholders with different roles will have different
concerns.”
(TOGAF)
So in summary Stakeholder(s) are:
 Interested in a project
 Affected by a project
 Can influence a project

What is Stakeholder Management used for?
Stakeholder management is usually identified in the initiation and includes the following:
 To determine levels of power and Interest of key stakeholders

 Plan fact finding and communication strategy
 Understand – analyse needs from fact finding
 Manage expectations
Why we need Stakeholder management

Stakeholder management allows architects to win the support of stakeholders thus enabling us to
define architecture successfully due to the following benefits:
 Powerful stakeholders can be identified upfront which means that we can uses their input to
shape the architecture which enables architects to improve the quality of the architectural
model procedures
 Support from powerful stakeholders cab help to win more resources
 Knowing your stakeholders and communicating with them regularly can lead to a more clear
and concise detailed architecture
 Increased anticipation of reactions to reactions to the architecture means that architects are
more likely to anticipate changes as react in positive manner
 Architects can identify competing and conflicting objectives early on and develop a strategy to
deal with them early on
A stakeholder methodology
The following is a 4 step way to handle Stakeholders advocated by TOGAF:
1. Identify Stakeholders
2. Classify Stakeholder Positions
3. Determine Stakeholder Management Approach
4. Tailor Engagement Deliverables
(1) Identifying stakeholders

It is key that Stakeholder are identified upfront by architects. It is often recommended to brainstorm as
many relevant stakeholders up front. When brainstorming the following questions should drive
stakeholder identification:
 Who is at benefit and disadvantage from this change?

 Who controls the change?
 Who makes the decisions?
 Who controls the resources?
 Who has the specialist skills the project needs?
 Who has influence?

Categorising Stakeholders
There are various categories of stakeholders. A list of generic Stakeholder categories is listed below
 Owners
 Customers
 Suppliers
 Employees
 Managers
 Partners
 Regulators and legal bodies
 Competitors
There are three key types of Stakeholder:

 Project Stakeholder
 Business Stakeholders
 External Stakeholders
Project Stakeholders
 Project Manager- Day to day control
 Business Analysts - Elicitation & Analysis
 Solution Developers - Technical feasibility, Produce prototypes
 Testers - validating that requirements are testable
 Architects
Business Stakeholders
 Project Sponsor - Ultimately paying for project, Signs off the requirements
 Subject matter expert - Local SME :Understands the business, Domain SME: Understands the
industry
 End users and managers: For whom the solution is designed
External stakeholders
 Customers
 Regulators
 Suppliers - Products and services
 Competitors - Can be difficult to engage with

(2) Classifying Stakeholders Positions (Stakeholder Analysis Matrix)
Below is an example of classifying stakeholders based on their commitment and understanding. There
are three key rankings high, medium and low.
Stakeholder Group
Ability to disrupt
Require support
Understanding
Understanding
Commitment
commitment
Stakeholder
Required
Required
Current
Current
change
Line
Sara Jane M M M H M M
Manager
Mark
CEO H M H H M M
Johnson
Christopher
CFO H L M L M H
Smith
(3) Determine Stakeholder Management Approach (Power/Interest Matrix)

When identifying and classifying stakeholder we can end up with a long list of stakeholders of which
some can have the power projects in either a positive or negative manner. So working out power,
interest and influence can help focus stakeholder engagement to get key information that is vital to the
project. The following technique will enable architects to devise the correct strategy for maintaining and
engaging in stakeholder relationships.
First identify your stakeholders by the Power (influence they have over the project) and Interest (what
their information needs are) using the following table as a guide:
High Some None

Power (to influence Can change the Has some influence Have (or feel they have)
the project) direction of the project Would be listened to no ability to influence
Tend to be directors or (possess specialist the project
senior management knowledge) End users typical
level of affected area Lower level managers,
Make project decisions senior managers of
non-affected areas or
supervisory level
Have the ear of those
making decisions
Interest Directly affected or Indirectly affected or Not affected by the
impacted by the project impacted by the project project
Is of a major concern Not sole concern, more
Employees in affected pressing or many other
area concerns
Users Employees in a related
area

Next construct a Power/Interest grid and plot your stakeholders onto it.
As a guide to the categories I have included the following table:
P/I Category Information needs

Keep satisfied These are Senior Managers & Leaders (think Board Members) who need to be
kept abreast of matters but from a high level
Key Players This group are likely to be more involved with the project possibly on a day-day
(or at least frequent) basis. The Project Sponsor would fit into this category
Keep Informed Someone who will be involved in the work but does not have the authority to stop
or change the work. Someone working in the programme or project for example.
In the case of EA then Programme & Project Managers often fit in here.
Minimal Effort People who cannot stop the work and have very few information needs.
Roles are cumulative so, for example, if Sue is a member of the Board (“Keep Satisfied”) and because
of another role she performs is also categorised as “Keep Informed” she goes in the “Key Player” box in
the power interest matrix.
(4) Tailor Engagement Deliverables

Engagement Deliverables is the term sometimes used by TOGAF to describe Views. In Stakeholder
Analysis we identify each Stakeholder Group then define (with them of course) their concerns which
form viewpoints and then lastly create Views (Engagement Deliverables) to satisfy the interest. Views &
Viewpoints have been discussed earlier so do not concern us here.
Here is a snippet from the TOGAF document showing Stakeholder details:

Value chain analysis
Introduction
Value Chain Analysis is a key tool for Enterprise Architects. Value Chain Analysis describes the
activities that take place in a business and relates them to an analysis of the competitive strength of the
business. Understanding the business in this way helps us identify:
1. Which activities are best undertaken by a business and which might be better outsourced
2. If the business process is structured correctly
3. If there is any waste in the process which can be removed
Value Chain Analysis was first described by Michael Porter in his 1985 book Competitive Advantage so
it has been around for some time and is well understood by Senior Managers, as such you will probably
use the VCA diagram as part of your Views for CxOs.
Porter introduced a generic value chain model that comprises a sequence of activities found to be
common to a wide range of firms; he identified groups of primary and support activities:
(1) Primary Activities - those that are directly concerned with creating and delivering a product
(e.g. component assembly)
(2) Secondary (Support) Activities - which whilst they are not directly involved in production,
may increase effectiveness or efficiency (e.g. human resource management)
The goal of these activities is to offer the customer a level of value that exceeds the cost of the activities,
thereby resulting in a profit margin. It is rare for a business to undertake all primary and support
activities.
Primary Activities
Value Chain Diagram for a Mail Order company

Primary value chain activities include:
Primary Activity Description

Inbound logistics All those activities concerned with receiving and storing externally sourced
materials
Operations The manufacture of products and services - the way in which resource inputs
(e.g. materials) are converted to outputs (e.g. products)
Outbound All those activities associated with getting finished goods and services to buyers
logistics
Marketing and Essentially an information activity - informing buyers and consumers about
sales products and services (benefits, use, price etc.)
Services All those activities associated with maintaining product performance after the
product has been sold
How the Value Chain Analysis can be used

 Modelling the business in this ways allows the Enterprise to gain
What activities a business undertakes is directly linked to achieving competitive advantage. So using a
diagram that models a process as a series of value generating activities makes sense. The diagram will
help leaders identify what needs to be changed to achieve their strategic visions. A competitive
advantage could be gained by:
 Cost advantage: by better understanding costs and squeezing them out of the
value-adding activities.
 Differentiation: by focusing on those activities associated with core competencies and
capabilities in order to perform them better than do competitors.
For example, a business which wishes to outperform its competitors through differentiating itself
through higher quality will have to perform its value chain activities better than the opposition. By
contrast, a strategy based on seeking cost leadership will require a reduction in the costs associated
with the value chain activities, or a reduction in the total amount of resources used.
Once the value chain is defined, a cost analysis can be performed by assigning costs to the value chain
activities. The costs obtained from the accounting report may need to be modified in order to allocate
them properly to the value creating activities.
Porter identified 10 cost drivers related to value chain activities:

 Economies of scale
 Learning
 Capacity utilisation
 Linkages among activities
 Interrelationships among business units
 Degree of vertical integration
 Timing of market entry
 Firm's policy of cost or differentiation
 Geographic location
 Institutional factors (regulation, union activity, taxes, etc.)
A firm develops a cost advantage by controlling these drivers better than their competitors.
A cost advantage also can be pursued by reconfiguring the value chain. Reconfiguration means
structural changes such a new production process, new distribution channels, or a different sales
approach. For example, FedEx structurally redefined express freight service by acquiring its own planes
and implementing a hub and spoke system.
Linkages Between Value Chain Activities
Value chain activities are not isolated from one another. Rather, one value chain activity often affects
the cost or performance of other ones. Linkages may exist between primary activities and also between
primary and support activities.
Differentiation and the Value Chain

A differentiation advantage can arise from any part of the value chain. For example, procurement of
inputs that are unique and not widely available to competitors can create differentiation, as can
distribution channels that offer high service levels.
Differentiation stems from uniqueness. A differentiation advantage may be achieved either by changing
individual value chain activities to increase uniqueness in the final product or by reconfiguring the value
chain.
Porter identified several drivers of uniqueness:
 Policies and decisions  Learning
 Linkages among activities  Integration
 Timing  Scale (e.g. better service as a result of
 Location large scale)
 Interrelationships  Institutional factors
Many of these also serve as cost drivers. Differentiation often results in greater costs, resulting in
trade-offs between cost and differentiation.
Secondary Activities
Secondary activities are necessary activities to support the Primary Value Chain. Secondary Activities
include:
Secondary Description
Activity
Procurement This concerns how resources are acquired for a business (e.g. sourcing and
negotiating with materials suppliers)
Human Those activities concerned with recruiting, developing, motivating and
Resource rewarding the workforce of a business
Management
Technology Activities concerned with managing information processing and the
Development development and protection of "knowledge" in a business
Infrastructure Concerned with a wide range of support systems and functions such as
finance, planning, quality control and general senior management

Steps in Value Chain Analysis
Value chain analysis can be broken down into a three sequential steps:
(1) Break down a market/organisation into its key activities under each of the major headings in
the model;
(2) Assess the potential for adding value via cost advantage or differentiation, or identify current
activities where a business appears to be at a competitive disadvantage;
(3) Determine strategies built around focusing on activities where competitive advantage can
be sustained
Top down/ Bottom up

Top-down and bottom-up are strategies of information processing and knowledge ordering, mostly
involving software, but also other humanistic and scientific theories. In practice, they can be seen as a
style of thinking and teaching. In many cases top-down is used as a synonym of analysis or
decomposition, and bottom-up of synthesis.
A top-down approach (also known as stepwise design) is essentially the breaking down of a system to
gain insight into its compositional sub-systems. In a top-down approach an overview of the system is
formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet
greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced
to base elements.
A bottom-up approach is the piecing together of systems to give rise to grander systems, thus making
the original systems sub-systems of the emergent system. Bottom-up processing is a type of
information processing based on incoming data from the environment to form a perception. Information
enters the eyes in one direction (input), and is then turned into an image by the brain that can be
interpreted and recognized as a perception (output). In a bottom-up approach the individual base
elements of the system are first specified in great detail.
During the design and development of new products, designers and engineers rely on both a bottom-up
and top-down approach. The bottom-up approach is being utilised when off-the-shelf or existing
components are selected and integrated into the product. An example would include selecting a
particular fastener, such as a bolt, and designing the receiving components such that the fastener will fit
properly. In a top-down approach, a custom fastener would be designed such that it would fit properly in
the receiving components. For perspective, for a product with more restrictive requirements (such as
weight, geometry, safety, environment, etc.), such as a space-suit, a more top-down approach is taken
and almost everything is custom designed. However, when it's more important to minimise cost and
increase component availability, such as with manufacturing equipment, a more bottom-up approach
would be taken, and as many off-the-shelf components (bolts, gears, bearings, etc.) would be selected
as possible. In the latter case, the receiving housings would be designed around the selected
components

Requirements
What are requirements?

Business Analysts often define a Requirement in this way:
 A feature that a future solution has to enable such as cloud access

 A function that a future solution has to execute like calculate savings
 A fact that a future solution has to enforce ie a compliance regulation
 A quality that a future solution has to exhibit as in “access to a file in 1 second”
Fundamentally, a requirement is how Customers and Suppliers, Business & Vendors develop a
common understanding as to what makes an acceptable deliverable (usually a combination of Scope &
Quality)
Different approaches to project development have a different take on what a requirement is. In Agile,
requirements are fundamentally negotiable whereas in a traditional (Waterfall or Iterative) Software
Development Methodology (SDM) changes are only allowed within a rigorous change management
process.
The International Institute for Business Analysis (IIBA®) in its Business Analysis Body of Knowledge™
(BABOK®) defines four fundamental types of requirements:
Requirement type Description

Business Define the goals and objectives that the organisation as a whole strives to
achieve
Stakeholder Identify the specific needs and wants of groups or individuals (Stakeholders)
within the Enterprise
Solution Identify the functions and qualities that a solution has to encompass to be
accepted (Fit For Purpose)
Transition Define attributes and actions necessary to implement the new solution in the
existing Enterprise when it is ready to roll-out.
Each type of requirement expresses a different level of detail. Business requirements are very high level
and a typical project will address very few. Business requirements lead to stakeholder requirements
which in turn give us solution requirements. A typical project needs many stakeholder requirements to
specify the business requirements from the perspective of the people involved. Solution requirements
turn the focus of the stakeholder requirements towards the solution technology. There can be a very
large number of solution requirements. Finally, transition requirements define components of the
solution that only exist to replace the current solution, as it exists today. As you can see these four types
of requirement fit nicely with the Enterprise Architecture Cycle.

Business requirements
Business requirements define high-level goals and objectives of an organization as a whole and
address the question, “Why is this project needed?” The executive level within the Enterprise usually
defines the business requirements.
Stakeholder requirements
Stakeholder requirements express the needs and wants of one or more stakeholders and how they will
interact with a solution. Stakeholder requirements bridge business and solution requirements.
Interviews, Business Scenario workshops and User Story Workshops are common tools for gathering
stakeholder requirements.
User Stories follow a simple format:
As a {Stakeholder/Group}, I/we {can / cannot} {do, know, or have something} to {achieve my

goal or objective}.
For example,
“As a customer, I can browse the current product catalogue to select items that I want to buy.”
Solution requirements (functional & non-functional)

Solution requirements describe specific characteristics of a solution that meet business and stakeholder
requirements and can be split into two groups:
Functional Define what the solution has to do or know

A requirement related to data into or output from a system, and to processes and
business rules for input and output
Non-functional Define characteristics that any solution must exhibit for it to be acceptable
A requirement about the ability of a system to perform its functions (whatever
they are) effectively and efficiently. Usually quantitatively measurable
Functional Requirements include:

 The steps of a process (including sequence), decisions, alternatives, exceptions,
responsibilities (i.e. “Calculate total charges including delivery costs and taxes.”)
 Business rules including calculations, derivation rules, authority levels, event responses (i.e.
“Do not ship goods to customers with overdue accounts.”)
 Business data components including user views, relationships, meta-data (i.e. “The monthly
aging report”)

Non-functional requirements
The BCS Reference Model defines the categories of non-functional requirements as:
Performance Subdivides into two measures, often in opposition:

 Throughput: number of services executed in a time period.
 Response or cycle time (aka latency): time taken from request to
response
Availability The amount or percentage of time that the services of a system are ready for
use, excluding planned down time.
Recoverability The ability of a system to be restored to live operations after a failure
Reliability The mean time between failures. Usually applied to the technologies in the
Infrastructure, ignoring the more likely risk of application failure
Source: BCS Reference model
Other non-functional requirements are:
 Legal requirements
 Service level agreements
 Contractual obligations
 Audit requirements
 Internationalization requirements
 Corporate standards
 Flexibility,
 Scalability
 Portability
 Usability
Audit requirement
A requirement to do with ensuring an auditor can find the when/where/how/who of a process or stored
data, and can replay events. (Considered by some to be a functional requirement and others to be
non-functional.)

Transition requirements
Transition requirements describe capabilities needed to integrate (transition) the proposed solution into
Business As Usual.
They describe capabilities that the solution must have to facilitate getting from the baseline to the target
state. Transition requirements are usually only needed for the implementation of the new solution and
can then be discarded.
Examples of Transition Requirements are:
Sales personnel must attend the 2-day new customer acquisition program prior to using the
new Sales Support System.
All existing customer data will be maintained in both the old and the new database format until
the end of the first quarter.
Requirement statement
A Requirement statement is a “statement of need with which compliance must be demonstrated”
This implies an acceptance test and an acceptance authority (requirements should be SMART).
Requirements can be held as entries in a requirements catalogue or a use case description.
Requirements attributes are likely to include:
 Reference number
 Description
 Source
 Owner
 Type
 Priority
 Deadline

CRUD Matrix
A CRUD (Create, Read, Update, Delete) matrix is a tool that can be used to help understand how a
process or procedure uses a data structure. It is often used in Database design and optimisation as
discussed in the example below but in fact has uses outside of this domain.
In database design and optimisation, a CRUD matrix is a table with (Database) tables for columns, and
procedures for rows. Each procedure may perform any combination of Create, Read, Update, or Delete
operations on one or more of the DB tables. If you see too many operations being performed by a single
procedure, that procedure is a target for refactoring (though it's normal to have one procedure change
multiple tables -- that's typically the point of using them, so the transaction can be done in the
procedure)

List of Standards
Enterprise Architecture
IEEE 1471 now ISO-42010 Recommended practice for an Architecture description of software
intensive systems (Ref 3.2.2)
People (Ref 2.2.6)

Freedom of Information act
UK disability discrimination act
US Americans with disability act
Shareholder protection & Audit (Ref 2.2.6)

US Sarbians-Oxley
Basil II
Security (Ref 8.2)

ISO/IEC 17799
ISO/IEC 24762: 2008
ISO/IEC 27001
ISO9001
Is a standard for quality management systems

Migration Planning
While identifying what needs to change and how the new business will look is an important part of the
Enterprise Architects function, there should be more to a cycle of Architectural Work than just the
Architectural Definition. The next step in the chain is Migration Planning, this is where a programme is
drawn up that identifies a series of implementation projects which will transform the business to the
degree needed to meet the Business Vision of Senior Stakeholders.
Before we get into projects and programmes we need to have a look at some key areas needed by both
– Issues & Risks, and Planning.
Issues & Risks

An Issue is a fact; it is something that has happened. “It has just rained” is technically an issue. In
projects we are generally concerned with things that will impact the project objectives (cost, end date,
Business Case). Problems are a type of issue that needs a resolution.
A Risk is a potential issue. It has not happened yet but it might do! There is some uncertainty expressed
- “it might rain this afternoon”.
Risk appetite
Determines the amount of risk that management are prepared to accept. Think of it as gambling – how
much do you spend on lottery tickets? That’s your risk appetite for gambling.
Business Case Risks

Most Business Cases have a risk section, this is usually a simple listing of major threats to the project or
the business which might affect the decision as to whether the project is viable.
Assumption
Assumptions carry risk with them. When we plan we often base our estimates on assumptions, that is
things we think are true but we have not checked. So for example we are costing up a server build and
we assume that we can negotiate a 15% discount on the hardware. This assumption is built into our
costings but what if it is incorrect? In that case the assumption suddenly turns into a risk or an issue
rd
(other assumptions might be “we can get the server delivered by 23 April”,” installation and
configuration will take no more than 5 hours” etc). It is good practice when writing a plan to include a list
of assumptions that informed your estimates of costs and timescales.

Dependency
A Dependency is something that must be in place for a plan or process to execute properly. Suppose
you were charged with installing three servers in a secure location, dependencies could be that “there
must be power in the location”, “the server racks have been installed” etc. So a dependency from a
project point of view is something that needs to be in place before you can do something else (for
example you need foundations in place before you can start erecting a building shell (the foundations
are a dependency of the shell). From the programme perspective we often talk about dependency
projects, these are projects that must complete before other projects can start.
When considering risk, dependency often is considered to be a cause of a risk. External dependencies
are particularly risky as they come from outside the project or programme manager’s area of control.
RAID Catalogue
In is necessary to keep track of Risks, Assumptions, Issues & Dependencies and often Logs or
Registers are used for that purpose. Some people like to have separate logs for each type, others
advocate a combined approach in a RAID Log or Catalogue. RAID stands for what you would imagine
by the way!
Planning
All projects and programmes need to be planned. It is common to have several levels of plans to service
the different information needs of stakeholders and implementers. For example you could have an
overarching project/programme plan which covers the work end-to-end. This is usually high level and
gives a good idea of the overall work. It is often divided into sections (often called stages or increments).
In turn the stages are planned in more detail often just before they are needed. This gives the accuracy,
immediacy, and detail needed to actually manage the work.
Plans should contain more than just a schedule as they need to demonstrate how an outcome will be
reached. Typically a plan will contain the following sections:
 Overview/ Scope of the plan

 Assumptions
 Dependencies
 Costs
 Timescales
 A schedule
 Key risks
Assumptions and dependencies are covered in the Issues & Risks section I think the others are
self-explanatory.
Levels of plan
Plans are needed at all stages of the Enterprise Architecture cycle. Plans have breadth (scope of what
they cover) and depth (detail they go into). Usually the broader the breadth the less the depth.
The BCS syllabus describes three level of plan for you to be aware of:
 Migration Path / Migration Plan
 Roadmap
 Project Plan

Migration path or plan
Often used in place of roadmap however often used to describe a series of transition architectures
or models of how the business will look at different points on the roadmap.
A company wishes to develop a Contact Centre (they call it a Global Help Desk). This will involve
creating a building, recruiting staff and installing the infrastructure. The above shows how the three
projects will fare over three periods.
Roadmap
In Enterprise Architecture the term Road Map is often used to describe a specific type of plan which
charts how the Business will migrate from the current baseline to the desired target. A Road Map is
often a timeline of the implementation projects needed showing their order (thus illustrating
dependency) and with an indication of costs, resources and timescales. Here is a simple example. A
High Street hardware provisions merchant has a vision of moving into on-line sales. Their roadmap
might look a little like this:
A Road map is often considered more detailed than a migration path but not as detailed as a project
plan.
Project plan
Plans one individual project – usually in Enterprise Architecture this is an Implementation Project

Planning and Scheduling Complex Projects
Complex projects and programmes need more by way of planning than just simply tacking a list of
milestones to a wall. There are three useful planning/scheduling tools that can be of use:
 Gantt Chart
 Critical Path Analysis
 PERT Charts
These tools provide the basis both for preparation of a schedule, and of resource planning (in small
projects you might not all or any of them) .
During management of a project, they allow you to monitor achievement of project goals. They help you
to see where remedial action needs to be taken to get a project back on course.
Gantt Charts tend to be used within projects while CPA and PERT charts tend to be used for more
complex work and programmes, however remember this is just a rule of thumb – if you need them then
use them.
Networks
In project planning terminology, the term “Network Diagram” has a different meaning to IT. The project
Network Diagram shows activities which need to be conducted serially or sequentially and those that
can run in parallel and the events associated with them. A project defines an activity as a task that must
be performed if the project is to be successful and an event as a milestone indicating either the start or
completion of one, or several activities.
There are two main philosophies when constructing network diagrams, Activity-on-node, and
Activity-on-Arrow
Activity-on-node
Activity-on-node is a project management term that refers to a precedence diagramming method which
uses boxes to denote schedule activities. These various boxes or “nodes” are connected from
beginning to end with arrows to depict a logical progression of the dependencies between the schedule
activities. Each node is coded with a letter or number that correlates to an activity on the project
schedule.
Typically, an activity-on-node diagram will be designed to show which activities must be completed in
order for other activities to commence. This is referred to as “finish-to-start” precedence – meaning one
activity must be finished before the next one can start. In the diagram above, activities A and D must be
done so that activity E can begin. It is also possible to create other variations of this type of diagram. For
example, a “start-to-start” diagram is one in which a predecessor activity must simply be started rather
than fully completed in order for the successor activity to be initiated.

Activity-on-arrow (Arrow diagramming method or ADM)
In ADM the activities are shown as arrows
With the ADM network drawing technique, the start and end of each node or event is connected to an
arrow.
The start of the arrow comes out of a node while the tip of the arrow goes into a node. Between the two
nodes lies an arrow that represents the activity.
The event represented by the circular node consumes neither time nor resources.
 A node is a specific, definable achievement in the project.
 It has zero duration and consumes nil resources.
 All activities that lead into a node must be completed before the activity lines following this node
can start.
Gantt Charts
A Gantt chart is a well-known and easy to understand planning tool. It graphically illustrates the
relationship between tasks/ activates and time:
As you can see above, the Gantt chart lists the tasks/activities on the left then shows when these will
take place.
Gantt charts illustrate:
 Activity start points, end points, duration

 Whole project start points, end points, duration
 Overlap (resource contention?)
A Gantt chart graphically illustrates both the activities to be performed and how these are scheduled
(you do not need much more to make a roadmap).

Critical Path Analysis (CPA)
Critical path analysis is a technique to construct a model of the project that includes the following:
 A list of all activities required to complete the project (also called a work breakdown structure)
 The duration of each activity
 The dependencies between the activities
What is the critical path?

The critical path could be defined as the least amount of time necessary to complete a number of tasks.
Critical Path Analysis formally identifies tasks which must be completed on time for the whole work
stream (in our case a project or programme) to be completed on time.
CPA allows identification of the following:
 The minimum time needed to perform a work stream

 Which activities or tasks could be accelerated to bring the end date forward
 Which activities and tasks can be delayed without endangering the end date
 Which activities and tasks can be run in parallel
 Whether you have a robust and realistic plan.
The downside of CPA is that it is not as intuitive as a Gannt chart partly as the relationship of tasks to a
timeline are not really indicated.
Sequential and parallel tasks

A basic concept of CPA is that some activities are dependent on other tasks completing first (the
concept of dependency has been mentioned before). Sequential tasks are tasks which need to be
completed in order with each one finishing (more or less) before the next starts. Other activities have no
dependencies and can be started at any time (so long as they have time to complete before the end
date) – these are known as parallel tasks (in this section I will use “tasks” and “activities”
interchangeably).
So a work stream such as a project or programme could consist of a mixture of parallel tasks and
sequential chains. The length of the longest serial chain represents the critical path ( the least amount of
time you need to complete a work stream). Delaying any task on the Critical Path will delay the end date
of the whole work.
Consider the diagram above – imagine that this illustrated a project which had two sequential chains (1
& 2) and two parallel tasks (3 & 4). As all of these four are not dependent on each other they can be
started at any convenient time. 2-4 all take less time than 1 so chain 1 sets the minimum time this

project will take to complete. If Task B extends to 3 days then the end date moves back a day
accordingly. If Task E extended by 2 days then the end date would remain unchanged. Chain 1 defines
the critical path for this project, as tasks 2-4 are not dependent on each other or on 1 they can “float” that
is they can start after 1 and can expand without harming the end date. However each has a date that
they must be started on otherwise the project will overrun.
Here is the same project illustrating this state of affairs
I suspect at this point you can begin to see the value that CPA might add to your planning activities!
Activity networks
CPA uses Activity Networks as a way of visually linking together the activities needed to produce a
result. Each node has some useful planning information attached to it (as I will describe a little later).
Each box (node) on the network identifies an activity, the arrows (connectors) show the dependency
and flow. The network should start with “Begin” and “End” boxes
Activity boxes
It is common to add extra information into each activity box to aid planning:

You can see how useful some of these are from the following diagram:
Program Evaluation and Review Technique (PERT)

PERT is a method to analyse the tasks involved in completing a given project, especially the time
needed to complete each task, and identifying the minimum time needed to complete the total project.
PERT originally was an activity on arc network, in which the activities are represented on the lines and
milestones on the nodes. Over time, some people began to use PERT as an activity on node network.
For this discussion, we will use the original form of activity on arc.
The Program Evaluation and Review Technique (PERT) is a network model which was developed in the
late 1950s for big complex projects (the Polaris Missile project actually). PERT represents activities by
arcs (lines with arrows) and milestones by nodes (Circles).
While PERT charts are usually complex we need to just consider a very simple example:
TomSoft an internet gaming company is developing a proof of concept new game “Car Crash
3000” as part of an AGILE project.
The game involves players logging on and creating a character, they then select a car and the
appropriate bits (these are actors) then drive round a rendered 3D map committing mindless
acts of mayhem and having a thoroughly good time (OK you’ve got the picture!).
The first SPRINT has the seven activities as listed below:
Activity Estimated time Depends on task

..
A: Create basic actors 3 days -
B: Write the wire frame map 4 days -
C: Build log in screen 1 day A
D: Write the player inventory database 2 days A
E: Write the rendering (3D code) 2 days B
F: Build player inventory system 3 days C
G: System & User testing 5 days DEF

And a PERT chart illustrating this on a network diagram would look like this:
The nodes are numbered, the higher the number the later the activity needs to start. It is common to
leave gaps in the numbering so that new activities can be easily inserted (the numbers are ordinal not
relative).
The arrows indicate dependencies, tasks, and the expected duration of each task.
Estimating times
“An Estimate is a probabilistic assessment based on Skill and Experience of the Time and Resources
required for the Delivery of a Specified End Product.”
Estimating is both an art and a skill, unfortunately we do not have time to go into estimation methods
here a simple listing of common techniques will have to satisfy us:
Cone of Uncertainty
At the beginning of a project little is known about the work,
and therefore estimates are subject to high variability
Beginning:
100% estimate range
Outline Planning:
50% range
Task: Single estimate
Compare estimations based on work

Bottom-up & Top-down estimating
Bottom-up
Usually performed at the task level
 Identify every discrete activity in a stage of the Project
 Estimate for each activity in the stage
 Sum activity estimates into a total estimate for the stage
Top-down
Usually performed when doing high level or overall planning
 Estimate for the Project overall
 Typically only a single figure produced
 Identify the major stages required
 Check the relative sizes of stages
 Apportion the overall estimate
 Usually based on our knowledge of past cases
Expert Judgment (wide-band Delphi)

 Gather experts
 Pose the question (e.g. “How long will it take”)
 Obtain estimates from each expert individually
 Let estimates be seen and discussed by the group
 Get justification for those outside the norm
 Allow people to change their minds
 Arrive at consensus
A good example of wide-band Delphi is Planning Poker
Analogy
Estimate produced by comparing the present project with previous completed and successful projects.
Advantage:
Based on actual experience
Disadvantage:
Is the experience valid?
Is the experience recorded?
One useful thing about PERT is that it can handle uncertainty in estimations. For each activity it is
possible to indicate any of three types of estimation:
Optimistic time Usually the shortest time we estimate the activity to take
Most likely time The completion time having the highest probability
Note: Do not confuse Most likely time with Expected Time
Pessimistic time The longest time we reasonable can foresee the activity taking

Expected Time
PERT uses a statistical formula (the beta probability distribution) to estimate Optimistic, Most likely, and
Pessimistic, times. We do not need to go into this here however the Expected Time (that is the time we
reasonable can assume the task will take) can be approximated using the following formula:
Expected Time = [ Optimistic + 4(Most likely) + Pessimistic ] / 6
This equation is a weighted average where the most likely estimate is weighted 4 times more heavily
than the optimistic and pessimistic estimates. This prevents the PERT number from being too heavily
skewed in one direction.
Example:
Suppose a project manager wishes to estimate time to complete some work. She sits with the team and
using their experience they estimate the following:
1. The time it would take to perform the work if there were no hold ups at all (let’s say this comes
to 7 days)
2. Common and frequently occurring hold-ups in work of this nature and how much they could add
to the project duration (5 extra days)
3. Unlikely and rare hold-ups that could occur in work of this nature and how much these would
add to the project duration (17 extra days)
You can see that experience and estimation techniques are critical here!
From this the team can calculate:

 The most likely time to complete the project (1+2 from the above list). This will be 12 days in
our example.
 The most optimistic time for the project (1 only) if there are no delays (7 days).
 The most pessimistic prediction for the project (1+2+3). This is 29 days.
However, while we are pretty sure that some of the hold-ups will happen, we are confident that not all of
them will. So what would a reasonable estimate of project duration be?
Using the formula described earlier, The PERT estimate for the duration of the project would be:
[7 + 4(12) + 29]/6 = 84/6 = 14 days
To calculate the variance for each activity completion time you can use the following approximation
( Expected - Optimistic ) / 6

Summary Steps in the PERT Planning Process
1. Identify the specific activities and milestones.
2. Determine the proper sequence of the activities.
3. Estimate the time required for each activity.
4. Construct the network diagram.
5. Determine the critical path. (discussed earlier)
6. Update the PERT chart as the project progresses to reflect changes.
What PERT will illustrate

PERT can help identify the following:
 Expected project completion time.

 Probability of completion before a specified date.
 Start date to complete on a given date
 Sequential & parallel paths
 The critical path activities that directly impact the completion time.
 The activities that have slack time and that can lend resources to critical path activities
 Activity start and end dates.
PERTS’s limitations
Like all techniques PERT has areas that it does not perform well in. A major area of concern is the
estimation system used.
Despite the statistical formula used estimation is always going to be just that – a hostage to fortune so
there is still a need to have experienced estimators. Group estimates (at least 3 people help) but there is
always bias however hard you try to avoid it.
Even if the estimates are sound the distribution may not be exactly as assumed by PERT so there might
be in-exactitude here.
PERT focuses on one chain as being the critical path but cannot easily compensate for other chains
becoming critical as they experience delays and because of this PERT often underestimate actual
project completion time (Monte Carlo Simulations technique can be used to compensate for this
problem in some degree).

The Business Case
Any change to a process causes disruption, inconvenience, and takes time and money. Why should we
want to put ourselves through this aggravation unless it was justified – that is the changed state
produces a beneficial outcome which outweighs the trouble caused? Consider the hassle of going on
holiday. All the effort: the packing, finding the passports, the ghastly queues at the airport full of
screaming kids (fortunately I’m passed that stage now – mine slope off to the bar!), not to mention the
cost! Why do you do it? Because despite all the trouble you enjoy your break, you look back at it with
fond memories; simply put - you get out of your holiday more than you put in.
In business every proposed change should be justified to demonstrate that it is worthwhile. The formal
way of justification is to create a Business Case. Business Cases are many things to many people, the
E&SA syllabus considers that a Business Case should contain the following elements at a minimum:
 ROI (Return On Investment)
 Options (business or technical),
 Impacts
 Risks
A Business Case provides justification for a change to take place; this means it justifies the work to
make the things (deliverables) that cause the change (a new process for example) and the work to plan
the delivery and production of those deliverables. In other words a Business Case also justifies a project
or a programme.
ROI (Return on Investment)

ROI is a bit of a balance sheet – on one hand you have the expected benefits of a change on the other
you have the cost of making the change plus the ongoing maintenance and support costs. If the former
outweigh the latter then the project is viable. If not the project should not go ahead. Benefits should be
measurable in some way, cash (often savings made) is a good comparator as it can be easily stacked
up against costs however this is not always possible so a benefit might be something like: “regulations
complied with”, or, “the resolution of specific problems” (such as the benefit of running a project to
provide data integrity is to save the cost of data dis-integrity. In many cases a little forethought will allow
you to take a non-cash benefit and convert it into a cash benefit for comparison reasons.
Cost-benefit analysis
A financial technique used to contrast the costs and benefits of a change. Often there are several ways
to make a change and a Cost/Benefit analysis will help indicate which might be the most beneficial to an
business.
One way of performing a Cost-benefit analysis is Discounted Cash Forecasting which converts a future
return into current savings.
Options
Options in the Business Case should list alternative solutions to meet the need for change. A Business
needs to increase its profitability – options could be: Increase Market Share, sell off a loss making
subsidiary, or invest in re-engineering a process to make it more efficient. One option you should
consider putting in a Business Case is the option to “Do Nothing”, this acts as a nice illustration of what
will happen if nothing is done!
How a selected Business or Technical option is achieved is described by Solution Options (discussed
a little later)
Impacts
Describes the effect the change would have on the business should it be carried out. This should
describe the work to be done and the changes made to the affected organisations

How many business cases?
It may be advisable to have a Business Case for the Architecture Definition part of the Architecture
Cycle. If a Full Business Case is not felt to be a necessity then consider writing an Outline Business
Case (OBC) instead. An OBC is a much less precise form of a Business Case produced with much less
effort as the analysis is less rigorous. It is adequate for simple small scale projects as it has enough
discrimination to detect major show stoppers.
Implementation Projects need their own Business Case; this is often produced by the Project Managers
as part of the Project Establishment process.
Solution Options
Once the Technical or Business solution has been decided it is necessary to identify how that solution
can be achieved. For example, supposing that (from the previous example) it has been decided to sell
off a loss making subsidiary, how would the business go about this? Should they call in a firm of
consultants, find their own buyer and arrange a sale, or form it as a separate entity and float it? These
are known as Solution Options (as opposed to Business or Technical Options in the Business Case)
At the solution vision stage there may be several Solution Options proposed. As the cycle progresses
and more information becomes available, the options will be contrasted & compared. Comparison
methods commonly employed could be:
 Cost-benefit analysis (covered previously)

 Risk analysis
 Gap analysis
 Trade-off analysis
Risk analysis
The BCS reference guide for this syllabus considers Risks to be threats to the ability of the target to
meet the non-functional and security requirements specified as part of the Architecture Definition.
An initial risk analysis should be performed at the beginning of the cycle as well as subsequently as the
cycle progresses.
Gap analysis (options)

A Gap is a difference between two lists or structures. Gap Analysis identifies the difference. A good
example of Gap Analysis is comparing Baseline and Target Architectures. This allows identification of
elements which need to be removed and added to the Baseline to transform it into the Target state.
Further it can highlight when something has been dropped deliberately or by mistake.
Trade-off analysis
Is yet another technique from the Software Engineering Institute of Carnegie Mellon University.
A consultant leads analysis of all the system options and investigates the trade-offs between them. This
helps identify the best option.
Solution Option Business Case?

By performing the above you just about have a Business Case for your options. You may want to go the
whole hog and write up business cases for each potential solution. These can be amended as the cycle
progresses and more detail becomes available.
Business scenario
Is similar to a User story but much more comprehensive, It identifies a process and the actors who
interact with it. Usually created within a workshop it is useful in identifying risks and concerns of
stakeholders and also capturing requirements. May be used initially in pre-cursers or during the
investigation into the Business Domain. Can be used in support of a Business Case or a Solution Vision
or may be presented as an example instance of a business process.

Programme & Project Management
Projects & Programmes

A project is a planned endeavour with the aim of delivering a defined outcome to an agreed level of
quality within the constraints of time and cost. There is more but most people understand what a project
is and this will do for us. Projects consume resources (time, money, people etc) and should bring about
a change in some form.
There are many Project Management Methodologies around which attempt to describe how a project
can be managed and controlled (or governed) effectively. Most methodologies describe five things:
 A philosophy describing what a well-managed project should look like

 A set of principles supporting the philosophy
 A process (or set of processes) illustrating the lifecycle of a project (the order that tasks need to
be performed in)
 A set of management deliverables which can be used to control and guide the work (Business
Case, Project Plan etc)
 A collection of techniques which can be used to perform project tasks (Risk Analysis, Critical
Path Analysis etc)
Methodologies differ between themselves although there is often an overlap between the management
deliverables and the techniques described by different methodologies. Some (but not all) specify that
the project should have a single person assigned to manage the work on a day to day basis (this is the
oft maligned Project Manager). TOGAF and other Enterprise Architecture methodologies can be
considered as a high level project methodology in a way.
Software Development Life Cycle (SDLC)

Implementation projects spawned by an Architectural Description are likely to be about creating or
upgrading software in one form or another.
Many IT/IS related improvement methodologies follow the “System Development Life Cycle” (or SDLC
for short). SDLC describes a solution development process centred on software engineering (and thus
of interest to EAs). SDLC compliant methodologies can take several forms (such as agile, iterative or
waterfall/V) however any method should cover the following steps:
SDLC step focus

Strategy The planning of an organisation’s overall systems development effort
Analysis The detailed definition of requirements for a particular area of the business
Design The specific application of technology to the requirements defined during
analysis
Construction The actual construction of the system
Documentation Preparation of the user manuals, reference manuals, etc. to describe the
system
Transition The implementation of the system, so as to make it part of the infrastructure
of the organisation
Production The ongoing monitoring of the system to ensure that it continues to meet the
needs of the organisation

SDLCs break down into three main variants or characteristics:
SDLC type Characteristics

Waterfall or V Usually consists of a sequential series of process steps: analysis,
design, build, test and roll out
The team work in a straightforward way completing each step before
moving on to the next
Waterfall is usually the most cost effective way to run a project so long
as all the requirements can be established at the beginning of the
project and never change!
Iterative The project consists of a number of increments. The aim of an
increment is to produce part of the eventual solution which hopefully is
capable of deployment and returning value to the business as soon as
possible. Think of releasing Web Site version 1, version 2, version 3
etc.
Early release gives a better ROI as benefit can be drawn earlier in the
project lifecycle
Note: not all Iterative projects are Agile
Agile As well as being iterative Agile projects do not assume that the
requirements are all known before work starts. Short iterations allow
customers to see functional product early and decide what should be
done next. Users are embedded with the developers so they can
adjust on the spot
Project Management Methodologies

Implementation Projects (Application Development Projects) should be run under an appropriate
methodology. There are a number of PM Methodologies in common use.
PRINCE2
PRojects IN a Controlled Environment. The strength of PRINCE is that it describes a flexible set of
processes and a good set of management deliverables (PRINCE calls them Management Products).
The governance framework is particularly attractive as it provides a good degree of control coupled with
a minimum use of senior management time. PRINCE’s great weakness is that it only describes a very
few techniques. Also the methodology has an ill deserved reputation of being inflexible and
bureaucratic.
While PRINCE describes how to control a project well it does not concern itself too much which how the
delivery teams should go about their business.

Scrum
Scrum is a lightweight Lean/ Agile methodology much touted as the way to develop software quickly. It
focusses on a small empowered set of developers who plan and perform their work “on the fly”. They
interface with a representative of the Business (the Product Owner or PO)
The PO defines the requirements (what needs to be delivered) which are held in the Product Backlog.
The development Team work in short cycles of between 2-4 weeks called a Sprint. At the start of a
Sprint the Product Owned and the team agree what is to be completed during that sprint (the Sprint
Backlog) then the team plan the work and get on with it. Each day of the Sprint starts with a short
meeting (Scrum) were the development team plan the day’s work. The end of a sprint sees the
completed work as something that could possible be integrated into the business (Potentially Shippable
Product).
Scrum is good for rapid development but starts to struggle as the Development Team expands in size.
Also the governance and control frameworks are minimal (to be generous) so Scum often is not suitable
for compliance/ security focussed Implementation Projects.
Dynamic Systems Development Method (DSDM)

Is grown up (or Corporate) Scrum. DSDM takes the idea behind SCRUM and uses a Project Manager to
provide a layer of overall control and co-ordination. A DSDM project could be likened to a series of
Sprints orchestrated by a PM and withadditional technical & business oversight.
DSDM starts with two short phases (Feasibility and Foundations) which together provide for project
establishment. Plans and governance are set up (minimalist as per the Lean philosophy) and a high
level set of requirements produced.

The development work takes place in Timeboxes. Timeboxes have fixed end dates which must not be
exceeded. Timeboxes are the equivalent of the Scrum sprint and usually are of 2-4 weeks duration.
Requirements are prioritised using a three point system (Must Have, Should Have, Could Have). The
Development Team have full authority within the timebox so long as they are on track to deliver at least
the “Must Haves”.
Increments consist of chains of multiple timeboxes and end with a deployment. At the end of an
increment (during deployment) the business decides what needs to be done next (if anything) and the
whole process starts again
Programme
If the work is too complex to manage with a single project then it needs to be split up. This results in
several interdependent projects which in turn need to be co-ordinated. A collection of interdependent
projects is called a Programme and the process of managing it is known as Programme Management.
The dependent projects shelter under the umbrella of the Programme. Usually the projects are funded
from the Programme budget and there is some form of Programme Governance which controls the
projects.
The Enterprise Architecture cycle should include Implementation Projects (Application Development
Projects) and these usually need to be co-ordinated under a Programme Manager into a programme.
MSP (Managing Successful Programmes) is a well-respected programme methodology which could be
used at the Enterprise level in this manner.

Implementation Management
This section addresses the organisations and processes needed to govern and implement an
Architecture Description, in development and operation, including the management of changes
Why?
Implementation Management is about having a high level understanding of how Implementation
projects work. Implementation projects are those which turn the Enterprise Architect’s carefully crafted
model into reality. This is usually were it all goes wrong.
Architecture implementation
Enterprise Architects are charged with initiating a change to an Enterprise. To do this they listen to
Senior Stakeholders and seek to understand the direction in which an enterprise is heading in the future
(this is often called the Vision or the Business Vision). They then draw up a model of how the Enterprise
will look if this Vision is translated into reality. Next they contrast this future state model with how the
Enterprise is now (the Baseline or Current State model) so that they can identify the difference between
the two states.
What happens next depends on the methodology, we shall follow the TOGAF viewpoint on this as it is
probably the best accepted EA methodology on the block. TOGAF states that the EA helps to develop a
programme of implementation projects (assisted by Solution Architects and Programme & Project
Managers) which if actioned by Business will make the changes needed to support the Vision. Once
sanctioned, the Implementation projects are managed by Programme & Project Managers with the
Enterprise Architect keeping an eye on things as they progress. So there are two types of “project”
which concern the EA. There is the Architecture Definition in which the modelling and gap analysis
takes place and there is the Implementation in which the EA takes a back seat (but not too much of a
back seat!). Implementation projects may be expensive and they will only be worthwhile if they deliver
the requirements specified by the Enterprise & Solution Architects who have in turn listened to the
needs of their stakeholders. So the EA needs to audit and monitor each implementation project to make
sure it stays on track to deliver what has been promised. Things change, and sometimes the outputs of
a project need to change as well. EAs need to understand (and get involved with the change process as
well).

Once the Implementation Projects have built their deliverables the final task of the EA is to see that they
are handed over to the Business so that they can be put into productive use. This is known as
Transition.
Transition
Once the implementation projects have done their work the Architecture Cycle is just about finished. All
that remains is to perform a planned shutdown of the cycle and release the implementation deliverables
to the Business. Usually the completed systems, processes, or what have you, are handed over to two
business units:
Managed Operations (Transition into Operations): Everyday operations of the business
Maintenance/ Update (Transition into Maintenance): Supporting and maintain the products
ISO9001
Is a standard for quality management systems. ISO9001 includes:
 A set of procedures that cover all key processes in the business

 Monitoring processes to ensure the processes are effective
 Keeping adequate records
 Monitoring output for defects (which can trigger corrective action if required)
 Regular reviews & audits of process and how they are measured with the aim of continual
improvement

Governance & Control
RFCs & the need for Architecture Change Management

Every plan experiences change in some way. No project delivers exactly the same scope & quality as
was originally envisaged. Project methodologies and Project Managers who ignore this simple fact are
destined to deliver unsatisfactory product or in the worst case no product at all.
So every project (and an Architecture Development Cycle is no exception) needs to accommodate
change, however this brings us to another set of problems. Change introduces risks, costs, and delays.
Who is to say that these are acceptable to the organisations in the Enterprise being affected by them?
So every project needs to make sure that the following is defined:
Issue Typical Enterprise Development way of dealing with it

There needs to be a way of Request For Changes (RFCs)
raising suggestions to change Change Control
what has been agreed
There needs to be a body (or Governance Board (GB)
bodies) with the authority & Escalation procedure
technical experience to identify
worthwhile changes and
commission them if needed
Handling change (RFCs and Change Requests)

In the initial stages of an Architecture Development Cycle little detail about the proposed changes is
clear. As work proceeds it often becomes obvious that the original architecture definition and
requirements are not suitable or are not sufficient to complete the implementation of a solution to
stakeholder satisfaction. Alternatively, external factors – such as market factors, changes in business
strategy, and new technology opportunities – may open up opportunities to extend and refine the
architecture in a way not foreseen at the start.
In these circumstances, a Change Request may be submitted in order to initiate evaluation by those in
authority as to the benefit of making changes. The form documenting the Change Request is known as
a Request For Change (RFC).
A good change request should have the following sections:
Change Request
1. Description of the proposed change
2. Rationale for the proposed change
3. Impact assessment of the proposed change, including:
 Reference to specific requirements
 Stakeholder priority of the requirements to date
 Phases to be revisited
 Phase to lead on requirements prioritization
 Results of phase investigations and revised priorities
 Recommendations on management of requirements
4. Repository reference number

The RFC should be transmitted to the Governance Board (more on them later).
Handling changes
This is TOGAF’s view of handling changes:
Simplification E.g. consolidation of 20 servers to 3, this can be handled by change

Change control of project
A change driven by a requirement to reduce investment
Changes at Infrastructure level often can be handled by
simplification
The decision is pushed back down to the Implementation Project
with re-visiting any part of the Architectural Definition.
Incremental Change A change driven by a requirement to derive additional value from
the existing investment
This will probably need us to revisit parts of the Architecture
Definition (a domain perhaps) and also revisit our Implementation &
Migration Plan
re-architecting Takes us to Phase A to re-plan
change A change driven by a requirement to increase investment in order to
create new value for exploitation
This is usually such a significant change that the whole Architectural
Definition needs to be done again from the beginning.

Governance
Managers need to ensure that their requirements are met. For example in RACI how does an
Accountable role know that those Responsible are actually performing the work correctly? The answer
is twofold:
Firstly they check (“audit”) that the work is going according to their needs. They might not check
directly themselves. They may delegate the actual auditing to people who they trust and who
are not involved with the work being audited. For example, the EA is often asked to audit
implementation projects to ascertain if they are meeting the requirements set out in the
Architecture Contract.
Secondly they give guidance to their subordinates on which decisions the subordinate can
make and which need to be passed upwards to them.
So Governance is Management ensuring that the goals, rules and principles laid down are followed.
Enterprises exercise governance at three levels:
Area Responsibility
Corporate governance and principles Board of Directors
IT governance and principles IT Board
Enterprise Architecture and principles Architecture Governance Board
The Architecture Governance Board (or Governance Board)

The Architecture Governance Board (AGB) are the Enterprise Architecture Teams “boss”. They are
Senior Managers who are usually responsible for the following:
 Architecture principles maintained

 Governing Architects appointed
 Architecture Development Cycle properly performed
 Final decisions concerning RFCs & Risk (Highest level within the cycle)
The AGB (or “Governance Board) support the EAs as the Architecture Definition proceeds by being
available to provide advice and direction and to consider RFCs. Members of the Governance Board
should be drawn from the areas of the business which will be impacted by the current cycle of
Architecture Definition and change implementation. This allows senior management to satisfy
themselves that changes will not be made to the parts of the business for which they are responsible
without their knowledge and permission.
One of the duties of the AGB is to make sure that the Enterprises Architecture process has the required
level of capability.
Capability Maturity Model (CMM)
“Capability” is the ability to do something such as a task or a process.

“Maturity” refers to the level of ability – how good we are at doing
something. As an example, both I and David Beckham have a football
capability (we can both kick a ball around) however I have two left feet
and am considered (by my youngest son) as rubbish while Mr
Beckham is very very good. So my maturity level is low (let’s say 1),
and David Beckham’s maturity in football is high (let’s say 10).
When a football team manager is looking for a new player they look for
people with the correct level of skill for their team a Premier League
manager needs someone with a high level of skill. In other words they
want a player with a high maturity level, possibly 10. A Second
Division manager does not need quite such a good player and will
settle for a (cheaper) 7 or 8. The point is that to meet a business need
you do not necessarily need the brightest and best.
How do our Managers assess potential candidates? They test them to
establish their maturity. This means that first they need to establish
what maturity level they need in this bit of their football business. This
is known as a Capability Assessment (naturally).
So a Capability Maturity model acts as a reference framework evaluating the maturity (capability level)
of an organisation and its processes. Enterprises will establish the capability required to satisfactorily
perform a task then perform a Capability Assessment to see where they are. They may perform a gap
analysis to identify the difference between the two levels then develop a “road map” to bridge the gap.
The best known maturity model is the CMM for software processes, from the Carnegie Mellon
University Software Engineering Institute. Capability Maturity Model Integration (CMMI) is the
successor to CMM administered and marketed by Carnegie Mellon. Carnegie Mellon University claims
CMMI can be used to guide process improvement across a project, division, or an entire organisation
CMMI and has established maturity models for many different sectors and industries.
There are maturity models for architecture organisations and processes.

CMM's Five Maturity Levels of Software Processes
CMM is divided into five levels as shown on the following table:
Level What it covers

1: Initial Used as a basis for comparison. Success is likely to depend on individual efforts
(both PM and developers), and is not considered to be repeatable (unless the same
team is used again), because processes would not be sufficiently defined and
documented to allow them to be replicated. In many cases, the development
process consists of writing code with minimal testing
2: Repeatable Basic project management techniques are established within the organisation,
project management is based on accumulated experience and there are
documented standards for produced software. There is some form of a Quality
Management Group in place however if the system is placed under pressure it tends
to revert back to the Initial level.
3: Defined The organisation has developed its own standard for the processes of software
development, maintenance, and Project Management. Because of the introduction
of standards more effective technologies are embraced. A specialist Quality
Management Department is goaled with building and maintaining relevant
standards. At this level the Enterprise is not dependent on the skills of particular
individuals (because there is not a standardised framework in place).
To achieve this level the business must invest in advanced training of staff.
4: Managed The organisation monitors and controls its processes measuring against quantitative
metrics.
5: Optimising Processes are constantly being improved through monitoring feedback from current
processes and introducing innovative processes to better serve the organisation's
particular needs
The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International
Organisation for Standardisation (ISO). The ISO 9000 standards specify an effective quality system for
manufacturing and service industries; ISO 9001 deals specifically with software development and
maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001
specifies a minimal acceptable quality level for software processes, while the CMM establishes a
framework for continuous process improvement and is more explicit than the ISO standard in defining
the means to be employed to that end.
Change control procedures

To succeed, an Enterprise needs to be Agile when it comes to handling change. There needs to be a
change control procedure in place which addresses the following:
 Monitor the potential sources of change

 Record change requests
 Perform impact analysis
 Decide which changes should be made.

Change Boards
Some RFCs are highly technical and need specialist consideration; some need a senior level of
management consideration but not perhaps the ultimate level of the Governance Board. In instances
such as this the Governance Board might set up specialist groups or committees often called Change
Boards to consider specific types of RFC. Change Boards can have a specialist technical remit or be
regional in nature.
Impact analysis
When a RFC is generated the Change Control procedure should perform Impact Analysis so that the
effects of a change and the impact on the current baseline can be understood. The end result of an
Impact Analysis is an Impact Analysis Report which should identify risks, costs, benefits and constraints
associated with the proposed change.
Escalation path & Out of Band

Ultimately the Governance Board hold the accountability for deciding on the correct response to a RFC
(and risks for that matter). However as the Architecture Cycle progresses into implementation the
amount of RFCs can become huge. The members of the Governance Board are senior managers in the
business and have limited time to spend on Board duties it would not be efficient to waste their time on
minor highly technical questions. One response to this is the establishment of Change Boards however
whenever the Governance Board delegate decision making responsibility to someone they weaken
their control. The usual compromised is For the Governance Board to carefully define what decisions
each Change Board might consider, any changes which fall outside such a remit must be referred to
them. This is often referred to as an Out of band escalation. This concept can continue down the whole
chain of command
The concept is illustrated in the above diagram. Note that this is just one way to set up escalation there
are many possible paths I have not shown here (otherwise I would have arrows all over the chart). Also
be aware that there can be many Change Boards at all levels of this hierarchy (I have only shown one)

Governance of Implementation Projects
The Architecture Development Cycle ends in the initiation (and monitoring) of Implementation Projects.
These projects need to be monitored so that the Governance Board members and other senior
stakeholders can to satisfy themselves that the work underway conforms to the architecture principles,
policies and models specified.
Architecture Contract
This is the trigger that is used to authorise an implementation project. It is signed by senior stakeholders
and may be a legally binding document (for external suppliers) or a simple Memorandum of
Understanding (if used internally). Either way this is the point of “No Return” were vendors are
commissioned to perform work.
From the Enterprise Architecture perspective an Architecture Contract should specify:
 Start & end dates

 Payment
 Requirements, Principles & policies
 Escalation for RFCs & Risks
 Relevant Stakeholder rights & interests
Governing architect
There are many Architects involved in an architectural cycle so it is convenient for the Governance
Board to have one senior Enterprise Architect as their main point of contact. This person assumes the
role of Governing Architect (sometimes called “Lead Architect”, “Chief Architect”, or “Design Authority”)
and is charged by the AGB with ensuring that the systems specified as an outcome of an Architecture
Definition are built and/or run in accord with its architecture contract, managing risk and making sure
that the value of the system to its stakeholders is maintained
Architecture compliance reviews

To ensure that the provisions in the Architecture Contract are being honoured, The Governance Board
should conduct Architecture compliance reviews .
Reviews (sometimes called Gateways) may take place at key points during the implementation project
and may be formal or informal. Often the Board find it convenient to use some form of checklist (a
standard list of general questions)
The Governance Board may find it helpful to have the Governing Architect present at a review although
this is optional.
Amongst other things, an Architecture Compliance Review should establish the:
Architecture conformance How well or how much of an architecture contract is met

level by a system, or an architecture description is realised in
a system
Architecture compliance How well or how much of a system corresponds to its
level architecture contract and/or description

Dispensation
What happens if a supplier cannot meet a requirement on time? One option is to grant the supplier a
Dispensation. This cuts the supplier some slack and gives them time to rectify a problem without being
penalised. For example, suppose the average response time has been specified as under 2ms and with
release date looming the best that can be obtained is 2.1ms and it will take 3 months to optimise down
to the agreed level. Technically the supplier is in default however your Senior Stakeholders are keen to
get the database into production and short term the response is satisfactory to them. In this case the
Governing Architect could issue a dispensation for 3 months accepting the current response time. The
important point is that dispensations are “time bound” that is they cannot be open ended (they must be
reviewed after the specified time).
Architecture in Operations
IT Services Management (ITSM & ITIL)

The organisation and processes for managing IT infrastructure and the services it provides. ITSM is
provided by your IT team who plan, manage & maintain the IT infrastructure on a day to day basis.
A recognised International Standard for ITSM is ISO/IEC 20000 (based on the earlier British Standard,
BS 15000). It promotes the integration of processes to deliver managed services to meet the business
and customer requirements. Processes include Planning & Implementing New or Changed Services,
Service Delivery Process, Relationship Processes, Control Processes, Resolution Processes and
Release Process.
Best practice in this area is described by ITIL (formerly known as the Information Technology
Infrastructure Library). ITIL is a large and globally recognised body of advice from the UK government
(originally the Office of Government and Commerce) describing how to manage an IT services
organisation. ITIL underpins ISO/IEC 2000 (although there is some difference).
ITIL advocates that IT services are aligned to the needs of the business and support its core processes.
It provides guidance to organisations and individuals on how to use IT as a tool to facilitate business
change, transformation and growth.
The ITIL best practices are currently detailed within five core publications:
 ITIL Service Strategy

 ITIL Service Design
 ITIL Service Transition
 ITIL Service Operation
 ITIL Continual Service Improvement.
These five volumes map the entire ITIL Service Lifecycle, beginning with the identification of customer
needs and drivers of IT requirements, through to the design and implementation of the service and
finally, the monitoring and improvement phase of the service.

Operations Architecture
The organisation and processes that are needed to manage the architecture description of an
operational system is often described a Architecture in Operations or Operations architecture. The aim
is to facilitate the ongoing support and management of IT services infrastructure of an Enterprise and
make sure that they achieve expected performance levels. The technique is to provide a centralised
unified single control point for the IT infrastructure.
The IT infrastructure of an Enterprise will often be a mixture of many different services, systems and
platforms, often in different geographic locations. Some of the IT services provided are:
 Management of user roles and identities,

 Client device configuration,
 Storage administration,
 Network provision, monitoring and analysis,
 Server provision, monitoring and analysis,
 Business activity monitoring,
 Virtualisation,
 Back up & restore,
 Incident and problem management.
COBIT (Control OBjectives for Information and related Technology)

COBIT is a Framework for the governance and management of Enterprise IT (as you can see on the
screen dump). COBIT is controlled by Information Systems Audit and Control Association (ISACA).

Configuration Management: Keeping track of things
It is essential to have a detailed knowledge of your organisation's IT infrastructure in order to make best
use of it. The components or parts of your IT Infrastructure are known as Items (elseware they are often
called Assets) and a group of Items (or assets) is known as a Configuration. Items under the control of
Configuration Management (CM) are known as Configuration Items.
The main task of Configuration Management is to keep an up-to-date record of all the components
(called Configuration Items or CIs) in in the IT infrastructure configuration and the interrelations
between them. CIs may be as simple as a single server, a source code component or a hardware
device or as complex as the entire IT department. A requirement could be a CI. Cis are items in
Baseline Configurations (known configurations).
CM is not a simple task and is closely linked to Change Control (including RFCs) and the release of new
and/or updated products into the business environment. Because of this CM depends on the
cooperation and goodwill of the people managing other processes, in particular Change Management
and Release Management. In large organisations a configuration manager may be appointed to
oversee and manage the CM process. In ITIL version 3, this process has been renamed as “Service
Asset and Configuration Management”.
A good CM system should Support other processes, in particular: Incident Management, Problem
Management and Change Management.
It does this by providing accurate and reliable information to the rest of the Enterprise about all the
components of the IT infrastructure.
The main way it can provide this information is by maintaining an up to date a database of CIs (the
CMDB or Configuration Management DataBase) which should hold:
 Up-to-date records of all CIs: identification, type, location, status, etc.

 Interrelations between CIs.
 Services provided by each CI.
Part of CM is having a robust Asset Management System however be careful as the term “Asset
Management System” can mean one of two things either a record of all IT assets or sometimes it is just
focused on end user devices.
Using CM gives the following benefits:
 Faster problem resolution: A common source of problems is the incompatibility between

different CIs, (out-of-date drivers, latest applications on old O/Ss etc). Having to detect these
errors without the current information held in the CMDB can cause delay (considerable delay in
some cases). MTTR (Mean Time To Repair) decreases with good CM.
 More efficient Change Management. When considering a RFC it is essential to know what
the current structure (the Baseline) is in order to make sure that the changes do not produce
new incompatibilities and/or problems leaving us without benefit.
 Saves money: If we know what we have then we can re-use it. If not we may purchase
something we do not need (we cleared out our garden shed a few weeks ago – we have about
5 sets of pruning shears as I kept losing them and buying new ones!).
 License control: On that theme a good CM system can keep you up to speed on the software
installed on your infrastructure. You might still be paying licenses for software discarded years
ago, you might not have enough licenses (and could get prosecuted), you might be using old
packages which breach compliance regulations.
 Security: An up-to-date CMDB aids your security team in detecting vulnerabilities in the
infrastructure
 Faster Fix/ Roll Back time. If you know how the components in your system interact, and the
baseline of each then recovering to a working state will be much easier and quicker.

Configuration management database (CMDB)
“A database of records of configuration item specifications including relationships among configuration
items.” (ITIL).
A CMDB is a repository that acts as a data warehouse for configuration items (CIs), and their attributes.
The CMDB holds the authorised configuration of the significant IT components. The CMDB is a vital part
of the configuration management process and should relate to any enterprise architecture repository.
When populated, the repository becomes a means of understanding how critical assets such as
information systems are composed, what their upstream sources or dependencies are, and what their
downstream targets are.
CI attributes
Every CI has attributes associated with it. The three main ones are described in the table below:
Attribute Description
Technical Data that describes the CI's capabilities which include software version and
model numbers, hardware and manufacturer specifications and other
technical details like networking speeds and data storage size. Keyboards,
mice and cables are considered consumables
Ownership Part of financial asset management, ownership attributes record purchase
date, warranty, location and responsible person for the CI. Identification
numbers like bar codes and type, like software, hardware and documentation
are also ownership attributes
Relationship The relationships between hardware items (e.g. a printer), software (e.g.
drivers), and users (i.e. Eric).
Depending on the CI type or category, there are many attributes that might be captured, basically
anything that you need to know about a CI is an attribute. Here are some more examples:
 Version Number (a unique Identifier or ID)

 Name or Label (often, both, long names and short names)
 Abbreviations or Acronyms
 Description
 Importance
Common Information Model (CIM) is a standard which defines how the elements in an IT environment
can be represented as a common set of objects and relationships in a CMDB
Baseline
In Configuration Management, a Baseline describes a known state of a component. When a
component has been passed as Fit for purpose usually by passing a test, it is handed over to the
Configuration Manager who gives it a unique version number. If the item subsequently needs to
change it is modified and re-tested, then it is given a new version number to distinguish it from its
predecessor.
Usually a baselined item can only be changed by passing through a formal change control process.

Enterprise Continuum v1C

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Enterprise Continuum v1C

Загружено:

Авторское право:

Доступные форматы

Enterprise Continuum

Enterprise Continuum V1.1 Page 1

1: documentation describing the structure (components) and behaviour (processes) of a

The role of (IT) Architect

Enterprise Continuum V1.1 Page 2

 Holistic understanding of business and technical goals

Source: BCS Reference Model

What is Enterprise Architecture?

What is an Enterprise Architect?

Enterprise Continuum V1.1 Page 3

 Improved alignment of business and IT

Enterprise Continuum V1.1 Page 4

 Identifying the current IT/IS Baseline

Scope of the brief

Enterprise Continuum V1.1 Page 5

Business Application/ Data/ Technology/

Business Enterprise Data architecture Servers

Architecture Domain Hierarchy

Enterprise Continuum V1.1 Page 6

 Timeliness of IS/IT project deliverables

Enterprise Resource Planning (ERP)

Supply Chain Management System (SCM)

Customer relationship management (CRM)

Enterprise Continuum V1.1 Page 7

Role What it does

Enterprise Continuum V1.1 Page 8

Methodology: the Architectural Cycle

Enterprise Continuum V1.1 Page 9

The life cycle breaks down this way:

Enterprise Continuum V1.1 Page 10

 An information base used by architects

Enterprise Continuum V1.1 Page 11

Enterprise Continuum V1.1 Page 12

 organisation unit to business function

Views & Viewpoints

Enterprise Continuum V1.1 Page 13

Group Example member Viewpoint

User The people who work in the system Functioning network

Enterprise Continuum V1.1 Page 14

Enterprise Continuum V1.1 Page 15

Enterprise Continuum V1.1 Page 16

ADM Cycle – the heart of TOGAF

The Architecture Development Method is the core of TOGAF.

An iterative cycle of eight phases (centred round

Enterprise Continuum V1.1 Page 17

Enterprise Continuum V1.1 Page 18

Typical sections of a SAW are:

 Architecture project request and background

The ADM cycle is iterative

Enterprise Continuum V1.1 Page 19

Summary of TOGAF phases

Phase What it does ….

A: Architecture  The start of the cycle!

Enterprise Continuum V1.1 Page 20

H:  Home of the Architecture Governance Board (a group of senior business

Enterprise Continuum V1.1 Page 21

1. Model how the business is now (baseline)

As a start you need to do the following:

Phase A: Architecture Vision

Enterprise Continuum V1.1 Page 22

Phase C: Information Systems Architecture

Phase D: Technology Architecture

Enterprise Continuum V1.1 Page 23

Phase F: Migration Planning