Development · integration · reverse engineeringOstwald · Alsace · Remote projectscontact@dtouch.fr
Architecture · dependencies · integration

Information systems architecture

An information system is built in the relationships between its components. Dtouch supports architecture choices to link applications, bases, processing, interfaces and operation.

Read the system before changing it

The visible need may depend on several applications: an interface, a repository, a processing service and file storage. We examine their roles, their exchanges and the operations that connect them.

The mapping also identifies responsibilities: who provides data, who can modify it and which tool should consume it. This reading allows you to prepare for changes by understanding their impact on overall functioning.

Define joints between components

An architecture must specify the interfaces, identifiers, formats and expected states. API, events, file exchange and delayed processing can meet different needs.

The Rey’actif course provides concrete context: PIM, PostgreSQL, office applications, WebSocket, tasks and InDesign Server. Architectural work brings these tools closer to production uses.

Preparing the steps and dependencies

We distinguish between what can evolve independently and what requires coordination between several components. Resources, access and test environments are part of the framework.

A new interface should not be evaluated in isolation: the demand should be monitored until processing and the result obtained. The recovery scenarios and error situations complete this verification.

Period documents & interfaces

A 2017 architectural study to organize applications and their exchanges.

Study of architecture Akeneo, Nextcloud and Rey-ActiveEnlarge
Study of architecture Akeneo, Nextcloud and Rey-Active

Design document from January 2017: study of exchanges between Excel imports, PIM Akeneo, images in Nextcloud and Rey’actif production platform.

Architecture study · design document · 27/01/2017

Making architecture workable by teams

The documentation must allow developers, operations and users to locate a problem. A description of flows, control points and responsibilities serves future interventions.

Dtouch combines this overview with technical management: organizing the contributions of specialists and providing continuity between design, development and production.

Understanding the exchanges

Manage developers and project dependencies.

The technical management role brings together business teams, developers and specialists to maintain consistency from framing to production.

Manage developers and project dependencies.Enlarge the diagram
  1. 01

    Business need

    Uses and priorities

    Journey • constraints • challenges
    Set expectations ↓
  2. 02

    Technical framework

    Perimeter and architecture

    Data • dependencies • steps
    Organize the production ↓
  3. 03

    Developers

    Implementation and integration

    Team • partners • offshore
    Checking uses ▼
  4. 04

    Recipe

    Check the routes

    Scenarios • differences • arbitrations
    Preparing for commissioning ▼
  5. 05

    Put into production

    Preparing for exploitation

    Deployment • monitoring • continuity
    Develop tools ↓
  6. 06

    Developments

    Organize returns

    Uses • maintenance • priorities
Manage developers and project dependencies.Enlarge the diagram
Functional diagram · synthetic reading of flows and control points.
Frame

Define expected results and responsibilities.

Coordinate

Treat dependencies between developers and specialists.

Transmit

Make decisions and operating conditions understandable.

Your job deserves
the right tools.

A specific need, a software to evolve, a project to frame.

Exchange on your project

Complementary expertise, the same high standards.