A framework for an Integrated Technical Architecture in EU research projects with a geographically and organisationally distributed partner setup

Disclaimer: The author of this blog entry is also the editor/co-author of the document which describes the Technical Architecture Integration Concept that this blog entry recommends/promotes as a best practice for EU commission funded research projects.

Getting straight to the point, this deliverable document from the STREETLIFE project (available here @ CORDIS which is the European Commission's primary public repository and portal to disseminate information on all EU-funded research projects and their results) has to offer "a reusable framework for an early approach within European Union (EU) research projects with a distributed partner/pilot platform setup to arrive at an integrated technical architecture". Although, this could generally also be applied in situations where a Software Architect needs to work with a cross organisational distributed setup for research or business projects. To understand the background and associate it with the need for an integrated technical architecture in your architecture projects, continue reading further.

1. For WHOM is this relevant?

In general, the approaches try to address working with constraints put forth by organisational and geographical boundaries when working within projects that are setup with teams picked across organisations and regions. In my opinion, this is a pattern that occurs often within many EU projects commissioned by the former FP7 or the newer Horizon 2020 framework. Hence, this article is particularly relevant for Software Architects working in such projects.

2. WHY?

Mel Conway from his 1967 paper on "How committees invent?" submitted to the Harvard Business Review states

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

Therefore, the structure of the software built by partners within an EU project will tend to reflect the social boundaries of the organization(s) that produced it. EU projects are in general composed of partners that are distributed across the European Union and have completely disconnected managements, software development processes, test and deployment environments. As a result, the architectures of software built within an EU project is bound to be under duress. This is due to the organisational architecture of the partners within the project which defines the communication structure from which the definition of the architecture design is derived.

In my opinion, at the beginnings of many EU projects with a distributed team/pilot/partner setup, it is highly unlikely that all architectural views and viewpoints are laid out and most importantly 'agreed' upon by all partners. It might be that the Architect will need to define such architectural views during the early part of the project's lifetime for addressing the purpose/goals of the project. Development work can only begin after some high level views and viewpoints are agreed upon.

A collaborative pattern persists in EU projects of this nature. There are partners from many EU corporate companies, EU city administrations, EU research institutes/universities that participate in the project jointly.

Probability is high that the partners will have their own development and deployment environments to satisfy their own local experiments. Therefore, having a common software platform in most instances is not a viable option.

This normally leads to conflicting requirements within the project. An example below,

• Requirements from the EU commission's project office that the partners'/cities' platforms should work in a completely connected way as a necessity to provide concrete re-usable results, standalone software components at the end of the project. 

This conflicts with the following,

• Requirements from partners within the project that their platforms need to work independently due to intellectual property restrictions, data privacy restrictions or speed of deployment or control restrictions.

These constraints complicate the overall system architecture. More such constraints are described in the D2.2.2 deliverable document within the context of the STREETLIFE project.

3. HOW? 

In particular, within the scope of the projects it should be avoided right from the start that similar solution components are developed in each city's pilot site leading to a 'reinventing the wheel' phenomenon. Ideally, the solution components needed across all pilots are shared after it is agreed upon where it is to be built within the project. Ideally, the pilots also develop common project goals and evolve them into scenarios that involve some process orchestrations across different city pilot solution components.

The document in focus here (Deliverable D2.2.2 from the STREETLIFE project) attempts to address all these constraints and generalize all the solutions into a framework that could be reused/reapplied within EU research projects with a distributed team/partner/pilot setup similar to STREETLIFE. For details, one can always lookup the document from the link above or from the references section. These concepts are based on the Integration Architecture concept from the 'Managed Evolution' book by Stephan Murer and Bruno Bonati.

In summary, the deliverable details how to define integration in your projects and then defines two concepts - vertical and horizontal (gif animations below) through with many constraints presented can be handled.

Vertical or Scenario based Integration Concept

Horizontal or Component based Integration Concept

4. REFERENCES

1. STREETLIFE Deliverable D2.2.2
• Blueprint Architecture, Security Architecture and Pilot Specific Architectures (Intermediate)
• Download the document from the Cordis Europa Site here
2. The STREETLIFE project on the Cordis Europa Site
3. The STREETLIFE project website
4. CORDIS - the European Commission's primary public repository and portal to disseminate information on all EU-funded research projects and their results in the broadest sense
5. Managed Evolution - Stephan Murer and Bruno Bonati