I think I have lost count of the number of times a new IT system has been hailed as a salvation to a whole host of business problems and failed to deliver. Failure to deliver functionality. Failure to deliver on time. Failure to deliver on budget.
The bottom line in may cases has been due to the system not being needed in the first place. In this day and age there are virtually no green field sites for IT systems. As such the primary rational for implementing a new IT system is to provide some functionality which is perceived to be absent from an existing system or to replace some system which has been deemed un-supportable.
In the first instance, where new functionality is required, the real reason for implementing a new system is almost always that the existing system is so poorly understood that the very idea of extending it to cover the new functionality sends shivers down peoples spine. The architecture of the system has never been owned and therefore becomes an unknown quantity as those that implemented it move on to new and more interesting projects.
This is almost the same reason that systems are labelled as unsupportable. The system has aged, the people who understood the architecture have moved on and the artefacts that remain are buried in impenetrable volumes of documentation.
In both cases failing to understand the architecture and functionality of the existing system dooms any new system which intends to replace it. The failures can be manifold but most commonly include.
- Failing to understand the data model of the system thus causing no-end of issues migrating data from the old system in to the new system.
- Failing to understand all functions of the old system and thus not subsuming them in to the new system. This issue then compounds issue 1 by often requiring both systems to run in parallel with data synchronisation.
- Failing to understand all the places where a system needs to be accessed from, which result in hacks around the edges to allow users to access it, possibly compromising security as they weren’t designed in from the beginning.
- Failing to understand the roles and responsibilities and work that key users need to undertake with the system resulting in a cottage industry in spreadsheets and other swivel chair interfaces to the new system. Other examples of this are that users just can’t do the job they need without inflated user access rights or other database scripts being run under the covers to perform functions that should have been provided to users.
- Under performing systems which don’t deal with things in a timely manner because non-functional requirements such as how long a job will take are just not considered until the terminal stages of any new system implementation.
- Poor justification for the new system in the first place with over inflated rational for the new requirements. Most often this boils down to some speculative cost savings which are seldom if ever realised.
All of these reasons for failure can be addressed with proper architecture of your existing systems. I am not saying don’t ever implement a new IT system, sometimes it is required, but unless you know your current architecture, you don’t know for sure, and you won’t get it right.
Each of the causes of failure above corresponds to one column of the Zachman Framework and can be directly attributed to no-one having even looked at that column of the Enterprise Architecture. Working on these columns will help make better decisions about when to implement new systems, when to extend existing ones, when to just not bother because non-IT processes are efficient enough. More importantly they will ensure that when you do need to implement a new system that you know all the data you need to migrate, all the functions you need to implement, all the locations you need to access the system from, the people and the roles and responsibilities they will have, the times things need to be done in, and above all why you need to do it.
Some projects do manage to look at these various aspects of the architecture they are implementing but the artefacts all end up buried in a mire of word documents. Blueprints for a house are just that. You don’t have to dig through hundreds of pages of interpretation and boiler plate to find the information about which walls are load bearing. When this information is buried in many documents covering multiple project phases and multiple projects the architecture of the whole enterprise is just not easily accessible to new projects wanting to find out what is ripe for re-use.
Architecture is not documentation. The current obsession with documenting things endlessly in an ever increasing volume of word documents is not Architecture. The knee jerk reaction when something is missing or not located in a document is to request another document or gap analysis, further compounding the issue.
In order to be able to move on and make effective decisions Architecture practice must be stripped back to what is needed. Simple primitive models of the systems, both as is and to-be, their inter-dependencies and their interfaces. Where documents need to exist they should be light weight, easy to read functional descriptions of the interfaces and how to use them. Much as you would have a blueprint for a house which referrers to instructions for correctly fitting the boiler. Nothing new should be implemented without doing a full impact analysis on the existing models to make sure you won’t break anything and you are not duplicating effort. An impact analysis in this case should not involve more documentation as you should be able to take an existing model of the environment, apply changes to create a to-be model and see if the systems all hang together.
Models and diagrams should be the entry point to any Enterprise architecture and not be Buried and distributed through many documents where it takes days if not weeks to garner a full view of the enterprise. If it takes time to get the right information together then the chances are it won’t get done or at the very best it will be done hastily and incompletely.
Something needs to be done now to fill these models and the only way to justify it is on the vague promise that we might be able to save some money later on down the line. The saving grace is that, with money being tight now and fewer projects being implemented, there is a window in which we can try to play catch up on our architectural models.
