Photo removed
Gordon Brown
The Open Group Certified Architect (Open CA)
Program:
Certification Package
Level 2: Master Certified IT Architect
October 03, 2008
Revision 2.3
Candidate Name
Last Name
Brown
First Name
Candidate I/D
98765
Middle Initial
Gordon
W
This template is to be used with:
The Open Group Certified Architect (Open CA) Program:
Conformance Requirements Version 2.01
And is for applications for certification at:
Level 2: Master Certified IT Architect
© Copyright 2005 - 2008, The Open Group
All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in
any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,
without the prior permission of the copyright owner. Permission for storage, editing and
transmission by electronic means is hereby granted for the sole purpose of supporting
applications to The Open Group for Open CA Certification.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
1
1. Contents
1.
Contents ................................................................................................. 2
2.
Compliance With Skill Requirements ........................................................... 3
2.1
Skill Levels ...................................................................................... 3
2.2
Compliance to Core Foundation Skills Requirements ............................. 3
2.2.1
People Skills ........................................................................ 4
2.2.2
Project Management ............................................................. 8
2.2.3
Business ............................................................................. 9
2.2.4
Architecture ....................................................................... 10
3.
Compliance With Experience Requirements ............................................... 23
4.
Professional Development ....................................................................... 28
5.
Contributions to the IT Architect Community ............................................. 30
6.
Experience Profiles ................................................................................. 31
6.1
6.2
6.3
7.
Experience Profile 1: ENTERPRISE ARCHITECTURE: TRAINING ACADEMY32
6.1.1
Project Summary ............................................................... 32
6.1.2
Business Opportunity or Problem .......................................... 32
6.1.3
Solution ............................................................................ 34
6.1.4
Results.............................................................................. 38
6.1.5
Lessons Learned ................................................................ 38
Experience Profile 2:
<Project>: BUSINESS SOLUTIONS ARCHITECTURE39
6.2.1
Project Summary ............................................................... 39
6.2.2
Business Opportunity or Problem .......................................... 39
6.2.3
Solution ............................................................................ 40
6.2.4
Results.............................................................................. 43
6.2.5
Lessons Learned ................................................................ 43
Experience Profile 3: INFORMATION-EXCHANGE ARCHITECTURE: AAA AUTHORITY
44
6.3.1
Project Summary ............................................................... 44
6.3.2
Business Opportunity or Problem .......................................... 44
6.3.3
Solution ............................................................................ 45
6.3.4
Results.............................................................................. 47
6.3.5
Lessons Learned ................................................................ 48
References ............................................................................................ 48
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
2
2. Compliance With Skill Requirements
2.1 Skill Levels
See Open CA: Conformance Requirements section 3.1 and 3.2
Skill Level
Skill Levels and Proficiency Ratings
Proficiency
Experience
Limited
Limited or no knowledge
None
General
General conceptual knowledge
only
Limited – Read about it, some
education
Applied
Applied knowledge
Performs with supervision or
mentoring
Deep
In depth knowledge
Mastered the current state of the
art and is able to perform without
supervision.
Expert
Expert knowledge
Advances the state of the art.
Use the above skill level definitions when completing the Core Foundation Skills tables below
2.2 Compliance to Core Foundation Skills Requirements
Evidence for CFSs and ECs should normally be within 8 years. It is recommended that
Candidates use examples from the projects cited in the experience profiles. If evidence is not in
the last 8 years, expect to be questioned closely by the board.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
3
2.2.1
People Skills
CFS01
Apply Communication Skills
Demonstrate good written communications, including the use of proper
grammar, spelling, document organization, clarity, and use of content
appropriate for the audience. Demonstrate good verbal communications,
including strong eye contact (where culturally appropriate), responsiveness
to questions, ability to stay on subject, use of good feedback, and follow-up
questions, etc., so that effective two-way communications is demonstrated.
Skill level required:
Skill level you claim:
CFS01.1
Deep
Deep
Demonstrate written application of communication skills
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
List three or more documents that were published or provided to
clients that demonstrate your ability to effectively communicate
architectural decisions and designs.
Provide the name of the document and a short description of the
purpose of the document.
10/09
03/10
XXXXX – construction of
the <major facility> by
the AAA Authority
AAA Authority (A-A) – Information Management Strategy.
This document describes the intended strategy for A-A’s handling of
information (documents, computer aided design (CAD) drawings,
geographical information systems (GIS) data, etc) throughout the
phases of the Program. The document described (using Archimate
notation), the information flows, processes, stakeholders and
business objects involved. The document was submitted to the A-A
Executive Management Board (EMB), receiving its unanimous
endorsement. It was also subsequently endorsed by The National
Archives and sets out the principles for information management by
the A-A.
07/09
03/10
Consultancy: Business
Solutions an energy
research centre,
<Location>.
Final Report: <Customer> Business Solutions. This document
was the final deliverable in a major consultancy project. The report
addressed the software-enabled services required by the Research
Center, describing the deployment architecture (based on a fully
virtualized platform) together with the functional and non-functional
requirements for each system to be procured and configured. The
document forms the basis of the invitations to tender that will be
provided to prospective Master Systems Integrators who wish to bid
for the <Project> systems contract. Section 6.2.3 below refers.
01/08
06/08
Training Academy –
Information Systems and
Services Development
Training Academy – Information Systems Strategic Plan
2008. As Chief Information Officer (CIO) of the Training Academy,
I was responsible for the formulation of the Information Technology,
Information Systems and Information Management strategy for the
organization. In exercising this responsibility, I was required to
prepare a Strategic Plan to express the vision for information
systems development and delivery and to define the overall
systems architecture. The Academy is a complex federation of
organizations, with links to parts of Government . Hence, the
systems architecture is complex, with numerous stakeholders and
special requirements. The Strategic Plan was accepted by the
Academy’s Management Board and formed the basis of subsequent
procurement and development activity. Section 6.1 below describes
my enterprise architecture work at the Academy in further detail.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
4
CFS01.2
Demonstrate verbal application of communication skills
Project or Major Activity
List three or more formal presentations that were published and
presented verbally to stakeholders, and which demonstrate your
ability to effectively communicate architectural decisions and
designs.
Provide the name of the document and a short description of the
purpose of the document.
05/10
<Project>: Business
Solutions Project
Presentation to <Employer> Management Consulting Forum
2009 – <Project> Business Solutions Architecture. This
presentation, to an audience of around 200 consultants from
<Employer>’s practices around the world, was to inform
<Employer>'s consultants about my recent activity with the Firm in
Enterprise Architecture. The presentation covered the use of
methods (specifically, the TOGAF ADM), frameworks (notably
Archimate but also MODAF) and their application to the creation of a
systems architecture to provide the business solutions required for
a major overseas energy research centre.
02/10
04/10
Consultancy: Deployment
Architecture for ABC Rail’s
Automated Fare Collection
(AFC) System
Final Presentation to Management Board – Automated Fare
Collection System Deployment Architecture. ABC Rail required
consultancy advice regarding the technology platforms to be used to
support their future Automated Fare Collection system. The matter
was contentious, as the Board had received conflicting advice from
its selected supplier and its own internal IT department. The
presentation to the Board addressed the advantages and
disadvantages of the solution options, recommending a way
forward. The recommendation was unanimously endorsed by the
Board and now forms the basis for the future development of the
AFC system.
01/07
03/07
Evolution of the
Information Systems and
Services, and enterprise
architecture, for the
Training Academy.
Strategic Plan for Information Systems Development at the
Training Academy: Briefing to the Academy Management
Board. I delivered this briefing in my role as Chief Information
Officer of the Training Academy. My audience was composed of
senior academic and business management responsible for the
major components of the Academy. The purpose of the briefing
was to present my proposals for the future evolution of the
information systems needed by the Academy as it evolved and
expanded. The proposals included an overarching information
systems architecture to enable the integration of the geographically
and culturally distinct components of the Academy into a cohesive
whole. The architecture was accompanied by a Strategic Plan for its
implementation. Both deliverables had been produced during the
period January – March 2007 and were built upon the foundation of
my previous architectural and strategy work at the Academy.
From
(mm/yy)
To
(mm/yy)
05/10
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
5
CFS02
Lead Individuals & Teams
Given a scope of architectural work to be accomplished, plan the work, form
a team to perform the work, and guide the team in performing the work to
completion.
Skill level required:
Skill level you claim:
Deep
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Provide three instances where you led a team to perform a specific
work effort and were recognized as the driving force to perform and
accomplish the task.
Describe the project or major activity in which you were the
recognized leader. Provide a short description of the leadership
skills that you used to accomplish this task.
01/04
06/08
Enterprise Architecture:
Training Academy
The development of an EA for the Training Academy is described in
my Experience Profile. At the outset of the engagement, I held the
post of Chief Technology Officer. The duties of this post were
extended part-way through the work described and re-designated
Chief Information Officer. In those roles, I directly led a team of 12
managerial and technical staff and had overall responsibility for the
governance of ICT delivery across the Academy. The major tasks,
described in further detail in the Experience Profile, over which I
had direct leadership responsibility and full accountability for
outcome were the creation of the overall EA; the creation of the
intranet/portal; the creation of the public website (including
extranet); the creation of the new VLE. Section 6.1.3 below refers.
10/04
05/07
Training Academy:
Interface to wider
Government Systems
In this project, I was the leader of a team comprising my own staff
(a total of 8 technical specialists were involved during the course of
the project architecture and delivery phases), a further 4 specialists
from the Academy’s academic partner University IT team and, for
performance and security optimisation work, an additional 2
specialist sub-contractors. I planned and managed implementation
of the architecture, chairing the relevant steering group meetings,
providing overall leadership to the delivery team, and reporting
upwards.
07/09
03/10
<Project>: Business
Solutions
The delivery of the architecture and business solutions
requirements specification for <Project> was a project for which I
was accountable. I was required to assemble a team to deliver the
work to demanding time limits and within budget. I did so by
creating a team of supporting consultants from within my
(consulting) group and from the wider Firm, and I also engaged a
sub-consultant from another organisation. My team and I engaged
with the client’s technical team. I was, as team leader, responsible
for all aspects of delivery of the project, from conception to release
of the final deliverables. In directing that process, I was also
accountable for the quality control and budget management of the
work. Section 6.2.2 below refers.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
6
CFS03
Perform Conflict Resolution
Mediate opposing viewpoints and negotiate equitable solutions to ensure
successful and stable outcomes.
Skill level required:
Skill level you claim:
Applied
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Document three situations where you helped to mediate opposing
technical/architectural viewpoints and successfully negotiated an
equitable solution to ensure the successful outcome of an IT project
or architectural task.
02/10
04/10
ABC Rail Automated Fare
Collection System
deployment architecture.
<Employer>’s Newcastle office asked me for specialist architectural
support to mediation between their client’s (a major rail and public
transport company)business leaders and the IT organisation. The
disagreement related to the solution deployment architecture. The
business envisaged a wholly outsourced solution; the internal IT
department warned of significant associated risks and
disadvantages. A stalemate had been reached. The timely delivery
of the project was at risk. I assessed the architectural options and
the risks to service delivery, cost containment, timeliness and
security (including PCI/DSS compliance). I concluded the
engagement by the delivery of a report and a presentation to the
Management Board and the Head of IT. I recommended (inter alia)
that the local IT department operate the disaster recovery facility
instead of the outsourced service provider. This resolved the
conflict equitably and unblocked the project.
08/09
06/10
Information-Exchange
Architecture: AAA
Authority
I was asked to mediate between the IT provider and the Information
Security group within the A-A. The former wished to deliver a costeffective IT service with what they perceived as adequate levels of
security; the latter wished to avoid, or at least minimise, risk. I was
asked, by the Head of Systems and Technology (representing the AA Finance Director) to assess the risk and cost implications of the
alternative architectures from impartial perspective. I did so,
recommending a more balanced and cost-effective option. This was
adopted. The business-level outcome was that the A-A was able to
proceed towards systems accreditation, whilst containing the cost
within the original budget and without jeopardising the building
program or risking contractor penalties. Section 6.3.2 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
One of the early consequences of the architecture I proposed was
the interconnection of previously separate LANs and the creation of
inter-domain trusts between their Windows domains. This was, at
first, vehemently rejected by the Heads of IT in the Colleges that
were to be joined. The reasons put forward for the rejection were
related to the risks that such connection and extension of trust
would, it was argued, incur. It was argued that these risks would
mean that the service expected of their respective IT departments
could not be provided.
The solution that I proposed was to adopt a incremental, measured
series of transitional architectures, gradually opening up interconnections as trust was established. This route was slower and
more costly than a leap to the target architecture, but was more
appropriate for the culture of the colleges concerned. Therefore,
the interconnection came into being with high-grade firewalls at
either end of a “no man’s land” of fibre across the site; each firewall
was controlled solely by the nearest College’s IT staff. Domain
trusts were also slowly and incrementally established; at first the
trust extended only to specific machines and was not transitive; this
was progressively extended to meet the more urgent business
requirements until, eventually, full inter-domain trust was created.
Eventually, with a change in the arrangements for IT support across
the Academy’s main campus, one of the two firewalls was removed.
The final (distant) target architecture was the full removal of all
firewalls between the College systems and their combination in a
single Active Directory domain. Nonetheless, a workable
arrangement was put in place and the degree of inter-College IT
integration improved sufficiently quickly to support the courses that
spanned multiple Colleges. Section 6.1.2 refers.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
7
2.2.2
Project Management
CFS04
Manage Architectural Elements of an
IT Project Plan
Given a project plan, identify those elements of the plan that put the
integrity of the architectural elements at risk and manage those elements
through to the agreement by the client/project manager that the project
has been successfully completed.
Skill level required:
Skill level you claim:
Deep
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Document 3-5 examples where you worked closely with the
client/project manager to identify and address elements of the
project plan that put the architectural integrity of the project
plan/timeline at risk – show how you mitigated or otherwise
managed the risk to both the architecture and the project
milestones.
01/04
06/08
Enterprise Architecture:
Training Academy
One of the key architectural principles that I had established for the
Training Academy was that of single sign-on based on
authentication with the central Windows Active Directory. However,
the project manager for the intranet project wished to deploy the
project with an exception because the open-source application
chosen was not readily compatible with Windows integrated
authentication (NTLM). He intended to use a separate, intranetspecific, authentication source. This would preserve the project
budget and timeline, but I considered that this would unacceptably
damage the architectural integrity. Therefore, I worked with the
project manager to identify a specialist developer able to write a
custom adapter for the intranet to allow it to authenticate users
with NTLM. I arranged for the project budget to be augmented
from a central fund for integration projects (which was under my
control) to allow this work to proceed. The resulting interface
component was successful; single sign-on was achieved, and the
architectural principle was obeyed.
08/09
06/10
Information-Exchange
Architecture: AAA
Authority
During my work at the AAA Authority to provide an integrated
information-exchange architecture, the project manager for a
Consolidated Secure Remote Access project was reluctant to
implement the specified target architecture, based on a common
two-factor authentication service. In order to meet his own
company targets, he argued for an exception to be permitted for
certain applications, suggesting that they did not justify two-factor
log-in and that a special case should be made. On my
investigation, it became apparent that he was unaware of the likely
future increase in the sensitivity of the information handled by
those particular applications. Therefore, I arranged meetings to
explain this – the future increased security risk profile – and
obtained his support for the intended, universal two-factor
authentication service to control remote access, as specified in the
target architecture. Section 6.3.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
An architectural principle I had established was that of costeffectiveness, including sufficient, but not excessive, capacity,
resilience and availability. A contractor was appointed to develop a
new database system to support a newly created major course.
The availability of the system did not need to be extraordinarily
high; a recovery time objective of several hours, based on manual
intervention in the event of hardware failure, was acceptable. The
technology architecture initially proposed by the contractor risked
violating the cost-effectiveness principle; it was extravagant, with
multiple clustered physical nodes, automatic failover, etc. I
arranged a meeting between myself, the business sponsor, the
project manager (PM) and the project technical architect to resolve
this. The PM recognized that the existing design would violate the
cost-effectiveness principle and we arrived at a decision to simplify
the database technology architecture, removing the excessive high
availability elements. This resulted in compliance with the
architectural principles, cost savings and a satisfied business
sponsor.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
8
2.2.3
Business
CFS05
Understand Business Aspects
Understand the stakeholders’ business needs, and how they relate to their
business and mission.
Skill level required:
Skill level you claim:
Applied
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Provide three examples where you have demonstrated your
understanding of the stakeholders’ business needs, and how these
needs relate to the wider context of the business and mission.
Examples must show how you made an explicit linkage between the
technical architecture and business need, and how you expressed
the architectural value proposition in business language.
01/04
06/08
Enterprise Architecture:
Training Academy
When the Training Academy formed, the principal business sponsor
was the Director. His first priority was the integration of the
constituent Colleges’ activities. This was achievable in the short
term only by exploiting IT to improve functional integration. I
proposed a new technical architecture which involved the creation
of network links (leased-line LAN extensions) between hitherto
separate Colleges and inter-domain trusts to facilitate information
sharing and collaborative working. My explanation of this was
based on the use of high-level architectural diagrams, together with
explanations of the business scenarios that the architectural
changes would make feasible. The Director was convinced by my
proposal and provided funding and his explicit support for the
changes needed. My proposed architecture was implemented
incrementally. Most of the major changes were achieved over the
course of the next two years and were considered by the Director
and his Management Board to be extremely successful.
10/04
05/07
Training Academy:
Interface to wider
Government systems
The organisation’s headquarters needed to communicate securely
with others in the Government and to reach secure, internal
government websites. The business sponsor was the Chief of Staff
(COS) of the Academy. I discussed the need with the COS and
with others who had related requirements. I also investigated
future planned changes to the requirement (e.g. the imminent
introduction of a new financial system that the Academy would
need to reach; and a growing need for interaction between
students and the wider government systems). The most obvious,
conventional solution to the problem would have been unaffordable
and would not scale to meet future demand. I developed a novel
technical architecture to provide a cost-effective and efficient
solution and briefed it to the COS and other key stakeholders. I
used high-level architectural schematics and business scenarios
(linked to specific functions within the Academy) to explain the
concept. I explained the cost savings in terms of the capital and
operating costs anticipated over a 5 year period, comparing the
conventional option with my proposed architecture. The business
sponsor was persuaded to fund my proposal. The resulting system
was extremely successful and met all business needs at a cost of
£8M less than the conventional solution.
07/09
03/10
<Project>: Business
Solutions
One of the principal reasons that <Employer> was awarded the
consultancy work to support the creation of the business solutions
architecture for the <Project> energy research centre was that I
was able to convince the Project Management and Proponent team
that the needs of their operational activities (i.e. the Centre's
business) would form the basis of the technical architecture that I
would propose. As with my earlier examples, the linkage between
technical architecture and business requirements was expressed
using the language of use cases and business scenarios. These
illustrated to the client the way in which essential business
(administration and research) processes would unfold and how the
proposed information systems architecture would support those
processes. I employed the same approach to describe the value of
the non-functional requirements specified in the architecture - for
objectives such as recovery from major failures or disasters.
Section 6.2.2 refers.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
9
2.2.4
1
Architecture
CFS06
Develop IT Architecture
Given one or more business requirements, create the structures of a
solution that can be validated to meet those requirements.
Skill level required:
Skill level you claim:
Deep
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Document 3 – 5 instances where you created the structures of a
solution represented as architectural artifacts (for example with
UML or with another modeling notation) that satisfied the functional
and non-functional1 business requirements. The architectural
solution was communicated to the development team and
reviewed/validated by the client.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
01/04
06/08
Enterprise Architecture:
Training Academy
I presented the structure of the intended overall solution, during
the early stages of my architectural work at the Academy, as a “rich
picture” following the Soft Systems Methodology proposed by
Checkland. The presentation was to the Director and his Chief of
Staff, later repeated to the Management Board. This is a fairly
freeform representation of the influences on the situation in
question, including the stakeholders, key processes, etc. However,
in this case, it was very useful to explain the development of the
Academy and the effect on that development of the disconnected
information systems present at the time. The rich picture served to
clarify the issues and the potential remedies that I was suggesting,
including the high-level requirements. My presentation of the
problem and the high-level solution in this way helped to move the
overall program forwards. Section 6.1.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
One of the major application developments in the program was the
creation of an intranet/portal as the central “hub” of collaboration
across the Academy. The Zope-based intranet was integrated with
a number of other major systems, including Windows Active
Directory (an LDAP-based integration), two separate Student
Records Databases (ODBC connections), the Virtual Learning
Environment of one major college (embedded iFrames), two
separate Library Management/Catalogue systems (Z39.50
protocol), and a special-purpose second Zope instance (XML-RPC
integration). Clearly, explaining a solution of this complexity to the
various stakeholders involved, both business-side people and IT
support staff, required a combination of model-derived diagrams,
catalogues, matrices and other architectural artefacts to explain the
intent, the impact, and the requirements to be satisfied. I used
UML (generated using the ‘Poseidon’ tool) for the diagrammatic
work and a combination of Word and Excel for the text products.
Section 6.1.3 refers.
08/09
06/10
Information Exchange
Architecture for the AAA
Authority (A-A)
There are several key stakeholders in the information flows needed
to prepare for, and to deliver, XXXXXXX. These include the A-A
(responsible for building the facilities); the organising committee
actually delivering XXXXX); the Security Directorate (all aspects of
security); the Government Department (security and other political
aspects); the Transport Coordination Centre (all- transport during
XXXX); and several others. I, and the team I lead, modelled the
complex network of information flows that will be required between
these organisations in a <vendor, application> tool. I am using the
model to generate a range of architectural products – diagrams,
catalogues and matrices – to communicate the requirements, both
functional and non-functional, to the stakeholders. I am also using
the model to communicate requirements to the managers of
specific projects needed to address capability gaps. The modelling
language I am using is based on Archimate 1.0 with modifications
and extensions to address the specific requirements of the XXXXXX
information-flows task.
See TOGAF 8.1.1 Chapter 19 “Taxonomy of Service Qualities”
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
10
CFS07
Use Modeling Techniques
Use modeling techniques – such as use case scenario modeling,
prototyping, benchmarking, and performance modeling – to describe the
problem space, to size the solution and to validate that the proposed
architecture addresses the business requirements.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where you employed accepted modeling
techniques for different purposes. Identify the purpose of each
model and how that purpose was achieved.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
06/10
Information Exchange
Architecture: AAA
Authority
I am using use case and business scenario modelling – illustration
of the principal situations to be handled using the target
architecture – as an important element of the architectural work I
am leading at the AAA Authority. The use of use cases is an
important tool for ensuring shared understanding with the non-IT
stakeholders – for example specialists within the security services;
it allows both the solution architects (i.e. my team) and the future
user to confirm that the situations that the intended solution is to
satisfy have been understood and prioritised correctly. It also
allows me to link the technical systems and the final (business
level) outcomes – i.e. “if this thing fails, you won’t any longer be
able to handle that situation”. In addition to textual use cases, I
used models represented graphically (in UML and, for higher-level
concepts, using Archimate notation) to demonstrate the future
system’s configuration and operation.
07/09
03/10
<Project>: Business
Solutions
I also used use case based scenario modelling as an important tool
in the architectural work I led to meet the information systems
needs of the <Project> energy research centre. Many of the
Proponent team members were not experienced in the processes
required in an academic/research establishment. Therefore, I
elected to use modelling techniques, with process diagrams
illustrating dynamic, time-based flows of activity, to explain the
usage scenarios for the main systems I proposed. This allowed me
to gain client support for the functional and non-functional
requirements I suggested would be necessary and for the intersystems integration that I felt would be required. Gaining support
in this way then allowed the project to proceed to detailed
requirements definition. In this project, as with that above, I used
visual models of both the intended (static) architecture and of the
intended dynamic process flows to explain my proposals. The
models were produced using the Archimate notation and processes
were modelled in the Business Process Modelling Notation (BPMN).
The experience profile at Section 6.2.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
I used UML-based modelling, usually followed by the creation of a
working prototype, extensively in the development of the individual
systems required by the Training Academy’s target architecture. A
number of the key systems (e.g. Intranet, Extranet, public website,
course-support database, online registration system) were created
on a Python-based application server platform. This platform
supported model-based application development; i.e. UML models
could be created to represent the intended application functionality
and structure, and substantial components could then be generated
into Python code by the framework. This greatly accelerated
communication with business sponsors – who could see the
concepts involved in creating their desired business service
expressed in the graphical model – and actual development, as
much “boilerplate” code could be reliably auto-generated. In many
cases, the UML modelling was preceded by higher-level visual
modelling based on storyboards. This process – storyboard, to
UML, to prototype, to application - proved to be an excellent way to
resolve uncertainty regarding process flows, requirements, etc and
led to a rapid and effective final-system development. Section
6.1.3 refers.
From
(mm/yy)
To
(mm/yy)
08/09
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
11
CFS08
Perform Technical Solution
Assessments
Given a technical solution and the underlying business requirements that
drove its development, assess the technical integrity and risks inherent in
that solution in such a way that the recommendations and findings are
appropriate and implementable.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where you evaluated, for different
purposes. a solution in the context of the business requirements.
Identify the purpose of each assessment and how that purpose was
achieved, for example: risk assessment, security assessment agility
assessment, and capacity assessment.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
04/10
ABC Rail: Automated Fare
Collection System
Deployment Architecture
I was appointed, as an independent enterprise architect, to
examine the deployment architecture proposed for the new
Automated Fare Collection (AFC) system to be used by ABC Rail. A
major difference of opinion had arisen between the ABC Rail
management team and the company’s IT department regarding the
proposed deployment architecture – which was to be based entirely
in the service provider’s data centres. I was asked to assess the
proposed solution architecture (and the service level agreements
and reporting indicators for future service level management) with
regard to risks associated with “vendor lock in”; security; PCI/DSS
compliance; value for money; and ability to change (for example to
cope with altered trading conditions or new regulations). I
examined all project documentation and design materials;
interviewed the key stakeholders; and conducted targeted research
in particular areas (such as PCI/DSS compliance in virtualized
environments). The product of my work was a briefing to the
management board and a written report. These products identified
a future architecture that was acceptable to both the business
(Board) and the technology (IT) sides of ABC Rail.
05/10
08/10
Network Rail – Integrated
Train Planning System
Review for Office of Rail
Regulation
I was appointed in the formal role of “Independent Reporter Part
A”, according to the provisions of the Rail Regulator, to examine a
major systems deployment by Network Rail. The project had been
delivered 2 years late, over the budget agreed in the original
business case, and had caused substantial disruption on “go live”.
I was asked to review the system architecture, the project
planning, project management and other aspects of system design
to report, to the Office of Rail Regulation, on the root causes of the
problems. My work revealed that these were related to inadequate
risk management throughout the project; inadequate system
capacity (a combination of application architecture and technology
architecture issues were involved); an unsuitable data architecture
(data quality and data exchange formats were unfit for purpose);
and an unsuitable testing regime. The product of the work was a
written report to the Office of Rail Regulation; the report is being
used to support further (ongoing) action by the ORR.
11/09
12/09
Geographical Information
System for the AAA
Authority
I performed a risk assessment for the disaster recovery provisions
associated with a key system at the A-A – the GIS for Transport.
The ability of all of the A-A’s systems to withstand various
prospective interruptions was subject to scrutiny. The other major
systems were demonstrably resilient and rapidly recoverable.
However, my investigation revealed that the GIS was installed on
physical servers (i.e. not on virtual machines) with direct-attached
storage (i.e. internal hard disks) and had taken considerable effort
to build to a satisfactory state. Therefore, although the operating
software was stored safely (in a definitive software library), the
data (content) was backed up regularly and the build was
documented, the anticipated recovery time following a total server
failure would have been unacceptable. I specified a revised
architecture based on a virtual server platform, with virtualised
data storage. The change is now funded and will be implemented
as part of an overall Accreditation and Resilience program.
From
(mm/yy)
To
(mm/yy)
02/10
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
12
Given project requirements that call for or would benefit from the use of
standards, establish, implement, and enforce appropriate standards in the
creation and implementation of the solution to meet those requirements.
CFS09
Apply IT Standards
Skill level required:
Deep
Skill level you claim:
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Provide three examples where you effectively integrated open IT
standards, industry IT standards or your company’s/client’s IT
standards into the solution design in order to meet project/business
requirements. You may also use examples where you created a
new standard that was necessary in order to meet the project
requirements.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
01/04
06/08
Enterprise Architecture:
Training Academy
The intranet portal created as the central hub of information
distribution and sharing at the Academy was heavily based on the
use of open standards to promote interoperability and integration.
The specific standards that were central to this work were LDAP
(for access to data held in the central Windows Active Directory);
Z39.50 (for interaction with library catalogue systems); HTTP and
HTTPS (self-evidently for web-based content delivery); XML-RPC
(the method for calling remote services that was then the main
mechanism supported by the Zope application server); and ODBC
and JDBC (for connection to remote relational databases). My
selection of the particular solution was heavily influenced by its
extensive support (and that of Python, the underlying programming
language) for open standards. Section 6.1.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
One of the major projects within the overall solution set deployed
by me at the Training Academy was the Electronic Document and
Records Management System, EDRMS. The specific solution I
selected was based on the open-source Alfresco software.
Alfresco’s support for open standards and a specific industry
standard – Microsoft’s CIFS (Common Internet File System) – was
heavily influential in my choice. Firstly, Alfresco supported the use
of REST (representational state transfer) for simple web services
interactions, which was valuable for its integration with other webbased services at the Academy. Secondly, it supported both LDAP
integration and Windows Integrated Authentication (via the NTLM
protocol) – valuable for single sign-on and integration with other
Directory services. Thirdly, the support for CIFS – quite unusual
for enterprise-grade EDRMS – meant that it could present itself to
users as simply a lettered drive, allowing them to use familiar
actions such as drag and drop, and “save as” to the EDRMS. This
dramatically improved user acceptance and reduced the training
burden. Section 6.1.3 refers.
03/10
08/10
Integration of energy use
displays with building
management systems –
“Low2No” project
This project is a current <Employer> activity funded by the YYY
Government, addressing a development in <Location>. I led the
design of an integrating architecture, intended to allow the building
management systems (BMS) and building automation systems
(BAS) deployed in the buildings involved in the project to
communicate with an analytical and presentation service layer and
thence to user-visible displays. The objective was to provide
feedback and control to users and facilities managers regarding
building energy usage and carbon release. The architecture I
produced had to address both the standards used by existing and
legacy BMS and BAS – typically BACnet and LonWorks - to facilitate
communication with those systems – and a common language for
information and command exchange with other applications and
services – including future services. The latter was achieved by
using the HTTP protocol to provide web services using a RESTbased architecture. Thus, the solution combined both highly open
standards with widely deployed industry standards.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
13
CFS10
Establish Technical Vision
Given requirements and a list of stakeholders, identify approaches, tools,
techniques, and technologies to meet the requirements, and explain the
present and future rationale so that stakeholders accept the choices and
agree with the rationale.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where given the functional and nonfunctional principles of the project and a list of stakeholders, you
identified different approaches, tools, techniques that could be used
to successfully implement the project. Briefly describe the rationale
used to obtain consensus from the stakeholders (developers,
project management, client team, etc) to accept your architectural
decisions.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
Each example must demonstrate the connection between business
and technical architectural decisions.
03/10
<Project>: Business
Solutions Architecture
I was appointed to lead the architectural design of the systems
architecture needed by this major new energy research centre.
The work was conducted under contract to <Partner>, which was
responsible for overall project management. I worked firstly to
establish the business-level requirements and constraints; these
were based on both expressed needs and on internationally
recognized best practice. I then presented, in the form of
architectural schematics, business scenario descriptions, and
cause-effect (Ishikawa) diagrams the options that I considered
feasible. I took into account a wide range of influences, including
technical capability, cost, supportability, alignment with wider
<Partner> practice, security, etc. I also adopted an explicit
examination of project risk, using a risk register to highlight and to
track potential risks.
One approach considered, but not fully adopted, made extensive
use of “cloud” resources – infrastructure, platform and software
services externally provided – with the rationale that substantial
cost savings and flexibility gains could be realized. Another
approach considered, and partially adopted, was extensive use of
open source technologies to control cost and risk of vendor lock-in.
However, there was cultural resistance to some elements of these
approaches. Nevertheless, I did gain consensus in using a Linux
based platform to support the ERP system, the whole service being
externally hosted by a third party. This was, overall, substantially
cheaper than Windows-based, in-house options. The remainder of
the solution adopted was based on Microsoft technologies. I
obtained consensus on this based largely on the ease of integration
of the sub-components; on the ease of obtaining technical
expertise in <Location>; and on Microsoft’s increasing adoption of
open interface standards to assist future expansion and integration.
I also proposed that the services should use an integrating
middleware layer (to be based on BizzTalk Server) to support
integration with the ERP system and envisaged future systems.
After some discussion of the merits and costs, this was accepted.
08/09
06/10
Information-Exchange
Architecture: AAA
Authority
At the initiation of this work, although the high-level requirements
were reasonably clear, the selection of tools and techniques
remained open. The conventional approach to systems
architectural work, used elsewhere in the A-A, generally used a
combination of Microsoft Visio (for diagramming) and Microsoft
Excel (for data capture). Neither an enterprise architecture tool
nor a formal notation or language were used. However, I explained
the merits of the tool+formal language approach – increased
consistency, ease of updating, etc – and obtained agreement for
the budget required to adopt an approach based on an architectural
tool and a formal notation, notwithstanding the higher cost (in an
era of budget scrutiny). My recommended approach was
recognized as the most cost-effective and valuable for the long
term. Section 6.3.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
I led the architectural development of a new course-support system
for the Training Academy and also acted as project manager for the
From
(mm/yy)
To
(mm/yy)
07/09
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
14
development and deployment. A new major course was being
created and a central coordination platform was required to support
it. The requirements were diverse – including communication of
course timetables, obtaining feedback from students, collecting
submissions for marking, distributing course material, providing
urgent notifications, etc. I worked with the business sponsors
(teaching and administrative staff) for the new system to identify
viable architectural choices. I helped them to examine commercial
off-the-shelf (COTS) options, an option to modify existing systems,
and options to create a bespoke system. In the latter, I offered
two choices – a Microsoft based option and an open-source based
one. I used diagrams to show the various architectural building
blocks - capabilities – required, to explain the significance of the
choices to be made. I explained my rationale in terms of future
flexibility, acquisition and operating costs, ease of use, and
business scenarios to be addressed. I had developed the analysis
in terms of pros and cons for each option. No “off the shelf” or
open source software was available to meet all of the perceived
needs adequately. My final recommendation, of an architecture
based on development of a bespoke system using open source
components, was accepted. I then led the development of a
prototype, which led to the deployment of a highly successful, and
economical, final system.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
15
Given an architectural question, use and apply various techniques, such as
data collection, data analysis, hypothesis, and solution formulation, to
produce a supportable answer to the question.
CFS11
Use of Techniques
Skill level required:
Deep
Skill level you claim:
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Provide three examples where given an architectural question, you
used and applied various techniques, for example, data collection,
data analysis, hypothesis, force field analysis, functional
decomposition, joint application design or solution formulation, to
produce a supportable answer to the question.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
01/04
06/08
Public Website for the
Training Academy, with
online services
I led the team that developed the Training Academy’s public-facing
website and created the architecture for that service, including its
back-end integration with internal authentication and database
systems. I applied a range of techniques to collect and analyse the
requirements and constraints for the design. These included
stakeholder analysis; modelling of the information exchanges that
needed to be supported (e.g. for course registration online); formal
risk assessment of the site security; stakeholder analysis; and
functional decomposition – to determine and then to prioritise the
requirements and hence the appropriate architectural elements.
These addressed various matters, including Spam rejection, ability
to handle large media files, single-source authentication and site
workflows.
01/04
06/08
Intranet for the Training
Academy
I also led the team to create the concept for, obtain support and
budget for, and to create the Academy’s internal intranet system. I
applied a combination of graphical and textual representations of
stakeholders, influences, data flows, workflows/process flows were
used to determine the core capabilities that the system would need
to exhibit. Furthermore, a particular technique that I applied was
user interaction testing. In this, I set various representative
“challenges” for the test users to address, by using the intranet and
associated search engine. Their interaction with the system was
recorded and the data analyzed to improve usability on key tasks.
The outputs from these processes formed inputs to the
architectural design.
08/09
06/10
Information Management
for the AAA Authority
(an element of Experience
Profile 3)
I was appointed to lead the A-A’s work on information and records
management. In performing that task, I was required to create an
architectural roadmap for the systems needed to meet the A-A’s
obligations. The roadmap was then used to ensure coherent effort
from the team placed under my direction. A key element of that
concerned the process flows and supporting systems architecture
needed for the final disposal of the vast quantities of information
generated during the construction phase. I was tasked with the
production of an architecture and description of what was required,
for presentation to the Executive Management Board. In preparing
this recommendation, I conducted an analysis of present and future
information requirements, information flows, influences (using force
field analysis to prioritise and represent the various types of
influence) and hypothesis to address unclear aspects. Section
6.3.3 refers.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
16
Given a work effort select a method that meets the method recognition
criteria in section 6 of the Conformance Requirements, adapt, apply, and
enforce the use of that method to successfully guide the creation of work
products that meet the requirements of the work effort.
CFS12
Apply Methods
Skill level required:
Deep
Skill level you claim:
Deep
Project or Major Activity
Provide three examples where, given a work effort, you selected a
method that met the recognition requirements, and adapted,
applied, and enforced the use of that method to successfully guide
the creation of architectural work products that met the
requirements of the work effort.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
06/10
Information-Exchange
Architecture: AAA
Authority
The method I selected for the information flows architectural work
at the AAA Authority was TOGAF 9, but was adapted to produce only
the artefacts necessary for the task. For example, the full content
framework of TOGAF 9 was not required; instead an Archimate
model was created and customised views were produced. However,
the Architecture Principles, Architecture Definition Document, and
Architecture Requirements Specification envisaged by TOGAF were
produced, albeit with more organisationally-appropriate names.
Section 6.3.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
The method I applied here was, as described in Experience Profile 1,
initially based on Checkland’s Soft Systems Methodology but later,
as the nature of what needed to be done became more clear and
more widely recognized, I developed the architecture using TOGAF 8
(again, adapted to the local circumstances) and, in the absence of a
content framework in that version, some of the views of MODAF.
Section 6.1.3 refers.
07/09
03/10
<Project>: Business
Solutions
I developed the Business Solutions architecture for <Project>
following the TOGAF 9 ADM, again using Archimate as the notation
and core metamodel. The full ADM cycle was not required for
<Project> because the final deliverable required by the client as an
outcome of the engagement was a set of requirements definitions
(including architecture documentation) which were to be used for
Invitation to Tender (ITT) action. Therefore, the work was required
to complete only Phases A, B, C, D and E of the TOGAF cycle. Phase
E was required, since in some areas specific solution options were
required by the client. The terminology and document structure
used were adapted, from those in TOGAF itself, to match the
requirements of the client’s in-house style and format. Section
6.2.3 refers.
From
(mm/yy)
To
(mm/yy)
08/09
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
17
CFS13
Define Solution to Functional and
Non-Functional Requirements
Given the functional and non-functional requirements, define a solution that
meets the stated requirements using the organization’s and industry
standard procedures and tools.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where given the functional and nonfunctional requirements, you defined a solution that met the stated
requirements using the organization’s and industry standard
procedures and tools.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
05/07
Secure Access to
Government Information
Services from the Training
Academy Desktop
In a prior phase of this project, I had defined the functional and non
functional requirements. I led the team that converted the
requirements into a deliverable solution. I defined the architectural
building blocks and described their inter-relationships using a
graphical tool (Poseidon) using the UML notation, as this was
familiar to the team members. I, and my team, then evaluated
candidate technical solutions for their suitability for inclusion as
solution building blocks. Since the final solution had to undergo
formal government security accreditation, I also followed the
prescribed procedure for preparing a “risk management and
accreditation document set” (RMADS) for the solution architecture.
Other tools I used to support the project were MS Project, to
produce Gantt charts and for resource planning, and MS Excel to
track project costs against budget.
07/09
03/10
<Project>: Business
Solutions Architecture
I led this project throughout, supported by a team of 7 others. An
early stage of the project had generated the requirements, using
the Volere method. When the requirements were reasonably clear
(future discussion and workshops were still required to evaluate
various potential trade-offs) I represented the intended target
architecture as a structure of architectural building blocks. A
graphical presentation was important, with the ability to filter the
views and to query the model. Therefore, I selected a modelling
tool to support the work and elected to use Casewise’s Corporate
Modeler tool. Some of the architectural building blocks could be
translated immediately into solution building blocks, because of
constraints imposed by the client (e.g. the use of specific SAP and
Microsoft technologies to deliver certain capabilities). The final
solution architecture was, after discussion with the client to confirm
choices, also modelled in Corporate Modeler. The tool was used to
develop the architecture in all domains, including the underpinning
technology infrastructure, delivery of which was the responsibility of
others. The model provided a common point of reference for all
members of the team.
08/09
06/10
Information-Exchange
Architecture: A-A
The requirements for the XXXXX information exchange were
expressed in general terms by the various stakeholders involved.
The team that I led used the Volere method to ensure that the
requirements were clearly expressed, unambiguous and testable.
The tool used to manage the requirements was the existing
document management tool (<vendor><application>). The
requirements were used by me to derive a generic architecture and
the tool selected to model the future information exchange services
was <vendor, tool>. As the characteristics required of the building
blocks became better defined, specific solutions were identified for
each component and the model developed to show the actual
solutions, with their performance and other detailed characteristics.
I developed the model at different degrees of resolution for different
parts of the overall scope.
From
(mm/yy)
To
(mm/yy)
10/04
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
18
CFS14
Manage Stakeholder Requirements
Given approved business goals, objectives, and constraints, document,
clarify, refine, detail and prioritize functional and non-functional
requirements.
Skill level required:
Skill level you claim:
Deep
Deep
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Provide three examples where, given approved business goals,
objectives, and constraints, you documented, clarified, refined,
detailed, and prioritized functional and non-functional
requirements.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
01/04
06/08
Enterprise Architecture:
Training Academy
The Director of the Training Academy, with his Management Board,
set the overall goal as the integration of the hitherto separate
Colleges that had amalgamated to form the Academy. How this
integration was to be achieved was, insofar as information systems
were concerned, the work that I was appointed to lead. Certain
objectives were expressed by the Director and his board, but in
high-level, output-focused, terms. My task was to convert those
high-level aspirations into tangible requirements, both functional
and non-functional, and to articulate the assumptions that I had
made so that they could be formally agreed (or corrected). I
conducted research into the approaches and methods available to
produce actionable requirements definitions and elected to use the
“Volere” template produced by the Atlantic Guild. I have
subsequently found this an extremely effective approach for
articulating prioritised, measurable requirements in a way that helps
communication with the sponsor. I produced requirements that
were based on usage scenarios and more detailed use cases. I had
arrived at these scenarios following extensive discussion with the
business sponsors in the various Colleges, intended to elicit their
principal concerns and to put them in priority order. I then created
a hierarchical, prioritised set of requirements and constraints based
on my research with the College Principals. These requirements,
described by using the Volere template, were then discussed with
the Director and his Chief of Staff to arrive at the agreed, prioritised
set used to set the budget and to form the input to the definition of
the solution architecture.
07/09
03/10
<Project>: Business
Solutions
The vision for this project was set very approximately by the
Proponent team, based on what they had seen in other research
centres around the world. A significant part of my consulting task
was to convert this vision into a set of prioritised requirements (and
then into a solution architecture). I (and the team I led) developed
the requirements based on discussions with the client business
sponsors and on research with other comparable institutions. I
again used the Volere template, adapted to meet the specific needs
of this project, to ensure that each requirement was expressed
unambiguously and was capable of subsequent verification. The
organisation’s expressed research priorities were used to guide the
requirements, which were ranked using the “MoSCoW”
(must/should/could/will eventually) approach. Version control of
the evolving requirements was imposed using <Employer>’s
internal document management system’s inbuilt version control.
08/09
06/10
Information-Exchange
Architecture: AAA
Authority (A-A)
A significant element of this task was the definition of requirements
for information and records disposal at the time of the expected
dissolution of the A-A (in 2014). Although the overall goals were
set, and the relevant legislation and regulations set some of the
constraints, these influences needed to be converted into defined,
measurable requirements that could be satisfied (for example by
projects to define processes, system configuration, etc). I again
used the Volere framework to guide requirements development and
used Archimate to express the process flows involved. The
prioritisation of the requirements was developed in conjunction with
key stakeholders via a series of table-top exercises in which various
possible scenarios were examined, their impact considered, and the
implications of failure evaluated. This allowed me to allocate or to
clarify the priorities allocated to the information exchanges and the
systems needed to realize them.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
19
CFS15
Establish Architectural Decisions
Determine, document, and communicate architectural decisions to
support and rationalize the design of the solution.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where you established, documented, and
communicated architectural decisions that supported and
rationalized the design of the solution.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
05/07
Secure Access to
Government Information
Services from the Training
Academy Desktop
I led the conception and creation of the architecture to provide this
secure access. I was also the project manager for the subsequent
implementation. The high-level requirement was to enable
affordable, convenient but secure access to Government
information services from the desktops connected to the Academy’s
LAN. There were various architectural options available, each with
its supporters. I was, as lead architect, required to decide between
the solutions and to explain my reasoning to the Management
Board. To resolve the definitive architecture for the system, I
mapped the key user requirements to the expected characteristics
of the possible architectural solutions. The various architectural
options offered different strengths and weaknesses. However, the
best overall combination was, I demonstrated, the configuration
that I had recommended. This met all key requirements and most
secondary requirements in the most cost effective way. This
impartial mapping of capabilities to architectural options persuaded
the supporters of the alternative solutions to align behind my
suggestion. This then formed the basis of further development and
eventually led to a highly successful outcome.
07/09
03/10
<Project>: Business
Solutions Architecture
I led the development of the architecture for all software-enabled
services at this research centre. The early part of the work focused
on identifying and prioritising the requirements to be met by the
business solutions. I then produced what I considered to be the
optimum architecture to integrate the various building blocks,
aiming for a solution that was not excessively complex but which
would provide the flexibility needed for the future growth of the
establishment. I expressed the proposed architecture using views
prepared from a model developed in Casewise’s Corporate Modeler,
using the schematics to explain the rationale to the business
sponsors. The recommendations were accepted and formed the
basis of the subsequent detailed design work. Sections 6.2.3.3 and
6.2.3.4 below outline the development of the architecture.
08/09
06/10
Information-Exchange
Architecture: AAA
Authority
I was the lead architect for this work, which was a significant
element of my role as Chief Enterprise Architect for the A-A. I (and
the members of the team I led) gathered business-level
requirements from the stakeholders in this information exchange.
My role in designing the architecture was then to determine which
architecture building blocks – predominantly communications
capabilities – would be needed to support the use cases and
scenarios that the stakeholders had envisaged. I had to elicit from
them the details that would influence the architecture. As the
target architecture became increasingly clear, I prepared
schematics using a <tool>-based model to explain the proposed
architecture. These schematics supported the discussion that I led
to obtain a consensus, and in turn formed the basis of more
detailed solution design work and system acquisition projects.
From
(mm/yy)
To
(mm/yy)
10/04
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
20
CFS16
Validate Conformance of Solution to
the Architecture
Given a set of requirements, define and execute strategies and plans for
ensuring and demonstrating that the solution satisfies the documented
architecture.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where, given a set of requirements, you
defined and executed strategies and plans for ensuring and
demonstrating that the solution satisfied the documented
architecture.
Only provide examples where your role in the effort was as the lead
architect of the project or a significant subsystem or component.
05/07
Training Academy:
Interface to Government
information services
Because of the crucial role of Government accreditation of the
system delivered in this project, it was essential for me to
demonstrate that the deployed system actually conformed to the
target architecture – on which accreditation decisions were made.
The steps I took to ensure this were the instigation of regular
technical design reviews, which mapped the detailed technical
design with the architecture, highlighting any deviations. I
instigated a formal change and exception handling process for any
such misalignment, such that the architecture, the detailed design,
the deployed system and the accreditation documents (the RMADS
– Risk Management Accreditation Document Set) were all aligned.
The conformance of the deployed solution to the documented
architecture was also tested by independent penetration testing
and audit.
08/09
06/10
Information-Exchange
Architecture: A-A
As with the example above, the highly specific requirements of
Government accreditation were drivers to ensure that the delivered
solutions conformed to the documented architecture. Again, the
central element in the accreditation document set was the target
architecture, which was expected (by the independent Accreditor)
to accurately reflect the “reality on the ground”. In this case, I set
up an Accreditation Board which provided oversight of project
delivery and which applied a formal, minuted change and
exceptions process to the deployment process to ensure that the
solution delivered conformed to the intended architecture. Section
6.3.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
During the deployment of the various individual solutions required
for this architecture, described at Section 6.4.3 below, I instigated
a governance body, the Information Systems Working Group. This
body, chaired by me, was formed of the Heads of IT for the various
component organisations, assisted by their technical staff. Part of
the formal remit of the Group was to examine the alignment
between each project, from inception to entry to service, to ensure
that its development conformed to the intended architecture.
Where deviations from this were suggested, the reasons were
examined by the Group and an exception process was applied.
Section 6.1.3 refers.
From
(mm/yy)
To
(mm/yy)
10/04
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
21
CFS17
Perform as Technology Advisor
Maintain IT industry knowledge to advise on technical trends and
techniques and apply them to the development of solution designs.
Skill level required:
Skill level you claim:
Deep
Deep
Project or Major Activity
Provide three examples where you have advised on IT industry
technical trends and techniques and applied your knowledge of
them to the development of solution designs.
NOTE: Only provide examples where your role in the effort was as
the lead architect of the project or a significant subsystem or
component.
05/07
Training Academy:
Interface to other
Government systems
I was CTO of the Training Academy and fulfilling the role of lead
architect. In this role, I created an innovative approach to the
problem of creating an affordable interface between the Academy’s
ICT and that of the wider government. My solution relied on my
knowledge of the current capabilities of Windows Terminal Services
and other forms of desktop virtualisation. The development of the
solution required an understanding the specific technical options
that might be applied, combined with an understanding of the
broader government IT environment (including the various forms of
authentication that were required for different application services)
and of the accreditation process prescribed by the government.
01/04
06/08
Enterprise Architecture:
Training Academy
Also during the period for which I was CTO and fulfilling the role of
lead architect, a requirement became clear for a more flexible,
simple-to-use, and effective remote access service – that would be
capable of passing formal accreditation. The only existing means of
remote access was a problematic and inconvenient IPSEC VPN
system. I conducted research into the current state of the art, and
proposed the introduction of a then-groundbreaking SSL VPN
system (from a vendor named Neoteris, now Juniper). This service
proved to be exceedingly effective and simple both to use and to
administer. My initiative was then adopted more widely to provide
secure, auditable, accreditation-worthy remote access. Section
6.1.3 refers.
01/04
06/08
Enterprise Architecture:
Training Academy
A further aspect of the architecture introduced by me at the
Training Academy, in the role of CTO/lead architect, involved the
innovative use of RF identification (RFID) devices and readers to
allow fast, safe check-in/check-out of <physical assets>. Some of
the Academy’s courses dealt with design aspects of <physical
assets> and these had, on a regular basis, to be taken for
demonstration. Furthermore, government regulations required
100% stock checks to be conducted at regular intervals. I
introduced a highly novel RFID-based database-supported workflow
to dramatically improve the reliability and assurance of the process
(formerly based on paper documents and spot checks). Section
6.1.3 refers.
From
(mm/yy)
To
(mm/yy)
10/04
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
22
3.
Compliance With Experience Requirements
See Open CA: Conformance Requirements section 3.4
Evidence for CFSs and ECs should normally be within 8 years. It is recommended that
Candidates use examples from the projects cited in the experience profiles. If evidence is not in
the last 8 years, expect to be questioned closely by the board.
EC01
Experience
Producing
Architectures
You must have at least three (3) years of experience producing IT architectures.
Guidance to Candidates: The Program is intended to recognize those individuals that possess both
the required skills and a level of experience that demonstrates that they have mastered the ability
to successfully produce IT Architectures.
Candidates for Level 2 Certification (Master Certified IT Architect) are expected to have taken
responsibility for producing successful IT architectures with occasional assistance from less
experienced IT Architects where appropriate.
Project or Major Activity
From
(mm/yy)
To
(mm/yy)
Description of at least 36 months of full-time equivalent
engagement with, and accountability for, the architectural aspects
of one or more projects or engagements
01/04
06/08
ENTERPRISE
ARCHITECTURE: TRAINING
ACADEMY
I was wholly responsible for the architectural conception and design
of the architecture to meet the Training Academy’s requirement for
integrated information systems. This extended to the subsidiary
architecture of the major building blocks of the overall solution.
The work addressed the business architecture of the ICT services
provision and the information systems and technology architectures
for major technology projects including those to deliver EDRMS,
intranet, website, business services, e-learning environment,
integration with government systems and others. The work is
described in greater detail at Experience Profile 1, section 6.1.
07/09
03/10
<Project>: BUSINESS
SOLUTIONS ARCHITECTURE
I delivered the architecture for the software-enabled services,
including the virtualised server platform, for a major energy
research centre. The work addressed all of the information services
required to support the Centre’s activities, both administrative,
communicative and research. The details are described in
Experience Profile 2 (section 6.2)
08/09
06/10
INFORMATION-EXCHANGE
ARCHITECTURE: AAA
AUTHORITY
I was (and am), as Chief Enterprise Architect for the A-A,
responsible for the overall systems and information-flows
architecture. One representative architectural project was that for
the information exchanges with external stakeholders and within
the A-A itself, to support the various phases of XXXXX preparation
and delivery. My role as CEA at the A-A actually began in June
2008, with other projects related to business and information
systems architecture. The work on the information-exchange
architecture project is described at Experience Profile 3, at section
6.3.
Reference may be made to the Experience Profiles in Section 6
Provide, in the table below, the names and contact details of people who can vouch for your
participation and contribution in each of the above experiences.
Your References may be customers/clients or Master Certified IT Architects who are not your
immediate manager.
References are required to substantiate the above experience. Please include letters or emails
from your references in section 7 of your certification package below.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
23
Project or
Major Activity
ENTERPRISE:
TRAINING
ACADEMY
BUSINESS
SOLUTIONS
INFORMATIONEXCHANGE
Name and position/job title of Reference
Your References will be contacted.
Please provide current addresses, phone numbers and
email addresses
Mr A Jones
Project Manager
12, Abc Drive, Reading, Berks, RG1 2BH. UK
+44 1234 5678910
a.jones@nowhere.com
Mr A Smith
Application Development Manager
121 Charing Cross Road, Holborn. London, WC2H 0EW. UK
+44 207 11111111
a.smith@hotmail.com
Miss K Kat
Senior Account Manager
1 Monument Hill, Weybridge, Surrey KT13 8RX. UK
+44 2222 1263456
k.kat@whiskers.co.uk
References are required to substantiate the above experience. Please include letters or emails
from your references in section 7 of your certification package below.
EC02
Breadth of
Architectural
Experience
You must have experience architecting IT solutions which:

Involve the application and integration of a broad variety of products, technologies and
services from either the enterprise or solution perspective

Encompass both functional and non-functional components across multiple elements of IT
architecture in each project (Business, Application, Infrastructure, Information)
Guidance to Candidates: A Master Certified IT Architect has experience integrating multiple
elements of IT architecture to enable the development of correct and complete solutions to
business problems.
From
(mm/yy)
To
(mm/yy)
Project or Major Activity
Description of three Qualifying Experiences
Reference may be made to specific sections within the Experience
Profiles, or Candidates may provide detailed descriptions of work
efforts that demonstrate compliance with this criterion.
10/04
05/07
Training Academy:
Interface to the
government information
services
This project was one of the major projects needed to deliver the
architecture for the Academy and was needed to enable the
organisation to interact effectively with the wider government
community. It involved the integration of wholly disparate
networks and networked services with stringent security
requirements, and based on a variety of different technologies. The
architectural work addressed each of the business, applications,
information and technology domains, as well as the vitally
important security domain. The solution that I proposed was the
creation of a wholly separate Windows domain at the Academy,
connected via high-grade firewalls to the wider government’s wide
area network and its services. In that domain would be created
client machines (based on Windows XP) and these machines would
be reached from the Training Academy LAN desktops by means of a
virtualisation system - prospectively based on Windows Terminal
Services (TS). By this means, any entitled user on the Academy
LANs would be able to open a Terminal Services session, to a
machine in the government environment, to be able thereby to
operate in that environment.
07/09
03/10
<Project>: Business
Solutions Architecture
(Experience Profile 2)
This project, described in detail at Section 6.2.3.1, involved the
creation of an architecture and detailed requirements specifications
for an integrated solution combining Microsoft, SAP and Oracle
technologies. It also required architectural work in all four principal
domains, plus security.
08/09
06/10
Information-Exchange
Architecture: A-A
(Experience Profile 3)
One substantial aspect of my work as Chief Enterprise Architect at
the A-A is described at Section 6.3.3.1 – that on information
exchanges. The architectural aspects of this work were broad,
addressing the overall operational/business requirements, the
applications and data needed by the operators and the various
technology services needed to support the complex interchanges.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
24
EC03
Experience with
different types of
technologies and
architectures.
You must have experience with multiple types of systems and applications architectures,
and multiple hardware and software platforms.
Guidance to Candidates: A Master Certified IT Architect has had exposure working with different
systems, application architectures. Through this experience, a Master Certified IT Architect can
effectively make the decisions that most appropriately satisfy requirements and mitigate or
otherwise manage risk to the project
From
(mm/yy)
To
(mm/yy)
Type of systems,
applications, hardware, and
software platforms you
have worked with
Description of one or more Qualifying Experiences
Reference may be made to specific sections within the Experience
Profiles, or Candidates may provide detailed descriptions of work
efforts that demonstrate compliance with this criterion.
10/04
05/07
Microsoft Server 2000;
Windows Active Directory;
Windows XP;
Microsoft Exchange;
Checkpoint Firewall;
Oracle Financials as web
service;
Microsoft Terminal Services;
Zope-based intranet
(Python-based) on Linux
(Red Hat) operating system,
with Virtuozzo operatingsystem level server
virtualisation;
A project was required at the Training Academy integrate a
combination of technologies, including major products from
Microsoft, Oracle (the Government’s then-new HR system, an
essential application service on the interface system; and a new
Oracle-based financial system), and Checkpoint firewalls. The
objective of the integration was to allow the business level
interactions between the Training Academy and the wider
government environment to take place, at an affordable cost but
with a high level of security. The integration of the various services
and components involved had to be designed by me and capable of
formal security accreditation. The information systems architecture
I proposed included an Exchange email server within a Terminal
Services environment, file and print servers and application servers
for specific services needed by particular staff roles (particularly the
Finance function). I also specified a secure FTP server, with full,
auditable logging, to facilitate controllable file transfer between the
local and the domains used in other government systems. The
architecture I proposed allowed entitled staff and users to move
readily between the local and the other government environments,
with cut and paste action between documents in the two
environments. This was a particularly welcome aspect of the
architecture. The common point of reference for all users of
information systems at the Academy was the intranet, the
architecture of which I had created. This system was based on the
Zope application server and was created on a Linux (Red Hat
Enterprise) platform. As the role and complexity of the intranet
increased, I elected to use virtual servers and, for reasons of
scalability, efficiency and cost-effectiveness, I elected to use the
open-source Virtuozzo platform from Parallels.
07/09
03/10
Microsoft Sharepoint 2010,
Exchange 2010, Office
Communications Server
2008R2;
Oracle 11g on Windows
Server 2008;
SAP ERP on Linux (Red Hat
Enterprise);
Microsoft BizTalk Server;
IBM/SPSS analytics
software.
The <Project> project described at 6.2.3.1 involved the integration
of collaboration technologies from Microsoft, database and data
analytics technologies from Oracle and IBM, and ERP services
provided by SAP. The SAP installation was based on Red Hat Linux,
because of the greater cost effectiveness and performance felt to
be available from that platform. I was required to apply sufficiently
deep knowledge of each product to design an implementable
architecture that would satisfy the client.
08/09
03/10
Airwave digital trunked
radio;
Microsoft Sharepoint 2007;
Juniper SSL VPN;
Ultra Electronics NRE secure
portal;
BRENT2 secure telephony;
Entrust 2-factor
authentication server.
The technologies involved in the A-A’s interaction with the broader
stakeholder community are diverse, ranging from secure radio
(Airwave) used by the security and emergency services, to secure
web platforms and strong authentication services used for classified
document exchange. The work is described at Section 6.3.3.1.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
25
EC04
Application of
Methods
You must have repeated and successful experience of selecting and applying an
appropriate method recognized by The Open Group (or one that meets The Open Group’s
Recognition Requirements set out in section 6 of the Conformance Requirements) to do
architectural work
Guidance to Candidates: Demonstrated ability to select and apply a recognized method ensures
repeatability of delivery and success. Candidates are not required to have used more than one
method
Method
Description of at least three experiences using one or more
recognised method(s). (Three experiences using the same
recognised method to do architectural work fully meets the
requirement).
Reference may be made to specific sections within the Experience
Profiles, or Candidates may provide detailed descriptions of work
efforts that demonstrate compliance with this criterion.
06/08
TOGAF 8 & MODAF
I applied TOGAF 8 to both of the architecture program and the
major projects at the Training Academy, described in the
Experience Profile 1. The architectural work was conducted in
accordance with the ADM, but the format and naming of the
architectural products were tailored to the organisational
requirements and culture. The views of the architectural model
were based on MODAF recommendations.
07/09
03/10
TOGAF 9 & Archimate
I used TOGAF 9 to guide the architectural work for the <Project>
Business Solutions (Experience Profile #2, Section 6.2.3.3). As
with my use of TOGAF 8, I tailored the method and the products
produced to meet client expectations and needs. The content
model was replaced with the Archimate framework, which was itself
modified.
I also used the TOGAF 9 ADM in work needed to support ABC Rail’s
decision making regarding deployment architecture. The use of
explicit baseline and target architectures was helpful to allow the
stakeholders to take a more dispassionate view of the drivers and
requirements.
08/09
06/10
TOGAF 9
I applied TOGAF 9 to the Information Exchange architecture work
for the A-A, described in Experience Profile #3, section 6.3.3.2.
Some of the viewpoints from the MODAF framework were selected,
as was the Archimate language to define notation and entity types.
From
(mm/yy)
To
(mm/yy)
01/04
EC05
Intentionally left blank.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
26
EC06
Full Lifecycle
Involvement
You must have been responsible for the architecture definition activity of a project or
engagement across the full lifecycle appropriate to that project or engagement, and
must have been involved as an IT Architect, or in some other capacity working with
others, to ensure the architecture has been realized.
Participation in each phase of the lifecycle need not be as lead IT Architect.
Guidance to Candidates: A Master Certified IT Architect is expected to have had full lifecycle
experience.
Project
Description of Qualifying Experience
You must identify at least one project or work effort in which you
have performed architectural work across the full lifecycle
from inception through to deployment.
Reference may be made to Experience Profiles, or Candidates may
provide a detailed description of a work effort that demonstrates
compliance with this criterion. If none of your Experience Profiles
demonstrate full life-cycle, be prepared for detailed questioning
about your full life-cycle experience
Experience Profiles in which you claim full lifecycle
involvement must be listed here.
05/07
Training Academy:
Interface to other
government information
services
I was fully accountable for the project, one of the major
implementation projects arising from my enterprise architectural
work at the Training Academy (Experience Profile 1). My
responsibility extended from initial conception, to definition of the
business requirements and constraints, to application and data
architectures, to the detail of the technology architecture. The
latter was particularly affected by the security demands – the
system was novel, but had to be formally accredited for information
security. I was also responsible leading system detailed design,
delivery and oversight of service management. My role was CIO
and de-facto Chief Enterprise Architect.
06/08
Enterprise Architecture:
Training Academy
(Experience Profile 1)
This work is described at Section 6.1.2 onwards. I was responsible
for the entire high-level systems architecture and for the full
lifecycle of the major component projects, from initial concept to
in-service delivery and support.
From
(mm/yy)
To
(mm/yy)
10/04
01/04
EC07
You must have demonstrated expertise in one or more industry sectors, including the
Industry Knowledge business, legal and regulatory context
Guidance to Candidates: Master Certified IT Architects need to have broad, up-to-date and
relevant expertise in the industry sectors in which they work, and must have applied that
knowledge.
Industry
From
(mm/yy)
To
(mm/yy)
Description of at least three activities through which you have
acquired your industry sector knowledge
Reference may be made to specific sections within the Experience
Profiles, or you may provide detailed descriptions of work efforts that
demonstrate compliance with this criterion
Education
01/04
06/08
My years as CTO and then CIO of the Training Academy, working with
academic and support-systems colleagues from partner and other
universities provided me with a deep understanding of the use of
technology to meet the business requirements of higher and further
education. Section 6.1.2 refers.
Construction
06/08
07/10
I have worked for a little over one year on full time secondment to the
AAA Authority, as Chief Enterprise Architect, followed by a further full
year on a 2-3 days/week basis. The function of the A-A is construction
(of the <major facility>). My role has demanded a substantial level of
expertise in the ICT needed to support major construction activities,
including the legal and regulatory aspects. Section 6.3.2 below
describes an example of the scope of my duties.
Transport (Rail)
02/10
07/10
I have performed consulting assignments for rail transport operating
companies and for the Office of Rail Regulation related to systems
architecture and program management. These tasks have required
me to develop a significant understanding of the systems
requirements and regulatory issues for rail transport.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
27
EC08
Knowledge of IT
Trends
You must have demonstrated knowledge of the significant trends in the IT domain.
Guidance to Candidates: Master Certified IT Architects need to be aware of current significant
market and technology trends and possess the ability to apply trends to architectural decisions
From
(mm/yy)
To
(mm/yy)
Description of at least three activities through which you have acquired your knowledge of IT
market and technology trends
Reference may be made to specific sections within the Experience Profiles, or you may provide
detailed descriptions of work efforts that demonstrate compliance with this criterion.
07/09
03/10
Virtualisation: In my work on the <Project> business solutions (Section 6.2.2) I conducted
substantial supporting research into the use of virtualisation in modern IT architectures, at every
level of the infrastructure domain – storage virtualisation (ie. SANs); server virtualisation –
particularly the new capabilities for dynamic capacity management available in products such as
VMWare VSphere 4; desktop virtualisation (using leading products including VMWare View and
Citrix XenDesktop); and application virtualisation (with products such as Citrix XenApp and
Windows Terminal Services).
05/10
08/10
“Cloud” Computing and Federated Identity Management: A recent piece of work for which
I have been engaged (through <Employer>) is related to the provision of a new, highly flexible
end-user “desktop” for a major UK transport-related organisation. To support this work, I have
conducted extensive research into both virtual desktop technology (extending my work as
described above, but to include new devices such as smartphones) and federated identity
management to provide single sign-on for “cloud” based solutions – using technologies including
SAML2, Shibboleth, and OpenID.
02/10
07/10
PCI/DSS and Virtualisation: As server virtualisation becomes more widely adopted, the
impact on computing resources shared through virtualisation are of increasing significance to the
credit card industry, and in particular to PCI/DSS compliance. A recent engagement with a major
rail transport operator required me to analyze the security and regulatory implications of a
virtualized infrastructure, proposed by an outsourced service provider, but which would need to
be certificated as PCI/DSS compliant by the Rail Operator.
4. Professional Development
PD01
Training
During the last five years you must have completed training in the design and
engineering of IT architectures either through attendance at a taught course, or through
self-study.
Course
Date
(mm/yy)
Course Description
Description of Qualifying Course or Self Study Program or Material
Provide the date and name of the course or self-study program or material,
along with a description of the course or self-study objectives and content.
02/08
MODAF
MODAF for Practitioners. Formal 4 day course by Cranfield University,.
11/07
TOGAF 8
Formal 5-day course by Architecting the Enterprise. London.
08/09
Casewise Corporate
Modeler EA tool training
Formal 2 day vendor course on the use of the Corporate Modeler tool to produce
enterprise architectures. London, 19/20 August 2009.
10/09
BiZZdesign Architect tool
training
2 day course on the latest version of the Architect tool and the Archimate
language. Liverpool John Moore University, 28/29 Oct 2009.
03/10
Salamander MooD training
2 day course on the latest version of MooD.
06/10
TOGAF9 Self-Study
Studying TOGAF9 Open Group material, with a view to the bridge exam.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
York, UK, March 2010.
28
PD02
Maintain IT Industry
Knowledge
Candidates must provide a written description of the activities they have
undertaken to maintain their knowledge of the technology, trends, and
techniques in the IT industry.
Please list the activities in which you have participated in the last three years. Activity is
required in at least 2 of the categories in the table below
Category
Conferences Attended
Personal Reading
Activity


Gartner BPM Summit, February 2009;
Cisco CIO Day 2010 (2-day conference to address future trends & advances in
technology and their effect on the IT industry and various verticals). Date: 01/10
Subscriber/reader: Information Age, Computer Weekly, PC Pro.
Formal Education
Being Mentored
Training Courses
Related Professional
Memberships
Other Activities
PD03
Maintain Vertical Industry
Knowledge


IT Infrastructure Library (ITIL v3) Expert Bridge 4-day Course – Date: 04/08
ISO/IEC 20000 Consultants Course & ISEB Exam, August 2007.
Membership of BCS and BCS Elite; participation in educational and social/educational
events.
“Enabling Innovation” – 2 day workshop held by <Employer>. The event addressed the
innovation process, with particular regard to ICT, the built environment and future
transport systems and routes to optimisation. Date: 02/09
Candidates must provide a written description of the activities they have
undertaken to maintain an understanding of the client's business as it pertains
to the client's vertical industry (e.g. telecoms, financial, etc.). Candidates should
be aware of the latest trends and techniques that may influence IT architectures
for their customers within industry verticals. Candidates should endeavor to
sustain this learning process during the time they are engaged with a client or
produce architectures that are industry specific
Please list the activities in which you have participated in the last three years. Activity is
required in at least 2 of the categories in the table below:
Category
Conferences Attended
Personal Reading
Activity






Institute of Civil Engineers (ICE) – Conference on IT in Construction, July 2009
ITSMF Service Delivery conference Nov 2009
BCS Conference on Quantum Computing, Mar 2010.
I3CON (“Industrialized, Integrated, Intelligent Construction”) EU project Research
Report Handbooks, 2009, 2010
Advances in Government Enterprise Architecture. Collected papers, P. Saha, 2009.
Handbook of Research on Urban Informatics. M. Foth. 2009.
Formal Education
Being Mentored
Training Courses
Related Professional
Memberships
Other Activities
Cisco CIO Day 2010 Barcelona – senior level, invitation only 2 day workshop in Feb 2010
on IT in various verticals, including construction.





<Employer> Innovation Workshop ERIM4 – 2 day workshop on innovative thinking
and solution development in engineering, held at London School of Economics. Feb
09.
One-day workshop on virtualisation in the construction environment (VMWare, UK
HQ), Mar 2010;
One-day workshop with UK National Air Traffic Services and <tool vendor> to discuss
enterprise architecture in aviation (with CTO and Chf Enterprise Architect) Aug 09.
Research in energy-related studies with UK Energy Research Centre (based in
Imperial College, London) in support of architecture consulting work for <Project>.
Regular listening to “ITConversations” podcasts, particularly “Interviews with
Innovators” series. Many of these recordings contain interviews with leading-edge
specialists in various sectors, many of which are related to <Employer>’s consulting
work and target markets.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
29
PD04
Develop skills and
knowledge in IT
Architecture
Candidates are expected to continually develop their skills and knowledge in IT
Architecture.
Please list the activities in which you have participated in the last three years. Activity is
required in at least 3 of the categories in the table below:
Category
Conferences Attended
Activity





Personal Reading




Gartner Enterprise Architecture analysts clinic, held September 2009 – discussed
current developments in EA from Gartner’s perspective, including its application to
construction and transport market sectors.
Gartner BPM Summit, held February 2009 – addressed latest developments in
business process management and the relationship with enterprise architecture.
Salamander conference “'Getting your business in shape for the future: using EA to
positive effect” – 1 day event, held in London on 8 October 2009.
The Open Group 22nd Enterprise Architecture Practitioners Conference, London, April
2009.
The Open Group 18th Enterprise Architecture Practitioners Conference, Glasgow, April
2008.
TOGAF9 Manual and Open Group self-study certification materials;
Advances in Government Enterprise Architecture. Collected papers, P. Saha, 2009.
Enterprise Architecture as Strategy. Ross et al. 2006.
Building an Enterprise Architecture Practice. Van Den Berg. 2006.
Formal Education
Being Mentored
Training Courses





Related Professional
Memberships
Other Activities
Casewise Corporate Modeler training – 19/20 August 2009. Formal 2 day vendor
course on the use of the Corporate Modeler tool to produce enterprise architectures.
Salamander MooD tool training – 2 day course on the latest version of MooD, held in
York March 2010.
BiZZdesign Architect tool training – 2 day course on the latest version of the Architect
tool, and on the Archimate language, held at Liverpool John Moore University, 28/29
Oct 2009.
TOGAF 8 – formal course by Architecting the Enterprise. London, November 2007.
MODAF for Practitioners – February 2008
I am a member of the BCS and BCS Elite and attend various seminars and
educational/social functions related to architecture work.
Research related to business development for the business and enterprise systems
architecture practice within <Employer>.
5. Contributions to the IT Architect Community
CC01
Contribution to the IT
Architecture profession
Candidates must make contributions to the architecture profession for example,
mentoring, publications, teaching, research collaboration or participation in
professional organizations.
Please list activities in which you have participated in the last three years. Contribution is
required in at least 3 of the categories in the table below:
Category
Your Contribution
Mentoring
I perform mentoring of the members of both my team (business and enterprise systems
and architecture) within <Employer> and also of members of other consultants within the
IT & Communications consulting practice. A significant element of my duties involves
such development of our architectural capabilities.
Publications
Article for the (internal, <Employer>-wide) journal, entitled “The Architecture of
Enterprise Systems”, describing the use of enterprise architecture, supported by tools, for
complex, major projects involving IT systems development or change..
Teaching
I prepare and deliver seminars and training sessions for consultants within <Employer>,
ranging from lunchtime learning sessions to all-day focused teaching sessions on
architecture related matters and how they can be applied to our consulting areas.
Research
As a part of my job as a managing consultant, I am regularly required to perform
research into architectural and systems technology matters for our clients. We are
frequently required to deliver to clients leading-edge IT-enabled solutions. Some of this
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
30
CC01
Contribution to the IT
Architecture profession
Candidates must make contributions to the architecture profession for example,
mentoring, publications, teaching, research collaboration or participation in
professional organizations.
Please list activities in which you have participated in the last three years. Contribution is
required in at least 3 of the categories in the table below:
Category
Your Contribution
research is conducted in collaboration with leading UK universities.
Related Professional
Memberships
Other Activities
I am a member of the British Computer Society and the British Computer Society’s Elite
group.
Development of internal awareness and understanding of enterprise architecture within
the <Employer> Group, by: [1] holding lunchtime seminars; [2] production of articles for
the internal “Connect” journal; [3] presentations/training sessions targeting specific
vertical markets, such as construction, airport systems, rail systems.
6. Experience Profiles
The following pages provide a template for your Experience Profiles. You are required to
provide three Experience Profiles, and you may provide up to five.
An Experience Profile is a coherent written description of a project or architectural engagement
(for example: enterprise architecture, solution architecture or architectural framework) that
provides you with the opportunity to show how you perform as an IT Architect, and enables a
Certification Board to understand and question your thought processes and decisions.
See section 4.1 of the Open CA Conformance Requirements and, in particular, Table 4 which
lists specific attributes (EXP01 – EXP07) that each of your Experience profiles should
demonstrate.
Please also note that:
Candidates must provide three Experience Profiles describing projects undertaken within
the eight (8) years preceding an application, at least one of which must have been
undertaken in the last three (3) years. Projects over two (2) years long may be used for
multiple Experience Profiles under either of the following conditions:

The project had clearly-defined work efforts which took place in parallel, each with
their own solution development and design activities and their own deliverables.

The project had clearly-defined phases that were executed in succession, each with
its own solution development and design activities and deliverables. Note that a
second project phase that constructs and implements the solution developed by the
first phase does not meet this requirement.
When writing your Experience Profiles please provide your own thoughts – do not just copy
project documentation. Diagrams from the project documentation may be helpful, but the text
should be in your own words
Please use the first person in your discussion, so it is clear to reviewers what you did versus
what others did – say “I did X” rather than “X was done”.
Note that even in discussing what some other project member did you can demonstrate your
thinking as an architect
Diagrams can be very helpful, but please ensure they are relevant, readable, and help the
board members to understand what you did on the project.
Focus on quality rather than quantity. If you provide more than three Experience Profiles, copy
the Profile template as needed.. Remember, you must stay within the 50 page limit.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
31
Your profiles do not need to demonstrate full life-cycle involvement (see EC06) but we strongly
recommend that at least one does so.
Experience Profile Summary:
Profile Name
Start Date
End Date
Full Lifecycle involvement?
Profile 1
Enterprise Architecture: Training
Academy
01/04
06/08
Yes
Profile 2
<Project>: Business Solutions
Architecture
07/09
03/10
No
Profile 3
Information-Exchange Architecture:
AAA Authority
08/09
06/10
No
6.1
Experience Profile 1: ENTERPRISE ARCHITECTURE: TRAINING ACADEMY
6.1.1
Project Summary
6.1.1.1
Identification
Client Name
Training Academy
Nature of project
Enterprise Architecture to support a radically-revised business model
Location of project
<Location>
Name of your employer
<Employer>
Duration
6.1.1.2
From
To
Total project duration
01/04
06/08
Your involvement
01/04
06/08
Resources
6.1.1.3
Your Team
Client
Subs
Project team size
12
15
7
Size of team led by you
12
15
7
6.1.1.4
Personal Involvement
Please list the phases of the project in which you were personally involved
Start
Completion
01/04
03/04
Architectural vision
03/04
03/05
Core architecture development 1 – intranet and networks
03/05
03/06
Core architecture development 2 – EDRMS, student data systems, web systems
03/06
06/08
Core architecture development 3 – Integration of external Academy organisations
Yes
6.1.1.5
Phase Description
I was involved in the full life-cycle of this solution.
Your Role(s)
IT Architect Role
X
Lead IT Architect
Lead IT Architect for a major
subsystem
6.1.2
6.1.2.1
(Optional) Other Roles You Also
Performed
X
Project Manager
Developer / Tester
Business Opportunity or Problem
Describe the business opportunity or problem(s) this project addressed and how it
related to the client’s business and mission.
The Training Academy was created as an amalgamation of historically and culturally separate educational
and research organisations. Each had its own IT systems and processes, most of which had grown in an ad
hoc manner to support local needs. Furthermore, the Academy had two principal academic partner
universities each of which brought their own elements of IT to the Academy’s heterogeneous system of
© 2005 - 2008 The Open Group
32
ALL RIGHTS RESERVED
systems. It was clear from the inception of the Academy that the integration between the various components
would rely on ICT support and that, in some areas, ICT-enabled change would lead the way. However, the
first Director of the Academy did not wish to embark on a major change and integration program and therefore
planning a master systems architecture, with associated business process changes, had to await his
successor, who arrived in 2004. At that point, I was asked by the-then Chief of Staff and the new Director to
advise the Management Board on a strategy, including an overall systems architecture, to enable the
numerous islands of IT-supported activity to come together to increase the coherence of the overall
organisation. The overhauled enterprise architecture would help to transform the Academy from being a
group of almost wholly independent Colleges and Components, into a coherent organisation with its own
identity and operating processes. The change was extremely substantial. It was expected that the major
changes would take a number of years implement, with further changes of a less dramatic nature following on.
6.1.2.2
Describe the scope and complexity of the problem.
The scope of the problem embraced the entire enterprise of the Training Academy. This was a
geographically-diverse organisation, with four major sites and five smaller ones. Its operating budget was
around £125M annually, of which the ICT budget constituted around £8M. My work on the ICT strategy and
architecture addressed the entire organisation, but my remit was to prioritise the work to address the
discontinuities that were likely to affect major courses. Such discontinuities were expected to become more
significant from 2005 onwards, because a new course – one that was required for all staff at some point in
their career – would span two historically entirely separate Colleges within the Academy. Other widelyattended courses were expected to follow the same pattern. Furthermore, the Academy wished to increase
its usage of “blended learning” – i.e. the use of electronic online teaching in combination with classroombased education. New emphasis was placed, therefore, on effective e-learning systems and other webdelivered services. My task was both technically complex – each College had its own systems to support
each of the core business processes – and politically complex – as not all organisations or academic
departments were “bought in” to the notion of the Training Academy and the anticipated loss of independence
and autonomous action that it was feared to imply. These political and cultural issues were made tangible
and clear by the architectural work. The technical complexity stemmed from the profusion of different
operating systems in use, the mixture of applications (frequently used by different Colleges to perform
essentially the same function); the absence of any agreed standards to support integration or even
information exchange; and the highly closed, proprietary nature of some key applications – particularly those
which had a strong footprint in the Higher Education/Further Education sector.
6.1.2.3
Describe your relationship and communications with client management / user
management / end users.
My relationship with the Training Academy Director and the Chief of Staff (effectively the Chief Operating
Officer) was good and I had, fortunately, their full support in addressing the challenges of the task. My
communication with them used a variety of means, which ranged from producing senior-level briefings (both
to the entire Management Board and, for some sensitive issues, to the Director alone), to issuing briefing
papers, to normal business correspondence on day to day matters. My interaction with the Academic and
Business management and other key persons in the major Colleges and Components of the Training
Academy was regular and effective. In most cases, particularly with the more technologically-focused
Colleges, my message was welcome; in other cases – particularly with the more traditionally-minded
Colleges, progress was slower to achieve and the explicit support of the Director of the Academy was
occasionally required.
The Universities proved to be, on the whole, strong and effective supporters of the re-architecting of the
Training Academy. The senior staff – both in the academic departments and the IT departments – could see
the merits of a more cohesive and better integrated architecture. Some of the business process leaders were
more reluctant, principally because of the implications for changing their long-established processes and ways
of working. Some staff simply did not wish to see any change, so their conversion was a gradual process.
My relationship with end users was effective and quite close. From my previous career I was very familiar
with the subject matter of the Academy and had previously been a member of the Academic Staff. In those
earlier roles, I had experienced some of the frustrations of both staff and students with ICT that was ill
matched to the business vision and real requirements. I was therefore able to work very effectively with the
people who would be affected in their day to day teaching and research by the proposed architectural
changes.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
33
6.1.3
6.1.3.1
Solution
Discuss the architecture you defined to address the business problem(s), including the
rationale behind its choice. Please enumerate the architectural alternatives you
considered and your reasons for their rejection.
The core of the architecture I defined was an inter-connected network of local-area networks (LANs), each
based on Windows Active Directory domains, with inter-domain trusts to allow reciprocal authentication and
access control across the Academy. In that sense, the “enterprise service bus” was a provider of networking,
authentication and access controls services made up of the principal LANs of the Colleges, inter-connected by
leased lines (operating as LAN extensions) or directly across the primary campus. The network interconnections were all protected by high-grade (EAL3) firewalls at either end of the connection. The rationale
for this particular, rather expensive, choice was twofold: firstly, it allowed the inter-connection to be politically
acceptable, notwithstanding the historical mistrust between Colleges and, secondly, it made more
straightforward the necessary formal Accreditation of the networks to carry high security traffic. The more
obvious alternative of direct connection of the LANs, and the creation of a single Windows Forest (or even a
single Windows domain) would have made much more difficult and time-consuming the task of obtaining
acceptance from the principal stakeholders.
The choice of a Windows Domain-based architecture was straightforward; all of the Colleges were
using some form of Windows system, so the migration of a single Windows-based platform, using Active
Directory to provide authentication services, was the only realistic choice. However, I also specified the use of
the Active Directory Global Catalog interface to provide standard LDAP (Lightweight Directory Access
Protocol) services to certain applications services. This was to provide a cost-effective means of ensuring
that the number of non-Windows applications in use across the Academy could use a single source of
authentication data, so that even though not strictly a single sign-on environment, the user would have to use
and remember only one username and password for all systems. This was welcome, as the historical
approach had been to create separate authentication credentials databases for each application, requiring
each user to remember numerous different account details, passwords, etc.
The services on the inter-connected LANs were, where appropriate, to be exposed to the Internet via
other high-grade firewalls. A part of my architecture development was to determine, in liaison with the
academic and research business leaders, what services should be presented to the outside in this way and
then how best to arrange this.
In respect of the Internet presence, the first phase of my architectural work addressed the creation of
a coherent, capable public web site (www.ta.xxx.gov.uk) and a single email domain capable of serving all
Academy staff with a common email domain name (@ta.xxx.gov.uk). Prior to my work, each College either
did not use public email (using only email on internal, Government systems) or had its own web and email
identity. The various objections to the coherent approach – adoption of a common web system, with a
common web address and a place for each College specified by path under the base URL, and the use of a
common, Academy-wide email domain – was eventually accepted following a number of meetings to address
the technical and operational implications of the change.
In parallel with proposing a technical architecture of inter-connected, mutually trusting Domains
across the Academy to support the Academy’s business vision of seamless interaction and collaboration, I
proposed a new core internal service – an intranet portal. Although each College had some form of intranet,
in all cases it was based on the use of individual HTML pages, created with graphical tools (e.g.
Dreamweaver) and placed on an HTTP server. This did not address the requirements of the business
architecture for inter-College and inter-Departmental collaboration and rapid information flows to staff and
students.
Therefore, I proposed a new, central intranet – to be used by and accessible from all of the Colleges –
based on a content management system. Furthermore, the architecture I proposed would place the intranet
at the heart of the Academy’s collaboration systems – essentially as an intranet/portal - to avoid the inefficient
data collection processes that were endemic – such as student registration (11 separate paper forms used) or
student feedback (paper questions sheets distributed and results manually typed into a spreadsheet for
analysis), etc. Therefore, I elected to use a CMS that had, at its core, a flexible application server and a
database. The architectural principles I had set out, and had obtained agreement to, emphasized the need to
adopt open standards and technologies – including open source software where appropriate. After examining
a wide range of options, with the participation of colleagues from the principal partner University and the other
Colleges, I elected to base the core intranet/portal system on the Zope application server and content
management system, which was build on the Python programming language and with an object database
behind it.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
34
My choice of a Zope (later developed to include the Plone presentation layer) based system, rather
than the Java-based or Microsoft CMS based, or other open-source based alternatives examined was based
on the quality of its own internal architecture and the availability – whether by virtue of Zope-specific
components or through the very extensive libraries available in Python – of means to integrate the Zope core
with other application services in use at the Academy. The latter included the relational databases in use by
the various Colleges (for example at the back end of proprietary systems used for student records, course
details, etc) and library management systems. Each College had different systems. However, the databases
could all be reached by means such as ODBC or JDBC calls from the Zope server; and the library
management systems could be interrogated (to produce a common library catalogue) by using the Z39.50
protocol – for which an effective Python library was available.
I did consider the use of an enterprise service bus (ESB) to support integration. However, at the time
of formulating the Academy’s architecture, no suitable open-source ESB was available in proven use, the
proprietary systems that existed were new, expensive and not particularly well suited to the needs of higher
education, and the need for (or value of) a fully service oriented, bus-based architecture was not universally
recognized.
Second Phase of Architecture Work
The second major phase of architecture development which I led at the Training Academy related to the
deployment of an Electronic Document and Record Management System (EDRMS); a new Virtual Learning
Environment; and the exposure of further services via the public (Internet-facing) website.
EDRMS: I had, in Phase 1, proposed an architecture which eschewed file-share based document
management and collaboration. The reasons were, inter alia, that it was not readily searchable; did not offer
version control; did not allow people to subscribe to be notified of changes; approval workflows could not be
enforced; and if documents were renamed or moved, any links to them would be broken. The second phase
of the architecture proposed the introduction of a central EDRMS to avoid the difficulties inherent with
conventional NTFS file shares. My architecture envisaged a single system at the main campus, where LAN
speeds were high, to be followed by the deployment of other, federated systems based on the same
technology at the other campuses, once the central system was well established and proven. As with the
other systems, Active Directory would be used to provide the central authentication and authorisation (and
auditing/logging) services. Furthermore, the architectural principles of adopting open standards and avoiding
proprietary lock-in wherever possible were applied.
The solution adopted, and deployed, was determined after an evaluation of a number of alternatives,
including Zope/Plone (i.e. use of the Intranet system as an EDRMS); Microsoft’s Sharepoint; Documentum;
IBM’s CMS; and the-then recently release Alfresco Enterprise CMS. The latter was adopted, since it offered
the best fit with the architectural, functional and non-functional requirements that had been agreed. Of the key
architectural requirements, the accessibility of its functionality as web services and the exposure of the folder
structure through an accurate presentation of Microsoft’s CIFS (Common Internet File System) format, were of
particular value. The former allowed the EDRMS to be integrated with other systems easily, by use of web
services (using the straightforward REST mechanism), and the latter allowed the users to view the EDRMS as
simply a new shared folder in their familiar Windows Explorer interface, or to “save as” from their applications
straight into the EDRMS folder structure.
Virtual Learning Environment (VLE): Changes to the business architecture desired by the
Academy included the increased use of e-learning and blended learning. The VLE in existing use by our
partners in the principal partner University was proprietary, costly, and difficult to integrate. It was not used by
other Colleges. Therefore, I proposed an addition to the cross-Academy information systems architecture of a
new, open-standards compliant, VLE. A number were evaluated but the final selection was based on the
open-source Moodle platform.
Extended Web Services: I proposed further changes to the overall architecture, by adding new
functionality to the public web site. This site was, as with the Intranet, based on a Zope/Plone platform –
essentially for the same architectural reasons of open-ness and cross-system compatibility. The further
development of the Academy’s integrated architecture included the use of this website to provide a Webaccessible interface to other information services on the internal network. These included:
 Student online registration, in which data was collected from future students via the website’s pages,
assessed by validation services, then passed into the back-end student registration system at which
point the Departmental workflow was invoked.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
35


Online discussion and feedback, in response to articles published on the Academy website. This
service provided some assurance of legitimacy (via CAPTCHA testing – relatively new at the time)
and invoke automated notification services to internal staff who had to respond to the comments.
Integration with the VLE, in which content on the website and in the VLE was automatically
synchronized between the two environments, removing duplication and the risk of presenting
conflicting material.
Third Phase of Architecture Work
The final phase of the architecture for which I was responsible was the extension of the architecture to include
a number of new organisations that had joined the Training Academy. The target business architecture did
not envisage a very detailed integration. Therefore, I proposed a revision of the architecture which would add
them to the Academy’s common email domain and public website, whilst allowing their internal systems to
remain unchanged. However, it was, at the time of my leaving the Academy, envisaged that the extent of
their integration with the core Academy (and their potential relocation to the main campus) would profoundly
change the business architecture – and therefore the appropriate information systems and technology
architectures.
6.1.3.2
Enumerate and describe the key decisions you made, and the reasons for making them
as you did.
A large number of key decisions were required throughout the evolution of the Training Academy’s enterprise
architecture, some of which are described above. However, perhaps the most significant were:
 My recommendation of the adoption of a common email domain, for all Components and to replace
their existing separate email domains, to provide a tangible expression of the coherence and
unification of the Academy;
 My parallel recommendation of the creation of a unified web presence, rather than separate websites,
for the entire Academy, in which a common style would be applied to all content and the individual
Colleges would appear as path elements under the single Academy domain;
 My recommendation to leave intact the existing LANs, whilst inter-connecting them via firewalls and,
where required, leased lines, with inter-domain transitive trusts applied so that the entire technology
architecture could function as a coherent whole, at least at the level of IP traffic and authentication
and access control services;
 My adoption of the principle of using open standards and, where appropriate, open-source software
as a means to avoid lock-in to particular vendors and to simplify future integration of new
organisations or changed business services;
 My decision to expose increasing numbers of services via the Academy’s web presence (website,
both publicly-accessible and log-in only extranet) and the VLE (accessible only via log-in), to drive
process change away from paper-based to online and workflow-based;
 My decision to deploy separate intranet and EDRMS systems, in which a guiding architectural
principle was the avoidance of binary file content (i.e. Word documents, spreadsheets, Powerpoint,
PDF, etc) in the former as far as possible, instead storing it in the latter and exposing it either via
hyperlinks or other techniques (e.g. IFrames). The rationale was to maintain control over documents,
keeping them in a cohesive repository which provided version control, notification, indexing, workflow
and other key document and record management services.
 Overall, I adopted an incremental approach, but one executed in accordance with a high-level
roadmap that led to greater integration within the Academy, with flexible, adaptable and – as far as
possible – non-proprietary information systems. This was to ensure that the pace of information
systems architecture change was commensurate with the overall organisational appetite for business
architecture change.
6.1.3.3
Describe the architecture method and any design methods used on this project and the
rationale for their selection.
I had, at the inception of this architecture work, some familiarity with the US Department of Defense
Architecture Framework (DoDAF) and its development, in the UK, into MODAF (MOD Architecture
Framework). Therefore, I was familiar with the concept of enterprise architecture and the use of views derived
from viewpoints. This awareness was at the heart of the architectural method I initially adopted.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
36
I was also quite familiar with Checkland’s “Soft Systems Methodology” which found particular favour
at the time with staff of the principal partner University.. I therefore, used this – highly graphical - approach to
develop the business architecture and to express the high-level aims, processes and rationale.
Since I was familiar with the Unified Modeling Language (UML), I used UML concepts extensively
throughout the architecture work, in all domains from Business to Technology. The concept of use cases was
particularly helpful in allowing me to explain the evolution from the baseline architecture to the target
architecture and why it would make sense for the stakeholders involved.
Part-way into the project, I became aware of the Robertson’s “Volere” requirements method and
greatly appreciated its value in producing clear, actionable definitions of requirements that would be testable
and which could be used to generate understanding amongst all participants. I have used this method
extensively since that time for requirements analysis.
6.1.3.4
List the design tools you selected for use on this project and discuss the rationale for
their selection.
The majority of the early architectural work was supported by using Microsoft Office products, principally Excel
(for catalogues and matrices), Visio (for diagrams) and Word (for text-based architectural products). Version
control was achieved by file naming convention.
Towards the end of Phase 1 of the work, as I began to use UML more extensively to explain the
concepts in greater detail to the various stakeholders, I began to base my work on the Poseidon for UML tool
(from Gentleware); this proved to be a powerful, yet easy to use system and architecture modelling tool. It
was also extremely helpful in supporting some of the actual implementation work, since Poseidon was able to
support model-driven programming in the Plone environment – creating executable code and new object
classes in the Zope/Plone intranet and website systems, directly from the UML application and data
architecture definitions (via a mechanism named “ArchGenXML”).
In Phase 2, I began to use the <vendor, tool> tool for high-level architectural modelling. The rationale
for the choice was partly on account of its flexibility and good graphical qualities; and also because of its
adoption for enterprise architecture work (particularly to support MODAF) elsewhere in Government – a topic
in which I had a deep professional interest.
6.1.3.5
List the project’s architectural deliverables and summarize the reason for their inclusion.
The project’s first architectural deliverable was a strategy proposal, which summarised the proposals for
unified email, web presence and inter-connected local networks. In essence, this paper was an architectural
definition document and an architecture roadmap combined. The paper contained schematics showing the
major building blocks of the intended overall systems architecture for the Training Academy, together with the
key principles (i.e. architectural principles) that would govern the future development of the information
systems structure. The strategy proposal also formed the basis of a briefing which was delivered to a number
of senior-level governance bodies within the Academy. The document and associated briefings constituted
the principal means of communicating the intention for the use of better-integrated ICT to support the closer
unification of the Academy and to obtain the support of the key stakeholders in the program that would be
required.
The strategy paper was refined and updated as the project developed. As specific solutions were
identified, the intended architectures, requirements and systems designs were documented in other
supporting products. The more detailed documents were produced to communicate to those who would be
involved in the practical implementation and migration activities – including development staff, staff
responsible for supporting services (such as Active Directory, DNS, firewalls configuration, etc), and external
MOD staff responsible for security accreditation. Document sets of this type – including system schematics –
were prepared for each of the major systems required by the new architecture.
The meetings of the Academy Management Board and the subsidiary ICT Steering and Working
groups that provided the governance structure for ICT development were recorded in the form of minutes.
These minutes were circulated and subject to formal approval at subsequent meetings of the relevant body.
In this way, an auditable record of the development of the organisations’s architecture was maintained.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
37
6.1.4
6.1.4.1
Results
Was your solution implemented? If so, describe the role, if any, you had in the
implementation. If not explain why not.
The architecture described above was implemented. The work of actual implementation was carried out
through a series of projects to close each gap between the target and the existing (baseline) architecture.
The projects were, in some cases, managed directly by me using the resources of my development and
architecture team; in other cases they were executed the assistance of the partner University IT staff; and
certain of the later changes were delivered with the assistance of the-then recently appointed service provider
(<provider>). All steps of the implementation were under my direction as the then Chief Information Officer of
the Training Academy.
6.1.4.2
Assess the overall success or failure of the project. Comment on client satisfaction,
attainment of objectives, and ultimate versus proposed cost and schedule.
The Director of the Training Academy who led the organisation throughout the major portion of the
architectural changes was fully satisfied with the progress made, to the extent of requesting that I remain in
post for an extended period to continue to oversee the realization of the intended architecture. The primary
objective - of supporting the effective unification of the Academy by means of a much more closely integrated
and coherent set of information systems and services was realized. The secondary objectives – of increasing
the effectiveness of the staff and students working at the component Colleges and research establishments –
was also attained.
The system changes required by the proposed architecture were not costed as a whole at the outset
of the project; instead, the projects needed to deliver the target architecture were themselves costed and
budgeted for. All of the work had, of course, to be delivered within the overall agreed operating budget of the
Training Academy and, in particular, the funds allocated for ICT services and service development. Each of
the implementation projects was delivered successfully within the allocated budget and, in general, according
to the anticipated timescale. Certain projects were delayed (although costs did not significantly increase)
because of the time needed to obtain the support of all stakeholders. In some cases, the time required for this
was difficult to predict, particularly where the Academy was seeking to make a change which was viewed as
innovative and a departure from convention.
6.1.4.3
Assess the success or failure of the architectural aspects of the project.
The success of the restructuring of the Academy’s information systems and services was heavily reliant on
the use of an overall architecture which described the vision, articulated the detail from the business,
applications, information and infrastructure perspectives, and which then served as the strategic roadmap for
actual delivery of the changes required. The use of an architecture-based approach was judged to have been
a welcome change from the previously fragmented and piecemeal approach to information services
development at the Academy’s formerly-independent component Colleges.
6.1.5
6.1.5.1
Lessons Learned
In retrospect, what might you have done differently on this project and what lessons did
you learn?
I learned a great many lessons throughout the extended portfolio of projects that I led at the Training
Academy.
One interesting lesson was that open source software solutions can, if selected appropriately, provide a very
robust, flexible and extremely cost effective solution to challenging IT-related problems. Furthermore, the
quality of information available concerning specific solution building blocks is, usually, greater for high quality
open source products than for proprietary equivalents – not least because the actual source code is
accessible and, frequently, the original authors of that code are identifiable, contactable and willing to help
neophytes with their specialized software.
Another lesson, learned later in the projects than I would have preferred, was the value of TOGAF as a clear
and rational method for developing a solution architecture that is well aligned to the needs of the end users
and other stakeholders. Once I had begun to use TOGAF, I did not embark on other projects without at least
partial use of the ADM and other elements of the Framework.
Another lesson learned was that simple integration interfaces are better than complex ones. In many cases, I
had to design the integration between different systems. In some of these cases, I used quite complex
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
38
approaches (e.g. using SOAP as the protocol) but eventually came to prefer the use of more web-based
methods, particularly REST (representational state transfer) architectures which were simpler to design,
create and maintain.
Another example of the lessons was the value of virtualization, at all levels from storage, to server, to network,
and to application and desktop. The server efficiency gains realized by my deployment of Virtuozzo and
VMWare virtualisation were very substantial (around a 15:1 consolidation) and extremely successful. The
virtualisation of the desktop made feasible (and economical) by using Windows Terminal Server saved the
Academy a great deal of money and gained a lot of flexibility.
6.2
Experience Profile 2: <Project>: BUSINESS SOLUTIONS ARCHITECTURE
6.2.1
Project Summary
6.2.1.1
Identification
Client Name
<Client> (through Partner)
Nature of project
Development of Business Solutions for a new energy research centre to be built
2010-2012
Location of project
<Location>
Name of your employer
<Employer> (IT/Communications Consulting)
Duration
6.2.1.2
From
To
Total project duration
07/09
03/10
Your involvement
07/09
03/10
Resources
6.2.1.3
Your Team
Client
Subs
Project team size
7
6
1
Size of team led by you
7
0
1
6.2.1.4
Personal Involvement
Start
Completion
07/09
08/09
Proposal Preparation
08/09
11/09
Preparation of enterprise architecture (vision)
11/09
01/10
Preparation of enterprise architecture (detailed)
01/10
03/10
Specification of requirements to support ITT
No
6.2.1.5
Phase Description
I was involved in the full life-cycle of this solution.
Your Role(s)
IT Architect Role
X
6.2.2
6.2.2.1
Lead IT Architect
(Optional) Other Roles You Also
Performed
X
Project Manager
Business Opportunity or Problem
Describe the business opportunity or problem(s) this project addressed and how it
related to the client’s business and mission.
The AAAA government had decided to set up a major national facility to conduct research related to energy
production and consumption. The facility is to be constructed on an undeveloped area to the north of
<Location> and will occupy an entirely new, highly innovative series of buildings designed by <Architect>.
<Employer> was commissioned to provide a number of consulting services; the area which I led was the
conception and design of the software-enabled systems, described by the client as business solutions. The
business solutions will be the core enablers of the centre’s operations.
6.2.2.2
Describe the scope and complexity of the problem.
I was the lead architect and <Employer> project lead for the software systems required to operate the
research centre. They were content and collaboration services; central database services; project portfolio
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
39
management services; enterprise search services; energy simulation and modelling services; and back-office
(ERP) services. The scope of the work included the extensive use of virtualisation – which I proposed should
be at the storage, server, desktop and application levels. The application services were expected to integrate
effectively with each other and with other building (e.g. intelligent building management system) and security
services. Furthermore, the centre’s research activities were expected to involve international collaboration,
hence the “content and collaboration” services required had to be accessible from both inside the Centre’s
bounds and from the Internet. Finally, the security architecture was particularly important, since the Centre
will be the core repository for highly sensitive national data concerning energy supplies.
6.2.2.3
Describe your relationship and communications with client management / user
management / end users.
I was the central point of coordination for all matters related to the business solutions, between the Project
Management Team, PMT (formed as a consortium between <Client> and a specialist in-country consultancy
<Partner>) and the so-called Proponent Team. The latter were research specialists and ICT specialists who
were drawn from the operational arms of <Client> and who represented the final end users who would occupy
the finished Centre. The Proponents were the de facto end users of the systems for which I was responsible.
My communications with the PMT and the Proponents were conducted by a combination of document
exchanges, telephone and video conferences, and three visits to the team headquarters in <Location> to
conduct workshops. I was responsible for organising and leading the workshops and all other communication
related to the business services work.
6.2.3
6.2.3.1
Solution
Discuss the architecture you defined to address the business problem(s), including the
rationale behind its choice. Please enumerate the architectural alternatives you
considered and your reasons for their rejection.
The architecture I proposed was based on a fully virtualized technology platform, capable of dynamic resource
allocation, automated fail-over and dynamic power management. The platform was to use a high-capacity,
scalable storage area network for disk-based storage. The core collaboration and content, documents and
records management services were to be based on Microsoft Sharepoint 2010 and the enterprise search
services were to be provided by Microsoft FAST for Sharepoint, possibly (subject to budget) augmented by
deploying SAP’s Inxight Smart Discovery server for text analytics purposes. Other elements of the
collaboration platform, providing messaging services, were Microsoft Exchange 2010 and Microsoft Office
Communication Server 2008R2. Project Portfolio Management (PPM) services were to be provided by
Microsoft’s PPM solution. The central source of authentication and access control was to be a distributed
installation of Microsoft Active Directory, augmented by Entrust Server to provide two-factor authentication
(token + username/password) for remote system users. The central energy database was to be based on the
Oracle 11g platform to be used in conjunction with Oracle extract, transform and load (ETL) and reporting
tools. Modelling and simulation services were specified using a variety of special-purpose tools, reflecting
those in use at comparable research organisations worldwide. ERP and back-office services (HR, Finance,
Supply Chain Management, Asset Management) were to be provided using SAP services. To minimise the
need for custom-coded point to point integration between the major system components, I specified the use of
Microsoft BizTalk Server to provide a middleware layer capable of supporting message exchange, translation,
queuing, and transactions.
RATIONALE: The rationale behind the specification of the architecture was based on a number of influences:
[1] The site was to be operated initially, during build-up, by existing <Partner> staff. The IT service delivery
staff who would be involved were generally familiar with core Microsoft technologies, but much less expertise
was available to support other platforms, such as Lotus or Oracle collaboration and messaging systems.
Even less expertise was available to support open source technologies. Therefore, the availability of suitably
competent support staff in <Location> influenced the technology architecture selections.
[2] Collaboration between Centre specialists themselves, and between internal staff and external researchers
was a core requirement that the business solution was expected to support. The Sharepoint platform offered
a flexible and powerful basis for effective collaboration: it offered ready integration with the principal desktop
information management software (such as Microsoft Office) and the messaging systems anticipated.
Connectors were available to facilitate its integration with other major vendors’ systems – particularly SAP
products. Furthermore, the 2010 version of the product offered improved compliance with open web
standards, further simplifying future integration tasks and Microsoft’s acquisition of the FAST enterprise
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
40
search product ensure that effective search could be integrated with the core document and records
management services.
[3] The rationale behind my specification of a fully virtualized computing platform, introduced as an
intermediate layer between the physical server infrastructure and the operating system layer, was designed to
meet the Centre’s need for flexibility, energy efficiency, high availability and ability to grow without major
structural changes to cater for anticipated future increases in staff and workloads. The architecture also
included the use of virtual desktop infrastructure – i.e. virtualized PCs – for the Centre’s administrative staff.
This was to allow low-energy end point machines to be deployed, reducing overall energy consumption, whilst
also reducing the future administrative burden by supporting centralized administration and control of nearly
half of the desktops to be deployed.
Extensive virtualisation was also specified to help assure IT service continuity and business continuity
management. The client had elected to construct an auxiliary data room, but did not wish to populate it with
sufficient servers to provide an alternate functional infrastructure service to be used in the event of a disaster.
However, the ability to store the full configuration of the primary data centre, in the form of virtual machine
images, meant that the client could plan for post-disaster restoration without the need for skilled engineers to
rebuild servers; it would be enough to install the virtual images onto replacement hardware and the service
could be restored. This reduced costs without increasing time to recover (the recovery time objective, RTO)
from a disaster beyond what the client considered acceptable. The availability of the virtual machine images
and associated data was assured by replicating the storage area network (SAN) between the main data
centre and the auxiliary data room.
ALTERNATIVE ARCHITECTURES CONSIDERED, BUT REJECTED
I considered an architecture based on the use of open source software, using open-standards web services
(principally REST interactions over HTTP) to achieve the required integration between services. The choice
of products capable of meeting certain key functional requirements (e.g. for standards-compliant records
management and highly scalable document management) was limited, so such an architecture would have
been based on Java technology, using either the JBoss or the Apache Tomcat application server at the core.
The major architectural building blocks required by the Centre were available from the open source world – for
example, the Lucene search engine would have provided the necessary enterprise search service – and the
resulting system would have had a lower initial acquisition cost and would have avoided the risk of “vendor
lock in”. However this option was rejected, primarily on the grounds that the client’s IT staff were unfamiliar
with the required technologies and because their adoption would have violated the principle, agreed at the
outset, to avoid technology proliferation – i.e. the introduction of new, unfamiliar technologies where this was
not essential to the delivery of the required service.
I also considered an architecture based on fully virtualized desktops throughout the Centre. This
would have further simplified future system administration and incident management and offered the potential
for reduced capital costs. However, I rejected such a solution because of: (a) the uncertainties – and hence
risk – surrounding the compatibility of some of the key research applications that would be used with such an
infrastructure and (b) the need for researchers to be able to work effectively whilst off-line, for example when
travelling. However, my recommendation was to conduct a future pilot study to evaluate the use of virtual
desktop infrastructure with the Centre’s applications, to determine the feasibility of a move to a wholly
virtualized architecture. I considered that the need to work off-line could probably be addressed adequately in
future by the adoption of technologies such as Google’s “Gears” or HTML 5 compatible browsers.
I also considered the use of an infrastructure architecture based on physical servers. Such an
arrangement would have been more familiar to the client’s existing IT staff and would have reduced the
system software licensing costs. However, I rejected this option on the grounds of its inflexibility, poor asset
utilisation, and more complex disaster recovery. The low utilisation that could be expected would also have
violated an agreed architectural principle – the reduction of overall energy consumption by the IT services to
the lowest level practical, commensurate with effective operation of the Centre.
A further significant architectural choice was my election to specify a middleware layer – essentially
an enterprise service bus (ESB) – to facilitate the integration between the major system building blocks (such
as between the content and collaboration system and the ERP/back-office systems). The alternative would
have been to use point to point integration between systems, where this was required to meet the relevant
use cases. However, although such an approach would have been less initially complex and therefore less
costly, it would not have offered the flexibility needed to provide the services needed for an organisation that
was expected to grow and to evolve rapidly.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
41
6.2.3.2
Enumerate and describe the key decisions you made, and the reasons for making them
as you did.
I decided the format of the proposal to the then prospective client, briefed the client face to face following my
organization’s shortlisting, and finally secured the work.
I then decided on the team needed to carry out the architecture work for the Centre’s business
solutions. I held the roles of lead architect and project manager, delegating the work of requirements and
business analysis and associated technical research to other subject matter specialists within the firm under
my supervision. I also decided to use a junior enterprise architect to assist me.
I then made the architectural choices described in para 6.2.3.1 above – i.e. the use of well known
proprietary software (where the requirements could not be described independently of implementation detail)
instead of open source software at the core of architecture; my election for a specific degree of virtualisation,
at the storage, server, desktop and application levels; and the use of a middleware layer to facilitate the
integration of heterogeneous systems, instead of a “point to point”, API-to-API, approach.
6.2.3.3
Describe the architecture method and any design methods used on this project and the
rationale for their selection.
The architecture method used was TOGAF 9, specifically the Architecture Development Method and certain
aspects of the Technical Reference Model. I have favoured this methodology for some years and have found
its logic – particularly that behind phases A-D and the emphasis on business scenarios as a means to
understand the full context of the solutions proposed – compelling for the prospective clients I have briefed
regarding the approach.
I elected to base the project’s metamodel and notation on Archimate 1.0, with a small number of
modifications to model entities such as goals, concerns, projects, etc. I favoured Archimate because of its
clear graphical notation and the logic of its subdivision of entities into structural, behavioural and relational.
These concepts were readily understood and recognized by the client team and significantly aided
communication at the workshops held during the projects, greatly helping to bridge the language and cultural
barriers.
6.2.3.4
List the design tools you selected for use on this project and discuss the rationale for
their selection.
The principal architectural design tool I selected was Corporate Modeler from Casewise. I had reviewed this
tool shortly before embarking on the architectural modelling phase of the project and had completed the
vendor’s two day course. Therefore, since the tool was compatible with the Archimate language and since the
engagement afforded me to an excellent opportunity to put my recently acquired knowledge of that particular
tool into practice, I elected to use Corporate Modeler. The results were very satisfactory and elicited praise
from the client for their clarity and value. The tool was used to produce schematics for the final deliverable
based on architectural views relevant to particular stakeholders or specific areas of capability. The
architectural model was also valuable to ensure that gaps – particularly in regard to integration needed to
address the required use cases – were addressed.
6.2.3.5
List the project’s architectural deliverables and summarize the reason for their inclusion.
The client received an intermediate report, with accompanying briefing and workshop in <Location>, followed
by a final draft report, with a further briefing and workshop, and lastly a final report incorporating all feedback
from the stakeholder interactions. The reports were, in essence, aggregating vehicles for the actual
architectural deliverables. These were effectively the principal TOGAF deliverables – an Architecture
Definition Document and an Architecture Requirements Specification. The report, in its two variants, also
contained an Architecture Roadmap.
The presentation format of the architectural products – aggregated as overall project reports - was as
required by the client. The content supported effective communication with the “Proponent” team regarding
what they system would actually do and how, at a high level, it would work. The more detailed content of the
Architectural Requirements Specification allowed the client’s procurement team to invite bids from prospective
system providers/integrators for actual delivery. The Architectural Roadmap provided the timeline for delivery
of the solutions.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
42
6.2.4
6.2.4.1
Results
Was your solution implemented? If so, describe the role, if any, you had in the
implementation. If not explain why not.
The solution is to be implemented starting in late 2010. Implementation will not begin earlier because of the
need to coordinate the infrastructure build with the physical construction of the Centre’s buildings. The client
was wholly satisfied with the products delivered by my engagement.
6.2.4.2
Assess the overall success or failure of the project. Comment on client satisfaction,
attainment of objectives, and ultimate versus proposed cost and schedule.
The project was undoubtedly a success. <Employer> received a laudatory letter from the client and the
agreed fee was paid promptly and in full. The objectives of the engagement were fully met; the future
architecture of the Centre’s information systems was defined to the satisfaction of both the client project
management team and the Centre’s Proponent team. The engagement was completed within the anticipated
budget. The duration of the project was extended by 2 months at the client’s request; this was due to the
unexpected temporary unavailability of certain key staff due to other operational commitments.
6.2.4.3
Assess the success or failure of the architectural aspects of the project.
The use of a TOGAF-based approach, adopting the Framework’s guidance on architectural method and
products, combined with the use of the Archimate language, proved to be very satisfactory for this project.
The client found the architectural products to be invaluable aids to communication; the architectural principles
were helpful in ensuring that the various workstreams were aligned with the Centre’s high-level objectives; the
schematic representation of the views of the target-state model were helpful to allow Proponent-team
specialists to focus on their particular areas of concern; and the quantitative, detailed requirements
statements in the Requirements Specification sections were suitable for direct incorporation in Invitation to
Tender documents.
6.2.5
6.2.5.1
Lessons Learned
In retrospect, what might you have done differently on this project and what lessons did
you learn?
The principal lesson learned on the project was the value of the combination of the TOGAF methodology and
Archimate. <Employer> brought forward planned education and mentoring sessions to increase the corporate
awareness of the role of enterprise architecture in the types of major IT-supported construction and service
projects with which <Employer> is involved. This constitutes the main thing that I would, with hindsight, have
done differently – I would have ensured that all members of the team received more intensive support and
training in enterprise architectural techniques at the very outset of the work, whether or not they were
designated as architects.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
43
6.3
Experience Profile 3: INFORMATION-EXCHANGE ARCHITECTURE: AAA AUTHORITY
6.3.1
Project Summary
6.3.1.1
Identification
Client Name
AAA Authority (A-A)
Nature of project
Generation of enterprise architecture to govern information exchange
Location of project
<Location>
Name of your employer
<Employer> (on secondment to the A-A as Chief Enterprise Architect)
Duration
6.3.1.2
From
To
Total project duration
08/09
06/10
Your involvement
08/09
06/10
Your Team
Client
Subs
Project team size
2
3
0
Size of team led by you
2
3
0
Resources
6.3.1.3
6.3.1.4
Personal Involvement
Please list the phases of the project in which you were personally involved
Start
Completio
n
08/09
09/09
Initiation
09/09
11/09
Feasibility
11/09
04/10
Development
04/10
06/10
Delivery of Phase 1 architecture (including briefings and production of an Executive
Management Board summary paper)
No
6.3.1.5
Phase Description
I was involved in the full life-cycle of this solution.
Your Role(s)
IT Architect Role
Lead IT Architect
6.3.2
6.3.2.1
(Optional) Other Roles You Also
Performed
Project Manager
Business Opportunity or Problem
Describe the business opportunity or problem(s) this project addressed and how it
related to the client’s business and mission.
The A-A was, in 2008, generating and managing a great deal of information related to the construction of the
<major facility>. This information was increasingly needed by others than the A-A itself, but the means to
ensure that information of sufficient quality (i.e. accuracy, currency etc) was available to those entitled to use it
but assuredly denied to others were not well defined and consisted of a number of “brittle” and relatively
insecure mechanisms that had been introduced in an ad-hoc fashion. I was commissioned to define an
information systems architecture that would provide the basis for future information exchange and
management.
6.3.2.2
Describe the scope and complexity of the problem.
The problem was substantial because of the number and diversity of the stakeholders who require (or who will
in pre-XXXXX testing, or during actual XXXXX) require information from the A-A. Each of the stakeholders
requires different types of A-A-originated information. The complexity of the problem is further compounded
by the sensitivity and hence Government Protective Marking of some of the information. Therefore, its
confidentiality, integrity and availability must be appropriately protected. Finally, the information is not limited
to conventional documents; complex information types such as computer-aided design drawings, with multiple
drawing layers and cross-referenced files are included, as are live video streams from CCTV security
cameras. The architectural task embraced the purposes for which the information flows are required (the
business architecture); the information flows themselves, i.e. the application and data architectures; and the
technical architecture required to support the higher-level architectures.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
44
6.3.2.3
Describe your relationship and communications with client management / user
management / end users.
My principal client was the AAA Authority itself, with whom I was engaged as Chief Enterprise Architect. In
that role, I had regular and direct access to the relevant senior managers and directors both to seek
information and to deliver briefings on progress. I, and the enterprise architect supporting me, also had direct
access to other staff, at both senior and operational levels, throughout the various stakeholder groups. That
right of access was exercised by visits, workshops, briefings and document exchanges. The relationship with
all stakeholders was excellent. In large measure, this was because all participants could readily appreciate
the complexity of the problem and the myriad of elements and inter-relationships involved. They therefore
valued the use of a structured, disciplined approach to tackling the task, supported by an architectural tool
capable of holding all of the relevant information but presenting it selectively, in the form of architectural views,
exposing relevant information whilst hiding the irrelevant for any given stakeholder.
6.3.3
6.3.3.1
Solution
Discuss the architecture you defined to address the business problem(s), including the
rationale behind its choice. Please enumerate the architectural alternatives you
considered and your reasons for their rejection.
The purpose of the architecture was, for this task, somewhat unusual in that a major part of its purpose was to
identify gaps and to improve understanding amongst the many stakeholders involved. For example, some
stakeholders needed to exchange information which will have to be protectively marked (i.e. classified) yet
they were unaware of the need to do this, and equally unaware of the technical means to ensure the
appropriate level of information assurance. Other stakeholders were aware of the implications of the
information exchange requirements that they expressed, but had made unfounded assumptions regarding the
availability of the necessary technology architecture. Such assumptions needed to be highlighted and
remedial action taken – either by an amendment of expectations or the initiation of a project to provide the
infrastructure services needed.
To achieve the objectives outlined above, the architecture was defined in a model which was used to
capture detail from the business architecture level – the scenarios to be supported by various types of
information exchange and the business-level capabilities required – via the information systems architecture,
dealing with the information needed by operational stakeholders and the applications needed to deliver and to
manipulate it – to the technology architecture needed to support the secure communications and delivery
expected. The metamodel was defined in close collaboration with the stakeholders, to ensure that the
entities, relationships and the attributes (characteristics) captured were sufficiently fine-grained to be able to
analyze their areas of concern.
Similarly, the views of the model I generated were determined in consultation with the stakeholders.
The views recommended by Archimate were not appropriate since the viewpoints were, in some cases,
unique to the XXXXX or to the security-related services. A better fit to the required views were some of those
defined in the MODAF (UK MOD architecture framework) and this framework provided some useful guidance
to the project participants. The MODAF concept of “needline” was particularly useful in the early stages of
architecture development; it was used to express some yet-to-be-defined requirement for information or other
exchange and served to highlight areas for further discussion.
I considered various alternatives to the pure Archimate metamodel in this project. These included the
TOGAF9 content framework and <tool’s> own generic framework. None of the “pure” metamodels was
entirely fit for purpose because of the very wide span of detail required in the model. In setting up the
metamodel in the architecture tool, all objects were allocated a custom set of attributes. The attribute values
were then used to generate relevant views or to apply visual emphasis – for example by colour-coding.
6.3.3.2
Enumerate and describe the key decisions you made, and the reasons for making them
as you did.
I decided to use an architectural approach to address the information-exchange problem faced by XXXXX in
general and the AAA Authority in particular, due to their complexity.
I then decided on the composition of the architecture team for the project; myself supported by one additional
full-time architect. This decision was intended to achieve an acceptable compromise between speed of
execution, extent of scope and project cost.
I then decided to use a modelling tool to support the work; the task would quickly become very difficult to
manage if attempted with standard office automation tools such as spreadsheets, Microsoft Visio, etc. A
repository-based tool was, in my view, essential.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
45
I selected <vendor, tool> tool after an extensive review, partly because of its very high degree of flexibility,
because of its good graphical presentation, and because of the possibility of using the model in future to
display and to interact with dynamic data feeds.
I then decided on priorities - the first was to map the information-flows architecture. The reason for the
urgency of this task was the long-lead time nature of any remedial projects (such as installation of new secure
communications) that might be revealed as necessary on examination of the information-flows architecture.
I had then to decide on the metamodel used to structure the information gathered. I elected to extend the
model to include such concepts as “capabilities” and “business (usage) scenarios”. These concepts, drawn
from MODAF and TOGAF, were helpful in establishing traceability between the infrastructure level and the
actual purpose of the information flows – to ensure the capability to deal with defined future scenarios.
Throughout the work, I had to decide on the level of detail to be modelled and included within the architecture
work. This was, of course, a somewhat subjective matter. However, an architectural principle established
early in the project was to avoid collecting and modelling information without a clear purpose, i.e. on which
action would be taken by identifiable stakeholders.
I then agreed with the business sponsors that further architectural effort should turn to the <major facility>
itself, where a more urgent need for such work had emerged. I decided to develop the same model and
architectural principles to address the command, control and coordination of the security systems on the
<major facility>.
I decided to make the model more accessible by exporting it as a structured series of web pages containing
the key views, to a secure internal website.
6.3.3.3
Describe the architecture method and any design methods used on this project and the
rationale for their selection.
The principal architectural method used was, as with my other enterprise architectural work, based on
TOGAF. The modelling language and notation was again based on Archimate 1.0, although certain more
detailed design aspects of the information-flows system were modelled using UML. As with other projects, the
rationale for the selection of TOGAF was the value brought to the project by the discipline of using the ADM,
tailored appropriately to meet the specific needs of the project, to ensure that the work was based on sound,
agreed principles; that project products were clear from the outset; that a structured approach to the
classification and storage of products would be used (based on the TOGAF concepts of Enterprise Continuum
and Architectural Repository).
6.3.3.4
List the design tools you selected for use on this project and discuss the rationale for
their selection.
The principal design tool used was <vendor, tool> tool. Other architectural products were stored in a specific
filing structure created within the A-A’s existing electronic document and record management system
(EDRMS), which was based on <vendor, application> product. The rationale for selecting <EA tool> was the
high degree of flexibility afforded to tailor: the metamodel; object attributes; and graphical presentations of
architectural views to meet the project requirements.
Furthermore, a valuable aspect of the tool was the ability to later change the type (i.e. class) of a
particular object instance. This meant that if an entity had been modelled as one type – based on dialogue
with stakeholders and current understanding of the future situation – it could be changed to another (perhaps
derived) type if necessary, perhaps as a result of a clarification of operational concepts. Most of the other
tools considered did not allow object type change, but instead required creation of a new object instance and
deletion of the old.
Since the procurement was to support a public sector project, demonstration of value for money was
also required, and the licensing model meant that the choice was a good fit for the architecture team
envisaged for the future (which will be larger than the team for the first phase of this work, the subject of this
Experience Profile).
My rationale for the associated use of the <application> EDRMS was to allow project artefacts to be
made available to those who were not familiar with the <tool> tool in a controlled way, and to ensure that all
project documents and other products could be reliably hyperlinked for cross-referencing purposes. One
useful aspect of this EDRMS is the generation of permanent URLs for content, which remain valid even if the
target object (document, etc) is later renamed or moved within the folder structure.
6.3.3.5
List the project’s architectural deliverables and summarize the reason for their inclusion.
The project deliverables have been:
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
46





6.3.4
6.3.4.1
Agreed metamodels. These were necessary in order to reach agreement with the sponsors on the
entities on which information was to be collected, the relationships between those entities, the “types”
or “classes” to be used to categorize the entities and their relationships, and the attributes to be
collected. The latter were intended not only to collect pertinent information, but were also to be used
as the basis of filtering to produce relevant views for different categories of stakeholder.
Architectural Principles. The underpinning principles on which the information exchange
architecture was to be based were set down at the outset and reviewed (in a few cases revised) as
the project progressed. These were to set expectations and bounds for the various stakeholders and
embodied such tenets as the use, to the maximum extent possible of existing Government
communications systems and protocols; the use of Government information assurance (info sec)
protocols and taxonomies; resilience enabled by an absence, unless specifically accepted, of single
points of failure that would cause the loss of a service, etc.
<Tool>-based architecture model – this was the actual overall architectural model, held in the
<tool> database and used to generate the various catalogues, matrices and schematics used in the
views required by various stakeholders.
Architecture Definition Document – this was based on the <tool> model and was an articulation of
the anticipated evolution from the present architectural landscape to the required future landscape
(i.e. target architectures). It address all four domains – from the operational purposes served by the
various information exchanges (the business architecture) to the systems and information to be
transferred (the information systems architecture) to the communications and other underpinning
systems needed – either present or constituting gaps to be filled – to support the higher architectures.
This document – actually a set of hyperlinked, cross-referenced sub-documents – contained the
information needed by the people who needed to take action based on the architectural work.
Architecture Repository – this was the set of documents, held in an appropriate folder structure in
the A-A’s EDRMS, that described the stakeholders, the architecture team’s roles and responsibilities,
the scope of the work (and the anticipated scope of follow-on architectural projects), the constraints
(principally duration, budget and maximum classification to be included in the model) and a log of
activity – principally expressed as the minutes of various meetings. These artefacts were required for
the effective governance of the work.
Results
Was your solution implemented? If so, describe the role, if any, you had in the
implementation. If not explain why not.
The architecture generated in the first phase of this project served to alert a wide range of stakeholders to the
value of the architectural approach to understanding complex systems such as those that abound in the
delivery of XXXXX. The architectural workstream has been expanded, and the current activity is addressing a
wider range of aspects of XXXXX, currently focusing on gap analysis for certain elements of the physical
communications structure on the <major facility>. Therefore, it could be considered that Phase 1 of the
project was implemented, in that it created Phase 2 and an expectation of further phases.
Furthermore, the long lead-time changes (both at the systems level and the agreements/contracts
and inter-departmental protocol levels) needed to realize the architecture envisaged in the first phase
architecture work have been budgeted and initiated as projects.
I, and the others in my architectural and information management team in the A-A, will be involved
with all aspects of delivery of the architecture up until go-live, and beyond during transformation of the <major
facility> and its systems for legacy use.
6.3.4.2
Assess the overall success or failure of the project. Comment on client satisfaction,
attainment of objectives, and ultimate versus proposed cost and schedule.
The project has been deemed extremely successful. The tangible value it added converted the many sceptics
on the Program who had not previously encountered the enterprise architectural approach supported by solid
methodologies and an effective modelling tool. The work was initially sponsored by the A-A Head of Systems
and Technology; it was then supported (financially and with encouragement) by the parent Government
organisation; and more recently has gained the full support (including further resourcing) of the A-A’s Head of
Security. The Phase 1 work was delivered within the allocated budget and within the timescale originally
proposed. It met its original purpose but, due to having done so, further scope has been added which will be
addressed in the follow-on architectural projects.
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
47
6.3.4.3
Assess the success or failure of the architectural aspects of the project.
The essence of the project was the architectural approach and the use of an architectural model, constructed
according to a recognized language and a clearly defined metamodel. Therefore, since the project is
considered to be wholly successful, this perception applies equally to the architectural aspects. Far more of
the senior stakeholders in the program than at the outset of this activity are now aware of the value that
architecture can bring to complex change and development projects such as the XXXXX. The approach has
received strong endorsement (and has also raised expectations that the architecture team will need to meet!).
6.3.5
6.3.5.1
Lessons Learned
In retrospect, what might you have done differently on this project and what lessons did
you learn?
The principal lesson learned is the value of the architectural approach and the use of a modelling tool whose
products (i.e. the model and the views) are accessible to a wide range of stakeholders over the network,
offering a “single version of the truth”. Although I was aware of the potential advantages, it would have been
worthwhile to have “evangelized” the approach more widely, even earlier in the program. However, there was
a balance to be struck in establishing credibility within the program prior to urging changes in approach. A
further lesson learned is related to the “Archimate compliance” of architecture tools. This appears to be a
somewhat loose concept in the minds of tool vendors. Some tools support the language very effectively and
well; others require a substantial amount of setup and customisation of templates, icons, etc. The tool
selected could be judged as in the latter category. This consumed some time early in the project that was not
fully foreseen at the outset.
7. References
Please insert your references here – please make sure they print with this document (for
example, inserted pdf files do not print)
Reference letters deleted in the sample package.
Please see examples of reference letters here https://www.opengroup.org/openca/cert/docs/OpenCA_FAQ_Reference_Letters.pdf
© 2005 - 2008 The Open Group
ALL RIGHTS RESERVED
48