Jede Unternehmens IT besitzt Architekturrichtlinien, definierte Verfahren und bevorzugte Technologien. Für konkrete IT Projekte wird i.d.R. dieses Portfolio als Basis genutzt, um eine bedarfsgerechte aber standardbasierte Architektur für das jeweilige Vorhaben zu definiere. Das Spektrum reicht dabei von umfassenden Architektur-Frameworks, über Pattern und Standardwarenkörbe bis hin zu einfachen Richtlinien auf Entwicklungsebene.
Eine zentrale Eigenschaft der ISA Modul Architektur ist es – sich nahtlos in jede bestehende Architektur einzufügen – ohne diese zu verändern oder zu etwas zu zwingen. ISA gelingt das, weil das Konzept “Modul” zum einen so universell ist, dass es nicht in Konflikt zu anderen Konzepten steht. Zum anderen weil das Modulkonzept gerade durch seinen hohen Allgemeinheitsgrad alle notwendigen Architekturfragen auch aus sich selbst heraus beantworten kann.
Auf diese Weise ist die ISA Modul Architektur sowohl eine vollständige “out of the box” Enterprise Architektur für Projekte auf der “grünen Wiese” – als auch ein architektonischer Bausteinkasten, dessen Elemente einzeln verwendet und kombiniert werden können – ohne bestehende Umgebungen verändern zu müssen.
Die folgende Tabelle zeigt grundlegende Fragestellungen, die in der Systementwicklung architektonisch beantwortet werden sollten – und welche universellen Antworten das ISA Modulkonzept darauf liefert.
Architekturfragen | ohne ISA | mit ISA | ISA Antwort |
Welche CS bzw. RPC Technologien werden benötigt | ![]() |
![]() |
Alle sind automatisch verfügbar |
Welche Programmiertechnologien werden benötigt | ![]() |
![]() |
Standard Java |
Wie sieht die grundlegende Projektstruktur aus | ![]() |
![]() |
Standard Java Projekt pro Modul |
Wie sieht die SCM Struktur und Strategie aus | ![]() |
![]() |
Modulversionen |
Wie ist der Build Prozess gestaltet | ![]() |
90% | Standardskript pro Modul |
Wie ist der Develop – Debug Zyklus gestaltet | ![]() |
![]() |
Standard Java |
Wie ist der Test Prozess | ![]() |
50% | Unittest pro Modul |
Wie sieht die Softwareverteilung und der Betrieb aus | ![]() |
![]() |
Module im zentralen Repository |
Wie sieht die Bibliotheksstruktur aus | ![]() |
![]() |
ein Modul ist eine Bibliothek |
Wie werden Klassen auf Bibliotheken verteilt | ![]() |
![]() |
Modulklassen in Modulbibliothek |
Wie werden Fremdbibliotheken eingebunden | ![]() |
![]() |
als eigenes Modul oder als Modullibrary |
Wie werden Abhängigkeiten gehandhabt | ![]() |
![]() |
automatisch zur Laufzeit |
Was wird wie versioniert | ![]() |
![]() |
Module mit [ma].[mi].[re] |
Wie ist das grundlegende Anwendungsdesign | ![]() |
![]() |
modular |
Was wird wie spezifiziert | ![]() |
![]() |
Module, ihre Anforderungen und Abhängigkeiten (siehe Modulspezifikation) |
Welche Schichten gibt es | ![]() |
![]() |
keine |
Was sind die Gegenstände der Entwicklung | ![]() |
![]() |
Module |
Welche Basisabstraktionen gibt es | ![]() |
![]() |
Modul bzw. Modulservice 3 |
Welche Integrationsschnittstellen gibt es | ![]() |
![]() |
Modul bzw. Modulservice |
Wo werden Querschnittsfunktionalitäten realisiert | ![]() |
![]() |
in Modulen |
Wie werden fachliche Anforderungen abgebildet | ![]() |
![]() |
in Modulen oder Regeln |
Wie werden technische Anforderungen abgebildet | ![]() |
![]() |
in Modulen |
Was sind die Gegenstände des Projektmanagements | ![]() |
![]() |
Module und deren Anforderungen |
Was ist ein Changerequest | ![]() |
![]() |
Eine neue oder geänderte Anforderung und eine neue Modulversion |
Wie sieht das Releasemanagement aus | ![]() |
![]() |
Konfiguration der benötigten Module |
Was ist ein Releasewechsel | ![]() |
![]() |
Inbetriebnahme der entsprechenden Konfiguration |
bedeutet, dass die Fragestellung beantwortet ist.
steht dafür, dass die Fragestellung einer individuellen Klärung und Beantwortung bedarf, wobei sie i.d.R. im Zusammenhang mit anderen Fragestellungen steht, die sich so in ihrer Konkretisierung individuell beeinflussen.
% Zahl bedeutet, dass die Fragestellung zum Teil beantwortet ist aber noch individueller Ergänzungen bedarf.