2.6.2 Vergleich Software Architektur mit einem Unternehmen

Mit dem Wachstum der Mitarbeiteranzahl (und aus anderen Gruenden), oder neuen Projekten organisert ein Unternehmen ihre Abteilungen neu. Man kann diese Umorganisation auch als Refactoring bezeichnen.

Das Ziel der Umorganisation:

• Kleine uebersichtliche Einheiten, um Probleme schneller zu erkennen.
• Kommunikation vereinfachen da
• Mitarbeiter die eng miteinander zusammenarbeiten, in einer Abteilung sind.
• Mitarbeiter die eng zusammenarbeiten, in der Nähe sitzen
• Besprechungen sind im kleineren Kreis, damit kürzer und zielgerichteter.
• Redundante Dienste auslagern
• Es gibt Dienste, die alle (produktiven)Abteilungen brauchen, diese sind in einer eigenen Abteilung (Verwaltung) zusammengefasst. Die Verwaltung ist ein Dienstleiter fuer alle anderen Abteilungen. Jede Abteilung seine eigenen Systemadministratoren bzw. jede Abteilung sein eigenes Personalbüro wäre redundant
• Die Verwaltung sollte sowenig möglich Wissen der Abteilungen benötigen, damit sie sich auf Ihre eigentlichen Aufgaben konzentrieren können. Die Mitarbeiter der einzelnen Abteilungen sollten sowenig Verwaltungsaufwand wie moeglich haben.(z.B nicht gleichzeitig Stunden in Excel und SAP bzw. Navision eintragen).
• Die einzelnen (produktiven) Abteilungen, sind i.a. nicht voneinander abhaengig, und können eigenständig arbeiten. (Dies stimmt nicht ganz, da Mitarbeiter an andere Abteilungen ausgeliehen werden. (Kappa-Show). Objekte und Mitarbeiter lassen sich zum Glück nicht ganz vergleichen).
• Sind die Abteilungen voneinander unabhaengig, so kann der Unternehmer einzelne Abteilungen auslagern. (Ich hoffe dem Unternehmer ist dabei bewusst, dass er es mit Menschen und nicht mit Objekten zu tun hat)
• Wichtig: Da sich der Markt dauernd ändert, sind immer wieder Umorganisationen notwendig.

Software Architekten machen i.a. genau dasselbe:

• Objekte die eng miteinander zusammenarbeiten werden in gemeinsame Abteilungen (Paketen) gehalten.
• Redundante Aufgaben von mehreren Abteilungen werden herausgenommen, und von allen Abteilungen genutzt.
• Wird eine einzelne Abteilung (Paket) zu gross, so dass sie nicht mehr von einer Person überschaut werden kann, versucht man das Paket in kleinere Paketen aufzuteilen.
• Abhaengigkeiten zwischen den Paketen werden minimiert. Besonders gegenseitige Abhaengigkeiten werden vermieden. (Verwaltung ist Dienstleister fuer die produktiven Abteilungen und nicht umgekehrt).
• Da die Pakete weitgehend voneinander unabhängig sind, sind bei neuen A nforderungen nur wenige Pakete davon betroffen. (Wenn ein Unternehmen eine neue Abteilung aufmacht; sollten nur die Mitarbeiter der neuen Abteilung sowie vielleicht noch die Verwaltung davon betroffen sein).
• Da die Pakete voneinander weitgehend unabhaengig sind, ist es einfach diese z.B vom Clienten zum Server zu verschieben (oder umgekehrt).

Bermerkungen dazu:

• So wie ein Unternehmer auf die Kommunikationsfluesse in seinem Unternehmen achtet, achtet der Software-Architekt auf die Kommunikationsfluesse zwischen den Objekten. Hohe Kommunikation ist wünschenswert, aber sie muss strukturiert und zielgerichtet sein.
• Ein Unternehmer versucht Redundanzen zu vermeiden, da jeder Mitarbeiter Geld kostet. Dem Programmierer ist leider oft nicht bewusst, dass redundanter Code Geld kostet. Der Programmierer fügt bei Bedarf eben einfach neue Objekte hinzu, und schaut nicht ob schon an anderere Stelle eine Loesung existiert. Würde ein Unternehmer so handeln, dann hätte z.B. jede Abteilung sein eigenes Personalbüro. Eine Abteilung würde seine Stunden in SAP, die andere in Navision, und wieder eine andere mit beiden Systemen ihre Stunden verwalten. (Und irgendein armes Schwein muss die Ergebnisse aus allen Systemen zusammenfassen).