Craig St. Jean, Vom jungen Programmierer zum Chief Technology Architect

Hallo! Ich bin Craig St. Jean, ein MVP von OutSystems mit Sitz in Ohio in den Vereinigten Staaten. Ich bin ein engagierter Xebianer, der von einem hohen Maß an intellektueller Neugier und dem Wunsch angetrieben wird, das Gelernte weiterzugeben. In diesem Beitrag werde ich Ihnen einen Eindruck davon vermitteln, wo ich mich in meiner Karriere befinde und wie ich hierher gekommen bin.

Frühe Inspiration

Ich kann wohl sagen, dass ich Ende der 80er oder Anfang der 90er Jahre "programmiert" (oder zumindest gescriptet) habe, als mein Onkel uns einen Commodore 64 schenkte. Damals war ich mehr an der Natur interessiert, aber die Idee, einige Spiele auf dem "Fernseher" zu spielen, war faszinierend. Der Commodore 64 versetzte Sie zunächst in eine BASIC-Shell. Wenn Sie also ein Spiel spielen wollten, mussten Sie LOAD-Befehle eingeben, um es vom Bandlaufwerk oder der 5½-Zoll-Diskette zu laden, und dann RUN-Befehle eingeben. Aber damals tippte ich nur ein paar Anweisungen aus einem Papier ein, das mein Onkel geschrieben hatte, um ein Spiel zu spielen.

Mein eigentlicher Einstieg in die Programmierung war später, 1995. Ein Freund schrieb etwas in BASIC, und der Computer folgte seinen Anweisungen. Die Idee, den Computer tun zu lassen, was ich wollte, machte mich sofort neugierig. Zu diesem Zeitpunkt wusste ich, dass ich sehr viel Zeit vor dem Computer verbringen würde.

Ich wechselte schnell vom Schreiben textbasierter Spiele in BASIC zu allem, was mir in C einfiel. Ich schrieb Tic-Tac-Toe-Löser, Dienstprogramme, die Probleme für mich lösten, und sogar eine eigene interpretierte Programmiersprache. Um meine Fähigkeiten zu erweitern, wechselte ich dann zu C++ und erstellte weitere textbasierte Anwendungen. Außerdem begann ich mit Win32- und MFC-GUI-Anwendungen wie TCP/IP-Chat-Tools, Remote-Systemadministration und mehr.

Nach all dem habe ich alles ausprobiert, was ich in die Finger bekam. Jemand hatte mir Delphi 5 Standard geschickt, also habe ich ein wenig damit gearbeitet. Als die allererste Beta-Version von Visual Studio.NET herauskam, fing ich mit C# an (ein großes Dankeschön an die Zeitschrift Dr. Dobbs, die mir die Disketten mit der damaligen Ausgabe geschickt hat), und ich schrieb CGI-Webanwendungen in Perl usw.

Vor OutSystems

Im Jahr 2006 begann ich schließlich meine berufliche Laufbahn als Java-Entwickler bei einer Sach- und Haftpflichtversicherung. Ich war ein Vollzeit-Praktikant und bildete mich in meiner Freizeit weiter. Im folgenden Jahr wurde ich schließlich als Vollzeit-Angestellter eingestellt, wo ich weiterhin außerhalb der Arbeitszeit zur Schule ging, um im darauffolgenden Jahr meinen Abschluss zu machen.

Als Java-Entwickler bei einer Versicherungsgesellschaft konnte ich wirklich anfangen zu verstehen, wie es ist, große Geschäftsprobleme in einem großen Unternehmen zu lösen. Ich hatte nicht mehr nur Spaß daran, kleine Kommandozeilenprogramme zu schreiben, ohne darüber nachzudenken, wie die Anwendung konzipiert war, sondern musste auch die Auswirkungen und die Strenge der Tests verstehen, die erforderlich waren, um nur eine kleine Sache in einer Bibliothek zu ändern, von der viele kritische Systeme abhingen. Schließlich wurde ich auch mit großen Integrationen konfrontiert, z.B. mit IBM WebSphere MQ, um eine Verbindung zu einem z/OS-Mainframe herzustellen und Policy-Daten zu lesen. Außerdem arbeitete ich zum ersten Mal an Webanwendungen, die über die einfachen CGI-Skripte hinausgingen, die ich zuvor in Perl geschrieben hatte, wobei der Großteil unseres Codes in BEA WebLogic gehostet wurde.

Damals gab es eine Redewendung: "Niemand wurde gefeuert, weil er sich für IBM entschieden hat", also migrierten wir von BEA WebLogic zu IBM WebSphere Application Server. Wenn ich zurückdenke, war dieses eine Projekt der erste große Wendepunkt in meiner Karriere, denn dadurch wurde mein Interesse daran, so viele Dinge wie möglich zu lernen, zu dem Wunsch, andere zu unterrichten. Ich wurde schnell zu einem der Ansprechpartner, wenn es darum ging, Anleitungen zu dokumentieren und bei der Diagnose von Problemen mit WebSphere und der von uns verwendeten IDE, IBM RAD, zu helfen. Ich ahnte nicht, dass all dies dazu führen würde, dass ich 7 Jahre später für Pluralsight einen Kurs über WebSphere Application Server unterrichten würde. Nach der Migration konzentrierten wir uns auf die serviceorientierte Architektur (SOA), einen entscheidenden Vorläufer der Microservices.

Abgesehen von den technischen Premieren hatte ich auch das große Glück, einen Mentor zu haben, der dafür sorgte, dass ich großartige Chancen bekam und mir zeigte, dass ich vielleicht zu viel von mir selbst hielt und immer viel von anderen lernen konnte. Er hat mir auch beigebracht, dass "dumm" nicht im Wörterbuch eines Profis steht, nachdem ich ihm meine ehrlichen Gefühle darüber mitgeteilt hatte, wie etwas aufgebaut war (ok, diese Lektion lerne ich vielleicht immer noch ... ), und ich habe auch gelernt, alles als Chance zu sehen.

Nach vielen weiteren Misserfolgen, Erfolgen und Erkenntnissen wechselte ich zu einer anderen Sach- und Unfallversicherungsgesellschaft. Hier wurden meine diagnostischen Fähigkeiten mit ihren Java-basierten Webanwendungen auf die Probe gestellt. Es gab keine Unternehmensarchitektur, kein J2EE (nur Tomcat) und die einzigen nennenswerten Integrationen bestanden darin, dass ein automatisiertes Tool eine Mainframe-Sitzung abfragte. Aber wir trieben die Webanwendungen voran, um die Anforderungen des Unternehmens zu erfüllen, und begannen gleichzeitig mit der Migration zu C# und ASP.NET mit einem angemessenen Systemdesign, DevOps usw.

Nach meiner Zeit bei der Versicherung wechselte ich zu einem globalen Einzelhandelsunternehmen, das sich auf Schmuck spezialisiert hatte und ebenfalls IBM WebSphere Application Server einsetzte. Während meiner Zeit dort entwickelte sich meine Karriere recht umfangreich. Zunächst arbeitete ich an einer iOS-App, die von unseren Führungskräften genutzt wurde, dann an verschiedenen Web-Apps und einer Android-App, die in den Geschäften eingesetzt wurde. Dann ging ich eine Partnerschaft mit Pluralsight ein, wurde ein geprüfter Pluralsight-Autor (was ein ziemlich schwieriger Prozess war) und veröffentlichte einen Kurs über IBM WebSphere Application Server. Danach wurde JavaScript immer beliebter, und ich entwickelte einige einseitige Anwendungen mit Dojo.

Während ich mich auf die Entwicklung konzentrierte, kam ein neuer CIO in das Unternehmen. Der CIO erzählte allen er war offen für Einzelgespräche, was die meisten Leute ablehnten.t zu tun. E ven obwohl er mein Chef war Chefs war Chefs... Chefs Chef, beschloss ich, ihn beim Wort zu nehmen. die anbieten. Fr om ihmhabe ich gelernt, dass es ein bisschen schwierig ist, einen CIO zu finden.tung, die zwischen technisch und Managementfähigkeiten. Er verglich es mit dem "Wenden" beim Segeln.

Der CIO hat es mir gesagt, "Sie kann nicht wachsen zu das hiHöchste Stufe von technical capabMöglichkeiten mitaus bei zumindest einige Gradree des Geschäftsumsatzesn, und Sie können nicht erhalten. zum höchsten Ebene des Geschäfts ohne mindestens einige Technikal acuMänner." Er sagte auchalt mir, dass "ein CIO ist mittendrinle der beiden, und zu get dort Sie müssen '.Wette 'tack'ween business und technisch."

Da ich seinen Rat befolgte und das Glück hatte, dass sich eine Stelle als Projektmanager eröffnete, beschloss ich, mich abseits meiner technischen Fähigkeiten zu versuchen, auch wenn ich eigentlich kein Interesse daran hatte. Aber die Erfahrungen, die ich in der Rolle des Projektmanagers gesammelt habe, haben mir wirklich die Augen für eine andere Sichtweise geöffnet.

Während ich mich in der Rolle des Projektmanagers zurechtfand, eröffnete sich bei denselben Geschäftskunden, mit denen ich zusammengearbeitet hatte, eine weitere Möglichkeit, nämlich die eines Product Capability Managers (im Grunde ein Mini-Direktor). Die Arbeit eines Projektmanagers gefiel mir nicht, und ich wollte mehr Verantwortung übernehmen und mehr über Mitarbeiterführung lernen, also wechselte ich in die Rolle des PCM. Amüsanterweise habe ich in dieser Zeit nie wirklich aufgehört zu programmieren; ich habe nur geändert, was ich programmierte. Anstatt Projekte zu programmieren, programmierte ich Automatisierungen für Budgetprognosen und dergleichen.

Als PCM hatte ich auch eine meiner Lieblingsinnovationen zu bieten. Das Unternehmen, das uns die Lagerverwaltung für unsere kundenspezifischen E-Commerce-Bestellungen zur Verfügung stellte, würde sein Lager schließen, und wir mussten alles intern verlagern. Ich leitete das Team, das die Integration mit unseren E-Commerce-Systemen vornahm und die Software für unser internes Lagerteam entwickelte, um die Produkte aus den Regalen zu nehmen, Versandetiketten zu erstellen usw. Da es sehr zeitaufwändig wäre, die Produkte für jede einzelne Bestellung zu kommissionieren, haben wir einen Prozess entwickelt, bei dem die "Kommissionierer" in einem Schritt alle für den Versand benötigten Artikel kommissionieren und dann in einem weiteren Schritt die Artikel für die Bestellungen scannen. Das System ermittelte, zu welchem Auftrag das Produkt gehörte, und erstellte die Versandetiketten. Wenn das Produkt jedoch zu einer Bestellung mit mehreren Produkten gehörte, gab es einen Prozessmangel, also entwickelte ich ein System, bei dem Produkte, die zu einer Bestellung mit mehreren Produkten gehörten, in speziell gekennzeichnete Behälter gelegt wurden. Wenn der Kommissionierer den nächsten Artikel in der Bestellung einscannt, weist das System ihn an, den entsprechenden anderen Artikel aus dem entsprechenden Behälter zu nehmen, in dem er sich befindet. Dieses Projekt hat mir sehr viel Spaß gemacht, denn es gab nicht nur die Möglichkeit, innovative Prozessverbesserungen vorzunehmen, sondern es war auch das erste Mal, dass ich an einem System gearbeitet habe, bei dem Menschen etwas tun mussten und nicht nur ein Computer etwas tun musste!

Obwohl ich in einer Führungsposition fantastisch gelernt habe, wollte ich mich wieder der technischen Seite zuwenden. In meinem letzten Schritt vor meinem Wechsel zu OutSystems kehrte ich also zu der ersten Sach- und Haftpflichtversicherungsgesellschaft zurück, für die ich als technischer Leiter gearbeitet hatte. Es war wirklich erfrischend, wieder mit den Menschen zusammen zu sein, die mir geholfen hatten, einen großartigen Weg einzuschlagen, und ich fühlte mich wie "zu Hause". Aber es sollte nur ein paar Jahre dauern, bis ich ein neues "Zuhause" fand.

Die Reise zu OutSystems

Da wir ein Versicherungsunternehmen und ein großes Java-Unternehmen sind, waren unsere Geschäftspartner daran gewöhnt, sich langsam zu bewegen. Agile Praktiken waren vielen Leuten fremd, ebenso wie viele Technologien außerhalb von IBM und Java. Neue Mitarbeiter in Schlüsselpositionen gaben jedoch eine neue Richtung vor, und ich befand mich mitten in einer agilen und digitalen Transformation.

Um schneller voranzukommen, evaluierte unser Enterprise Architecture Team Low-Code-Plattformen wie Appian, Mendix, Salesforce Lightning und, ja, OutSystems. Im Rahmen dieser Evaluierung habe ich mich mit Salesforce Lightning und OutSystems beschäftigt. Aufgrund früherer Erfahrungen stand ich jedem Low-Code-Tool äußerst skeptisch gegenüber, da ich feststellte, dass man in der Regel, sobald man den glücklichen Pfad des Tools verlässt, entweder nicht weiterkommt oder eine komplizierte Umgehung findet. Und als jemand, der es liebt, Code zu schreiben, wollte ich beweisen, dass keines der Tools unsere Anforderungen erfüllen würde.

Um zu beweisen, dass OutSystems nicht ausreicht, beschloss ich, einige Szenarien durchzuspielen, bei denen ich das Gefühl hatte, dass es nicht ausreichen würde. Das erste Szenario bestand darin, eine Website zu erstellen, die von einem Headless CMS gesteuert wurde, wobei die API-Aufrufe aus dem CMS dynamisches JSON statt einer statischen Struktur waren. Am Ende des Tages hatte ich jedoch eine funktionierende Demo mit der Open-Source-Komponente ardoJSON von Forge.

"Das ist gut", dachte ich. Mir schwebte etwas anderes vor: eine dynamische Umfrageanwendung, ähnlich wie SurveyMonkey, die es einem Administrator ermöglicht, Fragetypen mit verschiedenen Arten von Eingabefeldern zu definieren. Da alles, was ich in OutSystems durcharbeitete, sich hinsichtlich der Benutzeroberfläche etwas statischer anfühlte, dachte ich, ich hätte meine Wunderwaffe, zumal es ziemlich einfach war, so etwas in JSTL oder Razor zu machen. Zu meiner Enttäuschung stellte ich die Anwendung nach ein paar Tagen wieder fertig und erfüllte alle Ziele und Anforderungen, die ich für die Anwendung für notwendig hielt.

Zu diesem Zeitpunkt hatte ich mich mit der Tatsache abgefunden, dass OutSystems unsere Anforderungen erfüllen und sogar übertreffen würde. Jedes Mal, wenn ich versuchte zu zeigen, dass es nicht funktionieren würde, stellte ich fest, dass das Tool entweder eine großartige Lösung hatte oder so konzipiert war, dass es mir eine Alternative bot, ohne die Qualität und Wartbarkeit meiner Lösung zu beeinträchtigen. Sogar unser Informationssicherheitsteam war davon überzeugt und sagte, dass die OutSystems Cloud "unsere Sicherheit um 5 Jahre verbessern wird."

Da die Bewertungen von OutSystems erfolgreich waren, kauften wir die Plattform, um ein digitales Kundenerlebnis zu schaffen. Vier Tage später hatte ich einen funktionierenden Prototyp eines Kundenportals, das mit unserem System für Versicherungsansprüche integriert war, um den Kunden den Status ihrer Ansprüche mitzuteilen. Mehr noch, ich hatte mir vorgenommen, alles zu entwickeln, ohne eine einzige .NET-Erweiterung zu schreiben, was mir recht leicht gelang.

An diesem Punkt beschloss ich, meine Karriere auf OutSystems zu konzentrieren. Ich wurde zum OutSystems MVP-Programm eingeladen und begann, einen OutSystems-Partner zu suchen, der gut zu mir passen würde.

Beitritt zu einem OutSystems-Partner

Als ich mich entschied, weiter in die OutSystems Ökosystem entschied ich mich, zu einem OutSystems-Partner zu wechseln, wo ich für eine viel größere Anzahl von Menschen und Unternehmen einen Mehrwert schaffen konnte. Der Beitritt zu Netlink Digital Solutions (jetzt Xebia) lag für mich auf der Hand, da ich bereits Verbindungen zu Menschen von verschiedenen OutSystems-Veranstaltungen hatte und meine Gedanken und Wünsche mit ihren übereinstimmten. Dank der Synergien zwischen mir und Netlink Digital Solutions trat ich als Engagement Manager. Ich betrachtete dies auch als eine "Wende" in der Mitte zwischen der technischen und der Management-Seite der Dinge. Von hier aus würde ich mich geradlinig auf eine CTO-ähnliche Position zubewegen und sicherstellen, dass ich mich in alle Richtungen weiterentwickle, anstatt nur in eine.

Meine Karriere bei einem OutSystems-Partner ausbauen

Sowohl als OutSystems MVP als auch als Engagement Manager bei einem Partner gab es klare Möglichkeiten, sowohl meiner eigenen Organisation als auch anderen Organisationen im OutSystems-Bereich zu helfen. Um in dieser Richtung etwas zu bewirken, gründete ich das OutSystems Center of Excellence und wurde zum Direktor des CoE ernannt. Über das CoE würde ich daran arbeiten, die Qualität unserer internen Mitarbeiter und Schulungen zu verbessern, bei der Forschung und Eskalation zu helfen und eine wichtige Rolle bei unseren Marketingbemühungen zu spielen. Ich würde auch auf Veranstaltungen von OutSystems sprechen, einige unserer eigenen Veranstaltungen ausrichten und unser YouTube-Kanal .

Durch meine Arbeit als Direktor des OutSystems Center of Excellence konnte ich mich organisch zu einer CTO-ähnlichen Position entwickeln. Als Dienstleistungsunternehmen war ich der Meinung, dass ein Chief Technology Officer nicht besonders sinnvoll ist, da er sich in der Regel auf die internen Abläufe konzentriert, und so wurde ich Chief Technology Architect. Ich konzentrierte mich auf die Förderung unserer internen Fähigkeiten, auf die Entwicklung und Schulung von Spitzenleistungen, auf die Verbreitung von Low-Code und OutSystems und auf alle anderen Bereiche, in denen ich einen Beitrag leisten konnte.

Jeder hat seinen eigenen Weg zu gehen. Etwas so Einfaches wie die Mitarbeit an einem Projekt zur Technologieumstellung brachte mich auf den Weg zu Mentoring und Training - unterschätzen Sie keine Gelegenheit. Und scheuen Sie sich nicht, Ihre Komfortzone zu verlassen - ich war nicht daran interessiert, Menschen zu führen, aber ich habe den Schritt trotzdem getan, um mehr über die Branche und mich selbst zu lernen. Ohne diese beiden wichtigen Punkte in meiner Karriere wäre ich heute nicht da, wo ich bin. Arbeiten Sie hart, dokumentieren Sie Ihre Erfolge und Misserfolge, lernen Sie aus beidem und denken Sie daran, dass Sie immer von anderen lernen können, ganz gleich, wo Sie in Ihrer Karriere oder in Ihrem Leben stehen.