Reference architecture development
This UK-wide infrastructure management client (managing over 8000 commercial properties and a wide range of critical national infrastructure assets), realized that limitations on the information they had about the state of their physical assets was having major implications on the safety of their operations. They had to assume worst case scenarios and so instigate costly renewal and maintenance of assets, even when they suspected it was still not necessary. A strategic initiative was started comprising several programs. This was aimed at establishing solid information services offerings for the lines of business, with an anticipated investment over £200M. These multiyear programs had been put to tender and the suppliers were already in or beyond the discovery stage.
The client design authority was concerned about their own lack of capability to manage the architectural scope of these programs, as they were increasingly becoming aware of their interdependencies, gaps and overlaps.
Some programs had already requested client senior management to accept delivery delays and cost overruns.
A confidential report accepted that the risk of litigation around project scope was very high and that the program design authority was lacking a solid reference architecture and governance model.
(Case Study)
Solutions proposed
The client considered two main options:
- Restart a tender process for the Program design authority function including high level program architecture
- Engage an independent third party to deliver the high level solution architecture for the existing design authority function
Option 1 would introduce a delay and expose the client in the potential litigation. And given the high-profile political implications, option 2 was selected, and a contract EA resource was engaged. So this is how our engagement in the Agile delivery of the Information Services Program Architecture started.
Client contribution
The Design Authority function of the client initiative was the main point of engagement during the RFP stage. It was operating in two ways. Firstly, as the authority of the overall programme design. Secondly, to assure the architectural conformance of individual projects and project sub-contractors.
As an authority, they were working closely with the programme management team to define the rolling programme release plan. As an assurer, the team was working closely with the PMO to ensure that projects proceed through programme and project governance gateways.
Outline
An agile delivery method was used by all the architecture delivery streams.
We specifically led the Technology and the Integration streams and we also contributed to and quality assure all the others.
The overall integrity of the data was to a large extent taken care by the business rules being coded into the metamodel configured in the architecture tool. The Metastorm architecture tool had been selected mainly due to its ability to present information in a business friendly way so diagrams, reports and other views were directly leveraged in the program architecture documents.
Preliminaries
The Design Authority function of the client was the main point of engagement during the RFP stage. It was operating in two ways. Firstly, as the authority of the overall programme design. Secondly, to assure the architectural conformance of individual projects and project sub-contractors.
As an authority, the team was working closely with the programme management team to define the rolling programme release plan. As an assurer, the team was working closely with the PMO to ensure that projects proceed through programme and project governance gateways.
We were engaged to assure the enterprise architecture tool, to confirm it was fit for purpose.
The broader team joined to plan documentation of the Program Architecture. Each architect was assigned responsibility for the deliverables within one or more architecture domains. We led workshops with several client SMEs/Architects to quickly identify the rationale for and the detail of the architectures defined for the various projects, as well as their completeness.
Deliverables and outcomes
Defined the baseline Programme Architecture for Information Services. This meant working collaboratively to deliver artifacts that the Information Services Program Design Authority would use to rebaseline the programs and establish new governance.
The deliverables as of Sprint 0 included Business Capability Architecture, Business Process Architecture, Business Service Architecture, Application Architecture, Information Architecture, Programme Release Architecture. Programme Release Plan, IS Architecture Overview, Security Architecture, Integration Strategy, Business Capability Roadmap, Business Service Design, Technology Architecture, Integration Architecture, Information Model, Deployment Strategy, System Sizing Model, Failure Mode and Recovery Analysis, Business Process Poster, Glossary of Terms and Interface Catalogue.
Benefits:
- The design authority was able to articulate technology risk and structure business decisions for high risk projects, enabling the overall program to make decisions and hold the programs for timely delivery.
- The Strategic Technical Framework, allowing reduction of costs by converging on a smaller set of technologies was refreshed.
- Enabled the design authority to create Architecture Context Packs for program procurement.
Next steps
The client was able to use the architecture to assess and negotiate change requests the programs were submitting.
The integration strategy and architecture documents and the platform and channel topologies (which were part of the Technology Architecture) directly enabled the client to scope an RFP for a new corporate capability. The vision was to transform access to information management directly by the field workforce. This empowered the teams to analyse and respond to unforeseen events that would have previously led to cancellation and rescheduling of the maintenance typically 6-12 months later.
An initiative to establish corporate level Master Data Management was also started, building on the information architecture and model and the integration catalogue.
Requirements
The project took 3 months to complete, and the team included 5 enterprise architects.
Notes
The initial effort made to understand the business value of the initiative made a significant difference to the team being able to fine-tune the information gathering stage and also better understand the relevance of technical findings made.
The client found that the use of the architecture tool by all the workstreams led to significant efficiency gains, since this reinforced consistent use of terminology by the various streams. This did require more effort from a delivery viewpoint, since all inconsistencies had to be resolved across multiple domains before the target architecture could be documented.
The other benefit of is that when the Design Authority took over the program architecture it could immediately start detailing and evolving the target architecture skipping common steps required to ensure integrity.
Feedback
“Very impressed that you guys practice what you preach”, “Delivering this reference architecture using agile was one of the best decisions we could make”
The client was also very positive about the fact that, when dealing with programs that our own organization was accountable for, we would only start the engagement activity after confirmation that the approach to manage conflicts of interest was acceptable. The fact that the client usually trusted us to continue was in itself very positive feedback.
The client was also pleased with the speed of delivery and flexibility of our approach. They praised the collaborative and pragmatic mindset and that we made the effort to brief them on any relevant findings, irrespective of whether we had been specifically contracted to do so.