I wrote this just after finishing the solution architecture on a £20m strategic programme. The experience once again reminded me of where IT architects seriously adds value. I started the project with a mandate defining scope and cost. It is my first concern to verify the scope is deliverable. Here we frequently have to fight to extend scope to achieve good foundations. Poor foundations extend delivery risk and may result in an expensive change request to address late in the project delivery. It is only the architect who will assess this and can articulate the risk.
In looking at foundations I find myself looking at four distinct domains:
- The business architecture – the ability of the organisation to accept the change
- The application architecture – defining the surrounding IT application landscape
- The information architecture – defining how reference data is mastered within the architecture
- Infrastructure architecture – the organisations capability to delivery and manage infrastructure technologies and scale
The business architecture is not something a solution architect can question openly in all organisations. Whether you can do this openly or covertly it is necessary to consider this domain. A large degrees of change may be beyond the organisations ability to absorb. This may result in only part of an expensive solution being used and the benefit case never being realised. In such projects a phasing approach would de-risk the delivery of the project and the realisation of its benefit case.
The application architecture is perhaps the most obvious of these to explore. No solution architecture would be complete without an “As Is” and “To Be” application landscape being described. Here I am looking firstly at the upstream systems which will provide source data for my replacement solution (one or more applications). I’m trying to understand how supportable these applications are and the risk of potentially making change to these systems in order to provide the source data. By supportable I mean both from the supplier and from internal support teams. Secondly I will look at applications which will be provided data from the new system. Again how supportable are these and what the risk of any changes is in these systems. Generally the risks are slightly lower on downstream applications as it is more likely that data can be presented in its current form from the new solution. At this point in the project I am not really looking at true integration but simply around the logical data flows that I will be specifying in the conceptual architecture.
To give an example from a recent project looking at the upstream applications I found a key data supplier that was completely out of support from the supplier. This was compounded by low levels of capability in the internal application support team, for this application. For a relatively small cost change (less 2% of budget) I was able to specify a replacement application with required level of support. Doing this later in the project would likely have caused a delay to implementation and an overrun to delivery dates. Late in the project we have many more resources to maintain on the project which would magnify the costs of this change by four times or more.
Perhaps a little more neglected is the information architecture and in particular the reference data the application needs. In some ways this is similar to the source data applications we looked at as part of the application architecture. These reference or master data sources are about managing a single managed source for the data, rather than picking it up from any application that may have touched it in the landscape. Some of the key reference data are around the corporations finance, structure, staff and products. These might including:
- Finance: The financial year, quarters and account close dates. Also any account codes to be used by the system.
- Structure: Location and business unit structure.
- Staff: Organisational management (Staff to role to manager structure) frequently required for security access levels, work flow approval and escalation
- Product: product or services consumed and supplied by the corporation
This informational architecture really plays into the space of master data management, which is beyond my subject today. Frequently though these are an area that is neglected. It is hard for any single project to justify the scope to deliver these foundational services. In my experience it is organisations with a good enterprise architecture discipline that are able to demonstrate the benefit of these capabilities to a number of proposed projects. Even in these cases some business led projects will have to be delivered before the foundations are in place. In my most recent experience this was very true with organisational management being a service the project would really benefit from, but which won’t be in place prior to the project go live.
Finally it is important to consider the infrastructure architecture that we might be delivering the new solution on. Does IT have skills in the technology, at the scale being delivered and the level of availability? If not then delays in the delivery of environment, in experience in performance tuning and confidence in accepting the solution into production may significantly delay the project and cause overrun on costs. Building new capabilities in this area takes time and needs to be planned into the project or delivered as a foundational project before the business solution.
The four architecture domains that I have discussed here should not be a surprise as they are the normal domains of any solution architecture. Perhaps what is less usual is the degree that these need to be considered at the very beginning of a project, in verifying scope. From an architecture development framework like TOGAF what I have described here should form part of the responsibility of the Vision step right at the start of the project.
