Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

X36SSP Správa softwarových produktů 4. přednáška Ing. Martin Molhanec ČVUT – FEL K13113.

Podobné prezentace


Prezentace na téma: "X36SSP Správa softwarových produktů 4. přednáška Ing. Martin Molhanec ČVUT – FEL K13113."— Transkript prezentace:

1 X36SSP Správa softwarových produktů 4. přednáška Ing. Martin Molhanec ČVUT – FEL K13113

2 Dnešní témata Co je to SOA – podrobněji. Co je to TOGAF? Co je to ITIL?

3 Service-oriented architecture (SOA) Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service: –Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports) –Is self-contained –May be composed of other services –Is a “black box” to consumers of the service An architectural style is the combination of distinctive features in which architecture is performed or expressed.

4 Service-Oriented Architecture Abbreviated SOA, an application architecture in which all functions, or services, are defined using a description language and have invokable interfaces that are called to perform business processes.applicationarchitectureinterfaces Each interaction is independent of each and every other interaction and the interconnect protocols of the communicating devices (i.e., the infrastructure components that determine the communication system do not affect the interfaces).protocols Because interfaces are platform-independent, a client from any device using any operating system in any language can use the service.platformclientoperating system Though built on similar principles, SOA is not the same as Web services, which indicates a collection of technologies, such as SOAP and XML. SOA is more than a set of technologies and runs independent of any specific technologies. Web servicesSOAPXML

5 Elements of SOA

6

7 SOA principles guiding principles –Reuse, granularity, modularity, composability, componentization, and interoperabilitygranularitymodularityinteroperability –Compliance to standards (both common and industry-specific) –Services identification and categorization, provisioning and delivery, and monitoring and tracking

8 SOA principles specific architectural principles –Service EncapsulationEncapsulation –Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each otherLoose coupling –Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documentsService contract –Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world

9 SOA principles specific architectural principles –Service documentation - A description of a service- oriented design must contain at least three separate uses of the phrase "business value". –Service reusability - Logic is divided into services with the intention of promoting reuse –Service composability - Collections of services can be coordinated and assembled to form composite services –Service autonomy – Services have control over the logic they encapsulate

10 SOA principles specific architectural principles –Service optimization – All else equal, high-quality services are generally considered preferable to low- quality ones –Service statelessness – Services minimize retaining information specific to an activity –Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanismsService discoverability

11 Other factors and guidelines SOA Reference Architecture SOA Practitioners Guide Part 2: SOA Reference Architecture covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.SOA Practitioners Guide Part 2: SOA Reference Architecture

12 Other factors and guidelines Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.SOA Practitioners Guide Part 3: Introduction to Services Lifecycle

13 Other factors and guidelines Efficient use of system resources Service maturity and performance Enterprise Application Integration (EAI)

14 The Open Group Architecture Framework (TOGAF) The Open Group Architecture Framework, or TOGAF, is a complete package for creating an enterprise architecture. Provides both a method and the structure for developing an enterprise architecture. TOGAF is a framework, which typically means it defines the deliverables your work should produce and perhaps the means by which you should produce them.

15 The Open Group Architecture Framework (TOGAF) The Architecture Development Method (ADM): The ADM, which makes up the first third or so of the TOGAF specification, consists of eight phases of analysis and implementation to bring you from the start to the completed, implemented enterprise architecture. The ADM is a generic methodology, which means it's not geared toward any particular set of deliverables. You can even use ADM to design an enterprise architecture based on another framework. (And, in fact, TOGAF provides guidance for doing just that.) The Enterprise Continuum: The Enterprise Continuum is a repository of artifacts involved in the design and implementation of your system, such as models, patterns, and other architectural work. TOGAF defines a Technical Reference Model (TRM) that can form a foundation on which you can build your repository, as well as a second reference model and set of solutions and standards with which you can work. Additional Resources: TOGAF also provides a wealth of information to help you build an architecture, such as business scenarios, case studies, and various models, views, and guidelines.

16 Eight phases of the Architecture Development Method.

17 SOA lifecycle

18 High-Level Project Plan

19 ITIL (IT Infrastructure Library) ITIL (IT Infrastructure Library) je mezinárodně uznávaný standard pro řízení IT služeb, který začal vznikat ve Velké Británii v 80. letech minulého století. Dnes je tato knihovna spravována pod křídly Office of Government Commerce a šířena formou knih, CD, školení, konzultací a certifikací.Office of Government Commerce ITIL není metodika, a to ani metodika IT Service Managementu, ani metodika implementace ITSM v organizaci, ale rámec pro návrh ITSM procesů, který vychází z nejlepších praktických zkušeností, přičemž ponechává velikou volnost při implementaci těchto procesů. Protože ITIL je nezávislý na platformě a protože je to "rámec", jsou výstupy všech dodavatelů v celém odvětví kompatibilní a univerzálně použitelné (SW nástroje, školení, konzultační služby).

20 ITIL (IT Infrastructure Library) ITIL je rozsáhlý, konzistentní a procesně orientovaný rámec pro oblast IT Service Managementu (ITSM). ITIL je založený na nejlepších zkušenostech z praxe ITSM (Best Practice) - ITIL vznikl jako souhrn "Best Practices" z oblasti ITSM. ITIL je v současnosti již de-facto mezinárodním standardem pro oblast ITSM. Hlavním přínosem ITILu je především jasné pochopení k čemu jednotlivé procesy slouží, jaké jsou mezi nimi vazby, jaké role by se měly na procesu podílet a jaké parametry by měl proces mít. ITIL však není jen návodem jak dobře řídit IT služby, ale obsahuje také návody jak poskytování IT služeb zlepšovat. Vzhledem k tomu, že mechanismy pro zlepšování činností jsou obsaženy přímo v jednotlivých procesech, je implementace procesů dle ITIL v organizaci zárukou průběžného zvyšování kvality a produktivity.

21 ITIL (IT Infrastructure Library) Knihovna ITIL je rozdělena do několika částí, zaměřených na specifickou oblast řízení IT služeb, které odpovídají klíčovým procesům v IT oddělení a vzájemně se prolínají. Tyto oblasti jsou znázorněny na obrázku. Uvedené oblasti jsou pak popsány v jednotlivých knihách (CD), kterými je ITIL šířen.

22 Základní model metodiky ITIL Pohled podnikání (Business Perspectives), Správa aplikací IT (Aplication Management), Dodávka IT služeb (IT Services Delivery), Podpora IT služeb (IT Services Support), Správa IT infrastruktury (IT Infrastructure Management), Řízení IT projektů IT (Project Management). IT Service Management (ITSM).

23

24 Co ITIL neřeší Co od ITILu očekávat nelze, jsou podrobné návody, resp. připravené pracovní toky (workflow), které stačí jen vzít a nasadit, konkrétní podobu organizační struktury, obsazení rolí konkrétními pracovními pozicemi, ani podrobnou metodiku implementace ITSM. ITIL se totiž zaměřuje u jednotlivých procesů na klíčové principy, hlavní aktivity, výkonnostní kritéria a kvalitativní indikátory, takže je potřeba jej chápat vždy jako podklad pro definování příslušného procesu. Nicméně právě toto je při vytváření konkrétního detailního procesu velice důležité, neboť především způsoby měření a kvalitativní indikátory slouží jako kontrolní seznam pro použité datové položky v procesu a také výstupy, které je potřeba z procesu poskytnout. Kromě výše zmíněných parametrů procesu obsahuje ITIL také doporučení, jaké služby by měl pro daný proces poskytovat podpůrný softwarový nástroj, čímž IT pracovníkům zjednodušuje sestavování výběrových kritérií při nákupu podpůrné technologie.

25 Šest mýtů o metodice ITIL Mýtus č. 1 – ITIL je pro techniky. ITIL budou sice při své každodenní práci implementovat pracovníci provozu IT, avšak nezbytným předpokladem úspěchu je podpora manažerů. Mýtus č. 2 – ITIL je pouze o lidech a procesech. Technologie zde nehraje roli. Konzultanti ITIL se často zaměřují výlučně na zdokonalování procesů a organizační záležitosti. Definice procesů je sice důležitá, ale skutečného nárůstu efektivity lze dosáhnout pouze v případě, že jsou procesy automatizovány pomocí technologií.

26 Šest mýtů o metodice ITIL Mýtus č. 3 – ITIL řeší úplně všechno. Implementace ITIL nezkvalitní všechny procesy IT. ITIL sice velice přesně definuje nejlepší postupy řízení služeb, ale v jiných důležitých­ oblastech je tato metodika nedostačující. Mýtus č. 4 – Školení metodiky ITIL = úspěch metodiky ITIL. Většina organizací, které se pouštějí do implementace ITIL, začínají ambiciózními školicími programy. Často ovšem zapomínají, že zavedení platformy nejlepších postupů je především zásadní organizační a kulturní změnou. Pokud si to neuvědomí, mohou si koledovat o problémy.

27 Šest mýtů o metodice ITIL Mýtus č. 5 – Jeden proces za druhým. Hodně společností postupuje tak, že nejprve izolovaně zkvalitní jediný proces, například řízení incidentů. Jenže procesy ITIL jsou nevyhnutelně provázány, a proto organizace, které se dlouho věnují jen jednomu procesu, než se začnou zabývat ostatními souvisejícími, nezaznamenají hmatatelné výsledky svého úsilí. Mýtus č. 6 – Je třeba vybírat pouze řešení, která „vyhovují ITIL.“ Význam shody produktů s ITIL je přeceňován. ITIL nespecifikuje podrobné procesy a postupy, jichž se mají podniky držet, a proto může být každý informační produkt vyhodnocen jen na tak abstraktní úrovni, že užitečnost takového hodnocení bude omezená.

28 Problémy, když není řízení služeb IT! IT oddělení se nepovažuje za servisní útvar, ale za nezávislé oddělení, a proto nemá potřebu komunikovat s ostatními podnikovými odděleními. Nikdo v podniku nemá přehled, jaké náklady jsou spojeny s poskytováním jakých služeb a pro které skupiny zákazníků. Ostatní podnikové útvary nerozumí tomu, co vlastně IT dělá. IT oddělení se z hlediska ostatních částí organizace chová jaksi divně, občas se stává, že nerozumí potřebám uživatelů a ti zase zákonitostem fungování IT infrastruktury, a v důsledku toho se může stát, že IT nedodává to, co je zapotřebí. Řešení výpadku IT infrastruktury se neprovádí systematicky a strukturálně, proaktivní rozměr (předcházení výpadků) často zcela chybí. Správné fungování IT/IS je často závislé na individuálních znalostech jednotlivých specialistů.

29 Přínosy implementace ITIL měření kvality služeb, výkonnosti a spolehlivosti dodavatelů/vlastních pracovníků, měření dostupnosti IT popsané procesy a standardy provozu IT za účelem vyloučení případů náhodného či ad hoc hledání řešení usnadnění certifikace dle ISO 9000, ISO vyhovění požadavkům různých auditů (SOX) monitoring a reporting klíčových provozních aktivit monitoring a reporting požadavků uživatelů (finanční pohled) zvýšení spolehlivosti ICT systémů usnadnění komunikace mezi pracovníky ICT a uživateli

30 Implementace ITIL (Planning to Implemenent Service Management) 1) získání povědomí o ITIL, vysvětlení výhod implementace 2) ohodnocení současné situace a vytvoření strategie, tzn. rozhodnutí o tom, které oblasti a jaké aspekty řízení informatiky nejsou v souladu s ITIL a v jakém pořadí mají být řešeny 3) naplánování a následná realizace projektu 4) ověření, zda bylo dosaženo zamýšlených cílů

31 Ukázka z ITIL TOOLKIT $19 9

32 THE OPEN GUIDE This is an Open and Public Site for ITIL professionals and students. It is maintained by the ITIL community itself. Please feel free to contribute. $0 Nekomerční zdroje

33 ISO Skládá se ze dvou dokumentů: –ISO/IEC : 2005 IT service management. Specification for service management –ISO/IEC : 2005 IT service management. Code of practice for service management ISO/IEC is the first international standard for IT Service Management. It is based on and is intended to supersede the earlier British Standard, BS IT Service ManagementBritish Standard

34 Závěr Vytváření stále větších systémů je stále obtížnější. Velké systémy jsou silně heterogenní. Velké IT systémy jsou částí obchodních, výrobních, organizací služeb, státní správy, armády a školství systémů. Vznikají proto stále nové metodiky, jak toto všechno zvládnout. Integrace a správa takových systémů přesahuje schopnosti člověka!?

35


Stáhnout ppt "X36SSP Správa softwarových produktů 4. přednáška Ing. Martin Molhanec ČVUT – FEL K13113."

Podobné prezentace


Reklamy Google