Properties of 9 logical and implementation view - background - rationale - extensibility and business layer

  1. Properties
  2. History
  3. Community
  4. Source
content of data sources

By request of the stakeholders, the data sources of the application need to be extensible.

For this, we have determined three scenarios that we named current fit, partly extensible and fully extensible.


·         current fit – Fitted on the current source systems, without chance of flexibility

·         partly extensible – Fitted on the current situation, but with a flexibility to use systems with the same ways to process and retrieve the data.

·         fully extensible – Fully extensible and flexible to use every kind of source system


Based on the considerations documented in the considerations paragraph in the appendix under section “Extensibility”, and the profile of the stakeholders, the first scenario (current fit) can immediately be marked as not viable. The history and wishes of the stakeholders requires extensibility what the current fit can’t provide.

After we compared the second and third scenarios, we have made the decision to go for the partly extensible-solution. It is hard to predict what kind of new systems will have to be connected in the future. Also when we go for a fully extensible solution, the complexity and with that the development time and –costs rise. If we look at the profile of the stakeholders,

this complexity is not necessary for their situation. The partly extensible-solution is the best fit for the case of the stakeholders.


One of the main concerns of the stakeholders was that they like to experiment with different tools. At the moment they might use a specific tool, but if another, better tool arises, there is a large probability that they are going to experiment with it. One of the design decisions was that the architecture will support switching to another tool of a known type. An example is given in the appendix under section: Data gatherer Extensibility


Business layer


Secondly, the business layer. This is the core of the application; after all data has been abstracted to a certain type of data (version control system data, bug tracking issue data, etc.) the data still needs to be coupled and conclusions must be drawn from it.


This meant that globally a system or multiple systems would have to be responsible for the following tasks:


-          Receiving data to process from the data layer or pulling it from an external source

-          Storing data coupling rules (i.e.: if a developer commits to a certain project more than 50 times, he is an expert on the matter)

-          Coupling the data and persisting it to a data source or passing it through to a representation layer

contains knowledge about
9 logical and implementation view - background - rationale - extensibility and business layer


Knowledge Bases


  1. Local
  2. OpenID