Certification Package template V2.1 - KOSTA€¦ · Web viewThe Open Group Certified Architect (Open CA) Program: Certification Package Level 2: Master Certified IT Architect October

Photo removed

The Open Group Certified Architect (Open CA) Program:

Certification PackageLevel 2: Master Certified IT Architect

October 03, 2008Revision 2.3

Candidate NameLast Name Brown First Name Gordon

Candidate I/D 98765 Middle Initial W

This template is to be used with:The Open Group Certified Architect (Open CA) Program:

Conformance Requirements Version 2.01And 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 1ALL RIGHTS RESERVED

Gordon Brown

1. Contents

1. Contents.............................................................................................................22. Compliance With Skill Requirements...................................................................3

2.1 Skill Levels.................................................................................................32.2 Compliance to Core Foundation Skills Requirements.................................3

2.2.1 People Skills..................................................................................42.2.2 Project Management.....................................................................82.2.3 Business........................................................................................92.2.4 Architecture................................................................................10

3. Compliance With Experience Requirements......................................................234. Professional Development.................................................................................285. Contributions to the IT Architect Community....................................................306. Experience Profiles............................................................................................31

6.1 Experience Profile 1: ENTERPRISE ARCHITECTURE: TRAINING ACADEMY 326.1.1 Project Summary........................................................................326.1.2 Business Opportunity or Problem................................................326.1.3 Solution.......................................................................................346.1.4 Results........................................................................................386.1.5 Lessons Learned.........................................................................38

6.2 Experience Profile 2: <Project>: BUSINESS SOLUTIONS ARCHITECTURE396.2.1 Project Summary........................................................................396.2.2 Business Opportunity or Problem................................................396.2.3 Solution.......................................................................................406.2.4 Results........................................................................................436.2.5 Lessons Learned.........................................................................43

6.3 Experience Profile 3: INFORMATION-EXCHANGE ARCHITECTURE: AAA AUTHORITY 446.3.1 Project Summary........................................................................446.3.2 Business Opportunity or Problem................................................446.3.3 Solution.......................................................................................456.3.4 Results........................................................................................476.3.5 Lessons Learned.........................................................................48

7. References........................................................................................................48

2. Compliance With Skill Requirements

2.1Skill Levels

See Open CA: Conformance Requirements section 3.1 and 3.2Skill Levels and Proficiency Ratings


Skill Level Proficiency ExperienceLimited Limited or no knowledge NoneGeneral General conceptual knowledge

onlyLimited – 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.2Compliance to Core Foundation Skills RequirementsEvidence 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.


2.2.1 People SkillsCFS01Apply 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: Deep Skill level you claim: Deep

CFS01.1 Demonstrate written application of communication skillsFrom

(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.


CFS01.2 Demonstrate verbal application of communication skillsFrom

(mm/yy)To

(mm/yy)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 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.


CFS02Lead 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: Deep Skill level you claim: DeepFrom

(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.


CFS03Perform Conflict Resolution

Mediate opposing viewpoints and negotiate equitable solutions to ensure successful and stable outcomes.

Skill level required: Applied Skill level you claim: DeepFrom

(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 cost-effective 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 A-A 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.


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 inter-connections 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.


2.2.2 Project ManagementCFS04Manage 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.


(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.


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, intranet-specific, 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.


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 cost-effectiveness, 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.


2.2.3 BusinessCFS05Understand Business Aspects

Understand the stakeholders’ business needs, and how they relate to their business and mission.

Skill level required: Applied Skill level you claim: DeepFrom

(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.


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.


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.


2.2.4 ArchitectureCFS06Develop IT Architecture

Given one or more business requirements, create the structures of a solution that can be validated to meet those requirements.


(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.


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.


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.

1 See TOGAF 8.1.1 Chapter 19 “Taxonomy of Service Qualities”© 2005 - 2008 The Open Group 10ALL RIGHTS RESERVED

https://www.opengroup.org/architecture/togaf8-doc/arch/chap19.html#tag_20_04_03_02

CFS07Use 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.


(mm/yy)To

(mm/yy)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.

08/09 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.


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 inter-systems 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.


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.


CFS08Perform 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.


(mm/yy)To

(mm/yy)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.

02/10 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.


CFS09Apply IT Standards

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.


(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.


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.


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 web-based 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 REST-based architecture. Thus, the solution combined both highly open standards with widely deployed industry standards.


CFS10Establish 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.


(mm/yy)To

(mm/yy)Project or Major Activity Provide three examples where given the functional and non-

functional 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.

07/09 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.


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.


I led the architectural development of a new course-support system for the Training Academy and also acted as project manager for the 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.


CFS11Use of Techniques

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.


(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.


CFS12Apply Methods

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.


(mm/yy)To

(mm/yy)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.


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.


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.


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.


CFS13Define 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.


(mm/yy)To

(mm/yy)Project or Major Activity Provide three examples where given the functional and non-

functional 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.

10/04 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.


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.


CFS14Manage Stakeholder Requirements

Given approved business goals, objectives, and constraints, document, clarify, refine, detail and prioritize functional and non-functional requirements.


(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.


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.


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.


CFS15Establish Architectural Decisions

Determine, document, and communicate architectural decisions to support and rationalize the design of the solution.


(mm/yy)To

(mm/yy)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.

10/04 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.


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.


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.


CFS16Validate 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.


(mm/yy)To

(mm/yy)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.

10/04 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.


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.


CFS17Perform as Technology Advisor

Maintain IT industry knowledge to advise on technical trends and techniques and apply them to the development of solution designs.


(mm/yy)To

(mm/yy)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.

10/04 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.


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.


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.


3. Compliance With Experience Requirements

See Open CA: Conformance Requirements section 3.4Evidence 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.

EC01Experience 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.

From (mm/yy)

To (mm/yy)

Project or Major Activity 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

Reference may be made to the Experience Profiles in Section 601/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.

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.


Project or Major Activity

Name and position/job title of Reference Your References will be contacted. Please provide current addresses, phone numbers and

email addresses ENTERPRISE:

TRAINING ACADEMY

Mr A JonesProject Manager

12, Abc Drive, Reading, Berks, RG1 2BH. UK+44 1234 [email protected]

BUSINESS SOLUTIONS

Mr A SmithApplication Development Manager

121 Charing Cross Road, Holborn. London, WC2H 0EW. UK+44 207 [email protected]

INFORMATION-EXCHANGE

Miss K KatSenior Account Manager

1 Monument Hill, Weybridge, Surrey KT13 8RX. UK+44 2222 [email protected]

References are required to substantiate the above experience. Please include letters or emails from your references in section 7 of your certification package below.

EC02Breadth 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 ExperiencesReference 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.


EC03Experience 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 ExperiencesReference 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 operating-system 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.


EC04Application 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 workGuidance 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

From (mm/yy)

To (mm/yy)

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.

01/04 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.

EC05 Intentionally left blank.


EC06Full 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.

From (mm/yy)

To (mm/yy)

Project Description of Qualifying ExperienceYou 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 experienceExperience Profiles in which you claim full lifecycle involvement must be listed here.

10/04 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.

01/04 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.

EC07Industry Knowledge

You must have demonstrated expertise in one or more industry sectors, including the business, legal and regulatory contextGuidance 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 knowledgeReference 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.


EC08Knowledge 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 trendsReference 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

PD01Training

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 MaterialProvide 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 trainingFormal 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. York, UK, March 2010.06/10 TOGAF9 Self-Study Studying TOGAF9 Open Group material, with a view to the bridge exam.


PD02Maintain 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 ActivityConferences Attended 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

Personal Reading Subscriber/reader: Information Age, Computer Weekly, PC Pro. Formal EducationBeing MentoredTraining Courses IT Infrastructure Library (ITIL v3) Expert Bridge 4-day Course – Date: 04/08

ISO/IEC 20000 Consultants Course & ISEB Exam, August 2007.Related Professional

MembershipsMembership of BCS and BCS Elite; participation in educational and social/educational events.

Other Activities “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

PD03Maintain Vertical Industry Knowledge

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 ActivityConferences Attended 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.

Personal Reading 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 EducationBeing MentoredTraining Courses

Related Professional Memberships

Cisco CIO Day 2010 Barcelona – senior level, invitation only 2 day workshop in Feb 2010 on IT in various verticals, including construction.

Other Activities <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.


PD04Develop 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 ActivityConferences Attended 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.

Personal Reading 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 EducationBeing MentoredTraining Courses 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.

Other Activities Research related to business development for the business and enterprise systems architecture practice within <Employer>.


5. Contributions to the IT Architect Community

CC01Contribution 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 ContributionMentoring 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 research is conducted in collaboration with leading UK universities.


I am a member of the British Computer Society and the British Computer Society’s Elite group.

Other Activities 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 architectDiagrams 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.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

Academy01/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 Summary6.1.1.1 IdentificationClient Name Training Academy Nature of project Enterprise Architecture to support a radically-revised business modelLocation of project <Location>Name of your employer <Employer>

6.1.1.2 Duration

From ToTotal project duration 01/04 06/08Your involvement 01/04 06/08

6.1.1.3 Resources

Your Team Client Subs Project team size 12 15 7 Size of team led by you 12 15 7

6.1.1.4 Personal InvolvementPlease list the phases of the project in which you were personally involved

Start Completion Phase Description01/04 03/04 Architectural vision03/04 03/05 Core architecture development 1 – intranet and networks03/05 03/06 Core architecture development 2 – EDRMS, student data systems, web systems03/06 06/08 Core architecture development 3 – Integration of external Academy organisations

Yes I was involved in the full life-cycle of this solution.


6.1.1.5 YOUR ROLE(S) IT Architect Role (Optional) Other Roles You Also

PerformedX Lead IT Architect X Project Manager

Lead IT Architect for a major subsystem

Developer / Tester

6.1.2 Business Opportunity or Problem6.1.2.1 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 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 widely-attended 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 classroom-based education. New emphasis was placed, therefore, on effective e-learning systems and other web-delivered 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.

6.1.3 Solution6.1.3.1 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 inter-connections 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.

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 WorkThe 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 Web-accessible 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.

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 WorkThe 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.

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.

6.1.4 Results6.1.4.1 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 Lessons Learned 6.1.5.1 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 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 Summary6.2.1.1 IdentificationClient Name <Client> (through Partner)Nature of project Development of Business Solutions for a new energy research centre to be built 2010-

2012Location of project <Location>Name of your employer <Employer> (IT/Communications Consulting)

6.2.1.2 Duration


6.2.1.3 Resources


6.2.1.4 Personal InvolvementStart Completion Phase Description07/09 08/09 Proposal Preparation08/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 I was involved in the full life-cycle of this solution.6.2.1.5 YOUR ROLE(S)

IT Architect Role (Optional) Other Roles You Also Performed

X Lead IT Architect X Project Manager


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 © 2005 - 2008 The Open Group 39ALL RIGHTS RESERVED

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 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.



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 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 REJECTEDI 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. 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.



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.


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.

6.3 Experience Profile 3: INFORMATION-EXCHANGE ARCHITECTURE: AAA AUTHORITY

6.3.1 Project Summary6.3.1.1 IdentificationClient Name AAA Authority (A-A) Nature of project Generation of enterprise architecture to govern information exchangeLocation of project <Location>Name of your employer <Employer> (on secondment to the A-A as Chief Enterprise Architect)

6.3.1.2 Duration


6.3.1.3 Resources


6.3.1.4 Personal InvolvementPlease list the phases of the project in which you were personally involved© 2005 - 2008 The Open Group 43ALL RIGHTS RESERVED

Start Completion

Phase Description

08/09 09/09 Initiation09/09 11/09 Feasibility11/09 04/10 Development04/10 06/10 Delivery of Phase 1 architecture (including briefings and production of an Executive

Management Board summary paper)No I was involved in the full life-cycle of this solution.

6.3.1.5 YOUR ROLE(S) IT Architect Role (Optional) Other Roles You Also

PerformedLead IT Architect Project Manager


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. 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.



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 © 2005 - 2008 The Open Group 44ALL RIGHTS RESERVED

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.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: 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.


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. 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!).


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


https://www.opengroup.org/openca/cert/docs/OpenCA_FAQ_Reference_Letters.pdf

Documents

Certification Package template V2.1 - KOSTA€¦ · Web viewThe Open Group Certified Architect (Open CA) Program: Certification Package Level 2: Master Certified IT Architect October