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.
Typical example: A Blueriq Project Structure
In Blueriq it is possible to stack modules on each other to reuse elements from lower modules. This enables the use of generic functionality in lower modules, and specializing them in a specific module if changes are needed. These modules should represent business concepts, such as a product being sold. In below structure, the middle layer represents different labels of the company which are similar to each other in most aspects, and therefore use the same generic library. Each of these labels is represented to the end-user using a certain channel. Examples of such channels can be a website or an app on the phone or tablet. For each channel you want to change the behavior of the application slightly so that the user experience is changed to optimally function for that specific channel. This represents the top layer of the structure.
The underlying idea why this structure is agile and maintainable is that you can perform changes on the level that fits the change. In case that Label C has a slight variation on the rules, then you would create that logic in the Label C module. In case you want to split up your pages for Channel 2 (as that might be a mobile channel), then you change your flow in the Channel 2 module. If a change should be applied to all applications, then you perform it in the generic base module. When making changes you should consider when functionality should be moved up or down the module structure. You should make functionality more generic (moving down) when similar functionality is implemented in horizontally aligned modules. You should make functionality more specific (moving up) when you notice that each upper module changes the functionality significantly. A common pitfall is to create functionality in the generic layer while it is not generic (yet).
The advantage of this is that small changes could be implemented quickly. The disadvantage of this approach is an undesirable growth of the generic layer which leads to a high number of dependencies through the application landscape.
Small changes usually are:
- New label with small minor changes. A new module in the middle layer can be added based on the generic module.
- New channel with small minor changes. A new module can be added to the top layer for the corresponding label.
- New functionality within a known channel and label. Change the functionality in the corresponding module and consider if the new functionality causes refactoring to make it more generic or specific.
Overview
Content Tools