Anglais 1.5

A Roadmap
for the Implementation
of CIRCA-BC using Alfresco

DRAFT bla

Dokumenta S.A./mh, tk, BHS/Version 0.1, /09 May 2019

Document History

Date: / 09 May 2019
Version: / 0.1 / Draft
Authors: / Bernd H. Schmidt, Thomas Kopp
Revised:
Approved:

Table of Contents

Purpose of the Proposal

1.Prototype

2.Roadmap

2.1.Team composition

2.2.Configuration of Alfresco

2.3.Implementation

3.Controlling the Development

4.Cost estimation

Purpose of the Proposal

This paper proposes the next steps necessary to achieve a CIRCA-BC implementation based on Alfresco. The following goals have to be reached:

(1) Full CIRCA functionality:
All relevant CIRCA functions need to be available in CIRCA-BC.

(2) Fast implementation:
A running version of CIRCA-BC shall be available as fast as possible (mid 2006).

(3) Limited costs:
The implementation effort shall be limited to the mandatory parts only.

(4) Independence from Alfresco’s future directions:
An implementation of CIRCA-BC based on Alfresco should concentrate on OSS-based interfaces and wrap or at least identify Alfresco-specific code. Other JSR-170 (or JSR-283) compatible systems may substitute (parts of) Alfresco later.

1. Prototype

In a first phase, a prototype of a CIRCA-BC based on Alfresco with limited functionality will be built. In doing this, we get

– An environment to discuss the look and feel (UI) of future CIRCA-BC based on Alfresco.

– A first example of how to map Alfresco functions to CIRCA-BC needs

– An environment, which allows discussing the pros and cons of certain ways to implement CIRCA-BC functions (basis for 2.2.2 below).

– The basis for the decision of how to implement the needed functions (cf. 2.3.2 - 2.3.5 below)

In this phase, we will concentrate on few relevant functions, which may be used as a template or development pattern for a full-featured implementation (cf. 2.3.1 below).

We will start on the basis of the JSR-170 compatible library service and add features step by step. What is added next will be decided in close cooperation (cf. 3. below).

2. Roadmap

Based on the Prototype, a (still uncompleted) list of relevant tasks (configuration or implementation) will be produced.

For most functions needed, we can decide, how they shall be made available: Either by configuration of Alfresco (based on UI-decisions and certain templates) or by implementation.

Configuration and implementation may be performed by different teams or persons partly in parallel (cf. 2.1 below). This allows for time estimations and a concrete project plan.

2.1. Team composition

Depending on the task-list produced, a rough estimation of the work-load will be possible and hence, the developers can be assigned to tasks or at least task-blocks.

Number and skill of available developers need to be established in advance.

Interfaces between the developers as well as between the implementation blocks (cf. 2.3) can be defined. An infrastructure for team collaboration and synchronisation will be set up.

2.2. Configuration of Alfresco

We currently believe that most functions of CIRCA-BC will be established by “simple” configuration of Alfresco. To do this, an agreement with respect to the future look & feel (UI) of CIRCA-BC (based on the prototype) is mandatory.

2.2.1. Mapping of Alfresco’s Functions to CIRCA-BC needs

Many functions of Alfresco will directly be re-used as CIRCA-BC functions (if a slightly different UI is agreed).

2.2.2. Implementing CIRCA-BC by Configuration of Alfresco

CIRCA-BC functions may be achieved by a certain way of usage and a certain configuration of Alfresco.

But: Product architecture as well as product philosophy of CIRCA-BC and Alfresco need to be accomplished.

This is the most critical part of the migration process: It will save time and money, if configuration of Alfresco fully supports the needs and if CIRCA-BC users and administrators can comprehend this different way to reach the same goal.

In some cases, it may be a good decision to implement a different approach instead of doing a tricky configuration even if the implementation consumes time and money. Time and money may be saved later for administration and teaching. Decisions of this type are the main reason to install a committee (cf. 3. below).

2.3. Implementation

2.3.1. Implementation strategy: Templates & Development Patterns

As already mentioned above, we suggest to implement certain reproducible modules as a template or development pattern first and to implement (many) similar or equivalent functions in a second phase (probably by another implementation team).

In doing so, a proof of concept will be easier as well as an estimation of the implementation effort will be more precise. Also technical issues can be detected and solved early before producing a large amount of source code, which would have to be revised otherwise.

2.3.2. Wrapping Alfresco for Compatibility reasons

To avoid access to Alfresco-specific interfaces, they may be wrapped by own implementations. For most cases, however, it may not be necessary to implement an additional (redundant) interface, but only to identify and document the Alfresco-specific interface.

Note that wrapping proprietary interfaces is recommended for keeping CIRCA-BC portable: When for any reasons migrating to another JSR-170 compatible CMS, dependencies on a specific tool can easily be identified and adapted without changing application code on top of the wrapped interfaces.

2.3.3. Controlled Adaptation of Alfresco Modules

If relevant CIRCA-BC functionality can only be achieved by adaptation and changes of Alfresco, this results in a CIRCA-BC-specific Alfresco module. Since interfaces inside Alfresco may be very Alfresco-specific (even global variables may be used), a special class of source code evolves. This source code (not new but non-standard Alfresco code) will be dangerous and needs to be documented and controlled carefully.

2.3.4. Substitution of Alfresco Modules

Even if Alfresco modules are substituted, there is a risk of hidden Alfresco-specific interfaces and future incompatibilities. It needs carefully to be decided, to which extend a substitution is reasonable: Sometimes a complete substitution of a bigger part may be easier, since interfaces are well defined.

2.3.5. Adding CIRCA-BC-specific Code

CIRCA-BC-specific code consists of modules independent from Alfresco, but usually using interfaces to Alfresco. The Alfresco-specific interfaces need to be identified and explicitly documented.

It is recommended to use the JSR-170 API as far as possible when adding new code instead of using Alfresco-specific interfaces. This strategy again opts for portability of CIRCA-BC.

2.3.6. Source Code Control and Versioning

Source code needs to be controlled by a reliable source code control System. Secure collaboration (check-in/-out) via Internet needs to be supported to allow for concurrent distributed development. Metadata need to be associated to modules (“Alfresco-specific interface”, “JSR-170-specific”, etc.).

Source code developed for substitution or adaptation of Alfresco modules as well as Alfresco-specific interfaces need to be controlled and documented separately to have an easy and fast access, if standard Alfresco changes.

All these requirements could be fulfilled by using CVS as a reliable and widely supported standard version control system.

3. Controlling the Development

We propose to establish an audit committee to tailor the development goals to exact needs and to avoid unnecessary costs. This committee should meet on a regular basis (e.g. weekly) even if these meetings may be very short.

The project leader prepares a list of planned developments and flags the items, which need a decision, how the implementation shall proceed (2.2.1 or 2.2.2; 2.3.2-2.3.5).

4. Cost estimation

Concurrently with the development of the roadmap, cost and time estimation is possible and will be refined during the implementation process.

A first valid estimation will be possible, when team composition is complete and a first project plan is established. UI-Decisions (cf. 2.2.2) as well as architectural decisions (cf. 2.3.4) may change time estimations and hence need to be identified and fixed as early as possible.

Dokumenta S.A./mh, tk, BHS/Version 0.1, /03 February 20061