vývoj aplikací

Vývoj aplikací po roce 2009 =
mrtvá disciplína?
Ota Novotný
Máme se do vývoje vůbec pouštět?
Mezi 40% a 70%
projektů vývoje aplikací skončí špatně.
Evoluce tradičního vývoje aplikací
1GL
Assemblery
1960's
2GL
COBOL &
Fortran
1970's
3GL & 4GL
Strukturované
programování
1980's
Objektově
orientované
"Component
Based"
1990's
Business vyžaduje nové přístupy ke tvorbě
aplikací
Požadavky na
vývoj
Požadavky
Businessu
• Sniž a stabilizuj
čas průběhu
každého z
procesů
• Stanov jasné cíle
v oblasti redukce
času průběhu
procesu a
"prodej" je zbytku
firmy
Cíl
Doba vývoje
Rok
• Vyber a
zjednoduš klíčové 2002
procesy vývoje
60 dní
30 dní
2004
2006
2008
2010
2012
14 dní
7 dní
3 dny
ten samý den
• Sleduj a měř
hodnotu portfolia
aplikací pro
business procesy
• Změň se abys mohl
pomáhat businessu
v jeho plánech a
zachyť posun od
"programování" k
dalším způsobům
vývoje
• Zpomal abys mohl
zrychlit; nové agilní
architektury
Evoluce 'Business-Centric' vývoje aplikací
Distribuované
N-vrstevné
Servisně-orientované
?
Co budeme potřebovat pro IT řešení nové
generace?
Softwarové
služby
Vývojové
nástroje
Servisněorientované
architektury
Nástroje pro
řízení vývoje
a provozu
Dovednosti
a školení
"Dodávka a nasazení aplikací" bude v
nejbližší době stále aktuální
Posvátná aplikace!
Kompozice! Nikoliv aplikace!
Data
Messaging
Security
Logic
Management
Navigation
UI
Řízené dodavatelem aplikací
Známé platformy
Známé technologie
Známí dodavatelé
Explicit
Orchestration
Logic Data
Logic Data
Logic Data
Messaging
Network
Network
•
•
•
•
Navigation
•
•
•
•
Volná množina služeb
Explicitní orchestrace
Ztráta kontroly
Mnoho neznámých
Management
Security
UI
Lidé budou sice stále říkat 'Aplikace', ale
'Kompozice' se už dávno stávají standardem
Kompozice! Nikoliv aplikace!
Security
Navigation
Explicit
Orchestration
Logic Data
Logic Data
Logic Data
Messaging
Network
Volná množina služeb
 Explicitní orchestrace
 Ztráta kontroly
 Mnoho neznámých

Management
UI
Standardy ovlivňující vývoj aplikací
budou přicházet z mnoha různých stran
Technologie & Architektury
• Offline Ajax
• Všudypřítomný signál
• Neutrální sítě
Společnost & Sociální
oblasti
• Televize
• Mapy/lokalizace
• OSS aplikace
Business & Procesy
• Jednoduchý workflow
• Virtuální podniky
Budou založeny na požadavcích na dobrou službu jako celek, nikoliv jenom IT.
Reuse (znovupoužitelnost): Málo používaný klíč
potřebný k využití potenciálu služeb
Prvky reuse programu
Inventář
CREATE
ORDER
CUST
ORDER
ITEM
PROD
Zajištění kvality
ORDER
DB
Řízení
metadat
Metodologie
Standardy a
principy
Měření
Katalog/publikace
Pobídky/odměny
Využití Legacy aplikací pro zvýšení
efektivnosti? Prostě se jich nezbavíme!
Stavební prvky
aplikací v minulosti
Stavební prvky
aplikací v současnosti
Služby
Business
funkce 1
Business
funkce 2
Prvky na míru Balíky
(Packages)
Business aplikace
Business
funkce 3
Business Proces
Legacy aplikace se stávají novým aktivem —
schované za vrstvou kompozitních služeb a procesů
HR
Spustitelné
procesní
modely
Finance
Procení model
Procení model
HR
mezi HR a
financemi
Služby
Procení model
Rozpočtování
Zákaznické služby
Procení model
Zákaznická
služba #1
Služba
Legacy
logika
a data
Procení model
Zákaznická
služba #2
Služba
Služba
Služba
Ostatní
Služba
Služba
Logic
Logika
Data
HR
Legacy
Aplikace
Data
Logika
Finanční
Legacy
aplikace
Logika
Data Logika
Data
Zákaznické
Legacy
aplikace
Data
Ostatní
App
Nástroje pro vývoj aplikací v 21. století
budou zaměřeny na…
• Best practices agilního vývoje jsou důležitější než
stabilita technologie
• Techniky rapidní údržby/změn aplikací (Rapid
application maintenance - RAM)
• Techniky a technologie vývoje orientované na
procesy (jako je ISE a BPP)
• Integrované nástroje pro řízení životního cyklu
aplikace
• Znovuobnovený zájem o využití zkušeností
uživatelů vyvolaný ve velké míře koncepty Web
2.0 (jako je Ajax a kompozitní aplikace)
Gartner hype křivka – vývoj aplikací
Visibility
Technology
Trigger
Peak of
Inflated
Expectations
Trough of
Disillusionment
Slope of
Enlightenment
Plateau of
Productivity
Vývoj aplikací je komplexní disciplína a
musí ji dělat profesionálové
Obsah
Interface
Vývoj
Databáze
Runtime topologie
Vývoj aplikací je komplexní disciplína a
musí ji dělat profesionálové
Vizuální
Definice požadavků
Analýza pokrytí
Interface aplikace
/package
Sémantika dat
Web servery
Application servery
Transakční monitory
Firewally
Browsery
Applety
Servlety
Personalizace
Multikanálový obsah
Sledovat/řídit obsah
Agregace
Řízení verzí
vývoj/konstrukce
ASP/JSP
HTML/Java/Windows
GUI
Dynamický obsah
Grafický design
Applety
Obsah
Interface
Vývoj
Databáze
Runtime topologie
RDBMS
Replikace
Database gateways
Synchronizace dat
Datové modelování
JDBC/ODBC
XML
Faktem je, že už po řadu let vývoj aplikací
jenom profesionálové nedělají!
A tohle všechno je čím dále tím přístupnější širokým masám!
Webkinz nejsou jenom
pro zábavu
Děti se baví o firewallech
Slyšeli jste někdy o "mashups"?
Code generation?
Kompozitní aplikace.
MY
Modelování
Automatizace procesů
Web designéři
Power users
Vývojáři v ne IT odděleních
Faktem je, že už po řadu let vývoj aplikací
jenom profesionálové nedělají!
Faktem je, že už po řadu let vývoj aplikací
jenom profesionálové nedělají!
Až budeme mít dost
možností pro "skládání ",
stanou se z nás kuchaři
— nikoliv vývojáři!
Řízení portfolia: Zvážit všechny možnosti
Tolerovat
Integrovat
K dispozici
Tolerovat
Dostupnost znalostí
a dovedností
Eliminovat/Migrovat
Vysoká
Omezené
Eliminovat
Nízká
Má budoucnost
Nemá budoucnost
Technologická Platforma
Enterprise architektura musí být řízena v IT a
podle potřeby v oblasti vývoje aplikací
Business strategie
Trendy
Řízení vývoje architektury
Návrh architektury
Vývoj
požadavků
Vývoj
principů
Vývoj
modelů
Budoucí stav architektury
Governance a řízení
Současný stav architektury
Dokumentace
Řešení/zaplnění
nedostatků
Rozhodování prostřednictvím Governance
postupů
Řízení portfolia
Rozhodování o nasazení
Technologická
architektura
Aplikační
architektura
Business
architektura
Způsoby, postupy a metody
Finanční řízení
Řízení lidských
zdrojů
Faktor neúspěchu v SPI: Chybějící vize
Definuj vizi
Komunikuj
vizi
Průběžná zpětná
vazba
Prováděj
změny
CEO
Vyhodnocuj
výsledky
HR
CIO
a1
2a
CFO
3a
3b
Faktor neúspěchu v SPI: Přerušená
kontinuita podpory managementu
Typické akce v SPI:

Začínají rozhodnutím
managementu

Začínají velkým
"rámusem" a následnou
pozorností celé firmy

Trvají mnoho let

Týkají se řady manažerů
v různých oblastech
firmy

Týkají se mnoha
manažerů v oblasti
vývoje aplikací
(doménách)
Dokud…
 Procesy byly explicitně
změněny
 Je dosaženo písemné SLA
mezi businessem a
vývojem aplikací
 Relationship manažeři
fungují na rozhraní mezi
businessem a vývojem
aplikací
 Jak vývoj aplikací, tak
business používá
pravidelně metriky
 Incentivy nebo
kompenzace jsou
explicitně uplatňovány
Doporučení
 Přestat myslet jenom v pojmech aplikace. Začít
vždy nejdříve myslet na kompozice.
 Hledat ne-technologické pracovníky, kteří by se
podíleli na procesu vývoje.
 Žít reuse. Očekávat reuse. Oceňovat reuse.
Nečekat, že to přijde samo.
 Nebát se Legacy. Použít je k vytvoření nové
hodnoty.
 Procesní myšlení vyžaduje zaměřit se na procesy.
Nabírejte vývojáře, kteří tohle umí.
Kontakt
KPC-Group, s.r.o.
Zastoupení Gartner
Jeremiášova 769,
155 00 Praha 5,
Czech Republic
T: +420 257 322 524,
F: +420 257 325 085
E: [email protected]