Le logiciel doit évoluer sans devenir incompréhensible.
EOSX poursuit une idée à long terme: la complexité ne doit pas être gérée principalement par toujours plus de code interdépendant. L’ingénierie doit fonctionner davantage par capacités, relations, composition et évolution contrôlée.
Les capacités comme point de départ
La question centrale passe de «Quel code écrire?» à «De quelles capacités le système a-t-il besoin et comment doivent-elles coopérer?»
Faire évoluer l’existant
EOSX ne doit pas seulement permettre de nouveaux systèmes. Les solutions existantes doivent pouvoir être analysées, importées et modernisées progressivement.
Du logiciel aux systèmes techniques
La même idée peut être transférée à des domaines très différents si leurs capacités, règles et relations peuvent être décrites clairement et correctement implémentées.
Développement actif
L’architecture continue d’être développée et validée dans différents scénarios. Les détails techniques internes ne sont volontairement pas entièrement publiés.
Composition plutôt que croissance du code
Les nouvelles exigences doivent autant que possible être représentées par des capacités et relations plutôt que par une complexité monolithique croissante.