Odhady pracnosti

Jak se potýkáte s jejich přesností, jak vysvětlujete managementu proč je to takové nebo makové číslo?

Co kdybyste si museli vybrat z těchto možností? (časová jednotka je na vás)

0, 0.5, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, .. ->Fibonacciho řada (s lehce upraveným začátkem)

Nebo si podobnou řadu upravte  dle svých zkušeností. Pointa je jednoduchá, čím méně čísel se používá a tím jak se jejich rozestupy zvyšují si Vaše okolí rychleji zvykne na související nejistotu.

 

 

 

Školení podzim 2017

Power BI – 20.10.2017 – pátek / 1 den

https://www.eventbrite.com/e/sql-saturday-prague-2017-pre-con-power-bi-in-the-enterprise-deep-dive-tickets-38377128023?aff=efbevent

Shluknuté detailní informace o adiministraci a instalaci Power BI do jednoho dne, za 4 000Kč a kvalita zahraničního speakera garantována komunitou SQL PASS, tady není o čem.

GDPR – každý čtvrtek / 2 dny

https://www.tx.cz/gdpr/poverenec-pro-ochranu-osobnich-udaju

Je na čase získat ucelené povědomí a z pozice DWH se k tomu kvalifikovaně vyjadřovat.

DEVOPS

https://www.tx.cz/devops/master

Lektor má na linkedinu reference na projekťáka a školitele, ale kurz už nějakou dobu běží, tak mu lze dát šanci

nebo

http://www.gopas.cz/Kurzy/Katalog-kurzu/Kurzy-osobniho-rozvoje/Mastering-DevOps-DEVOPSM.aspx

Tento kurz ani nemá lektora uvedeného a popis je z číásti ctrl+c ctrl+v z jiného kurzu.. Ale uvidíme, jak bude gopas aktualizovat, přeci jen to chtějí spustit až lednu 2018.

 

 

 

 

Togaf Foundation – lessons learned

Togaf je architektonický framework, který vede k nižším nákladům na rozvoj a provoz podnikového IT. A to díky ucelenému pohledu na architekturu, přepoužívání funkcí (zamezí duplikaci funkcionalit), jednotnému přístupu pro udržování podnikové architektury, zlešení popisu interface a mnoho dalšího, to celé zasazuje do kontextu konkrétní firmy (při zavedení si framework lze hodně ohýbat a přizpůsobovat).

Více o Togafu celkem pěkně zpracovali lidé z Cleverlance, tak pouze odkaz a teď už jen to, co si odnáším já.

Nepřepálit to

Jedna z prvních věcí, co enterprise architekt udělá po příchodu do firmy je posouzení schopností svého nejbližšího okolí – konkrétně jde o PM, development, operation a security (případně dalších, se kterými bude spolupracovat). Toto posouzení je pak důležitým vstupem pro iniciální nastavení procesu řízení podnikové architektury. Jinými slovy, pokud je EA extra seniorní a přijde do extra juniorní firmy bude navrhovat jen velmi omezenou podobu togafu. V případě, že by to totiž přepálil, velmi reálně hrozí, že se s ostatními pohádá a nic moc do firmy nepřinese.

Toto je široce přepoužitelné a hodí se vědět, že někdy prostě zájem o TOP kvalitu není. A kde o něco není zájem, tam nemá smysl jít proti zdi. Raději po malých krůčcích s ostatními, než po velkých a sám.

V rámci BI stojí za to být připraven snížit maturitu dodávek solution architektury, to znamená mít oprioritizované architektonické principy, modely a metody v kontextu firmy tak, abyste mohli škrtat. Raději mít BI řešení s nižší maturitou, ale za to přijatelné pro ostatní stakeholdery. Zároveň platí, že každý si musí posoudit, co chce dělat, protože takové komplexní BI řešení s nejnižší možnou maturitou není žádný med (spíše se jedná o krev, slzy a pot). Stejně tak je dost obtížně mít proměnlivou kvalitu jednotlivých rozšíření DWH.

Architecture Repository

Togaf pro enterprise architekta vymyslel, co všechno ke své práci potřebuje a jak v tom mít alespoň trochu pořádek. Podle mě je to dobré a pro sebe (byť nejsem EA) implementuji – Architecture Method (Přehled všech artefaktů a jejich šablon, které jsem zvyklý používat), Architecture Landscape (ve smyslu uchovávání přepoužitelného know- how z projektů), Reference Library (různé zajímavé materiály, co se ke mně kdy dostaly). Dál se uvidí. (jednoduše jde o to, jak si (klidně i do složek) rozstřídit informace a být schopný v nich rychle dohledat a přepoužít co je třeba).

Togaf repository

 

Architecture artifacts

Přehled architektonických artefaktů asociovaných s core content metamodel and extensions (ještě teď jsem rád, že lektor dokázal velmi jednoduše vyložit někdy kostrbaté definice Togafu). Tahle tabulka je skvělá, dá se na ní velmi dobře ukázat, jak je na tom daná firma z pohledu architektury ve smyslu, co z těchto informací se někde eviduje. Umíte ve Vaší korporaci najít jen jeden nebo dva artefakty? Pak zřejmě platíte za IT práce více, než byste museli a počítejte, že analýza AS-IS stavu se prodraží. Samozřejmě pro použití v BI Solution architektuře bude nutné proškrtat a doplnit.

Artifacts Associated with the Core Content Metamodel and Extensions

Standardy a jiná pravidla

Jedním z výhod EA je, že dává dohromady požadavky na architektonickou a analytickou fázi napříč celou organizací. Díky sjednocení technologií je pak možné mít i jednotné požadavky na kvalitu implementace (ať už je proces testingu nebo struktura komentářů v kódu nebo něco jiného).

Ať už jste ve firmě EA, ať jste Solution architekt, vývojář, dodavatel nebo interní, vždy se vyplatí mít vlastní repository pro platné standardy. Mít totiž k ruce Togaf, ISA, ale i nějaká doporučení pro psaní kódu apod. zvyšuje šanci, že až budete na vážkách poradíte se s těmito standardy a výstup Vaší práce bude o něčem jiném.

V této kapitole úmyslně nepoužívám pojem Information Standard Base, který je v architecture repository v Togafu, protože jde spíše o jeho lehkou modifikaci.

A fool with a tool is still a fool

Při hledání dalších informací na internetu jsem narazil na tohle moudro, to je dobrá tečka na závěr!