Das Problem mit der Architekturqualität
Upcoming SlideShare
Loading in...5
×
 

Das Problem mit der Architekturqualität

on

  • 661 views

Kosten stehen über Qualität, billig sticht gut. Aber ist die schnelle billige Lösung automatisch die beste Wahl? Projektleiter und Architekten geraten aufgrund ihrer unterschiedlichen Aufgaben und ...

Kosten stehen über Qualität, billig sticht gut. Aber ist die schnelle billige Lösung automatisch die beste Wahl? Projektleiter und Architekten geraten aufgrund ihrer unterschiedlichen Aufgaben und Ziele oft in ein Spannungsfeld: Investitionen sind in der IT meist projektgetrieben, die Systemqualität leidet darunter. Dieser Artikel beschreibt, wie man dieses Spannungsfeld ausbalancieren und so höhere und langfristigere Architekturqualität erreichen kann.

Statistics

Views

Total Views
661
Views on SlideShare
661
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Das Problem mit der Architekturqualität Das Problem mit der Architekturqualität Document Transcript

    • www.bt-magazin.de 1.2012 Heft 8 expertenwissen für it-Architekten, Projektleiter und berater QualitätSonderdruck fürwww.codecentric.de Mythos Qualitätsmanagement Höhere Qualität, bessere Software „Funktioniert“ ist nicht genugwww.bt-magazin.de bt | 1.2012 1 © Software & Support Media GmbH
    • ArchitekturqualitätWie man durch einseitige Prioritäten viel Geld verschenktDas Problem mit derArchitekturqualitätKosten stehen über Qualität, billig sticht gut. Aber ist die schnelle billige Lösung automatischdie beste Wahl? Projektleiter und Architekten geraten aufgrund ihrer unterschiedlichen Aufga-ben und Ziele oft in ein Spannungsfeld: Investitionen sind in der IT meist projektgetrieben, dieSystemqualität leidet darunter. Dieser Artikel beschreibt, wie man dieses Spannungsfeld aus-balancieren und so höhere und langfristigere Architekturqualität erreichen kann.Autor: Uwe Friedrichsen Releasetermin ist in sichtbarer Nähe. Noch sieht alles ganz gut aus, aber viel Puffer ist nicht mehr vorhanden.Vielleicht kennen Sie die Situation: Sie sind Architekt Da stellt sich plötzlich heraus, dass das anstehende Fea-in einem Projekt und es steht eine wichtige Architektu- ture aufgrund eines dringenden Change Requests dochrentscheidung an. Sie empfehlen eine Lösung, die die anders umgesetzt werden muss als ursprünglich geplant.benötigten Qualitäten sinnvoll ausbalanciert, aber der Was tun?Projektleiter interessiert sich nur für die Kosten und Der Projektarchitekt überlegt kurz und sagt dann:wählt die billigste Lösung. Oder Sie sind Projektleiter „Um das halbwegs sauber und verständlich hinzube-eines Projekts, das Änderungen an bestehenden Syste- kommen, müssten wir einen neuen Service implemen-men erfordert. Eigentlich scheint die Aufgabe einfach, tieren und folgendermaßen einbinden …“ Er skizziertaber die Entwickler stolpern von einem Problem ins seine Idee am Whiteboard. Der Projektleiter antwor-nächste und bekommen die Lösung nicht stabil, wäh- tet: „Sieht schön aus. Aber wie viel Aufwand ist das?“rend der Releasetermin unerbittlich näher rückt. Oder Der Architekt und der Chefentwickler überlegen einenSie sind IT-Manager und haben das Gefühl, dass die Moment gemeinsam und nennen dem Projektleiter ei-Kosten für die Pflege Ihrer Systeme spätestens nach nen Aufwand. Der stöhnt auf: „Dann können wir dender dritten Erweiterung explodieren. Wenn Ihnen eine Termin vergessen! Geht das nicht auch einfacher?“ Derdieser Situationen bekannt vorkommt, dann sollten Sie Architekt schüttelt den Kopf: „Nicht, wenn wir eineweiterlesen. halbwegs wartbare Lösung haben wollen.“ Darauf der Projektleiter: „Nichts für ungut, aber ‚wartbar‘ interes-Die Wurzel des Übels siert mich im Augenblick nicht. Wir haben einen TerminLetzten Endes haben die hier geschilderten Probleme zu halten!“. Da meldet sich ein ambitionierter Jungent-häufig die gleiche Ursache. Zum besseren Verständnis wickler: „Ich hätte da eine Idee. Wir könnten doch denbeginnen wir am besten mit einem kleinen Beispiel: Das bestehenden Service hier nehmen, da noch ein Flag ein-Projekt läuft auf Hochtouren, etwa zwei Drittel der ge- fügen, hier und hier ein paar Verzweigungen ergänzenplanten Funktionalität sind bereits umgesetzt, und der und das Datenbankfeld hier in dem Fall mit den anderen2 bt | 1.2012 www.bt-magazin.de © Software & Support Media GmbH
    • Daten füllen, um uns die Schemamigration zusparen. Das könnte ich bis zum Ende der Wo-che fertig haben.“ Sie ahnen schon, wie die Geschichte aus-geht? Richtig: Natürlich greift der Projektlei-ter die Idee des Jungentwicklers auf, und eswird so umgesetzt. Die Warnung des Archi-tekten, dass die Lösung unter Wartbarkeits-aspekten eine Katastrophe sei, die zukünftigefachliche Änderungen extrem schwer bis un-möglich machen würde, wischt der Projekt-leiter mit Hinweis auf den Termin und die ehschon angespannte Budgetsituation beiseite.Frustriert nehmen Architekt und Chefent-wickler hin, dass „billig“ mal wieder „gut“gestochen hat, und das Projekt nimmt wei- Abb. 1: Das magische Dreieck für Projektleiterter seinen gewohnten Gang. Es gibt noch einpaar Probleme mit der Änderung, aber der Jun-gentwickler bekommt diese recht fix in den Griff und der Das umfasst neben dem Umsetzen der nichtfachlichenLivegang klappt termingerecht. Abblenden. Ende. Anforderungen insbesondere das Strukturieren des Also hatte der Projektleiter recht, als er sich für die Systems (Stichwort: Verständlichkeit) und das Aus-schnelle und billige Lösung entschieden hat, oder? richten an den Anforderungsdomänen (Stichwort: Änderbarkeit). Als zielgebende RahmenbedingungenUnterschiedliche Aufgabenstellungen muss er dabei die Zufriedenheit über alle Stakehol-Bevor ich auf diese Frage zurückkomme, möchte ich der-Gruppen über den Lebenszyklus eines Systemskurz auf die Ursachen für diesen Konflikt eingehen. Da- maximieren und gleichzeitig die Kosten über alle Ko-für müssen wir die Aufgaben eines Projektleiters und ei- stenarten über den Lebenszyklus eines Systems mini-nes Architekten etwas genauer betrachten. Beginnen wir mieren. Damit ergibt sich für den Architekten ein ganzmit den Aufgaben eines Projektleiters: anderes magisches Dreieck (Abb. 2).• Der Projektleiter hat die Aufgabe, ein Projekt erfolg- Vergleicht man die beiden Aufgabenstellungen, dann reich abzuwickeln. „Erfolgreich“ wird dabei in den sieht man sofort den Zielkonflikt: Während der Pro- Dimensionen des magischen Dreiecks für Projektleiter jektleiter auf Projekte fokussiert ist, ist der Architekt auf (Abb. 1) gemessen: Zeit, Budget, Scope und Qualität. Vereinfacht ausgedrückt versucht der Projektleiter mit einem Minimum an Zeit und Budget ein Maximum an Scope und Qualität zu erzielen, wobei sich alle Messungen ausschließlich auf das jeweilige Projekt beziehen. Häufig sind zu Projekt- beginn schon eine oder mehrere Größen vorgegeben, was die Handlungsmöglich- keiten des Projektleiters entsprechend ein- schränkt.Ein Architekt hat hingegen ganz andere Auf-gaben:• Der Architekt hat vereinfacht ausgedrückt die Aufgabe, ein System erfolgreich zu ma- chen. Dazu muss er die verschiedenen Qua- litätsattribute des Systems sicherstellen. Abb. 2: Das magische Dreieck für Architektenwww.bt-magazin.de bt | 1.2012 3 © Software & Support Media GmbH
    • was der Code macht und integriert eine Änderung. Das hat dann jedes Mal zur Fol- ge, dass irgendein Teil der ursprünglichen Funktionalität nicht mehr läuft. Das „Trial and Error“-Spiel nimmt seinen Lauf, die Aufwände explodieren und eine sta- bile Lösung ist nicht in Sicht. Der Projektleiter schimpft auf seine „inkompetenten“ Entwick- ler und versucht, den pragmatischen Jungent- wickler aus dem alten Projekt per Eskalation in sein Projekt zu bekommen („Der kann das bestimmt!“), während der Releasetermin er- barmungslos näher rückt. Egal, wie das Pro- jekt jetzt weitergeht, werden wahrscheinlich die falschen Schlüsse gezogen. Schafft es der Projektleiter durch Eskalation den Jungent- wickler in sein Projekt zu bekommen und der bekommt eine Lösung hin, dann wird er vomAbb. 3: Das natürliche Spannungsfeld zwischen Projektleitern und Archi- Projektleiter und dem Management als Heldtekten gefeiert und keiner stört sich daran, dass sol- che Probleme gehäuft im Umfeld seiner „prag- matischen“ Lösungen auftreten. Und läuft dasSysteme fokussiert. Ihr jeweiliger Fokus ist also orthogo- Projekt gegen die Wand, dann wird irgendein anderernal zueinander (Abb. 3). Schuldiger gesucht, wahrscheinlich die „inkompetenten“ Entwickler. Niemand käme allerdings auf die Idee, demEin Jahr später Projektleiter die Schuld für das Desaster zu geben, weilSind die unterschiedlichen Aufgabenstellungen und er vor einem Jahr nicht auf seinen Architekten gehörtFokussierungen denn kritisch? Dafür möchte ich noch hatte. Wenn man es recht bedenkt, kann man ihm aucheinmal das Beispiel vom Anfang aufgreifen: Seit dem gar keinen Vorwurf machen, denn er hat damals nur dieLivegang des Projekts ist ein Jahr vergangen. Das ihm gestellte Aufgabe so gut wie möglich erledigt. SeineSystem ist zwischenzeitlich in anderen Projekten wei- Entscheidung war bezogen auf die ihm gestellte Aufgabeterentwickelt worden. Nun läuft wieder ein Projekt, richtig. Aber wo liegt dann das Problem?in dem u.  a. ein neues, sehr wichtiges Geschäftsfea-ture umgesetzt werden soll, mit dem man sich gegen Das Problem aus Unternehmenssichteinen Mitbewerber positionieren will. Der damals Hierfür müssen wir Projekte und Systeme einmal auserfolgreiche Projektleiter ist wieder an Bord, der Ar- Unternehmenssicht betrachten. Beginnen wir mit denchitekt ist dieses Mal nicht dabei und der mittlerweile Projekten: Es ist für Unternehmen wichtig, schnell undbei Projektleitern für seine pragmatischen Lösungen flexibel auf interne und externe Treiber reagieren zu kön-geschätzte Jungentwickler ist in einem anderen wich- nen. Dies wird organisatorisch typischerweise in Formtigen Projekt unabkömmlich. Das Projekt geht ganz von Projekten abgewickelt. Projekte verfolgen meistensgut voran. Nur dieses eine kritische Feature macht un- eher kurzfristige Ziele und sind zeit- und budgetgetrie-geahnte Probleme. Zur Umsetzung muss nämlich der ben. Dauert ein Projekt zu lange, ist man vielleicht zuService erweitert werden, in den der Jungentwickler spät mit dem Feature am Markt, und verbraucht manaus dem initialen Projekt seinen „Hack“ integriert hat. zu viel Geld, dann rechnet sich das Projekt nicht mehr.Die Entwickler des aktuellen Projekts tun sich sehr Dann gibt es die IT-Systeme: Ohne die Systeme kön-schwer damit, überhaupt zu verstehen was der Code nen die meisten Unternehmen ihren Geschäftsbetriebmacht. Die wenige Dokumentation und die wenigen nicht aufrechterhalten, auch nicht für kurze Zeit. SieTestfälle helfen nicht so richtig. Auch die Benennung haben in der Regel einen Lebenszyklus von vielen Jah-der Methoden und Variablen scheint nicht zu dem zu ren, häufig sogar Jahrzehnten. Gerade die Kernsystemepassen, was der Code macht und die Architekturdo- zeichnen sich durch sehr lange Lebenszyklen gepaart mitkumentation hilft an der Stelle auch nicht. Manchmal häufigen Änderungen aus (was klar ist, weil in ihnen dieglaubt ein Entwickler trotzdem verstanden zu haben, Kernkompetenzen des Unternehmens abgebildet sind).4 bt | 1.2012 www.bt-magazin.de © Software & Support Media GmbH
    • Vernachlässigt man diese zwei essenziellen Qualitätsattri- bute von Systemen, dann verliert man als Unternehmen über kurz oder lang die flexible Reaktionsfähigkeit und damit meistens auch viel Geld – von Stress, Frustration und sinkender Motivation in den Reihen der Mitarbeiter ganz zu schweigen. Neben den Projekten benötigt man also auch einen Fokus auf die Architekturqualität, um seine nachhaltige Reaktions- und Innovationsfähigkeit zu bewahren. Wie in dem Beispiel am Anfang beschrieben, sind aber nahezu alle Investitionen in der IT projektgetrie- ben: Die Budgets gehören den Fachbereichen, Geld gibt es nur für das kurzfristige Umsetzen von Fachfeatures, je billiger, desto besser. Budgets für die Pflege der System- qualität gibt es kaum oder gar nicht. Die Effekte dieser Entwicklung sind hinreichend bekannt: Dadurch, dass die IT praktisch kein Geld mehr für die Systempflege bekommt, kämpfen die IT-Abteilungen mit den so ent- standenen, häufig unwartbaren Systemen, während das Management und die Fachbereiche, die dieses Projekt- system etabliert haben, beklagen, dass die IT „langsam und ineffizient“ sei, „die Innovation behindern“ würde. Entsprechend wird IT nur noch als Kostenfaktor wahr- genommen und man versucht weiter Budgets abzuzie- hen. Die Qualität der Systeme sinkt damit weiter, undAbb. 4: Unternehmensnutzen abhängig vom Fokus (verein- die IT wird noch langsamer. Ein Teufelskreis!facht) Gut, ganz so schwarz und weiß ist es in der Praxis dann häufig doch nicht, und auch die IT-AbteilungenIm direkten Vergleich ist der Lebenszyklus eines Systems könnten sicherlich eine Menge besser machen, als sie esdamit typischerweise um ein Vielfaches länger als die heute vielfach tun, aber insgesamt verlieren alle durchLaufzeit eines Projekts. die ausschließliche Fokussierung auf Projekte unter Ver- Jetzt stehen Unternehmen vor der Herausforderung, nachlässigung der Architekturqualität.jederzeit schnell und flexibel auf Treiber reagieren zukönnen. Dafür müssen sie ihre Organisation, ihre Mitar- Die Lösung des Problemsbeiter und ihre Ressourcen entsprechend aufstellen. Zu Aber wie kann man es besser machen? Die Lösung istden Ressourcen gehören auch die langlebigen IT-Syste- bereits grundsätzlich genannt worden: Man darf nichtme. Damit diese jederzeit schnell und flexibel geändert nur in Projekten denken und handeln, man muss auchwerden können, müssen sie zu jedem Zeitpunkt zwei der die Systeme und deren Nachhaltigkeit im Fokus be-vielen Qualitätsattribute erfüllen, für die ein Architekt halten. Gerade die Qualitätsattribute Verständlichkeittypischerweise verantwortlich ist: Verständlichkeit und und Änderbarkeit sind bei den langen Lebenszyklen derÄnderbarkeit. Systeme extrem wichtig, wenn man will, dass auch zu- künftige Projekte Änderungsanforderungen schnell und• Verständlichkeit bedeutet, dass ein Stakeholder (insbe- flexibel umsetzen können. sondere ein Entwickler) das System möglichst schnell Natürlich ist es dabei auch wichtig, nicht in das an- und einfach verstehen können muss. Verständlichkeit dere Extrem zu verfallen: Es ist niemandem geholfen, ist die Voraussetzung für Änderbarkeit: Was man wenn die IT sich jetzt nur noch mit der Verständlich- nicht versteht, kann man auch nicht ändern. keit und Änderbarkeit ihrer Systeme befasst und dabei• Änderbarkeit bedeutet, dass man (zukünftige) neue wichtige, kurzfristige Geschäftsanforderungen komplett Anforderungen auf möglichst einfache, kostengüns- ignoriert. Es muss eine sinnvolle Balance gefunden wer- tige und risikoarme Weise in ein bestehendes System den, um den maximalen Nutzen zu erzielen (Abb. 4). integrieren kann. Änderbarkeit entfaltet ihren Nutzen Aber wie kann man das hinbekommen? Es gilt, das in der Regel mittel- oder langfristig. natürliche Spannungsfeld zwischen Projektleiter undwww.bt-magazin.de bt | 1.2012 5 © Software & Support Media GmbH
    • Architekten auszubalancieren. Beide werden benötigt, ziele sind, sollte ein Architekt die Projekte weiterhinalso sollte man als Unternehmen das Spannungsfeld für zumindest beratend unterstützen, im Notfall auch mitsich nutzen. Heute sieht es meistens so aus, dass der Pro- Vetorecht ausgestattet.jektleiter die komplette Entscheidungsgewalt hat und Der Architekt begleitet bereits die Planungs- undder Architekt gar keine. Im Zweifelsfall bestimmt der Budgetierungsphase des Projekts: Aus ArchitektursichtProjektleiter und der Architekt hat das Nachsehen. Bes- sinnvolle Lösungen sind nicht unbedingt die billigstenser wäre es, wenn Projektleiter und Architekt sich auf Lösungen. Häufig werden in der BudgetierungsphaseAugenhöhe mit vergleichbaren Kompetenzen begegnen, aber zugunsten eines Business Cases oder anderer kom-um so eine konstruktive Diskussion zum Finden guter merzieller Gründe die billigsten LösungsmöglichkeitenKompromisse zwischen den beiden Zielen zu fördern. angenommen. Um den Projektleiter danach nicht vorGenau dies ist die Voraussetzung für nachhaltige Fle- ein unlösbares Problem zu stellen, sollte ein Architektxibilität und Reaktionsfähigkeit als Unternehmen: Das bereits die Planungs- und Budgetierungsphase eines Pro-Schaffen einer Umgebung, in der das natürliche Span- jekts begleiten. Dort kann er dann mögliche Alternati-nungsfeld zwischen Projektleiter und Architekt zum ven und deren Konsequenzen aufzeigen und so helfen,Tragen kommt und so die für das Unternehmen wich- die aus Unternehmenssicht ganzheitlich beste Lösung zutigen Größen Projektgeschwindigkeit (und Kosten) so- finden und zu budgetieren.wie Systemqualität in eine sinnvolle Balance kommen Technische Schulden explizit machen: Das ist keinekönnen. echte Lösung, aber zumindest ein erster Schritt, um Kon- sequenzen explizit zu machen. Hat der Architekt wederFein-Tuning Budgets noch Entscheidungskompetenzen und wird mitIn einem solchen Umfeld hat der Projektleiter ein Prob- aus Systemqualitätssicht schlechten Lösungen konfron-lem: Seine Aufgabe ist es doch, mit einem Minimum an tiert, so kann er diese Lösungen und deren Konsequen-Zeit und Budget ein Maximum an Scope und Qualität zen zumindest dokumentieren. Aus der agilen Welt gibtzu erzielen, wobei in der Praxis meistens schon viele der es hierfür den Begriff der „technischen Schulden“. Die-Größen vor Projektstart festgelegt werden. Wie soll er ser bezeichnet eine Lösung, die man vorläufig „quickdiese Aufgabe zielgerichtet umsetzen, wenn er jetzt nicht and dirty“ umgesetzt hat und die man zu einem späte-mehr die Möglichkeit hat, diese unumschränkt durch- ren Zeitpunkt noch einmal nacharbeiten muss, wennzusetzen? Er muss sich jetzt ja mit einem Architekten man nicht Zins und Zinseszins in Form von steigendenarrangieren, der die gleichen Rechte wie er hat, aber Fehlerquoten, Instabilitäten und sinkender Produktivi-ganz andere Ziele. Was tun? Jetzt könnte man sich auf tät zahlen will. Damit hat man das Problem zwar nochden Standpunkt stellen, dass es ihm damit immer noch nicht gelöst, aber man hat als Architekt Transparenz ge-besser ginge als bislang einem Architekten, der auch eine schaffen, was ein erster Schritt ist.Aufgabe hatte, aber letztlich keine Mittel sie durchzuset- Bei all diesen Ansätzen ist es essenziell wichtig,zen. Aber es gibt natürlich auch ein paar konstruktivere dass sich Architekten auf die beschriebenen Ziele fo-Lösungsansätze: kussieren. Das häufig schlechte Bild von Architekten Der Architekt bekommt ein Budget für die System­ rührt unter anderem daher, dass viele Vertreter die-pflege: Das wäre wahrscheinlich die sauberste Lösung. ser Spezies ein ausgeprägtes Bedürfnis entwickelt ha-Da sowohl die Projektziele als auch die nachhaltige ben, sich selbst Denkmäler zu setzen: ÜberkandidelteSystemqualität einen Wert für das Unternehmen dar- Architekturen, diktatorisches Verhalten usw. warenstellen, gibt man dem Architekten analog zum Projekt- häufig die Folge, gepaart mit unvermeidlichem Ver-leiter ein Budget zur Sicherstellung der Systemqualität trauensverlust. Deshalb ist es für Architekten immensim Sinne der Erfüllung der architekturrelevanten Qua- wichtig, sich als Dienstleister für die beschriebenenlitätsattribute, mit einem besonderen Fokus auf Ver- Ziele zu verstehen und im Zweifelsfall dem „Wenigerständlichkeit und Änderbarkeit. Allerdings könnten ist mehr“-Prinzip zu folgen. Dann hat man auch eineimmer noch Projekttermine durch für die Architek- reelle Chance, Akzeptanz für die hier skizzierten Vor-turqualität relevante Aktivitäten gefährdet werden. schläge zu bekommen.Hierfür gäbe es die Möglichkeit, eine Reihe dieserAktivitäten außerhalb der normalen Projekte durch- Kein Problem im agilen Umfeld?zuführen. Man hätte dann die normalen Projekte und Wie gut, dass wir agil sind, könnte man jetzt als agilerorthogonal dazu eine Systempflege. Um sicherzustel- Zeitgenosse denken. Da gibt es keine Projektleiter undlen, dass innerhalb der Projekte keine Entscheidungen keine Architekten und deshalb betrifft mich das allesgetroffen werden, die komplett gegen die Architektur- nicht. Das ist natürlich ein grober Fehlschluss. Auch6 bt | 1.2012 www.bt-magazin.de © Software & Support Media GmbH
    • wenn es in agilen Umfeldern häufig nicht die Rolle eines Notizen:Projektleiters oder eines Architekten gibt, so sind derenAufgaben und Ziele trotzdem nicht hinfällig geworden.Projektziele und Systemqualität sind in agilen Umfeldernmindestens genauso relevant wie in nicht agilen Umfel-dern. Damit treten die in diesem Artikel beschriebenenProbleme und Zielkonflikte ebenso auf, auch wenn mansie nicht mehr so einfach mit bestimmten Rollen asso-ziieren kann. Das beschriebene Problem ist nicht in dereingesetzten Methodik begründet, sondern systemischerNatur und deshalb muss man sich in agilen Umfelderngenauso mit dem in diesem Artikel beschriebenen Prob-lem befassen.FazitArchitekturqualität und Projektdenken passen häufignicht gut zueinander. Während Projekte sich nur auf dasGeschehen bis zum Projektende fokussieren, müssen Ar-chitekten weit darüber hinaus denken. Letztlich brauchtein Unternehmen beide Aspekte in vernünftiger Balance,um dauerhaft den maximalen Mehrwert aus seinen In-vestitionen sicherzustellen. Heute ist es aber meistens so,dass der Fokus ausschließlich auf Projekten liegt und dieSystemqualität den Projektzielen komplett untergeord-net wird. Damit verschenken Unternehmen viel Poten-zial, nachhaltige Innovationsfähigkeit und letztlich auchviel Geld. Durch eine gesunde Balance zwischen Pro-jekt- und Systemzielen und einem konstruktiven Span-nungsfeld zwischen Projektleitern und Architekten aufAugenhöhe kann man diese Situation verbessern undsich nachhaltig einen Wettbewerbsvorteil verschaffen.Architekturqualität ist kein nettes Feature, sondern einehandfeste wirtschaftliche Größe für jedes Unternehmen,das in signifikantem Umfang IT-Unterstützung für seineWertschöpfung benötigt, was mittlerweile für nahezualle Unternehmen gilt. Uwe Friedrichsen hat langjährige Erfahrungen als Archi- tekt, Projektleiter und Berater. Aktu- ell ist er bei der codecentric AG als CTO tätig und beschäftigt sich in dem Kontext insbesondere mit agilen Ver- fahren und neuen Architekturansätzen und Technologien.www.bt-magazin.de bt | 1.2012 7 © Software & Support Media GmbH
    • codecentric AG Kölner Landstraße 11 40591 Düsseldorf Tel: +49 (0) 211.9941410 Fax: +49 (0) 211.9941444 E-Mail: info@codecentric.de www.codecentric.de blog.codecentric.de8 bt | 1.2012 www.bt-magazin.de © Software & Support Media GmbH