Enterprise-Architektur: Capabilities und das TIME-Modell

Problem

Drei Systeme für Rechnungen und keins für Retouren

Der Shop wächst seit fünf Jahren. Bei jeder Bestellung stellt der Shop selbst eine Rechnung aus. Die Buchhaltung kauft ein eigenes System und stellt Rechnungen für Firmenkunden aus. Dann zahlt das Marketing für die Abos einen Rechnungs-SaaS, weil es „schneller ging“.

Die Finanzchefin fragt, warum die Rechnungen drei Nummerierungen haben. Währenddessen führt der Kundenservice die Retouren in E-Mails und einer Tabelle, und der Buchhalter kopiert jede Retoure von Hand.

Jedes Team kennt sein eigenes System. Niemand sieht das Ganze.

Die Idee

Was das Business tut, nicht welche Systeme es hat

Die Enterprise-Architektur schaut auf die ganze Firma: alle Systeme, wie sie zusammenhängen und wofür sie da sind. Sie beginnt nicht bei den Systemen, sondern bei den Capabilities: was das Business tut. Es verkauft, stellt Rechnungen, liefert, nimmt Retouren an. Das ändert sich selten. Systeme, Abteilungen und Lieferanten werden ersetzt, und der Shop stellt auch zehn Jahre später noch Rechnungen.

Eine Capability-Map ordnet sie in Gruppen, meist auf einer Seite:

MAP = {
    "Vertrieb": ["Katalog", "Warenkorb", "Bestellungen"],
    "Finanzen": ["Zahlungen", "Rechnungsstellung", "Buchhaltung"],
    "Logistik": ["Lager", "Lieferung", "Retouren"],
    "Kunden": ["Benachrichtigungen", "Support"],
}

APPS = {
    "Shop": ["Katalog", "Warenkorb", "Bestellungen", "Rechnungsstellung"],
    "Lager 2009": ["Lager"],
    "Buchhaltungssystem": ["Buchhaltung", "Rechnungsstellung"],
    "Rechnungs-SaaS": ["Rechnungsstellung"],
    "Zahlungsanbieter": ["Zahlungen"],
    "Kurier": ["Lieferung"],
    "E-Mail-Dienst": ["Benachrichtigungen"],
    "Helpdesk": ["Support"],
}

Unter die Map hängst du die Anwendungen: für jede Capability, welche Systeme sie unterstützen. Dann zeigen sich zwei Dinge, die sonst unsichtbar sind:

eine Lücke: eine Capability ohne System; die Leute machen es von Hand;
eine Doppelung: eine Capability mit mehreren Systemen; du zahlst mehrfach und hast mehrere Versionen der Wahrheit.

Sieh es dir an

Die Map, eingefärbt nach Abdeckung

# die Systeme, die die Capability unterstützen
def apps_for(cap, apps):
    return [name for name, caps in apps.items()
            if cap in caps]


def coverage(names):
    if not names:
        return "✗ kein System"
    if len(names) == 1:
        return names[0]
    joined = ", ".join(names)
    return f"⚠ {len(names)} Systeme: {joined}"

Schritt für Schritt, in Worten

Die Capability-Map: was das Business tut, in Gruppen. Noch ohne ein einziges System.
Die 8 Anwendungen kommen eine nach der anderen. Jede sagt, welche Capabilities sie unterstützt, und die Zähler wachsen.
Eine Capability mit genau einem System ist abgedeckt: grün.
Rechnungsstellung: 3 Systeme erledigen es. Drei Lizenzen, drei Rechnungsnummerierungen, drei Stellen für jede Korrektur.
Retouren: überhaupt kein System. Die Leute führen sie in E-Mails und Tabellen.
Die Map, eingefärbt nach Abdeckung: 1 Lücke und 1 Doppelung. Von hier aus beginnt der Zielzustand.

# die Systeme, die die Capability unterstützen
def apps_for(cap, apps):
    return [name for name, caps in apps.items()
            if cap in caps]


def coverage(names):
    if not names:
        return "✗ kein System"
    if len(names) == 1:
        return names[0]
    joined = ", ".join(names)
    return f"⚠ {len(names)} Systeme: {joined}"


def print_map(cap_map, apps):
    gaps = duplicated = 0
    for group, capabilities in cap_map.items():
        print(group)
        for capability in capabilities:
            names = apps_for(capability, apps)
            gaps += len(names) == 0
            duplicated += len(names) > 1
            print(f"  {capability}: {coverage(names)}")
    print(f"Lücken: {gaps}, dupliziert: {duplicated}")

print_map(MAP, APPS)

Vertrieb
  Katalog: Shop
  Warenkorb: Shop
  Bestellungen: Shop
Finanzen
  Zahlungen: Zahlungsanbieter
  Rechnungsstellung: ⚠ 3 Systeme: Shop, Buchhaltungssystem, Rechnungs-SaaS
  Buchhaltung: Buchhaltungssystem
Logistik
  Lager: Lager 2009
  Lieferung: Kurier
  Retouren: ✗ kein System
Kunden
  Benachrichtigungen: E-Mail-Dienst
  Support: Helpdesk
Lücken: 1, dupliziert: 1

Die Map und die Anwendungen sind Dicts: Ein dict behält die Reihenfolge des Einfügens, darum kommen die Gruppen und Systeme in der Reihenfolge heraus, in der sie geschrieben wurden.

Das Programm ist klein, aber die eigentliche Arbeit steckt in den Daten: was als eigene Capability zählt und was jedes System wirklich tut. Das erfährst du im Gespräch mit den Teams, nicht mit Code.

Probier es aus

Ergänze

Wie prüfst du, ob die Anwendung die Capability unterstützt?

[name for name, caps in apps.items() if cap  caps]

Die Idee

Anwendungsportfolio: TIME

Die Map zeigt, wo das Problem liegt. Das Anwendungsportfolio sagt, was du mit jedem System tun sollst. Für jedes hältst du fest, was es pro Jahr kostet, und zwei Bewertungen von 1 bis 5:

Wert für das Business: wie sehr das Business es braucht;
technischer Zustand: wie gesund es innen ist (wird es gepflegt, gibt es Leute, die es kennen, wie oft fällt es aus).

Aus den zwei Bewertungen ergeben sich vier Entscheidungen, bekannt als das TIME-Modell (Gartner):

	technisch gesund	technisch krank
wertvoll für das Business	Invest	Migrate
von geringem Wert	Tolerate	Eliminate

@dataclass
class Rating:
    app: str
    cost_per_year: int  # €
    business: int  # 1..5
    technical: int  # 1..5

# TIME: Ist es dem Business viel wert, und ist es innen gesund
def decide(r):
    valuable = r.business >= 3
    healthy = r.technical >= 3
    if valuable and healthy:
        return "investieren"
    if valuable:
        return "migrieren"
    if healthy:
        return "tolerieren"
    return "abschaffen"

Die Preise unten sind Beispiele, und die Bewertungen stammen vom Team.

ratings = [
    Rating("Shop", 60000, 5, 3),
    Rating("Lager 2009", 18000, 4, 1),
    Rating("Buchhaltungssystem", 24000, 4, 4),
    Rating("Rechnungs-SaaS", 9600, 2, 2),
    Rating("Helpdesk", 4800, 2, 4),
]
total = saved = 0
for r in ratings:
    decision = decide(r)
    print(f"{r.app}: {decision} (Business {r.business}, Technik {r.technical})")
    total += r.cost_per_year
    if decision == "abschaffen":
        saved += r.cost_per_year
print(f"Pro Jahr: {total} €, du streichst {saved} €")

Shop: investieren (Business 5, Technik 3)
Lager 2009: migrieren (Business 4, Technik 1)
Buchhaltungssystem: investieren (Business 4, Technik 4)
Rechnungs-SaaS: abschaffen (Business 2, Technik 2)
Helpdesk: tolerieren (Business 2, Technik 4)
Pro Jahr: 116400 €, du streichst 9600 €

TIME ist kein Urteil, sondern der Anfang eines Gesprächs. „Tolerate“ heißt „gib dafür nichts aus“, nicht „vergiss es“: Der Helpdesk läuft und steht nicht im Weg. „Eliminate“ braucht ein Datum und einen Plan, sonst lebt die Anwendung noch fünf Jahre weiter.

Probier es aus

Sage die Ausgabe voraus

Die mobile App bringt die Hälfte der Bestellungen (Business 4), ist aber auf einem Framework geschrieben, das nicht mehr gepflegt wird (Technik 2). Was sagt decide?

print(decide(Rating("Mobile App", 30000, 4, 2)))

Antwort

migrieren

investieren

tolerieren

Probier es aus

Finde den Fehler

Ein Kollege hat decide mit Copy-and-paste geschrieben. Jetzt sagt das Portfolio:

Shop: investieren (Business 5, Technik 3)
Lager 2009: investieren (Business 4, Technik 1)
Buchhaltungssystem: investieren (Business 4, Technik 4)
Rechnungs-SaaS: abschaffen (Business 2, Technik 2)
Helpdesk: abschaffen (Business 2, Technik 4)
Pro Jahr: 116400 €, du streichst 14400 €

Das Lager 2009 soll plötzlich Investitionen bekommen, und der Helpdesk soll abgeschafft werden. In welcher Zeile steckt der Fehler?

Wähle die Zeile mit dem Fehler.

Die Idee

Zielzustand und Roadmap

Die Map und das Portfolio ergeben den Zielzustand: wie die Landschaft in ein, zwei Jahren aussehen soll. Für den Shop:

Rechnungen gibt es nur im Buchhaltungssystem, mit einer Nummerierung; der Rechnungs-SaaS wird abgeschafft (eliminate), und das Rechnungsmodul im Shop wird abgeschaltet;
das Lager wird durch ein neues ersetzt (migrate), das auch Retouren unterstützt: Die Lücke wird dort geschlossen, wo die Ware liegt;
alles andere bleibt.

Die Roadmap ist die Reihenfolge der Schritte dorthin, mit Zwischenzuständen, die funktionieren:

Das neue Lager übernimmt die Retouren, und das alte bleibt für die Ware; die Anbindung an das Lager 2009 läuft über einen Anti-corruption Layer, damit sein CSV nicht in den neuen Code durchsickert;
die Ware zieht schrittweise ins neue Lager um, wie in „Ein laufendes System verändern (Strangler Fig, Expand–Contract)“, bis das Lager 2009 keinen Verkehr mehr hat;
die Rechnungen des Shops wandern ins Buchhaltungssystem; die Nummerierung wechselt zum neuen Jahr, damit es für die Buchhalter klar ist;
das SaaS-Abo wird nach der letzten Rechnung darin gekündigt.

Jeder Schritt ist eine eigene Entscheidung mit einem ADR, eigenen Kosten und eigenen Risiken im Register. Die Reihenfolge richtet sich nach Schmerz und Abhängigkeiten: Die Retouren kommen zuerst, weil dort heute Geld verloren geht.

Genauer, für Neugierige

Die Frameworks. TOGAF ist das bekannteste Framework für Enterprise-Architektur: Es beschreibt eine Methode (ADM) für diese Schritte und viele Dokumente. ArchiMate ist eine Sprache für Diagramme der Landschaft, und Zachman ist eine Tabelle zum Einordnen der Beschreibungen. Hier nennen wir sie nur: Der Kurs lehrt die Arbeit, und eine Zertifizierung ist ein eigener Weg.

Capability, Prozess und Abteilung. Eine Capability ist das „Was“ (Rechnungen stellen). Ein Prozess ist das „Wie“, in Schritten (Bestellung → Rechnung → Zahlung). Eine Abteilung ist das „Wer“. Die Map besteht aus Capabilities, weil sie sich am wenigsten ändern.

Die Werkzeuge. Große Firmen führen das Portfolio in eigenen EA-Werkzeugen oder in einer CMDB. Eine kleine Firma führt es in einer Tabelle. Wichtig ist, dass es ein einziger Ort ist und aktuell gehalten wird.

Die Idee

Wann es hilft und wann es Bürokratie ist

Enterprise-Architektur hilft, wenn:

es Dutzende Systeme gibt und niemand sie alle im Kopf hat;
die Firma mit einer anderen fusioniert und entscheiden muss, welches System bleibt;
die Ausgaben für Software wachsen und niemand weiß, wofür sie gezahlt werden;
eine Aufsichtsbehörde fragt, wo die Kundendaten liegen.

Sie schadet, wenn:

die Map das Ziel ist. Gezeichnet, gedruckt und vergessen. Eine Map, mit der nie eine Entscheidung getroffen wurde, ist Dekoration.
ein Gremium jede Bibliothek freigibt. Entscheidungen, die ein Team allein zurücknehmen kann, bleiben beim Team. Zentral wird nur entschieden, was für die ganze Firma teuer ist: gemeinsame Identität, Zahlungen, Kundendaten.
die Firma klein ist. Drei Systeme und ein Team brauchen kein Framework: Eine Tabelle auf einer Seite und ADRs reichen.
das Framework das Gespräch ersetzt. Die Dokumente des Frameworks sind nicht die Arbeit. Die Arbeit ist die Entscheidung, die daraus entsteht.

Übung

Der Zielzustand

Löse diese Aufgabe in deinem Editor.

Schreibe den Zielzustand als neue Liste von Anwendungen: Der Shop stellt keine Rechnungen mehr aus, der Rechnungs-SaaS ist weg, und das Lager 2009 ist durch ein „Neues Lager“ ersetzt, das das Lager und die Retouren unterstützt. Lass dieselbe Abdeckungsprüfung darüber laufen:

Vertrieb
  Katalog: Shop
  Warenkorb: Shop
  Bestellungen: Shop
Finanzen
  Zahlungen: Zahlungsanbieter
  Rechnungsstellung: Buchhaltungssystem
  Buchhaltung: Buchhaltungssystem
Logistik
  Lager: Neues Lager
  Lieferung: Kurier
  Retouren: Neues Lager
Kunden
  Benachrichtigungen: E-Mail-Dienst
  Support: Helpdesk
Lücken: 0, dupliziert: 0

Weitere Übungen

Eine Fitness Function für die Landschaft. Mach aus der Prüfung einen Test, der fehlschlägt, wenn es eine Lücke oder eine Doppelung ohne festgehaltene Entscheidung gibt (eine Liste erlaubter Doppelungen mit ihren Gründen).
Die Kosten der Doppelung. Füge die Kosten jeder Anwendung hinzu und gib aus, wie viel alle Systeme der doppelten Capabilities pro Jahr kosten.
Zwei Länder. Der Shop startet in Griechenland mit einem lokalen Kurier. Sind zwei Liefersysteme ein Verstoß? Wie zeigst du es auf der Map?

Test

Teste dich

1. Was ist eine Capability?Ein System im PortfolioEtwas, das das Business tut, zum Beispiel „Rechnungen stellen“, egal welches System oder welche Abteilung es erledigtEine Abteilung im Organigramm

2. Eine Capability, die drei Systeme unterstützen, ist…gut abgedeckt, das ist sicherereine Doppelung: dreifache Kosten und drei Versionen der Wahrheiteine Lücke

3. Das Lager 2009 ist für das Business wichtig (4), aber technisch in schlechter Verfassung (1). Was sagt TIME?Migrate: Die Funktion wird gebraucht, aber in einem neuen SystemTolerateEliminate

4. Wann ist eine Capability-Map Bürokratie?Wenn sie in ArchiMate gezeichnet istWenn sie Selbstzweck ist: gezeichnet, niemand trifft damit eine Entscheidung, und sie wird nie aktualisiertImmer, wenn die Firma mehr als zehn Systeme hat

Die Unternehmenslandschaft und ihre Capabilities

Cookies