Over the years, I’ve enjoyed working with, been very grateful for, and occasionally frustrated by architects on projects.  Whether they’re enterprise, solution or technical architects (and the titles are very fluid) they’re an essential member of the triumvirate leading project and programme teams, along with the project manager and business analyst.  Ideally, the business analyst is responsible for making sure we understand what the client needs and the architect for making sure that what we’re building will meet those needs, leaving me with the simple task of making it all happen.  In reality, we’re all senior IT professionals, with lots of experience delivering projects, so there’s a fair bit of overlap and teamwork.
At the BCS last night, two senior Enterprise Architects from Capgemini gave us an insight into their perspective on enterprise architecture, the role it plays in their projects, and a specific case study of introducing service management and a utility computing model in the cloud.

First up was Rob Rowe, Executive Enterprise Architect.  He talked about the role of the Enterprise Architect, understanding complex problems and communicating them, getting everyone working together by giving the big picture and setting the context.  He also mentioned something I often find myself doing – challenging whether a piece of work is really necessary.
In Capgemini’s method, traceability is a major responsibility of architects, which is something I’ve normally expected from business analysts, particularly if they’re taking up a role in testing later in a development or are working at a programme level, and so with the project or programme for the duration.  It probably doesn’t matter, so long as its clear who is responsible, and systems architecture tools make it much easier than more old-fashioned spreadsheet-based methods.

Richard Noon, Managing Enterprise Architect, presented a case study of a client who wanted to move an ecommerce site onto a utility computing model, in the cloud, and to simplify change.   Their solution was to use an enterprise architecture tool (System Architect) as the ITIL configuration management database, with full traceability from the high level analysis and architecture artifacts down to physical software and hardware components.  Where the latter were not accessible, because a service was provided in the cloud, then traceability stops at the service, and the service level agreement, and service quality targets are managed.  A services based representation of the enterprise architecture was key to getting this working in the cloud.

Of course, as Richard Noon admitted, this full traceability is expensive, but not only does it allow a client to be sure that what has been delivered is what was required, it also allows the impact of proposed changes to be easily assessed, and links architecture and project work to the ongoing operation and management of the services implemented.

Linking architecture to the ongoing delivery of the resulting services has got to underpin successful projects, at least if they are to measure up in their benefits reviews and be seen as a success well beyond launch.

The EA special interest group of the BCS are good at getting slides up on their website, so you maybe able to find them here in the next few days.