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


Experience Profile 2: : BUSINESS SOLUTIONS ARCHITECTURE



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

6.2 Experience Profile 2:

: BUSINESS SOLUTIONS ARCHITECTURE

6.2.1Project Summary

6.2.1.1Identification


Client Name

(through Partner)

Nature of project

Development of Business Solutions for a new energy research centre to be built 2010-2012

Location of project



Name of your employer

(IT/Communications Consulting)

6.2.1.2Duration





From

To

Total project duration

07/09

03/10

Your involvement

07/09

03/10

6.2.1.3Resources



Your Team


Client

Subs

Project team size

7

6

1

Size of team led by you

7

0

1

6.2.1.4Personal Involvement


Start

Completion

Phase Description

07/09

08/09

Proposal Preparation

08/09

11/09

Preparation of enterprise architecture (vision)

11/09

01/10

Preparation of enterprise architecture (detailed)

01/10

03/10

Specification of requirements to support ITT




No

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

6.2.1.5Your Role(s)





IT Architect Role







(Optional) Other Roles You Also Performed

X

Lead IT Architect




X

Project Manager

6.2.2Business Opportunity or Problem

6.2.2.1Describe the business opportunity or problem(s) this project addressed and how it related to the client’s business and mission.


The AAAA government had decided to set up a major national facility to conduct research related to energy production and consumption. The facility is to be constructed on an undeveloped area to the north of and will occupy an entirely new, highly innovative series of buildings designed by . was commissioned to provide a number of consulting services; the area which I led was the conception and design of the software-enabled systems, described by the client as business solutions. The business solutions will be the core enablers of the centre’s operations.

6.2.2.2Describe the scope and complexity of the problem.

I was the lead architect and 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.3Describe 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 and a specialist in-country consultancy

) and the so-called Proponent Team. The latter were research specialists and ICT specialists who were drawn from the operational arms of 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 to conduct workshops. I was responsible for organising and leading the workshops and all other communication related to the business services work.

6.2.3Solution

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

The architecture I proposed was based on a fully virtualized technology platform, capable of dynamic resource allocation, automated fail-over and dynamic power management. The platform was to use a high-capacity, scalable storage area network for disk-based storage. The core collaboration and content, documents and records management services were to be based on Microsoft Sharepoint 2010 and the enterprise search services were to be provided by Microsoft FAST for Sharepoint, possibly (subject to budget) augmented by deploying SAP’s Inxight Smart Discovery server for text analytics purposes. Other elements of the collaboration platform, providing messaging services, were Microsoft Exchange 2010 and Microsoft Office Communication Server 2008R2. Project Portfolio Management (PPM) services were to be provided by Microsoft’s PPM solution. The central source of authentication and access control was to be a distributed installation of Microsoft Active Directory, augmented by Entrust Server to provide two-factor authentication (token + username/password) for remote system users. The central energy database was to be based on the Oracle 11g platform to be used in conjunction with Oracle extract, transform and load (ETL) and reporting tools. Modelling and simulation services were specified using a variety of special-purpose tools, reflecting those in use at comparable research organisations worldwide. ERP and back-office services (HR, Finance, Supply Chain Management, Asset Management) were to be provided using SAP services. To minimise the need for custom-coded point to point integration between the major system components, I specified the use of Microsoft BizTalk Server to provide a middleware layer capable of supporting message exchange, translation, queuing, and transactions.

RATIONALE: The rationale behind the specification of the architecture was based on a number of influences:


[1] The site was to be operated initially, during build-up, by existing
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 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 REJECTED

I considered an architecture based on the use of open source software, using open-standards web services (principally REST interactions over HTTP) to achieve the required integration between services. The choice of products capable of meeting certain key functional requirements (e.g. for standards-compliant records management and highly scalable document management) was limited, so such an architecture would have been based on Java technology, using either the JBoss or the Apache Tomcat application server at the core. The major architectural building blocks required by the Centre were available from the open source world – for example, the Lucene search engine would have provided the necessary enterprise search service – and the resulting system would have had a lower initial acquisition cost and would have avoided the risk of “vendor lock in”. However this option was rejected, primarily on the grounds that the client’s IT staff were unfamiliar with the required technologies and because their adoption would have violated the principle, agreed at the outset, to avoid technology proliferation – i.e. the introduction of new, unfamiliar technologies where this was not essential to the delivery of the required service.

I also considered an architecture based on fully virtualized desktops throughout the Centre. This would have further simplified future system administration and incident management and offered the potential for reduced capital costs. However, I rejected such a solution because of: (a) the uncertainties – and hence risk – surrounding the compatibility of some of the key research applications that would be used with such an infrastructure and (b) the need for researchers to be able to work effectively whilst off-line, for example when travelling. However, my recommendation was to conduct a future pilot study to evaluate the use of virtual desktop infrastructure with the Centre’s applications, to determine the feasibility of a move to a wholly virtualized architecture. I considered that the need to work off-line could probably be addressed adequately in future by the adoption of technologies such as Google’s “Gears” or HTML 5 compatible browsers.

I also considered the use of an infrastructure architecture based on physical servers. Such an arrangement would have been more familiar to the client’s existing IT staff and would have reduced the system software licensing costs. However, I rejected this option on the grounds of its inflexibility, poor asset utilisation, and more complex disaster recovery. The low utilisation that could be expected would also have violated an agreed architectural principle – the reduction of overall energy consumption by the IT services to the lowest level practical, commensurate with effective operation of the Centre.

A further significant architectural choice was my election to specify a middleware layer – essentially an enterprise service bus (ESB) – to facilitate the integration between the major system building blocks (such as between the content and collaboration system and the ERP/back-office systems). The alternative would have been to use point to point integration between systems, where this was required to meet the relevant use cases. However, although such an approach would have been less initially complex and therefore less costly, it would not have offered the flexibility needed to provide the services needed for an organisation that was expected to grow and to evolve rapidly.

6.2.3.2Enumerate 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.3Describe 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.4List 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.5List the project’s architectural deliverables and summarize the reason for their inclusion.

The client received an intermediate report, with accompanying briefing and workshop in , 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.

6.2.4Results

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


The solution is to be implemented starting in late 2010. Implementation will not begin earlier because of the need to coordinate the infrastructure build with the physical construction of the Centre’s buildings. The client was wholly satisfied with the products delivered by my engagement.

6.2.4.2Assess 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. 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.3Assess the success or failure of the architectural aspects of the project.

The use of a TOGAF-based approach, adopting the Framework’s guidance on architectural method and products, combined with the use of the Archimate language, proved to be very satisfactory for this project. The client found the architectural products to be invaluable aids to communication; the architectural principles were helpful in ensuring that the various workstreams were aligned with the Centre’s high-level objectives; the schematic representation of the views of the target-state model were helpful to allow Proponent-team specialists to focus on their particular areas of concern; and the quantitative, detailed requirements statements in the Requirements Specification sections were suitable for direct incorporation in Invitation to Tender documents.

6.2.5Lessons Learned

6.2.5.1In retrospect, what might you have done differently on this project and what lessons did you learn?


The principal lesson learned on the project was the value of the combination of the TOGAF methodology and Archimate. 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 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.




1   2   3   4   5   6   7   8


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

    Main page