Solution Architect – MASTER

Účel projektu

Solution Architect je profesijný, metodický a projektový rámec pre prácu riešiteľského architekta.

Jeho úlohou je spájať potreby človeka, klienta alebo organizácie s technickým, procesným, obchodným a prakticky realizovateľným riešením.

Solution Architect nie je iba programátor.
Nie je iba analytik.
Nie je iba projektový manažér.
Nie je iba konzultant.

Je to človek, ktorý musí vedieť pochopiť problém, rozlíšiť skutočnú potrebu od povrchovej požiadavky, navrhnúť riešenie, vysvetliť ho rôznym ľuďom a ustrážiť, aby sa z dobrého zámeru nestal technický alebo organizačný chaos.

Hlavná myšlienka

Základná myšlienka projektu:

Dobré riešenie nevzniká tak, že niekto napíše kód. Dobré riešenie vzniká tak, že niekto najprv správne pochopí problém.

Solution Architect má byť mostom medzi svetmi:

• medzi klientom a vývojárom,
• medzi obchodom a technológiou,
• medzi predstavou a realitou,
• medzi požiadavkou a riešením,
• medzi chaosom a modelom,
• medzi modelom a realizáciou,
• medzi slovami a zodpovednosťou.

Jeho úloha je jednoduchá povedať, ale ťažká robiť:

Zmeniť nejasnú potrebu na bezpečne realizovateľné riešenie.

Charakter projektu

Projekt Solution Architect slúži ako pracovný rámec pre:

• profesijnú identitu,
• metodiku práce,
• klientsku komunikáciu,
• analýzu potrieb,
• návrh riešení,
• systémovú architektúru,
• procesné modelovanie,
• technické rozhodnutia,
• dokumentáciu,
• preflight pravidlá,
• riadenie rizík,
• a spoluprácu s AI nástrojmi.

Tento projekt prepája viacero ďalších projektov, najmä:

• ACONIS,
• Správca súborov,
• DREMONT,
• SinTrade.Company,
• TOPTOUR-Core,
• cascadya.pro,
• ChatForest,
• Jarmok,
• Dr.Fyto,
• Osobný kalendár vitality,
• WordPress vývojové projekty.

Kto je Solution Architect

Solution Architect je človek, ktorý dokáže stáť medzi víziou a realizáciou.

Musí rozumieť:

• problému,
• ľuďom,
• procesu,
• dátam,
• technológii,
• rizikám,
• peniazom,
• prevádzke,
• a následkom rozhodnutí.

Nie vždy musí byť najlepší programátor v miestnosti.
Ale musí vedieť položiť otázku, ktorá zabráni tomu, aby sa programovalo nesprávne riešenie.

Dôležitá veta:

Solution Architect nemusí vedieť všetko spraviť vlastnými rukami, ale musí vedieť, čo sa má spraviť, prečo, v akom poradí a s akými rizikami.

Základné zodpovednosti

Solution Architect má niesť zodpovednosť najmä za:

• pochopenie cieľa,
• pomenovanie skutočného problému,
• odlíšenie požiadavky od potreby,
• návrh riešenia,
• rozdelenie riešenia na etapy,
• výber vhodnej technológie,
• návrh dátového modelu,
• návrh procesov,
• bezpečnostné a prevádzkové hľadisko,
• komunikáciu s klientom,
• komunikáciu s vývojárom,
• kontrolu rozsahu,
• dokumentáciu rozhodnutí,
• rizikové scenáre,
• a udržateľnosť riešenia.

Čo Solution Architect nerobí

Solution Architect nemá byť človek, ktorý na seba berie všetko.

Nemá:

• robiť všetku prácu za klienta,
• hasiť každý chaos bez dohody,
• programovať naslepo,
• sľubovať nemožné,
• robiť zadarmo každú nadprácu,
• nahrádzať projektový manažment tam, kde ho klient odmieta,
• niesť zodpovednosť za rozhodnutia, ktoré klient nechce urobiť,
• opravovať nejasné dohody bez ich pomenovania,
• mlčať o rizikách len preto, aby bol pokoj.

Dôležitá zásada:

Architekt riešenia nesmie byť obetný baránok za neochotu pomenovať problém.

Požiadavka verzus potreba

Klient často príde s požiadavkou.

Napríklad:

• chcem formulár,
• chcem portál,
• chcem CRM,
• chcem upload súborov,
• chcem aplikáciu,
• chcem web,
• chcem automatizáciu.

Solution Architect sa musí pýtať, aká potreba za tým stojí.

Príklad:

Požiadavka:

Chcem, aby klienti mohli nahrávať súbory.

Skutočné potreby môžu byť:

• nechceme zahltené e-maily,
• potrebujeme bezpečne prijímať veľké súbory,
• potrebujeme vedieť, kto čo poslal,
• potrebujeme mať súbory pri zákazke,
• potrebujeme znížiť chaos,
• potrebujeme dôkaz, že podklady boli dodané.

Z toho vzniká úplne iné riešenie než obyčajný upload formulár.

Riešenie ako systém

Dobré riešenie nie je zoznam funkcií.

Dobré riešenie je systém.

Systém má:

• používateľov,
• roly,
• procesy,
• dáta,
• rozhodnutia,
• stavy,
• pravidlá,
• oprávnenia,
• výnimky,
• riziká,
• prevádzku,
• a hranice.

Solution Architect musí vidieť celok.

Ak vidí iba jednu funkciu, môže navrhnúť niečo, čo lokálne funguje, ale systémovo škodí.

Metodika práce

Základný pracovný postup Solution Architecta môže vyzerať takto:

1. pochopiť kontext,
2. vypočuť klienta,
3. oddeliť požiadavky od potrieb,
4. pomenovať cieľ,
5. opísať aktuálny stav,
6. navrhnúť cieľový stav,
7. identifikovať riziká,
8. rozdeliť riešenie na etapy,
9. určiť MVP,
10. navrhnúť dátový a procesný model,
11. pripraviť rozhodnutia,
12. pripraviť technické zadanie,
13. kontrolovať realizáciu,
14. dokumentovať zmeny,
15. vyhodnotiť výsledok.

Kontext

Pred návrhom riešenia treba pochopiť kontext.

Otázky:

• kto je klient,
• čo robí,
• pre koho to robí,
• aký má problém,
• čo ho bolí,
• čo už skúšal,
• čo funguje,
• čo nefunguje,
• kto rozhoduje,
• kto bude systém používať,
• aké sú peniaze,
• aký je čas,
• aké sú limity.

Bez kontextu sa ľahko navrhne technicky pekné, ale prakticky zbytočné riešenie.

Analýza problému

Solution Architect musí vedieť pomenovať problém.

Nie všeobecne:

Máme chaos.

Ale konkrétne:

• súbory prichádzajú rôznymi kanálmi,
• nikto nevie, ktorá verzia je aktuálna,
• klienti nevedia, kam čo poslať,
• správca nevie, kto čo už dodal,
• neexistuje stav spracovania,
• nie je jasné, čo je v paušáli a čo je nadpráca.

Dobre pomenovaný problém je polovica riešenia.

AS IS / TO BE / WHAT IF

Solution Architect prirodzene využíva metodiku ACONIS.

AS IS

Popisuje aktuálny stav.

Otázky:

• ako to funguje dnes,
• kto čo robí,
• čo bolí,
• kde vzniká chaos,
• čo je ručné,
• čo je nejasné,
• čo je rizikové.

TO BE

Popisuje cieľový stav.

Otázky:

• ako to má fungovať,
• čo sa zjednoduší,
• čo sa automatizuje,
• kto čo bude robiť,
• aký bude výsledok.

WHAT IF

Skúma riziká.

Otázky:

• čo ak klient nedodá podklady,
• čo ak používateľ urobí chybu,
• čo ak systém vypadne,
• čo ak sa zmení rozsah,
• čo ak rozpočet nestačí,
• čo ak technológia prestane byť vhodná.

MVP myslenie

Solution Architect musí vedieť navrhnúť MVP.

MVP nie je lacná polovičatá verzia.
MVP je najmenší funkčný krok, ktorý overí hodnotu riešenia.

Otázka MVP:

Čo najmenšie vieme vytvoriť tak, aby sme overili, či riešenie skutočne pomáha?

Pri MVP treba rozlíšiť:

• nutné teraz,
• dôležité neskôr,
• pekné, ale nepotrebné,
• rizikové,
• mimo rozsahu.

MVP chráni projekt pred tým, aby sa hneď na začiatku zmenil na mamuta v papučiach.

Etapizácia

Každé väčšie riešenie treba rozdeliť na etapy.

Etapy môžu byť:

1. analýza,
2. návrh,
3. MVP,
4. interné testovanie,
5. pilotné nasadenie,
6. opravy,
7. rozšírenie,
8. dokumentácia,
9. prevádzka,
10. optimalizácia.

Etapizácia pomáha:

• kontrolovať rozpočet,
• kontrolovať riziká,
• vysvetliť klientovi postup,
• zabrániť chaosu,
• a nestratiť cieľ.

Rozsah a hranice

Solution Architect musí strážiť rozsah.

Najmä pri klientskych projektoch treba rozlišovať:

• čo je súčasťou dohody,
• čo je nad rámec,
• čo je nový vývoj,
• čo je údržba,
• čo je chyba,
• čo je zmena zadania,
• čo je klientovo rozhodnutie,
• čo je technická nevyhnutnosť.

Dôležitá zásada:

Nejasná hranica rozsahu je najrýchlejšia cesta k únave, nespokojnosti a neplateným nadprácam.

Technologické rozhodnutia

Solution Architect má navrhovať technológiu podľa potreby, nie podľa módy.

Otázky:

• je WordPress vhodný,
• stačí plugin,
• treba vlastné tabuľky,
• treba samostatnú aplikáciu,
• treba API,
• treba mobilnú aplikáciu,
• stačí PWA,
• je hosting dostatočný,
• čo zvládne klient spravovať,
• aké sú náklady na údržbu.

Dôležitá zásada:

Najlepšia technológia je tá, ktorú projekt unesie aj o rok.

WordPress ako praktická platforma

Mnohé používateľove projekty prirodzene využívajú WordPress.

WordPress môže byť vhodný pri:

• webových prezentáciách,
• klientskych portáloch,
• admin rozhraniach,
• jednoduchých databázových systémoch,
• prototypoch,
• interných nástrojoch,
• BetterDocs / KB,
• WooCommerce,
• Tutor LMS,
• vlastných pluginoch.

Treba však rozlišovať, kedy WordPress stačí a kedy už projekt potrebuje samostatnejšiu architektúru.

Vlastné pluginy

Pri vlastných WordPress pluginoch musí Solution Architect riešiť:

• účel pluginu,
• hranice pluginu,
• dátový model,
• roly,
• oprávnenia,
• admin UI,
• front-end UI,
• bezpečnosť,
• aktualizácie,
• export/import,
• kompatibilitu,
• dokumentáciu,
• verzie,
• changelog,
• rozhodnutia.

Plugin nemá byť len miesto, kam sa postupne nahádžu funkcie.

Má mať jasné jadro.

Dáta

Dátový model je základ riešenia.

Treba sa pýtať:

• čo je hlavný objekt,
• aké má vlastnosti,
• s čím súvisí,
• kto ho vytvára,
• kto ho mení,
• kto ho vidí,
• kto ho maže,
• ako sa archivuje,
• ako sa exportuje,
• čo je citlivé,
• čo je verejné.

Dôležitá zásada:

Ak nevieme pomenovať dáta, nevieme bezpečne navrhnúť systém.

Roly a oprávnenia

Takmer každý systém potrebuje roly.

Príklady rolí:

• administrátor,
• klient,
• dodávateľ,
• obchodník,
• správca projektu,
• interný používateľ,
• verejný návštevník,
• editor,
• schvaľovateľ.

Každá rola má mať jasné práva.

Zásada:

Používateľ má mať právo robiť to, čo potrebuje, nie všetko, čo systém technicky umožňuje.

Bezpečnosť

Bezpečnosť nie je doplnok na konci.

Musí byť súčasť návrhu od začiatku.

Riešiť treba:

• prihlásenie,
• oprávnenia,
• súbory,
• osobné údaje,
• citlivé obchodné údaje,
• zálohy,
• logovanie,
• ochranu formulárov,
• ochranu API,
• aktualizácie,
• licencie,
• prístup tretích strán.

Dôležitá zásada:

Funkcia, ktorá obchádza bezpečnosť, nie je skratka. Je to dlh s úrokom.

Prevádzka a údržba

Solution Architect musí myslieť aj na prevádzku.

Otázky:

• kto bude systém spravovať,
• kto bude robiť aktualizácie,
• kto rieši chyby,
• ako sa zálohuje,
• kto obnoví systém pri páde,
• čo stojí údržba,
• čo je v paušáli,
• čo je nad rámec,
• čo sa stane po roku.

Riešenie, ktoré sa nedá udržať, nie je dobré riešenie.

Dokumentácia

Dokumentácia má byť súčasť riešenia.

Nie ako román, ktorý nikto nečíta, ale ako praktická pamäť projektu.

Dokumentácia môže obsahovať:

• MASTER článok,
• zadanie,
• rozhodnutia,
• dátový model,
• procesy,
• roly,
• bezpečnostné pravidlá,
• changelog,
• otvorené otázky,
• technické poznámky,
• používateľský návod,
• prevádzkové poznámky.

Dôležitá veta:

Dokumentácia nie je preto, aby niekto čítal všetko. Je preto, aby sa v správnej chvíli našlo to podstatné.

Rozhodnutia

Každé dôležité rozhodnutie treba evidovať.

Rozhodnutie má obsahovať:

• dátum,
• problém,
• možnosti,
• vybrané riešenie,
• dôvod,
• riziká,
• dopad,
• kto rozhodol,
• čo treba sledovať.

Rozhodnutie bez dôvodu je budúci zmätok.

Changelog

Changelog je technická aj projektová pamäť.

Mal by zachytiť:

• čo sa zmenilo,
• kedy,
• prečo,
• kto to požiadal,
• čo to ovplyvnilo,
• či vzniklo riziko,
• či vznikla nadpráca.

Pri vývoji vlastných pluginov je changelog nevyhnutný.

Preflight

Preflight je povinný ochranný princíp pred technickou prácou.

Pred zásahom treba overiť:

• aktuálny projekt,
• prostredie,
• repozitár,
• vetvu,
• verziu,
• názvy súborov,
• existujúce triedy a funkcie,
• závislosti,
• posledné rozhodnutia,
• otvorené riziká.

Dôležitá zásada:

Predtým, než opravíš lietadlo za letu, pozri sa, či sedíš v správnom lietadle.

Preflight je zvlášť dôležitý pri práci s AI nástrojmi ako Copilot.

AI ako spolupracovník

AI môže byť veľmi silný pomocník Solution Architecta.

Môže pomáhať:

• triediť požiadavky,
• navrhovať architektúru,
• generovať dokumentáciu,
• písať kód,
• kontrolovať chyby,
• pripravovať checklisty,
• sumarizovať rozhodnutia,
• tvoriť klientské texty,
• hľadať riziká.

Ale AI nesmie byť slepo nasledovaná.

Zásada:

AI môže zrýchliť prácu, ale nesmie preskočiť zodpovednosť.

Solution Architect musí overovať, či AI pracuje so správnym stavom projektu.

Spolupráca s Copilotom

Pri práci s Copilotom treba byť zvlášť opatrný.

Riziká:

• pracuje so zastaraným kontextom,
• vymyslí názvy súborov,
• opraví neexistujúci problém,
• prepíše viac, než treba,
• nerozlíši vetvu,
• nerozumie obchodnému rozhodnutiu,
• vytvorí technický dlh,
• navrhne nebezpečný príkaz.

Preto treba používať preflight pravidlá a presné zadania.

Klientská komunikácia

Solution Architect musí vedieť hovoriť s klientom tak, aby klient rozumel rozhodnutiu.

Klient často nepotrebuje vedieť, ako presne funguje databázová tabuľka.
Potrebuje vedieť:

• čo tým získa,
• čo to stojí,
• čo sa zjednoduší,
• čo sa stane, ak to neurobí,
• aké sú riziká,
• čo je v cene,
• čo je nad rámec,
• kedy bude ďalší krok.

Dôležitá zásada:

Klient nemusí rozumieť technológii, ale musí rozumieť dôsledkom rozhodnutia.

Jednoduchý jazyk

Solution Architect má prekladať zložité veci do jednoduchého jazyka.

Nie preto, aby ich zjednodušoval hlúpo.
Ale preto, aby ich spravil rozhodnuteľnými.

Nevhodné:

• zahltiť klienta technickými pojmami,
• dokazovať odbornosť slovníkom,
• tváriť sa, že nejasnosť je múdrosť.

Vhodné:

• pomenovať problém,
• ukázať možnosti,
• povedať riziká,
• odporučiť ďalší krok.

Obchodný rozmer

Každé riešenie má obchodný rozmer.

Solution Architect musí vidieť:

• hodnotu práce,
• cenu vývoja,
• cenu údržby,
• návratnosť,
• riziko neplatených nadprác,
• hranicu paušálu,
• licencie,
• hosting,
• dodatočné náklady,
• dlhodobú udržateľnosť.

Riešenie, ktoré technicky funguje, ale obchodne ničí dodávateľa alebo klienta, nie je dobré riešenie.

Paušál verzus nadpráca

Pri klientskych projektoch je dôležité rozlišovať paušál a nadprácu.

Paušál môže zahŕňať:

• bežnú údržbu,
• základný dohľad,
• malé opravy,
• aktualizácie,
• technickú podporu v dohodnutom rozsahu.

Nadpráca zahŕňa:

• nové funkcie,
• nové moduly,
• rozsiahle úpravy,
• integrácie,
• analýzy,
• dokumentáciu,
• vlastné pluginy,
• špeciálne riešenia.

Zásada:

Ak riešenie vytvára novú hodnotu, treba sa pýtať, či nejde o nadprácu.

Rizikové myslenie

Solution Architect musí myslieť na riziká skôr, než sa prejavia.

Riziká môžu byť:

• technické,
• obchodné,
• bezpečnostné,
• ľudské,
• procesné,
• právne,
• finančné,
• prevádzkové,
• reputačné.

Otázka:

Čo sa stane, ak sa veci nepohnú podľa ideálneho scenára?

To nie je negativizmus.
To je zodpovednosť.

Kvalita riešenia

Kvalitné riešenie je také, ktoré:

• rieši skutočný problém,
• je pochopiteľné,
• je udržateľné,
• má jasné roly,
• má bezpečné dáta,
• má primerané náklady,
• dá sa rozvíjať,
• má dokumentáciu,
• a dá sa vysvetliť.

Krásne riešenie, ktoré nikto nepoužíva, je len drahá dekorácia.

Etika riešenia

Solution Architect má niesť aj etickú zodpovednosť.

Nemal by navrhovať riešenia, ktoré:

• zbytočne sledujú ľudí,
• zbierajú nadbytočné údaje,
• manipulujú používateľa,
• zakrývajú riziká,
• vytvárajú závislosť bez potreby,
• predstierajú bezpečnosť,
• zavádzajú klienta,
• alebo zneužívajú nevedomosť používateľov.

Dôležitá zásada:

Technicky možné neznamená automaticky správne.

Prepojenie s ACONIS

ACONIS je metodický základ pre Solution Architect.

Pomáha najmä pri:

• AS IS,
• TO BE,
• WHAT IF,
• procesoch,
• roliach,
• dátových modeloch,
• rizikách,
• rozhodnutiach,
• dokumentácii.

Solution Architect používa ACONIS ako pracovný aparát.

Prepojenie so Správcom súborov

Správca súborov je praktický príklad riešenia, kde je rola Solution Architecta kľúčová.

Treba riešiť:

• potrebu klienta,
• roly,
• oprávnenia,
• súbory,
• bezpečnosť,
• upload,
• zdieľanie,
• logovanie,
• úložisko,
• GDPR,
• MVP,
• prepojenie s klientskymi projektmi.

Prepojenie s DREMONT

DREMONT je klientsky projekt, kde Solution Architect pomáha rozlišovať:

• paušál,
• nadpráce,
• licencie,
• web,
• hosting,
• Správcu súborov,
• bezpečnosť,
• mobilné UI,
• klientské rozhodnutia,
• technickú architektúru.

Prepojenie so SinTrade.Company

SinTrade.Company potrebuje Solution Architect vrstvu pri návrhu:

• obchodného systému,
• CRM logiky,
• dopytov,
• ponúk,
• produktov,
• zákazníkov,
• dodávateľov,
• cenotvorby,
• súborov,
• workflow,
• bezpečnosti.

Prepojenie s TOPTOUR-Core

TOPTOUR-Core potrebuje Solution Architect pri:

• dátových modeloch,
• Reference Finderi,
• cestovateľskom denníku,
• rezidentskom systéme,
• hodnotení zariadení,
• WordPress pluginovej architektúre,
• budúcom CRM smerovaní,
• a technických rozhodnutiach.

Prepojenie s cascadya.pro

cascadya.pro potrebuje Solution Architect pri:

• webovej architektúre,
• projektových príležitostiach,
• dátových modeloch,
• partneroch,
• obchodnom modeli,
• integrácii so Správcom súborov,
• SinTrade.Company,
• ACONIS,
• a evidencii rokovaní.

Prepojenie s ChatForest

ChatForest môže byť pomocným nástrojom Solution Architecta.

Pomáha:

• nájsť staré rozhodnutia,
• vyhľadať technické pokyny,
• dohľadať súvislosti,
• presunúť poznanie do KB,
• rozpoznať zastarané návody,
• udržať kontinuitu projektov.

Prepojenie s Jarmokom

Jarmok prináša Solution Architectovi širšiu hodnotovú vrstvu:

• dôvera,
• kontrakt,
• osoh,
• reputácia,
• spravodlivé plnenie,
• nefinančná hodnota,
• komunitná stabilita.

Pri návrhu systémov je dôležité myslieť nielen na funkciu, ale aj na férovosť vzťahov.

MVP projektu Solution Architect

Prvá praktická verzia projektu môže obsahovať:

• osobný profesijný manifest,
• základnú metodiku práce,
• klientsky dotazník,
• šablónu AS IS,
• šablónu TO BE,
• šablónu WHAT IF,
• šablónu rozhodnutí,
• preflight checklist,
• šablónu MVP,
• šablónu rozsahu a nadprác,
• šablónu technického zadania.

Cieľ MVP:

Vytvoriť praktickú sadu nástrojov, ktorá pomôže meniť nejasné požiadavky na jasné, bezpečné a realizovateľné riešenia.

Budúce moduly

Možné budúce moduly:

• Solution Architect metodika,
• klientsky dotazník,
• technický preflight checklist,
• šablóny rozhodnutí,
• šablóny dokumentácie,
• katalóg rizík,
• architektonické vzory,
• WordPress architektúra,
• pluginová architektúra,
• procesné šablóny,
• obchodné šablóny,
• AI spolupráca,
• Copilot pravidlá,
• projektový dashboard,
• spojenie s ACONIS a ChatForest.

Verejná komunikácia projektu

Projekt možno verejne komunikovať ako:

• rámec pre návrh riešení,
• metodiku riešiteľského architekta,
• most medzi klientom, procesom a technológiou,
• praktický spôsob, ako pred vývojom pochopiť problém,
• systémové myslenie pre malé a stredné projekty.

Nevhodné formulácie:

• vyriešime všetko,
• technológia spraví poriadok sama,
• architekt nepotrebuje klienta,
• AI všetko navrhne za nás,
• vývoj bez analýzy stačí,
• dokumentácia je zbytočná.

Odporúčané podčlánky

Postupne vytvoriť alebo doplniť:

• Solution Architect – profesijný manifest
• Solution Architect – metodika
• Požiadavka verzus potreba
• Klientsky dotazník
• AS IS / TO BE / WHAT IF v praxi
• MVP myslenie
• Etapizácia riešenia
• Rozsah a nadpráce
• Technologické rozhodnutia
• WordPress architektúra
• Vlastné pluginy
• Dátový model
• Roly a oprávnenia
• Bezpečnosť od návrhu
• Prevádzka a údržba
• Dokumentácia riešenia
• Rozhodovací register
• Changelog
• Preflight checklist
• AI a Copilot pravidlá
• Klientská komunikácia
• Obchodný rozmer riešenia
• Katalóg rizík
• Etika riešenia
• Prepojenie s ACONIS
• Prepojenie so Správcom súborov
• Prepojenie s DREMONT
• Prepojenie so SinTrade.Company
• Prepojenie s TOPTOUR-Core
• Prepojenie s cascadya.pro
• Prepojenie s ChatForest

Stav dokumentu

Tento článok je hlavný MASTER dokument projektu Solution Architect.

Slúži ako rozcestník, pracovná mapa a základná definícia profesijného a metodického rámca.

Nie je finálnou certifikačnou metodikou, technickou príručkou ani verejným portfóliom.
Je to živý pracovný dokument, ktorý sa bude dopĺňať podľa reálnych klientskych projektov, technických skúseností, chýb, rozhodnutí, šablón, nástrojov a postupného dozrievania profesijnej identity.

Cieľom projektu Solution Architect je vytvoriť spôsob práce, ktorý pomáha premieňať nejasné potreby na jasné riešenia — s rešpektom k človeku, procesu, technológii, riziku, peniazom a zodpovednosti.