Architecture of complex projects

A first question would be: what are complex projects? One viewpoint of complexity is technical, another one is organizational. We will take the organizational viewpoint, because technically a lot is feasible. What we see in a lot of literature is that the socio-politics of these complex systems are of great importance, especially where governments are involved. It needs involvement of lots of stakeholders, commitment at different levels (policy level, legal people, CEO's, CIO's, etc.). Once this commitment is achieved, these projects are rather program's with a duration of years instead of a year. It means that attention will shift, technology will change, etc. The final result is probably a solution that is implemented 5 to 10 years afte the start and is not yet meeting the objective.

An example can be given by the National Computerised Transit project. It started originally in 1985 and was implemented in 2000. Inbetween the focus changed from the development of an application to development of interfaces between all parties involved. However, to meet implementation dates, there was a request of some members in the program to develop applications and so they were made available. From a political perspective the system does not meet requirements since excise goods were excluded. It meant that the original objective of fraud prevention of excise goods like liquor and tobacco were not met and a new system was developed.

Other programs follow the same strategy, e.g. development of central applications before agreement on interfaces between all components. From an architectural perspective, a system consists of components and their interfaces. By developing the interfaces first, the components can be developed independently. Thus, the architecture can still be distributed based on interfacing.

There are other aspects that still require the development of a central component. From a technical perspective, a central component is not required. Communication facilities are available, messages and services can be defined, cloud computing can be applied, etc. There may be political or cost requirements to develop a central application. From a cost perspective it implies that knowledge of the system is managed and maintained by one group instead of several, the system needs to be operated at one or two locations, the system is fairly expensive by nature, etc. The new Schengen Information System is defined as a central system with a number of local components. However, other systems of which the costs are not high by the nature of the system, e.g. because it can be based on available knowledge and components are not new or expensive, there is no technical need to have a central system. On the other hand, technology also allows the development of a central system instead of local, communicating components. What is required in such occassions is most often a combination of central and local solutions, where the local solutions support additional functionality of the business of the user.

We welcome any contribution to a discussion on the development of this type of systems.