Architecture: an ounce more or less?

In deciding whether or not to bring projects under architecture, you can roughly distinguish two types of decisions, namely whether or not to develop within the framework of the Enterprise Architecture and if so, how much. Three important reasons for not applying Enterprise Architecture are time pressure, a temporary solution and an inadequate Enterprise Architecture. 

Time pressure is seen as an important criteria for not applying Enterprise Architecture. For example, project initiatives that arise from compliance with laws and regulations that are difficult to anticipate tend to be subject to time constraints. In addition, there are projects that provide solutions of a temporary nature. These are usually not developed within the framework of the Enterprise Architecture. An example is the implementation of a solution that temporarily exchanges information with chain partners. A third criteria is the inadequacy of the Enterprise Architecture itself. This then does not (yet) provide a concrete framework for the project. Fortunately, the decision not to develop within the frameworks of the Enterprise Architecture is an exception to the rule, because ideally, you always develop within the frameworks of the Enterprise Architecture. If you develop within these frameworks, then you assign resources such as the PSA and a controlling architect to review and adjust where necessary based on the principles and frameworks. In most cases this is a standard set of resources, but you can also determine the extent to which you apply these steering resources.

Highberg (formerly known as VKA) developed a decision-making model for determining the right degree of applying Enterprise Architecture as a steering tool for projects with an IT component. The decision-making model helps in (setting up) an effective and efficient working method in which the project can still be developed within the framework of the Enterprise Architecture, even in unforeseen situations. The allocation of appropriate resources is done based on the desired and/or required degree of control. In an implicit risk and impact analysis, you pay attention to how many resources and techniques are needed to implement a specific solution in accordance with the Enterprise Architecture. Ideally, you perform this analysis in parallel with the portfolio management process. This way, before the project starts, it is clear how many resources are needed to develop the project within the framework of the Enterprise Architecture. This also allows the architecture function to anticipate making the required resources available. This implicit risk and impact analysis is concretized in the following multi-criteria model:  

Minor Projects: Projects within the minor category are characterized by a relatively low amount of resources and techniques related to Enterprise Architecture. These projects are characterized by small changes that score low on the criteria. Therefore, these projects are subject to a lesser degree of scrutiny by the Enterprise Architecture function. In this category, the PSA is replaced by a starting memorandum, in which a limited number of agreements are made using principles and frameworks. Instead of a controlling architect, the project manager is responsible for ensuring that the project complies with the Enterprise Architecture. The project manager will not only consider time and resources, but must also consider the development of the project within the frameworks of the Enterprise Architecture. 

Medior projects: This category is similar to the average way organizations use Enterprise Architecture as a steering tool for projects. The extent to which the PSA is written depends on the project specifics. The normal PSA template is used for this purpose. The PSA consists of agreements made based on models, principles and frameworks. The role of the controlling architect is assigned to an architect from the organization who checks the project for compliance with the Enterprise Architecture. The delivered project results are tested against principles and frameworks through a lesser degree of control. In addition, the architect provides needed services to the project and can be consulted for an opinion. The controlling architect may be assigned to multiple medior projects simultaneously. 

Major projects: Within this category, resources and techniques related to Enterprise Architecture are applied to a more rigorous degree. Projects that score high on the various criteria are subject to a comprehensive PSA. The comprehensive PSA requires a more detailed description of models, principles and frameworks. The controlling architect assigned to this type of project is highly involved and performs compliance checks on a regular basis. The controlling architect assigned to this type of project is often an architect who already has more experience with the type of solution. Whereas the controlling architect may be assigned to multiple medior projects, the controlling architect of in this situation is permanently assigned. In addition, more detailed services are provided to the project such as detailed modeling and consulting. 

The above model is not a spreadsheet that you just fill in and an occupation rolls out. It does give direction to a structured thought process in which you determine how much architecture you want to deploy on a project. And that's good, because sometimes it can be an ounce less... and sometimes it can be an ounce more....