When developing an application, it is important to think of (1) the lifespan of the new application and (2) the frequency of changes over time. Depending on these characteristics, different needs arise for its maintainability. We roughly categorize applications as shown below:
| Type of application | Life-span | Changes over time |
|---|---|---|
| Proof of Concept (POC) | short After the proof of concept is done, it is thrown away and replaced by the actual implementation. | none After a high degree of changes during the POC, no changes are done after that. The project is often thrown away, as the knowledge gained is the important part. |
| Short Campaign | short Sometimes a company has a special campaign which runs between weeks and several months. After the campaign is complete, the application is not needed any more. | none Once the campaign is setup, no changes are planned until its completion. Only bug-fixes are performed which affect the currently running campaign. |
| A Single-Purpose Application and departmental applications | long When creating an application for a single purpose or for a single department, it is intended to fulfill this purpose for a long time, until it is succeeded by another application or the purpose becomes voided. | minor - major When the single-purpose is achieved, the changes to it are often minor. It is usually not affected by everything else that is happening in the company. However, single-purpose applications may become mission critical with many end-users. The life-cycle of the application also differs to the life cycle of the data, leading to changes in the application over time. Changes must be realized with no impact and/or risk. |
| Enterprise Application | long It is intended to run the majority of functionality with the application. This includes current functions, as well as new functions that will be added in the future. A function could be the selling of a product (mortgage, loans, subsidies, etc.), the internal process handling, etc. | high As the commitment of the customer is high, it is expected that the application can be extended for years to come. New functions will be added frequently, and existing ones need to be changed to reflect the new way of working, or be consistent with the rest. |
Having an application that is easily maintainable (with little to now impact and/or risk) is the most important for Enterprise Applications. As the other type of applications have a short life span or are not changed often, it is often acceptable to choose an architecture which is less maintainable over time. Such an architecture often has as benefit that it is easier or quicker to develop on the short term. The choice should be conscious, as you do not want to end up with a non-maintainable application for years to come, or spend much effort for a maintainable solution which is only short-lived.
Applications that are hard to maintain show the following characteristics:
- Decreased development speed
- Much work needs to be performed for a small change
- Unpredictable development speed
- Changes are complex, and often leads to unexpected errors
- Testability declines
- Not being able to test a small component, but always needing to test 'everything'
- Complex to test, only smoke tests possible
- Brittleness of the application
- Small changes may cause unpredictable failures in the application and will be hard to implement.
- Unhappy developers
- Only few developers understand the application
- New developers that understand such a complex application can not be found
Maintainability has to be facilitated on many levels. From naming conventions to the overall architecture. This design guide concerns the latter, and discusses the architecture using the concept of Clean Architecture
Overview
Content Tools