DYA: Development without architecture

I come across it regularly: Organisations implement a new service or application under high time-pressure.

Products or services need to be on the market fast, before the competition does (for instance in the telecoms sector), or some law is approved by the government which leads to a short-term change in applications (for instance in the Insurance business).

The problem here is that the application or service is built fast, but it does not comply to the company's architecture, or it does not comply with the security policy.

After the application or service is deployed, it takes much effort to manage the service. The extra cost of  managing this non-compliant service can be very high and will be apparent for many years after the original deployment. Also, the new service could introduce security issues that need to be solved later. Furthermore, the connectivity to other systems might be difficult or not rubust, because the other systems do comply to the architecture.

A solution for this problem is introduced in the DYA architecture method.

In DYA, one can choose to develop a project under architecture, or perform development without architecture. Systems that have to be introduced fast, don't have to comply to the architecture of the company. However, after the system is deployed, the development team is committed to start a new development cycle for the same system, but now developed under architecture. This second development cycle can take all the time it needs to develop the system using the normal architectural guidelines and principles.

A nice model.

I have never seen this working in practice. When a solution is in production, it is seldom replaced, just to comply to the architecture. Temporarily solutions usually remain permanent. On the short term the new development under architecture costs money, time and manpower, and it will deliver value only in the long run (mostly system admin costs). Usually system administration is on a different budget than the projects.

The only possibility I see is that the architecture must be followed always. When a project wants to circumvent the architecture, it can only do it if the cost or re-development under architecture is budgeted at the start of the project, and is an integral part of the total cost of the project. This way the cost of developing without architecture is known to the stakeholders of the project in advance. It makes it possible to make a balanced decision if the additional cost for de-development are worth the fast delivery of the service or application.

Obviously this only works if working under architecture is thoroughly embedded in the organisation (the so-called architectural governance), and has enough mandate from higher management.

This entry was posted on Friday 02 January 2009