Extensibility Scenarios

Current fit

Within this scenario, the application is fitted to the current system. This means that the application is tightly coupled to the current infrastructure of the organization.

For instance, the organization currently uses Mercurial for version control. In this scenario the application is tightly fitted to this version control system. If a new version control system is going to be used by the organization, the internal structure of the application needs to be modified.

Partly extensible

In this scenario, the data sources are categorized. For instance, there is a category version control, a category contact, etc. All these categories provide an abstract data representation and an interface for the concrete implementation.

Let’s continue with the version control sample. A commit to the version control system can be represented by a commit message and a set of changed files. This representation is isn’t coupled to a specific version control system because all systems share this signature, so this can be used to represent a commit, independent of the concrete implementation.

Secondly, the type defines an interface which the concrete data source needs to implement. This way, the concrete data source can be used but the system itself uses the abstract interface to call the data source. The system doesn’t need to know the specific data source to operate, because it operates on the interface.

This way, it is possible to switch the concrete data source of the current type, without the need to modify the internal structure of the system. Of course, the new data source has to be implemented within the application, but after that, it can be plugged into the application, without the need to modify the internal structure of the system. Within object oriented programming, this is often referred to as the Adapter Design Pattern.

When a completely new data source has to be implemented, for which there currently isn’t a type defined, the internal structure of the application still needs to be modified.
 

Fully extensible

In this scenario, the application is built in a way that new data sources can be added regardless of type. The application provides an interface for new data sources which needs to be implemented and after that, the new data source can be plugged in. The internal structure doesn’t have to be modified for any new data sources.

Considerations

Each scenario has its advantages and disadvantages which have to be weighed against each other.
 

Extensibility

If we look at extensibility, we see that the fully extensible-solution is the most extensible, like the name already says. It can be fully extended with different types of data sources.

The partly extensible-solution is also extensible, but more in a focused way. A new data source can be included, however the type of data source needs to be defined within the application already. For example, a new type of version control system can be included without changing the internal structure of the application, but for a completely new type of data source, the internal structure has to be modified to support this type of data source.

The first solution isn’t extensible, because it is fitted to the current infrastructure of the organization. When a new data source is introduced, it has to be fitted to the application as well.
 

Cost and complexity

The current fit-solution is not complex, relative to the other solutions, because there aren’t any abstractions. The implementations are tightly coupled in the system which makes the application pretty simple.

The partly extensible-solution has abstractions on the type level, which makes it more complex compared to the current fit-solution. This is because the abstractions have to be researched and a general data representation has to be developed. This raises the complexity.

The fully extensible-solution is even more complex, because the abstractions are at the data source level. Because of this, within the application there isn’t a structure available for types of data, in contrast to the partly extensible solution. This means that the application has to be able to handle every type of data, which raises the complexity a lot.

When the complexity of a system rises, so does the development time because if the solution is more complex, more time goes into research, design and development. More development time means more development costs. Because of this, the complexity of the application is proportional to the cost of the application.
 

Deployment

All solutions have to be configured because they need to be connected to the data sources. It is practically impossible to develop a solution which runs completely out of the box, because there is the necessity to authenticate the application with the external systems, etc. Also, before the application can be used it has to be included within the internal network of the organization because otherwise no one is able to access it and the application itself can’t access the other systems. Because this statement holds for all scenarios, we won’t take this configuration into consideration, but we will only look at the work which is necessary relative to the other solutions.

If we look at the first solution, we see that it is easy to deploy. Only the initial configuration is needed to fit it to the systems within the organization, and no other configuration is needed.

The second solution is more difficult to deploy because apart from the specific data source configuration, also the type of data source has to be configured. For instance, the application will not know out of the blue which instance of a version control system used or even how many version control systems are in operation within the organization, so this needs to be configured.

Lastly, the third solution requires a lot of configuration to fit it to the different data sources. Data models need to be configured and the translation between the data from the data sources and the data models needs to be defined. Because of this, the deployment of this solution is the most complex.

Comparison

To compare the attributes named above, we have included them in a table below and scored them.

Stakeholder profile and stakeholder feedback

The stakeholders indicated that they want to use the latest tools and techniques to use with their projects. If we look at the history of the company of the stakeholders, we see that they indeed switch their tools once in a while. However, they actually switch tools, and don’t add tools which they didn’t use before.

To double check, we asked the stakeholders how they foresee the use of tools in the future. They indeed verified that when they introduce a new tool, it is often to replace existing tools and not to introduce a completely new tool. They also indicated that there currently isn’t a need to introduce a completely new tool into the organization.