Moderní management závisí na modernosti architektur softwarových systémů

Moderní management závisí na modernosti architektur softwarových systémů Jaroslav Král, Michal Žemlička Department of Software Engineering Faculty of Mathematics and Physics Charles University, Prague Malostranské nám. 25 118 00 Praha 3 e_mail: [email protected], [email protected]

Keywords: systémová integrace, strategický management a peer-to-peer architektura, IS státní správy. Systémová integrace a peer-to-peer systémy. Abstrakt: Práce vrcholového managementu zatím prakticky nezávisela na tom, jak je napsán software (především informační systém), který vrcholový management používá při své práci. Technologické otázky softwarových systémů tedy byly, snad s výjimkou CIO, pro vrcholový management velmi málo významné. Tato situace se nyní mění, neboť proveditelnost mnoha strategických manažerských rozhodnutí a obratů, jako je decentralizace, CRM, vytváření koalic výrobců, různé varianty outsourcingu a BPR obecně, výrazné úspory prostředků na provoz informačních systémů atd., zásadním způsobem závisí na tom, zda mají používané softwarové (informační) systémy moderní architekturu. CEO by proto měl mít dostatek znalostí o vlastnostech a možnostech softwarových architektur důležitých pro jeho práci, aby možnosti moderního softwaru dokázal využívat, ale také proto, aby mohl kvalifikovaně ovlivňovat práci informatických oddělení ve smyslu toho, co má požadovat a jak požadavky formulovat. Použití moderních peer-to-peer architektur zásadním způsobem ovlivňuje práci CIO a také systémových integrátorů.

1. Úvod Technologické aspekty softwaru byly po dlouhou dobu pro práci vrcholového managementu nevýznamné. Pro vrcholový management nebylo důležité, zda jsou data uložena v databázi určitého typu či nikoliv nebo zda je software napsán s využitím objektově-orientované filosofie. Stačilo, aby vrcholový management získal včas informace, které potřeboval. To, jaká bude organizační struktura dané organizace a jaká strategická rozhodnutí budou přijímána, jen málo záviselo na technologických vlastnostech používaného IS. To již přestává být, díky pokroku informačních technologií, pravda. V dnešní době na architektuře softwaru závisí proveditelnost takových strategických rozhodnutí, jako: •

Decentralizace, outsourcing, prodej divizí a jiné formy restrukturalizace podniku,

•

integrace nově získaných organizací/organizačních (pod)jednotek,

•

restrukturalizace podnikových procesů (BPR),

•

moderní obchodní procesy (e-komerce, CRM, SCM, atd.),

•

atd.

Pokusme se nyní diskutovat tyto problémy podrobněji na konkrétním příkladu informačního systému státní správy (e-government).

SYSTEMS INTEGRATION 2003

437

JAROSLAV KRÁL, MICHAL ŽEMLIČKA

2. e-government Základní vlastnosti softwaru, který umožňuje řešení výše uvedených úkolů, jsou nejzřejmější v případě informačních systémů podporujících chod státního aparátu. Cílem e-governmentu je dosažení stavu, kdy se e-government chová jako integrovaný systém s jednotným srozumitelným rozhraním umožňujícím, aby občan mohl např. podat žádost, jejíž vyřízení závisí na více úřadech (např. žádost o stavební povolení), aniž by se staral, které úřady a v jakém pořadí mají žádost vyřizovat. Poněvadž musí e-government pracovat bez přerušení, není technicky schůdné, aby byl e-government rekonstruován tak, že by se celý napsal znovu s jednotnou databází jako distribuovaný, avšak logicky jednotný (monolitický) systém. Budování takového systému od počátku by bylo drahé a zdlouhavé a znamenalo by ohrožení chodu jednotlivých úřadů i státu jako celku. Existují i další požadavky, které takové řešení vylučují. Jednotlivé úřady mají závažné důvody požadovat, aby byla zachována autonomie jejich informačních systémů a aby jejich informační systémy pro dosavadní úkoly pracovaly "jako dosud". Jen za tohoto předpokladu mohou ručit za chod svého úřadu, za správnost dat, které používají, i za případné změny svého informačního systému. Neméně významné jsou mocenské úvahy a nelze pominout ani zájem o vliv na státní zakázky. Za této situace je jediným možným řešením budovat e-government jako systém, do kterého jsou informační systémy jednotlivých úřadů integrovány jako "černé skříňky" (známe jen jejich rozhraní, o jejich vnitřní struktuře nevíme nic a také na ní nezáleží; v dalším je budeme nazývat autonomní komponenty) prostřednictvím "bran", kterými musí být jednotlivé informační systémy vybaveny. Brány přijímají a odesílají zprávy vhodných formátů, které jsou dopravovány middlewarem (infrastrukturou zajišťující komunikaci mezi částmi systému včetně služeb; obvykle prostřednictvím internetu/intranetu). Detaily technické realizace lze najít např. v [KŽ01,KŽ02,KŽ03]. Poněvadž jednotlivé autonomní komponenty musí plnit příkazy přicházející náhodně z různých míst, musí být všechny komponenty integrovány jako permanentní služby do (virtuální) sítě typu peer-topeer (P2P), tj. všechny služby mají v principu stejná práva. Takový systém nazveme softwarovou konfederací. Základní vlastnosti softwarové konfederace jsou: •

systém je (virtuální) peer-to-peer (P2P) síť autonomních služeb integrovaných jako černé skříňky, které je možné koupit v pricipu od různých výrobců, nově vyvinout, nebo které mohou být jen málo upravené existující aplikace (legacy system);

•

rozhraní na jednotlivé typy uživatelů (uživatelské role) se implementují též jako autonomní služby;

•

služby spolu komunikují prostřednictvím middlewaru (např. Internetu) přenášejícím zprávy vhodného formátu (definovaného např. jako dialekt XML).

3. Další příklady použití softwarových konfederací Softwarové konfederace jsou nutností v mnoha dalších případech. Prakticky jsou nutné vždy, kdy je nutné budovat velký otevřený softwarový systém. U informačního systému zdravotnictví je nutné jako černé skříňky poskytující permanentní služby integrovat software laboratoří, zdravotnických zařízení, softwarové systémy praktických lékařů a v budoucnu i lékáren a výrobců léků a velkých úložišť medicínských dat; případně i lékařských fakult pro potřeby výuky. Informační systém zdravotnictví tedy v podstatě musí mít architekturu softwarové konfederace. Takovýto systém se již implementuje např. v Řecku [KTO00]. Nejefektivnějším způsobem výstavby IS podporujícího nákupní kartel výrobců je peer-to-peer síť, jejíž uzly (peers) tvoří autonomní informační systémy účastníků kartelu - tedy opět varianta konfederace.

438


MODERNÍ MANAGEMENT ZÁVISÍ NA MODERNOSTI ARCHITEKTUR SOFTWAROVÝCH SYSTÉMŮ

V obou právě uvedených případech bylo v podstatě nezbytné, aby byly jednotlivé komponenty integrovány jako černé skříňky, tj. aby nebyly podstatně měněny a řešen byl jen problém jejich bran. To není zdánlivě nutné v případě velkého (mezinárodního) podniku. I v tomto případě je v podstatě nevyhnutelné, aby byl příslušný informační systém softwarovou konfederací. Velké mezinárodní (nadnárodní) podniky jsou obvykle velmi dynamické a často mění svoji strukturu prodejem některých svých částí nebo akvizicí dosud samostatných podniků nebo prostě potřebují změnit organizační strukturu. Akvizice znamená integraci informačního systému nové organizační části do informačního systému celého podniku. Při prodeji divize podniku bývá požadováno, aby prodávaná část byla vybavena fungujícím informačním systémem. To může být nepříjemná podmínka, není-li tento požadavek zohledněn již při budování informačního systému podniku. Pokud je systém monolitický (jeden logický celek), může být prodej části podniku spolu s podpůrným informačním systémem technicky obtížný a může být spojen s rizikem, že budou vyzrazeny důležité informace o tom, jak podnik funguje. Při použití konfederativní architektury jsou tyto problémy poměrně snadno řešitelné. V softwarové konfederaci lze snadno změnit pravidla komunikace mezi komponentami. To usnadňuje organizační změny podniku i restrukturalizaci obchodních procesů (BPR) a je stejně důležité jako možnost podpory různých forem e-komerce. Řešení řady strategických manažerských požadavků tedy rozhodujícím způsobem závisí na technologických řešeních.

4. Úkoly pro vrcholový management (CEO) Rozhodnutí implementovat systém jako softwarovou konfederaci je klíčové a přísluší proto vrcholovému managementu. Ten musí rozhodnout z hlediska požadavků na funkce systému: •

zda systém implementovat jako softwarovou konfederaci,

•

zda využít možnosti nabízené architekturou softwarových konfederací k restrukturalizaci podniku (decentralizace, které organizační jednotky mají být autonomní, outsourcing, nákup nových divizí, atd.),

•

zda využít možnosti softwarových konfederací v nových způsobech spolupráce na trhu (např. nové formy spolupráce s obchodními partnery vyžadující přímé propojení informačních systémů partnerů).

Konfederativní systém může být velmi otevřený, lze např. realizovat přímé propojení IS spolupracujících podniků či zdravotnických zařízení nebo úřadů. Použití softwarových konfederací silně ovlivňuje úkoly vedoucích informatiky (CIO) v podnicích (viz níže).

5. Proč až teď/Proč právě teď Příčiny, proč až dosud klasická monolitická architektura informačních systémů vyhovovala a proč technologie nebyla důležitá pro vrcholový management: •

nebyla k dispozici dostatečně efektivní technologie poskytující žádoucí funkce (middleware) umožňující efektivní implementaci softwarových konfederací;

•

podniky necítily dostatečnou potřebu decentralizace,

•

používané informační systémy nebyly natolik složité, aby nemohly být přepsány v případě potřeby od začátku;

•

na straně managementu byly subjektivní překážky (nedostatek znalostí, zkušeností) bránících přijetí nových přístupů;

•

nebyli dostatečně připraveni vývojáři (ti jsou školeni spíše pro vývoj monolitických aplikací).

Důvody, proč to v této době začíná být zajímavé: •

Rostou nároky na rychlost reorganizací např. na začlenění/vyčlenění jednotek do/z organizace.

•

Objevují se nové prvky v ekonomice - např. nákupní koalice nezávislých výrobců, e-komerce.


439


•

e-business - poskytování služeb partnerům, kteří mohou potřebovat přímý přístup k podnikovému IS.

•

SCM, CRM potřebují dodavatelů/partnerů).

•

Potřeba snížit závislost na dodavatelích a technologiích a technologiích, protože často mizí z trhu i produkty velkých firem, na nichž mnohdy závisí chod organizací. Je-li informační systém podniku tvořen kustomizovaným softwarovým balíkem a tento produkt přestane být podporován, čelí podnik nejpozději do několika let problému, že na nových počítačích nebude schopen svůj IS provozovat a na ty, pro které byl systém vyvinut, již nebude schopen sehnat náhradní díly. Je-li systém složen z relativně nezávislých spolupracujících částí a přestane-li být některá z těchto částí podporována výrobcem, je snazší nahradit tuto část jiným systémem. Tím, že se převádí menší část systému, je tento přechod snazší a tedy i méně kritický pro podnik jako celek. Téměř absolutní závislost na jednom dodavateli/partnerovi je vždy nebezpečná, v softwaru zvláště.

•

Je třeba snížit náklady na údržbu softwaru a zajistit její operativnost (pružnost, rychlost odezvy na potřeby podniku). Změny se snáze provedou na menších SW celcích, neboť tím, že jsou uzavřené, je výrazně menší šance na zavlečení chyby mimo pozměňovanou část. Důsledkem jsou velké úspory a větší volnost při změnách.

podporu

IS

při

zachování

bezpečnosti

(připojují

se

IS

6. Další důsledky softwarových technologií pro práci manažera Důležitým aspektem softwarových konfederací je schopnost přímé komunikace s informačními systémy obchodních partnerů a státní správy. To je nutností v business-to-business (B2B) systémech e-komerce. Podobný aparát je možné využívat při implementaci procesů kontroly dodavatelských řetězců (SCM) a pro řízení vztahů se zákazníky (CRM). V obou případech lze zlepšit kvalitu řešení, je-li možná komunikace s informačními systémy obchodních partnerů. Poněvadž v softwarové konfederaci není umístění softwarových komponent důležité (mohou dokonce migrovat po síti a mohou, s malou nadsázkou, pracovat téměř kdekoliv), je možné provádět celkem snadno outsourcing některých částí informačního systému a také jednotlivých částí podniku. Není také obtížné provádět opačnou transformaci - insourcing. To rozšiřuje prostor pro různá strategická rozhodnutí managementu. Změnou některých komponent a pravidel komunikace mezi komponentami lze podstatně modifikovat uživatelské vlastnosti systému. Velmi výraznou výhodou je možnost, aby byly některé části systému převzaty z existujících systémů, koupeny, nebo vyvinuty znovu. Třetí možnost může znamenat konkurenční výhodu. Možnost nakupovat komponenty od různých výrobců snižuje nezdravou závislost na dodavateli informačního systému a snižuje finanční náročnost nákupu a modifikaci informačního systému. To, jak postupovat, je opět obsahem strategických rozhodnutí vrcholového managementu. Ten ovšem musí být schopen kvalifikovaně posoudit důsledky svých rozhodnutí. To však vyžaduje, jak jsme již uvedli výše, jistou znalost vlastností použitých technologií.

7. Proč zatím tak málo Výše uvedená diskuse potřeby konfederativní architektury naznačuje, že konfederativní systémy jsou pod tlakem nevyhnutelnosti realitou. Nejedná se tedy o výmysly teoretizujících informatiků - ti se k věci staví spíše odmítavě a milují objekty a třídy a nikoliv ošklivé hotové aplikace. Jednodušší formy softwarových konfederací jsou běžně používány [KŽ] při řízení procesů (systémů reálného času) již více než třicet let. Na druhé straně, na podnikové úrovni jsou konfederace pociťovány v lepším případě jako nevyzkoušená novinka, v horším případě jako východisko z nouze do doby, než se systém pomocí moderních objektových nástrojů kompletně přepíše. Ani jedno není správný názor 440



konfederativní přístup nabízí novou (vyšší) kvalitu jak pro uživatele, tak pro vývojáře. Tento potenciál není dosud dostatečně využíván z následujících příčin: 1. Nutná časová prodleva při zvládání nové technologie. Konfederativní architektura je, přes výše uvedená fakta, novinkou pro uživatele i pro mnohé vývojáře podnikových systémů. Vývojáři současných podnikových systémů jsou spíše orientováni na vývoj jednotlivých aplikací, než na budování sítí aplikací. Konfederativní přístup často pociťují jako něco, co je krokem zpět a porušováním všech dobrých a osvědčených zásad (typicky objektověorientované filosofie) jejich profese. Nejsou proto schopni konfederované systémy navrhovat a dokonce se tomu intuitivně brání. Konfederaci považují za nouzové řešení, které nebude mít dlouhé trvání. Poněvadž uživatelé nevidí uživatelské výhody konfederativní architektury, nevyvíjí tlak na vývojáře, aby změnili své názory a postupy. 2. Dodavatelé softwarových systémů nemají zájem oslabit závislost svých zákazníků na svých produktech, což by se po přechodu na konfederativní architektury pravděpodobně stalo. 3. Samotná technologie konfederací není dostatečně rozvinuta. Chybí dostatečně silné vývojové nástroje a nejsou rozvinuty (ani na konceptuální bázi) vhodné modely. Připomeňme, že ani aktuální standard UML není pro modelování konfederací vhodný. Technologie konfederací není zatím součástí učebních plánů vysokých škol. Tato překážka je méně důležitá, než problémy uvedené v bodu 1 a 2. Nedostatek vývojářů s konfederativním myšlením je v řadě případů možné oslabit tím, že na podnikové úrovni angažujeme vývojáře, kteří mají zkušenost se softwarovými konfederacemi při řízení výrobních systémů (CIM, flexibilní výrobní systémy) a technologií (systémy reálného času). To je problém, který rovněž musí být řešen na manažerské úrovni.

8. Náměty pro náměstka pro informatiku (CIO) Softwarová konfederace umožňuje vytváření velmi složitých systémů propojováním relativně malých aplikací. To umožňuje i při vývoji velkých systémů používat postupy vhodné pro menší aplikace, jako je extrémní programování [Be99]. CIO by měl být motorem změn transformujících používané systémy na softwarové konfederace. Především by měl ukazovat výhody konfederací vrcholovému managementu a spolupracovat na koncepci informatiky jako celku, tj. spolupracovat (i koncepčně) na rozhodnutích: •

jak přejít na konfederativní architekturu,

•

kdy použít existující aplikace,

•

co koupit od hlavního dodavatele a co od třetích stran, co vyvinout od počátku,

•

jaký formát zvolit pro zprávy v systému (standard SOAP nebo nové XML formáty),

•

kde najít vhodné lidi s konfederativním myšlením (lze je najít spíše v nižších patrech podnikového systému, např. mezi vývojáři výrobních systémů).

Přechod na konfederativní architekturu může být v mnoha případech bolestný proces. Softwarové konfederace však kromě výše uvedených výhod přináší i významné softwarově inženýrské výhody, jako je [So96]: •

inkrementální vývoj,

•

nové nástroje testování a prototypování,

•

stabilní systémy,

•

modifikovatelnost, otevřenost, snadnost změn, snazší údržba.

Využívání konfederací však vyžaduje změnu myšlení a také jiné způsoby spolupráce s dodavateli a především systémovými integrátory. Výsledky však mohou být překvapující. Je například možné, aby


441


student v rámci jedné diplomové práce modernizoval podporu práce velkého státního úřadu jako se tomu stalo v případě okresního úřadu pro Prahu 1 [Šk00]. Softwarové konfederace jsou pravděpodobně jedinou možnou cestou, jak dosáhnout toho, aby se softwarové systémy staly moderními technickými (hi-tech) artefakty jak co se týče vývoje, tak použití výrobků z různých zdrojů, tak i co se týče spolehlivosti.

9. Pohled systémového integrátora Zatím jsme se na problém konfederaci dívali z hlediska uživatele. Konfederativní architektura je klíčovou výzvou i pro systémové integrátory. Není obtížné nahlédnout, že se do značné míry jedná o problém života a smrti. Systémový integrátor (SI) musí v souvislosti s uplatňováním konfederativní filosofie čelit následujícím výzvám, které jsou podobné výzvám pro CIO zákazníka: 1. Je nutné rozhodnout, zda je vhodné být distributorem produktů jednoho výrobce nebo více výrobců. 2. Není-li SI prodlouženou rukou (dealer) jediného výrobce, musí se rozhodnout, jak širokou paletu produktů bude využívat (integrovat) a zda bude považovat některého dodavatele za hlavního. V každém případě musí SI formulovat svoji politiku ve věci integrace produktů svých zákazníků a třetích stran. To závisí na politice hlavního dodavatele. 3. Pravděpodobně bude nutné připravit specialisty na služby webu a na transformaci formátů zpráv (např. pomocí XSLT/PHP). 4. Je nutno rozhodnout, do jaké míry bude integrátor podporovat vývoj nových komponent u sebe a u zákazníků. 5. Upravit odpovídajícím způsobem obchodní strategie 6. Vyškolit specialisty pro vývoj konfederací. Lze očekávat, že během poměrně krátké doby dojde k velkým změnám v obchodní i odborné činnosti systémových integrátorů. Rozsah těchto změn bude značný a bude vyžadovat podstatné změny v profesním složení zaměstnanců systémových integrátorů, změny marketingu a také změny obsahu činnosti integrátora během integrace .

10. Závěr V průběhu posledních několika let pozorujeme stále větší specializaci pracovníků zapojených do vývoje softwaru. Vývojoví pracovníci se stále více zaměřují na technické aspekty tvorby softwaru. Uživatelé softwarových systémů mají stále více tendenci se vůbec nezabývat vlastnostmi implementace. To je, do značné míry, umožněno pokroky v nástrojích podporujících uživatelské rozhraní (GUI, prohlížeče). Rostoucí objem znalostí, které musí zvládat uživatelé softwaru (především uživatelé-manažeři) ve svém oboru, vytváří tlak na takovou míru specializace, při které se již stává komunikace mezi vývojovými pracovníky a uživateli velmi obtížnou. Programátoři mají stále méně znalostí matematiky a stále méně chápou potřeby oblasti aplikací. Uživatelé systémů - především vrcholový management na druhé straně nedostatečně chápou uživatelské důsledky softwarových technologií, tj. jak jsou jejich rozhodnutí a možnosti podmíněny architekturou používaných softwarových systémů. Je manažerským úkolem, jak na základě těchto znalostí upravit vztahy s dodavateli softwaru, aby bylo možné využívat potenciál moderních softwarových architektur (např. možnost využití systémů třetích stran, existujících systémů a nově vyvíjených systémů i podpora organizačních změn a restrukturalizace podnikových procesů) k dosažení významných konkurenčních výhod včetně

442



rozsáhlých úspor při provozu informačních systémů a snížení nezdravé závislosti na jednom dodavateli softwaru. Komunikační bariéra mezi uživateli a vývojáři negativně ovlivňuje kvalitu softwarových systémů a také kvalitu jejich využívání. To se týká jak již vyvíjených, tak i kustomizovaných systémů. Softwaroví odborníci nejsou schopni ani ochotni chápat - natož pak formulovat - požadavky na funkce systému. Uživatelé (především manažeři) nemají dostatek takových znalostí, které by umožnily formulaci požadavků využívajících potenciál moderních softwarových architektur. Tento problém musí být vyřešen aby bylo možné využít pokroku v informačních technologiích. To je úkol i pro systémové integrátory. V článku Standish Group "Recipe for success" (viz www.standishgroup.com) se navrhuje, aby manažer projektu fungoval jako "most" mezi světem uživatelů a světem implementace. To je jistě správná cesta, není však bez problémů. Není totiž jasné, zda má být základní profesí manažera projektu software (informatika), nebo znalostní doména aplikace (a managementu). To, které řešení je vhodnější, může záviset na okolnostech. Z výše uvedeného vyplývá, že dobrého manažera projektu může dobře dělat jen málokdo. Ani dobrý manažer projektu nemusí být schopen kompenzovat to, že díky absolutní neznalosti možností moderních softwarových technologií není zadavatel projektu (CEO) schopen formulovat požadavky na systém tak, aby přinášel maximální efekt, a také se rozhodnout pro správnou strategii rozvoje využívaných softwarových systémů. Poděkování: Tato práce byla částečně podporována Grantovou Agenturou ČR, grant č. 201/02/1456.

Literatura [Be99] [GHJV93] [KTO00]

[KŽ01]

[KŽ02]

[KŽ03]

[KŽ] [NAG02] [So96]

Beck, K.: Extreme Programming Explained. Addison Wesley, Boston, MA, 1999. E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns. Elements of Reusable Object-Orieneted Software. Addison-Wesley, Boston, MA, 1993. Katehakis, D.G., Tsiknakis, M., Orphanoudakis, S.C.: Information Society Technologies in Healthcare. V: Hlaváč, V., Jeffery, K.G., Wiedermann, J. (editoři): SOFSEM'2000: Theory and Practice of Informatics. LNCS 1963. Springer Verlag, Berlin, 2000. ss. 375-383. Král, J., Žemlička, M.: Electronic Government and Sofware Confederations. V: Tjoa, A M., Wagner, R.R. (editoři): Twelfth International Workshop on Database and Experts System Application. Los Alamitos, CA, USA: IEEE Computer Society. ss. 383-387. Král, J., Žemlička, M.: Global Management and Software Confederations. V: Khosrowpour, M. (editor): Issues & Trends of Information Technology Management in Contemporary Organizations. Idea Group Publishing, 2002. Král, J., Žemlička, M.: Software confederations - an architecture for global systems and global management. V: Kamel, S. (editor): Managing Globally with Information Technology, Heshey, PA, USA, 2003. Idea Group Publishing. ss 57-81. Král, J., Žemlička, M.: Software Confederations and Manufacturing. V přípravě (přijato na ICEIS 2003, Angers, Francie). Nelson, J., Armstrong, D.A., Ghods, M.: Old Dogs and New Tricks. V: Comm. of ACM, Vol. 45, No. 10, říjen 2002, ss. 132-136. Sommerville, I.: Software Engineering, 5th edition, Addison-Wesley, Reading, MA, 1996. ISBN 0-201-42765-6.


443


[Šk00]

Škoda, M.: Informační systém městských úřadů. Diplomová práce, MFF UK, Praha, září 2000.

Summary The work of top management has been till now practically independent on the style of the software (usually information system) they use. Technological aspects were not, with exclusion of CIO, for top management important. The situation is changing now. The management is dependent on the abilities of the software. Every change in the company structure and work must be supported by the company’s information system of a proper architecture. Examples are decentralization, CRM, manufacturers coalitions, different variants of outsourcing. If the system cannot support such activities, the company cannot perform them without facing big risks. If the system should support such activities, it must have a specific architecture. It must be a peer-to-peer network of permanent autonomous services. CEO should therefore have enough knowledge about features and abilities of modern software architectures important for his/her work. It is important not only for his/her better usage of the software, but also for his/her ability to positively influence the information departments in the sense what is its target, and what requirements are feasible and desirable. Modern architecture of peer-to-peer networks of autonomous services significantly influences the work of CIO, software engineering properties of the software like reliability and modifiability. It is a crucial challenge for system integrators.

444


Moderní management závisí na modernosti architektur softwarových systémů

Recommend Documents