Theorie des erfinderischen Problemlösens – TRIZ

Am 12.10.2017 durften wir die Gäste des 6. KME-Netzwerktreffen in unserem Lab minnoshere begrüßen. Neben den Sprechern von EurA – Herr Weigl, m3 management consulting – Michael Wilk, usw. durfte ich auch Dr. Robert Adunka begrüßen, der über TRIZ als Innovationskonzept sprach.

TRIZ als Innvoationskonzept beim KME-Netzwerktreffen

Diese Veranstaltung nehme ich auch zum Anlass einen kurzen Blog über das TRIZ als Innovationskonzept zu schreiben. Vor allem, da wir dieses Konzept auch tlw. in unseren Innovations-Workshops einsetzen.

Das primäre Ziel dieser Methode ist, ein ideales technisches Produkt zu entwickeln. Dabei wird eine Problemstellung identifiziert und soweit abstrahiert, dass aus den 37 Standard-Problemarten und 40 innovativen Prinzipien Lösungsansätze übernommen werden können.

Der Vorteil der Methode ist, dass die Beteiligten anhand von konkreten Punkten im Lösungskatalog Problemlösungsansetze systematisch drucharbeiten kann. Quasi Kreativität aus dem Katalog. Und ich kann Euch auch sagen, jeder Mensch ist kreativ 😉

Der Wandel zum Full-Stack-Architekten

Seit knapp drei Jahren findet man Stellenausschreibungen die in Richtung Full-Stack-Architekten gehen. Was ist das genau und was könnte man darunter verstehen?

Schauen wir doch zuerst einmal in die Vergangenheit

  • In den 60er und Mitte 70er Jahren waren die Mainframes der letzte Schrei im technologischen IT-Universum. Das änderte sich
  • in den Mitte 70er Jahren. Die kleinen Computer verbreiteten sich immer schneller und dies dauerte bis in die 90er Jahren an. Danach wurde es erstmals wirklich spannend und die Vernetzung von Rechnern startete durch.
  • In den 90er Jahren wurden viele Anwendungen und Architekturen durch das Client-Server-Konzept geprägt und vorangetrieben. Das dauerte bis etwa zur Jahrtausendwende an. Das Internet steckt noch in den Kinderschuhen und die Modems „dongten“ vor sich hin. Manch einer hatte da schon Ideen, aufgrund der Infrastruktur machte vieles aber betriebswirtschaftlich keinen Sinn.
  • Ab dem Jahrtausendwechsel bis etwa 2010 wurden durch die Internet-Technologie und verbesserter Infrastruktur viele Vorgehen, Architekturen und Infrastrukturen durchs SOA-, WebService- und VM-Dorf getrieben. Dann kam in dieser Zeit der Apfel und zeigte uns, damals noch wie von einem anderen Stern, das Wunderwerk Smartphone.
  • Von 2010 an, legt mich aber nicht genau fest, begann das mobile und heute noch aktuelle Zeitalter. Durch H+, ständiger Konnektivität, etc. war es möglich geworden Anwendungen zu bauen, die (fast) in Echtzeit miteinander agieren können. Viele neue Technologien, Vorgehen und Architekturpattern wurden seit dem geschaffen.

Es war seit Mitte 2005 gar nicht mehr so einfach ein Full-Stack-Architekt zu sein. Es gab Computer, Server und das Internet und es fing eine Spezialisierung an, die geprägt war von der Breite der Möglichkeiten und der Komplexität der Systeme. Ich erinnere mich noch an die Zeit zwischen 2007 und 2010 wo ich als Chefarchiekt in einem Pharmaunternehmen noch weitere Mitarbeiter in meinem Team hatte. Da war der

  • Infrastruktur-Architekt, der in seiner Domäne noch Spezialisten hatte für
    • Storage
    • Server und Hardware
    • Netzwerk
    • Virtualisierung und
    • Betriebssysteme.
  • Teilweise hatten wir auch einen eigenen Netzwerk-Architekten im Projekt-Team.
  • Dann kam der Middleware-Architekt und der
  • Data-Architekt und zu guter Letzt der
  • Application-Architect.

DER klassische FULLSTACK

Anwendung
Daten
Laufzeitumgebung
Middleware
Betriebssysteme
Virtualisierung
Server
Speichersysteme
Netzwerk

Diese Mischung wurde dann auch noch garniert mit vielen neuen Programmiersprachen, Plattformen, und Technologie-Anbietern. Das größte Problem war aber, dass alles beim Alten blieb. Es gab immer noch die Server, die Hardware und alle Schichten, die man so gebraucht hat. An Full-Stack-Architekten war da gar nicht zu denken. Ich kannte damals keinen, der sich das getraut hätte von sich zu sagen 😉

Heute haben wir 2017 und das Pflänzchen des Full-Stack-Architekten ist am wachsen und erfreut sich immer größerer Beliebtheit. Das haben einige große und kleine Technologie-Anbieter erkannt und den klassischen Stack für uns Architekten radikal reduziert. Unter den Schlüsselwörtern Iaas und PaaS wurden viele gute und erfolgreiche Konzepte durchgesetzt. Der Stack sieht dann in etwas so aus:

Anwendung
Daten
PaaS (Runtime, Middleware, OS)
IaaS (Virt., Server, Storage, Netw.)

Mit Hilfe von Technologien wie Cloud oder Docker, um einige zu nennen, brauchen wir uns keine Gedanken mehr zu machen welche Art von Server wir benötigen oder welche Betriebssysteme. Auch die Frage welche Programmiersprache bzw. -umgebung wird zweitrangig oder sogar obsolet. Somit können wir durch die reduzierte Stack-Landschaft, ein wenig Changing-Mindsetting und Es-Zu-Lassen die Produktivität für unsere Kunden rasant erhöhen und den Full-Stack-Architekten wieder zum Leben erwecken.