Projekte – atra.consulting –

Übernahme SCS Consulting GmbH

Michael Schwarze — Fri, 16 Apr 2021 10:19:44 +0000

Die Schwarze Consulting GmbH, Nürnberg übernimmt im Zuge einer Nachfolgeregelung die SCS Consulting GmbH, Stuttgart.

Nach über 10 erfolgreichen Jahren in der Beratung rund um Softwareentwicklung insb. im Umfeld Handel, Online/E-Commerce erweitert die Schwarze Consulting GmbH aus Nürnberg ihre Branchenexpertise mit Übernahme der SCS Consulting GmbH aus Stuttgart um die Bereiche Finanzdienstleistungen und Behörden. Gleichzeitig kann so die regionale Präsenz der Unternehmensgruppe auf die dann fünf Standorte Nürnberg, Stuttgart, München, Hamburg und Berlin ausgeweitet werden.

Zur Schwarze Consulting GmbH

Seit 2009 unterstützt das Unternehmen namhafte Kunden bei Fragestellungen rund um Softwareentwicklung und das Management von Softwareentwicklungsvorhaben, insb. im innovativen E-Commerce-Umfeld. Die Unternehmens-DNA ist ganzheitliches Software Engineering, also die Entwicklung von langlebigen und wartbaren Softwaresystemen. Dies umfasst Softwarearchitektur- und Technologieberatung, Organisationsberatung von Softwareentwicklungseinheiten zu Struktur- und Prozessfragen sowie Interimsmanagement im Technologieumfeld.

Michael Schwarze, geschäftsführender Gesellschafter der Schwarze Consulting GmbH:

»Ich freue mich sehr, nach 10 erfolgreichen Jahren organischem Wachstums mit der Übernahme der SCS Consulting GmbH nun das berühmte nächste Kapitel der Unternehmensentwicklung einläuten zu können. Die beiden Unternehmen ergänzen sich hervorragend hinsichtlich ihres Leistungsspektrums und der Branchenexpertise, aber auch bezogen auf ihre Unternehmensphilosophie. So können wir unsere Kunden zukünftig noch umfassender bei ihren IT-bezogenen Fragestellungen unterstützen. Gleichzeitig erreichen wir damit eine Größe, die es uns erlaubt, nicht mehr nur als Sperrspitze für innovative Themen, sondern als umfassender Lösungspartner für unsere Kunden auftreten zu können. Mein herzlicher Dank geht an Herrn und Frau Zink, die ein hervorragend aufgestelltes Unternehmen übergeben. Ich freue mich darauf, mit großartigen Mitarbeiterinnen und Mitarbeitern unsere treuen Kunden weiterhin nachhaltig unterstützen zu dürfen.«

Zur SCS Consulting GmbH

Gegründet 2004 unterstützt das Unternehmen renommierte Kunden aus den Bereichen Finanzdienstleistungen und Behörden im IT- und Business-Consulting. Dies umfasst diverse Managementservices von der Managementberatung bis zum Coaching, sowie die Konzeption und Entwicklung von komplexen IT-Services in einem weiten Technologieumfeld.

Klaus-Ulrich Zink, geschäftsführender Gesellschafter der SCS Consulting GmbH:

»Nach dreieinhalb Jahrzehnten IT-Consulting freuen wir uns, mit Herrn Schwarze und seiner Schwarze Consulting GmbH eine optimale Lösung für unsere Nachfolgeregelung gefunden zu haben. Meiner Frau und mir, als Gründer und Gesellschafter der SCS Consulting GmbH, war es wichtig, für unsere Mitarbeiter:innen sowie Geschäftspartner einen Nachfolger zu finden, der die gewohnte Kontinuität bietet und dabei aber auch den Generationenwechsel ermöglicht. Mit Herrn Schwarze und seiner Schwarze Consulting GmbH ist dies gewährleistet, denn es übernimmt ein erfolgreicher Unternehmer, der über umfangreiche Erfahrung in der Softwareentwicklung, Beratung und dem Management verfügt. Gleichzeitig passt bei ihm aber auch die »Chemie«, so dass wir das Unternehmen, die Kunden und Mitarbeiter:innen in den besten Händen wissen. Wir bedanken uns herzlich bei allen, die uns bis hierhin begleitet haben und wünschen das Beste für die Zukunft.«

Pressemitteilung herunterladen

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet. Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting

Conways Law in Aktion

Michael Schwarze — Thu, 31 Mar 2016 10:36:50 +0000

Abhängigkeiten, egal ob technischer oder organisatorischer Art, sind in der Softwareentwicklung problematisch. Größere, klassisch vorgehende Softwareentwicklungsorganisationen schaffen nach unserer Erfahrung bspw. regelmäßig nur 2-4 Releases pro Jahr, da die Organisation zu komplex und die Abhängigkeiten zu hoch sind. Durch die Harmonisierung von Aufbauorganisation und Systemarchitektur in Anlehnung an Conways Law lassen sich die Abhängigkeiten in der Softwareentwicklung um bis zu 80 % reduzieren, wie wir nachfolgend aufzeigen.

Conways Law, welches bereits seit 1967 (!) intensiv diskutiert und viel zitiert worden ist, besagt, dass Systeme die Organisationsstrukturen der Einheiten reflektieren, in denen sie entstehen:

»Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.«

Oder anders formuliert, man bekommt nicht zwangsläufig die Systeme, die am Whiteboard, Flipchart oder in UML designed wurden, sondern Systeme, die aussehen, wie das Organigram der sie umgebenden Organisation. Da Systeme und Organisationen i.d.R. anderen Änderungszyklen unterliegen und die jeweiligen Änderungen anders motiviert sind, laufen System- und Organisationsgrenzen irgendwann zwangsläufig auseinander:

Dies führt zu erheblichen Schwierigkeiten in Entwicklung und Betrieb entsprechender Software-Systeme, da sich die Verantwortung für ein System dann schnell über mehrere Organisationseinheiten hinweg erstreckt, was zu Abhängigkeiten, unklaren Verantwortlichkeiten, erhöhtem Abstimmungsbedarf, usw. führt.

Interessant ist zu sehen, was passiert, wenn man auseinander gelaufene System- und Organisationsgrenzen wieder in Einklang bringt, wie wir im folgenden Artikel an einem unserer Projekte in anonymisierter Form aufzeigen.

Hintergrund

Im konkreten Fall sollte der IT-Bereich eines Online-Unternehmens reorganisiert werden, da aufgrund des starken Wachstums der Firma, dieser den anstehenden Aufgaben nicht mehr gewachsen war. Das Unternehmen war einer klassisch-funktionalen Aufbauorganisation folgend strukturiert. Das nachfolgend vereinfacht dargestellte Organigram erschien auf den ersten Blick unauffällig:

Unsere der sog. [Theorie Z][4] folgende Analyse ergab u.a., dass die Mitarbeiter in der dortigen IT in einer eher technologischen Aufbauorganisation, welche nicht im Einklang mit der fachlichen, projektseitigen oder auch betrieblichen Realität stand, eine historisch gewachsene, [komplexe und komplizierte][5], monolitische Architektur mit einer Vielzahl an Technologien / Systemen und hohen technischen Schulden entwickelten und betrieben.

Selbst kleine Anpassungen führten zu hohen Aufwänden und regelmäßigem Überschreiten der vereinbarten Termin- und Budgetzusagen, da alles mit allem zusammenhing und eine Änderung an einer Stelle immer auch Anpassungen an einer Vielzahl von anderen Stellen bedeutete. Das Gesamtsystem war kaum noch beherrschbar.

Eine erste, qualitative Untersuchung der Makro-Architektur, insb. im Hinblick auf die wesentlichen Architektursichten brachte die in folgender schematischer Darstellung zusammengefassten Erkenntnisse:

Wie häufig war über die Architektursichten hinweg kein einheitlicher Systemschnitt zu finden. Die fachliche Anforderungssicht war bisher nur wenig ausgeprägt und folgte bspw. nicht der User bzw. Customer Journey eines Kunden im Portal. Die einzelnen Softwaresysteme waren »historisch gewachsen«, dabei aber zunehmend ihrem initialen, technologischen Ordnungsmuster der 3-Schichten-Architektur entflohen (»Architekturerosion«). Wenig verwunderlich, da die Gliederung in Frontend, Backend, und Datenhaltung (Persistenz) von Systemen i.d.R. wenig mit der Sicht des Anwenders gemein hat. Die Infrastruktur wiederum folgte einem ganz anderen Muster und war auch organisatorisch stark vernachlässigt, wie weiter unten zu sehen ist. In Folge kaskadierte sich eine einzelne fachliche Änderung auf zahlreiche Anpassungen diverser Systeme, welche wiederum weitere Änderungen anderer Systeme nach sich zogen.

Wobei an dieser Stelle auch eine Lanze für die Software-Architekten gebrochen werden muss: die einheitliche Durchsetzung einer Architekturidee über mehrere Architektursichten hinweg ist nach wie vor eine erhebliche Herausforderung. Bis dato kann der Architekt überwiegend retrospektiv und eher Dokumenten-basiert, also über Konzept-, Spezifikations- und Code-Reviews/-Analysen feststellen, ob (s)eine Architekturidee eingehalten und entsprechend umgesetzt wurde. Architektur-DSLs (Domain-Specific Languages) stellen hier einen interessanten Ansatz dar, die Wahrheit steckt aber schlußendlich im Code. Der Architekt ist in der Rücklage gegenüber der Software-Entwicklung, insb. im agilen Umfeld; nachträgliche Umbauarbeiten an den Systemen, um selbige wieder ins architekturelle Modell zu bekommen, sind nur selten gegen den üblichen Marktdruck durchsetzbar. Das Label »historisch gewachsen« haben wir schon an vielen anderen von uns untersuchten Architekturen gefunden. Die geschickte Kombination moderner Ansätze (Microservices-Architekturstil, Domain-driven Design, …) und das Verlassen etablierter Software-Engineering-Paradigmen, wie z.B. der zentralen Datenhaltung, aber bspw. auch das bewusste Akzeptieren von Redundanz, etc. verspricht hier Besserung, wie wir auch in folgenden Artikeln noch aufzeigen werden.

Im konkreten Fall war die gesamtheitliche Betrachtung von Architektur und Organisation, Conways Law aber auch unserem Ansatz von [IT-Management-Beratung][12] folgend, der nächste Schritt:

Weder die Aufbauorganisation der Fachbereiche noch der IT ließen sich in der Architektur verorten. Darüber hinaus standen aber auch die Strukturen der Fachbereiche, also der internen Kunden der IT, in keiner Beziehung zur Organisation des IT-Bereichs. In Folge setzte sich die schon auf Architekturebene gezeigte Abhängigkeitskaskade in der Organisation fort und verstärkte sich entsprechend. Eine einzelne Änderung führte nicht nur zur notwendigen Anpassung einer Vielzahl von betroffenen, abhängigen Systemen, sondern involvierte auch eine Vielzahl von Ansprechpartnern und Teams. Die Organisation war im permanenten Eskalationsmodus.

Die quantitative Auswertung der historischen Änderungsaufträge eines Jahres bestätigte die qualitative Betrachtung: in 50% der Fälle kam es zum sog. »Übersprechen«. Jeder zweite Änderungsauftrag führte im vorliegenden System- und Teamzuschnitt also zu Abstimmungen mit anderen Teams und entsprechenden Anpassungen weiterer Systeme.

Lösungsansatz

Welches Ordnungskriterium sollte nun aber angesetzt werden, um die erodierende Architektur wieder mit der divergierenden Organisation in Einklang zu bringen? Da Softwareentwicklung zumindest in den meisten Fällen kein Selbstzweck ist, sondern dem Kunden/Anwender dienen sollte, fängt auch unser Lösungsansatz mit der Fachlichkeit, also der Anforderung, dem Use Case oder der User Story an. Da Anforderungen häufig »organisationspolitisch« gefärbt sind, also von Interessen der Einheiten, die sie gestellt haben, geleitet werden, gingen wir im konkreten Fall zunächst noch einen Schritt weiter »zurück« in der Anforderungskette zum Anwender im Portal.

Insbesondere im kundennahen Online-Umfeld mit geringer Standardisierung und Wiederverwendbarkeit bei hoher Individualsierung durch die notwendige Differenzierung sollte der Fokus auch entsprechend extern, also auf den Kunden gelegt werden. Im Umfeld von ERP-Standardsoftware-Entwicklung bspw. mag der Fokus auch entsprechend eher intern auf Kostenoptimierung (Stichwort: Kostenführerschaft) gelegt werden.

In einem ersten Schritt analysierten wir dementsprechend innerhalb der fachlichen Architektursicht die User bzw. Customer Journey und leiteten daraus unter Hinzuziehung weiterer, unternehmensinterner Aspekte ein fachliches Domänenmodell ab. Eric Evans Domain-Driven Design, auf welches wir in einem separaten Beitrag eingehen werden, war hierbei natürlich mit in unserem Handwerkskoffer.

Dem Domänenmodell ordneten wir in einem nächsten Schritt die entsprechenden Softwaresysteme zu und es entstand eine fachlich getriebene Zielarchitektur, welche den Bebauungsplan für die notwendigen Umbaumaßnahmen der Systemarchitektur darstellte:

Anschließend richteten wir die Teams ebenfalls gemäß dem Domänenmodell neu aus. Das Produktmanagement stellte je Domänenteam einen Product Owner, der im agilen Sinne die Verantwortung dafür übernahm, was umgesetzt wird. Das Entwicklungsteam der IT verantwortete die technische Umsetzung, also das »Wie« und übernahm in seiner Domäne gemäß Werner Vogels (CTO Amazon.com) Ansatz »You build it, you run it« auch die Betriebsverantwortung.

Somit waren alle drei Architektursichten organisatorisch und technisch autark in jeweils einem Domänen-Team vereint, das Produktmanagement kapselte die Fachlichkeit, IT-Organisation und Fachbereichsorganisation sowie Architektur waren wieder im Einklang:

Die resultierende Matrixorganisation war dem Umstand der zwei beteiligten Linien-Organisationseinheiten geschuldet und in der konkreten Projektsituation das organisatorisch maximal Mögliche. Produktentwicklung hat ebenso wie Softwareentwicklung unserer Einschätzung nach einen langfristigen Charakter und sollte dementsprechend idealerweise auch in einer entsprechend langfristig ausgerichteten Linien-Produktentwicklungsorganisation erfolgen; dies werden wir in einem separaten Beitrag noch näher beleuchten.

Die anschließende quantitative Analyse der historischen Änderungsaufträge gegen die neue Architektur und Organisation ergab, dass das »Übersprechen« nur noch in 5-10 % der Fälle auftrat; gegenüber der Ausgangssituation mit 50 % also eine Verbesserung um ~80 %!

Neben unserer Erfahrung aus zahlreichen weiteren [IT-Management-Beratungsprojekten][18], insb. auch ähnlich gelagerten Vorhaben wie bspw. hier, fußte das Vorgehen und der Erfolg in diesem Projekt im Wesentlichen auf den genannten, etablierten (Conways Law; 1967) und neueren (Domain-Driven Design; 2003) Ansätzen; ganz nach dem Motto »Standing on the shoulders of giants«.

[1]: https://www.melconway.com/Home/Conways_Law.html

[2]: https://www.google.com/trends/explore#q=Conways%20Law

[3]: https://martinfowler.com/bliki/PolyglotPersistence.html

[4]: https://dev.atra.consulting/blog/theorie-z/

[5]: https://dev.atra.consulting/blog/wann-agil-und-wann-klassisch/

[6]: https://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2011/Architekturen/tilkov_ghadir_OS_Architekturen_11.pdf

[7]: https://www.computer.org/csdl/proceedings/icse/2003/1877/00/18770740.pdf

[8]: https://de.wikipedia.org/wiki/Schichtenarchitektur

[9]: https://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/analyseentwurf/articles/98362/

[10]: https://www.sigs-datacom.de/fachzeitschriften/javaspektrum/archiv/artikelansicht/artikel-titel/liebe-deine-architektur-architekturmodellierung-und-automatisierte-ueberpruefung.html

[11]: Domain Driven Design

[12]: Über uns