BPTrends a BEA publikovali prieskum “The State of BPM in 2008″, viď časť prvá a časť druhá.
Výber toho čo ma zaujalo:
  • Dôvody adopcie BPM
    Nakoľko prvá (Od BPTrends) a druhá časť (od BEA) prieskumu sa ohľadom dôvodov výrazne líšia, nebudem ich bližšie rozoberať a to aj pretože sú to klasické dôvody na akékoľvek business zmeny ako: potreba ušetrenia financia redukciou nákladov a zlepšením produktivity, potreba zlepšenia koordinácie riadenia a spokojnosti zákazníkov, atď.
  • Štandardy
    BPMN si vydobil výrazný podiel 41% (oproti 22% v roku 2006), BPEL urobil malý nárast na 26 % (oproti 23% v roku 2006), XPDL (6%) a OMG Process Metamodel (7%) sú v pozadí. Pomerne stabilné je UML (30%).
  • BPM Suite - nástroje
    V oblasti používaných nástrojov vládne silné roztrieštenie pod vedením lídrov ako IBM (FileNet), SAP a Oracle. Správa poukazuje na rozdelenie trhu na dve základné kategórie:

    • BPMS, ktoré sú používané na integráciu rôznych informačných systémov a
    • BPMS, ktoré sú používané na riadenie “human-centric” procesov.

    Druhá časť prieskumu (od BEA), že pri voľbe BPMS zákazníci berú do úvahy:

    • Jednoduchosť používania modelovacieho prostredia
    • Podporu rôznych druhov procesov
    • Silu a škálovateľnosť runtime prostredia
    • Vstavanú podporu integrácie so SOA technológiami
  • Prepojenie BPM a SOA
    Druhá časť prieskumu (BEA)  uvádza, že zákaníci používajúci SOA+BPM (v porovnaní s použitím samotného BPM) výrazne zvýšili svoje schopnoti:
    • rapídneho zlepšenia procesov
    • zdieľania a znovupoužívania procesov naprieč organizačnými jednotkami.
  • Trh BPM
    BEA časť prieskumu indikuje, že BPM trh je jeden z najrýchlejšie rastúcich softvérových trhov a prejavuje silné prvky konsolidácie dodávateľov (150 dodávateľov evidovaných v roku 2006 oproti 25 v roku 2007).
    Zatiaľčo na konci roka 2007 24% respondentov uvádzalo používanie BPM technológií, ďalších 25% očakáva investovanie do týchto technológií v roku 2008.

OMG vydala prípadovú štúdiu zaoberajúcu sa posúdením modelovania Enterprise Architektúry (EA) TOGAF (konkrétne časti Architecture Development Method, t.j. ADM) pomocou OMG metamodelov, predovšetkým SPEM.

Z pohľadu implementácie informačných systémov podľa princípov Enterprise Architecture vidím prínos použitia špecifikácie SPEM v2.0 pri definovaní procesného modelu (v prípade TOGAF ide o definovanie výstupu B. fázy, t.j.: tvorbu Business architecture) a následného použitia tohoto modelu pri rozpracovaní do Dátovej a Aplikačnej architektúry.

Poznámka na okraj: jeden z autorov spomínanej štúdie naštartoval nový projekt, kde zachytáva Architecture Development Method časť TOGAF-u používajúc EPFC.

Ďalšie zdroje k téme

Špecifikácia SPEM v2.0 (Software Process Engineering Metamodel) je aktuálne je v stave Beta2, čo je skoro finálne vydanie danej špecifikácie (nutné už len schválenie OMG’s business committee a hlasovanie na board of directors).

25. septembra bol vydaný Rational Method Composer v7.2.

Rational Method Composer (RMC) je komerčná verzia produktu Eclipse Process Framework Tool (EPFC) rozšírená o niektoré funkcionality. Vývojový model je silne podobný vývojovému modelu Linux distribúcií typu Fedora -> RedHat Enterprise Linux, či openSUSE -> SUSE Linux Enterprise, t.j. základom je komunitná opensource verzia produktu (v tomto prípade ako súčasť opensource projektu EPF) silne podporovaná materskou spoločnosťou daného produktu (v tomto prípade IBM), vyvíjaná otvorene a v spolupráci s komunitou. Samotný vývoj a vydávanie verzii produktu prebieha tak, že nové funkcionality sa najprv vydajú ako súčasť opensource verzie produktu, po testovaní a doplnení komunitou sa podľa zváženia objavia v komerčnej verzii produktu. Tento druh vzťahu je bližšie popísaný tu.
Keďže sú RMC a EPFC modelovacie nástroje, podstatná je používaná špecifikácia ukladaných dát samotného modelu. Tou je SPEM 2.0 (Software Process Engineering Metamodel) o ktorej som už písal a ktorá je aktuálne v schvaľovaní (Beta2). Samotný posun vývoja EPFC a RMC je vidieť práve v posune podporovanej špecifikácie, t.j. kompatibilite uložených dát modelu:

  • EPFC 1 M3 je kompatibilný s RMC 7.0
  • EPFC 1.0.x je kompatibilný s RMC 7.1 and 7.11
  • EPFC 1.2 je kompatibilný s RMC 7.2

Medzi kľúčové témy zlepšenia produktu RMC vo verzii 7.2 patrili (kompletný zoznam definoval P. Haumer):

  • poskytnúť viac možností prezentácie procesného modelu formou integrácie RMC s projektom Eclipse BIRT (projekt tvorby reportov pod Eclipse) umožňujúc publikovanie modelu v používateľsky definovanom formáte podporujúc rôzne scenáre použitia (napr.: publikovanie procesu pre auditora)
  • zvýšenie škálovateľnosti RMC so zreteľom na podporu distribuovaných tímov formou workspace, ktoré riadia Method Plugins z rôznych zdrojov a fyzických lokácií
  • poskytnúť zjednodušené GUI pre projektových manažérov za účelom prispôsobovania procesného modelu na projekty
  • poskytnúť novú a vylepšenú integráciu s externými sw nástrojmi danej oblasti (napr.: IBM Rational Portfolio Manager and IBM Websphere Business Modeler)

RMC v 7.2 som si stiahol a chystám sa na otestovanie vyššie spomínaných zlepšení, ktoré nie sú dostupné v EPFC v1.2. Medzi zmeny, ktoré sú hneď vidieť a je nutné otestovať však možno zaradiť:

  • zmenená štruktúra Method Plugins (metodika RUP je súčasťou RMC), ktorá si zaslúži zamyslenie
  • nové perspektívy Report Design a Tailoring

Ďalšie zdroje:

Dnes som narazil na veľmi podarený plugin pre aplikáciu JIRA. Ide o GreenHopper doplňajúci JIRA o vizualizáciu založenú na princípoch vývoja typu Agile software development alebo Lean software development používajúcich evidenciu požiadaviek klienta vo forme príbehov či kariet (ako napr.: Stories v Extreme Programming, či Feature v Feature Driven Development) . Veľa napovie úvodné video a základný popis funkcionality.

Projekt Apache ServiceMix sa stal oficiálnym ASF projektom. Ide o projekt tvorby open source ESB (Enterprise Service Bus), ktorý kombinuje funkcionalitu Service Oriented Architecture (SOA) and Event Driven Architecture (EDA).

Vývoj je veľmi dynamický a už prebieha vývoj ďalšej verzie, ktorá bude bežať na OSGi container-y a Apache Camel (implementácia Enterprise Integration Patterns). Pre doplnenie Apache ActiveMQ bude použitý ako JMS message broker a Apache CXF ako web services framework.

V súvislosti s vyššie uvedeným sa mi zaujímavým zdá:

Ďalšie novinky, ktoré ma zaujali:

Po dlhšom čase som sa zase dostal k webu a našiel niekoľko zaujímavostí:

SPEM a EPFC

Špecifikácia SPEM (Software Process Engineering Metamodel) je špecifikácia určená pre popisovanie procesov softvérového vývoja. Aktuálne pripravovaná verzia (2.0) slúži ako podklad pre implementáciu pomocou nástroja EPF Composer (EPFC). Zaujímavosťou je, že vývoj nástroja EPFC prebieha súbežne s prípravou, resp. schvaľovaním spomenutej špecifikácie SPEM 2.0, čím sa ich vývin vzájomne ovplyvňuje. Aj preto je poučné sledovať priebeh schvaľovania danej špecifikácie a zozbierané pripomienky.

Priebeh a aktuálny stav schvaľovania SPEM 2.0

Samotný priebeh schvaľovania OMG špecifikácie je popísaný v OMG Specification Tutorial. Špecifikácia SPEM 2.0 je aktuálne v stave Final Adopted Specification, čo znamená, že príprava bola ukončená a špecifikácia bola predložená na pripomienkovanie. Zozbierané pripomienky (termín bol 31. máj 2007) spracuje skupina Finalization Task Force (FTF) do správy FTF Report (termín je 05. október 2007) a zabezpečí prechod do stavu Proposed Available Specification. Následne skupina Revision Task Force (RTF) posúdi a rozhodne o zozbieraných pripomienkach, pričom výsledkom môže byť uzavretie pripomienky alebo odporučenie pre nové doplnenie/spracovanie (Request for Proposal). Výsledná správa t.j. RTF Report (súčasť finálneho procesu revízie špecifikácie) obsahuje zoznam aplikovaných a nutných zmien do predloženej verzie špecifikácie a je zároveň podkladom k rozhodovaniu o uvoľnení finálnej verzie OMG špecifikácie.

Prečo čítať špecifikáciu SPEM?

Prečo je dobré čítať spomínanú špecifikáciu? Ako príklad môže slúžiť neustály zdroj nedorozumenia vo výklade definície následnosti prebiehajúcich činností v procesoch, t.j. atribútoch prechodu medzi činnosťami typu finishToStart, finishToFinish, startToStart a startToFinish. Jednoznačný výklad k tejto téme je dostupný na strane 66, kapitola 9.14 Work Sequence Kind.

Ďalšie zdroje k článku

Google zverejnil inštalačné zdroje svojho softvéru pre rôzne distribúcie Linuxu (Ubuntu, Debian, openSuse, Mandriva) na stránkach Google Linux Software Repositories.

Na serveri InfoQ, ktorý sa zaoberá aj agilnými technikami vývoja softvéru, vyšiel článok o súťaži krátkych filmov propagujúcich agilné techniky. Odporúčam veľmi vtipné “propagujúce” video od High Moon Studios.