Gordon Brown The Open Group Certified Architect (Open ca) Program: Certification Package Level 2: Master Certified it architect October 03, 2008 Revision 3 Candidate Name


Download 479.74 Kb.
Date conversion04.09.2017
Size479.74 Kb.
1   2   3   4   5   6   7   8


6.3.1Project Summary

Client Name

AAA Authority (A-A)

Nature of project

Generation of enterprise architecture to govern information exchange

Location of project

Name of your employer

(on secondment to the A-A as Chief Enterprise Architect)



Total project duration



Your involvement



Your Team



Project team size




Size of team led by you



0 Involvement

Please list the phases of the project in which you were personally involved



Phase Description












Delivery of Phase 1 architecture (including briefings and production of an Executive Management Board summary paper)


I was involved in the full life-cycle of this solution. Role(s)

IT Architect Role

(Optional) Other Roles You Also Performed

Lead IT Architect

Project Manager

6.3.2Business Opportunity or Problem the business opportunity or problem(s) this project addressed and how it related to the client’s business and mission.

The A-A was, in 2008, generating and managing a great deal of information related to the construction of the . 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. 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. your relationship and communications with client management / user management / end users.

My principal client was the AAA Authority itself, with whom I was engaged as Chief Enterprise Architect. In that role, I had regular and direct access to the relevant senior managers and directors both to seek information and to deliver briefings on progress. I, and the enterprise architect supporting me, also had direct access to other staff, at both senior and operational levels, throughout the various stakeholder groups. That right of access was exercised by visits, workshops, briefings and document exchanges. The relationship with all stakeholders was excellent. In large measure, this was because all participants could readily appreciate the complexity of the problem and the myriad of elements and inter-relationships involved. They therefore valued the use of a structured, disciplined approach to tackling the task, supported by an architectural tool capable of holding all of the relevant information but presenting it selectively, in the form of architectural views, exposing relevant information whilst hiding the irrelevant for any given stakeholder.

6.3.3Solution the architecture you defined to address the business problem(s), including the rationale behind its choice. Please enumerate the architectural alternatives you considered and your reasons for their rejection.

The purpose of the architecture was, for this task, somewhat unusual in that a major part of its purpose was to identify gaps and to improve understanding amongst the many stakeholders involved. For example, some stakeholders needed to exchange information which will have to be protectively marked (i.e. classified) yet they were unaware of the need to do this, and equally unaware of the technical means to ensure the appropriate level of information assurance. Other stakeholders were aware of the implications of the information exchange requirements that they expressed, but had made unfounded assumptions regarding the availability of the necessary technology architecture. Such assumptions needed to be highlighted and remedial action taken – either by an amendment of expectations or the initiation of a project to provide the infrastructure services needed.

To achieve the objectives outlined above, the architecture was defined in a model which was used to capture detail from the business architecture level – the scenarios to be supported by various types of information exchange and the business-level capabilities required – via the information systems architecture, dealing with the information needed by operational stakeholders and the applications needed to deliver and to manipulate it – to the technology architecture needed to support the secure communications and delivery expected. The metamodel was defined in close collaboration with the stakeholders, to ensure that the entities, relationships and the attributes (characteristics) captured were sufficiently fine-grained to be able to analyze their areas of concern.

Similarly, the views of the model I generated were determined in consultation with the stakeholders. The views recommended by Archimate were not appropriate since the viewpoints were, in some cases, unique to the XXXXX or to the security-related services. A better fit to the required views were some of those defined in the MODAF (UK MOD architecture framework) and this framework provided some useful guidance to the project participants. The MODAF concept of “needline” was particularly useful in the early stages of architecture development; it was used to express some yet-to-be-defined requirement for information or other exchange and served to highlight areas for further discussion.

I considered various alternatives to the pure Archimate metamodel in this project. These included the TOGAF9 content framework and 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. 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 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 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 .

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. 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). the design tools you selected for use on this project and discuss the rationale for their selection.

The principal design tool used was 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 product. The rationale for selecting 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 EDRMS was to allow project artefacts to be made available to those who were not familiar with the 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. 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.

  • -based architecture model – this was the actual overall architectural model, held in the 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 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.

6.3.4Results your solution implemented? If so, describe the role, if any, you had in the implementation. If not explain why not.

The architecture generated in the first phase of this project served to alert a wide range of stakeholders to the value of the architectural approach to understanding complex systems such as those that abound in the delivery of XXXXX. The architectural workstream has been expanded, and the current activity is addressing a wider range of aspects of XXXXX, currently focusing on gap analysis for certain elements of the physical communications structure on the . 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 and its systems for legacy use. 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. the success or failure of the architectural aspects of the project.

The essence of the project was the architectural approach and the use of an architectural model, constructed according to a recognized language and a clearly defined metamodel. Therefore, since the project is considered to be wholly successful, this perception applies equally to the architectural aspects. Far more of the senior stakeholders in the program than at the outset of this activity are now aware of the value that architecture can bring to complex change and development projects such as the XXXXX. The approach has received strong endorsement (and has also raised expectations that the architecture team will need to meet!).

6.3.5Lessons Learned retrospect, what might you have done differently on this project and what lessons did you learn?

The principal lesson learned is the value of the architectural approach and the use of a modelling tool whose products (i.e. the model and the views) are accessible to a wide range of stakeholders over the network, offering a “single version of the truth”. Although I was aware of the potential advantages, it would have been worthwhile to have “evangelized” the approach more widely, even earlier in the program. However, there was a balance to be struck in establishing credibility within the program prior to urging changes in approach. A further lesson learned is related to the “Archimate compliance” of architecture tools. This appears to be a somewhat loose concept in the minds of tool vendors. Some tools support the language very effectively and well; others require a substantial amount of setup and customisation of templates, icons, etc. The tool selected could be judged as in the latter category. This consumed some time early in the project that was not fully foreseen at the outset.


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 -


1 See TOGAF 8.1.1 Chapter 19 “Taxonomy of Service Qualities

© 2005 - 2008 The Open Group


1   2   3   4   5   6   7   8

The database is protected by copyright ©hestories.info 2017
send message

    Main page