Galeria

CASE STUDY T-Mobile Polska

Strategia jest rozumiana różnie: w zależności od firmy, jej dojrzałości oraz potrzeb. Dla tych dużych organizacji to często zdeprecjonowane "korpo-słowo", dla tych małych – biznesplan na kolejne przedsięwzięcie. Niezależnie od tego, strategia jest potrzebna jako fundament ukierunkowania biznesu. Zaniechanie tworzenia strategii, doprowadza do myślenia krótkoterminowego, co przekłada się na ukierunkowanie jedynie na cele finansowe. W konsekwencji klient oraz jego zadowolenie z produktów i usług przestaje się liczyć, co ma katastrofalne konsekwencje.

Dla departamentów IT takim klientem jest biznesowa część organizacji. Strategia technologiczna powinna adresować potrzeby biznesu, ale też wyznaczać własne cele strategiczne pozwalające antycypować pojawiające się wyzwania. Architekci, jako osoby nadające takt części organizacji odpowiedzialnej za technologię, powinni pełnić w jej tworzeniu i egzekucji rolę kluczową/wiodącą/opiniotwórczą. Nowe trendy, technologie, języki programowania, dostawcy, produkty – to wszystko powinno być przedmiotem syntezy wykonywanej przez architekturę, a na tej podstawie powinna być budowana strategia technologiczna.

Prelekcja przedstawi zalety i wady takiego podejścia. Pokażę co jest niezbędne, żeby osiągnąć taki stan w organizacji oraz jakie są potrzebne do tego umiejętności. Nie zabraknie też informacji - z jakimi wyzwaniami zmagają się architekci w swojej pracy.

CASE STUDY Centrum Systemów Informacyjnych Ochrony Zdrowia

Ochrona Zdrowia to korporacja obejmująca obszar i populację całego naszego kraju. W liczbach przedstawia się następująco: użytkownicy końcowi ponad 38 mln, podmioty systemu ochrony zdrowia: podmioty lecznicze ponad 20 tysięcy, praktyki zawodowe lekarzy i lekarzy dentystów ponad 121 tysięcy, praktyki zawodowe pielęgniarek i położnych ponad 22 tysięcy, apteki i punkty apteczne ponad 16 tysięcy, pracownicy medyczni ponad 500 tys. W prezentacji zostaną poruszone zagadnienia:

• Źródła decyzji o wdrażaniu architektury korporacyjnej
• Nasze podejście do ładu i architektury korporacyjnej
• Architektura w projektach typu PRINCE to Agile
• Spodziewane korzyści dla biznesu

CASE STUDY BZ WBK

Praca w roli architekta to zarówno wyróżnienie, ale i szereg wyzwań. Dla właściciela biznesowego projektu, zarządzającego portfelem projektów, czy wreszcie – dla przysłowiowego biznesu,  architekt to problematyczny partner. Owszem, architekt bywa przydatny na etapie projektowania rozwiązania, ale często towarzyszy temu percepcja, w której:

• architekt forsuje wyrzeczenia (i koszty!) *teraz* w imię korzyści *kiedyś*.
• architekt usiłuje powiązać Projekt z innymi inicjatywami, rozszerzając zakres i dewastując harmonogram.
• architekt próbuje narzucać systematyki/formalizmy/taksonomie, których „biznes” nie lubi, nie potrzebuje i nie rozumie.

Agenda architekta jest często – w krótkoterminowym ujęciu – w konflikcie z agendą inicjatora zmiany, i niekoniecznie jest zrozumiała dla otoczenia i dla sponsora zmiany. W związku z tym wszelkie strategie, taktyki i narzędzia promowania i objaśniania perspektywy architektonicznej mają pierwszorzędne znaczenie w naszej codziennej pracy.

W naszej prezentacji dokonamy krótkiego przeglądu narzędzi, jakimi dysponuje Architekt. Szczególną uwagę będziemy chcieli zwrócić na technikę analizy luk. Prezentacja będzie oparta o nasze bardzo praktyczne doświadczenia z banku, w którym trwa Transformacja Cyfrowa.

WYNIKI BADANIA "Systemy legacy w Polsce"

Praktycznie każda większa organizacja dorobił się już co najmniej jednej „strucli”. Zazwyczaj jest to średni lub duży system, który został napisany kilka-kilkanaście lat temu i od tego czasu mocno się rozrósł (jeżeli chodzi o zakres funkcjonalności). Obecnie nie istnieje jego aktualna dokumentacja, kod źródłowy jest co najwyżej średniej (jak nie słabej) jakości, zastosowana architektura nie jest zgodna z żadnymi wzorcami projektowymi, technologia w której ten system został stworzony swoje lata świetności ma już dawno za sobą, zaczynają występować problemy z dostępem do zasobów ludzkich mogących rozwijać ten system, czas wprowadzania zmian w tym systemie zaczyna się mocno wydłużać, nie mówiąc o braku możliwości automatyzacji procesu wytwórczego systemu…

Z drugiej strony biznes, pomimo swoich ciągłych narzekań, przyzwyczaił się już do tego systemu, ceni jego silne dopasowanie do specyfiki firmy (co realizowane jest albo bezpośrednio – za pomocą jego kastomizacji, albo za pomocą dziesiątków mniejszych i większych aplikacyjek, którymi on obrósł przez ostatnie lata, albo i tego i tego), ceni stosunkową stabilność rozwiązania (chociaż pracuje ono z roku na rok coraz wolniej).

I w którymś momencie pojawia się pytanie – co dalej w takiej sytuacji? Są różne strategie postępowania – od niedostrzegania problemu do uruchomienia wielkiego programu transformacyjnego. Jedno jest pewne – praktycznie każda z nich, w przypadku niepowodzenia, może zakończyć się uwolnieniem potencjału aktualnego dyrektora IT na rynek. W prezentacji będę starał się udzielić odpowiedzi – czy i jak architekt może pomóc walczyć z takimi struclami.

Today, IT disruptions aren’t just weather-related disasters. Power outages, ransomware and even deploying new infrastructure can cause issues for IT. With the need for continuous availability organization need to be able to respond to a disruption so quickly that end-users and customers are not aware that a disruption occurred.

Organizations that take a proactive approach to BC/DR, focus on continuous availability rather than recovery after the fact. Automation and simplification of replication and recovery are part of resilience, and ensure that companies can prove the availability of their applications and data at any time. Join us to learn:

• How IT Resilience is different from Disaster Recovery
• How to achieve IT Resilience
• How to seamlessly recovery from anything

Współdziałanie Architektów korporacyjnych/IT z obszarem projektowym trwa już w Polsce kilka lat. Wydaje się, że jest to dobry moment na podsumowanie zarówno udanych elementów współpracy, jak i porażek.  W ramach wystąpienia zaprezentuję  wzorce i antywzorce, które spotkałem w pracach na styku architektury i projektów. Dodatkowo chciałbym przedyskutować wyzwania  architektoniczne pochodzące z projektów zwinnych czy też opartych o technologię Big Data oraz algorytmy uczenia maszynowego.

CASE STUDY Energa - Obrót

Doświadczenia i oczekiwania klientów kształtujące się podczas korzystania z usług globalnych liderów jakości obsługi, przekładają się na oczekiwania względem dostawców usług bankowych, telekomunikacyjnych, sektora użyteczności publicznej, a nawet urzędów. Podczas swojego wystąpienia opowiem o architekturze wspierającej realizację wyzwań związanych z omnichannel i CX na przykładzie branży utilities.

CASE STUDY innogy Polska

W dzisiejszych czasach prawie każda firma jest firmą technologiczną. Bez IT nie da się realizować działalności operacyjnej i rozwoju – zaciera się różnica pomiędzy biznesem a IT. Architektura nie tylko musi rozumieć biznes, ale także musi myśleć jak biznes. W sytuacji, gdy perspektywa planowania jest coraz krótsza, architektura musi odnaleźć się w zwinnym środowisku biznesowym.  Jaką rolę powinna przyjąć w organizacji?  I jakie błędy popełniają architekci?

Bazując na doświadczeniach z działu IT (wcześniej pracując jako Główny Architekt IT) oraz przejścia do działu biznesowego, porównam te dwie perspektywy. Jakiej architektury oczekują osoby odpowiedzialne za realizację projektów wspierających strategię firmy, realizację wyników finansowych i KPI? Opowiem także o oczekiwaniach biznesu w stosunku do architektury na poszczególnych fazach projektu, w różnych metodykach i rozwiązaniach, oraz o tym, jak architektura może się do nich odnieść, ułatwiając – a nie przeszkadzając – w realizacji projektów biznesowych.