Hvordan undgår man Agility-brillerne dugger mere end højest nødvendigt?

Jeg har haft “mistanken” i en del år, men nu gøres der noget ved det.

Delta t længe leve!

SOA Adoption and Architecture Fundamentals.

Fundet i alt-text på education.oracle.com

Hvad er egentlig en "Integrationsarkitekt" ?

 

 

 

SOA Governance er målet … der er håb endnu!

Udgivet i Arbejdsområde | Kommentarer slået fra

Jagten på Innovation … de 10 business agility ombud

Min påstand :  “Ægte innovation udspringer enten fra stor viden eller det diametralt modsatte; fordomsfri, abstraktivt uspoleret og ikke-ensrettet tankevirksomhed, som ofte kendetegner mindre børns syn på verden.”

Det ser ud til, at nogle er kommet frem til noget af det samme – meget lærerigt men tragikomisk. Man anner måske også problematikken omkring outsourcing :

http://www.forbes.com/sites/oracle/2012/11/06/the-hunt-for-innovation-10-strategic-insights/      

(Den fuld rapport: http://www.oracle.com/us/corporate/features/economist-program/index.html)

Jeg er for nylig blevet bekendt med en virksomhed, som ved første øjekast er tæt på de 10 bud … så det kan måske lade sig gøre.

Min søn bød også ind på “den uspoleret tankegang” :

https://www.facebook.com/bornecitater/posts/331387693579825

Philip, 5 år : “Far, hvad betyder det skilt ?”
Far: “Det er skiltet, som viser hvor toiletterne er.” (mand + dame symbol og en pil)
Philip peger dernæst på et grønt nødudgangsskilt (løbende mand mod åben dør) : “Er det så hvis man skal tisse meget?”

 God Jul og Godt Nytår

Udgivet i Arbejdsområde | Kommentarer slået fra

SOA – Et værn mod multiresistente BOB’s

Jævnfør tidligere indlæg er en BOB en process af typen Business Obstructive Behaviour. Det vil sige, en process der ikke tilfører virksomheden forretningsværdi snarere det modsatte. Det er min fasttømret holdning at BOB’s, herunder modvillighed både menneskeligt(POT’s lov) og økonomisk, koster arbejdspladser. Tilmed er de så hamrende dyre i drift, at det trodser enhver beskrivelse.

I have a Dream …. At et hvert kvartalsmøde eller lign. afsluttes med på rituel vis at slagte en BOB. Det vil blive en afsked domineret af lykke og lettelse. Som ved andre religiøse højtider skal man melde ud om nogen vil undsige beslutningen eller tie for evigt. Den gabestokslignende seance krydres med tilstedeværelse af ophavsmanden til BOB’en (Er innovatoren ikke tilstede skal LOB ansvarlig træde frem). Det vil være et tribunal af folkerretslig karakter, hvor man på demokratisk vis kan jorde mindretallet. Jeg helt og aldeles overbevist om, at medarbejdere/borgere vil have et bedre liv efterfølgende.

ex .: en pølsemand insisterer på, at alle medarbejdere under hensyn til smagsoplevelse skal lægge pølsebrød 32 grader magnetisk nord. KUN i tilfælde af særlig solvinde aktivitet kan dispenseres herfor dog ikke uden kundig vejledning hos vagthavende. Den OCD-lignende opførsel begrundes kort med “sådan har vi altid gjort”. I et sådanne miljø er det svært umuligt at fremelske innovativ adfærd. Konsekvensen er snarere af apatisk karakter – resignation. reductio in absurdum.

Gør ikke dit firma den bjørnetjeneste at lade BOB’s - af enhver art – leve et trygt og roligt liv. (det er godt nok uheldigt at bruge et 180 graders ord! Men halvdelen af befolkningen ved hvad jeg mener …)

Jeg henleder iøvrigt opmærksomheden på følgende artikel fra Ingeniøren. Konklusion herunder 80-20 eksemplet er tankevækkende :

http://ing.dk/artikel/76859-pas-paa-rygklapperen-dyrk-brokkeroeven alternativt http://soapera.dk/download/artikler/76859-pas-paa-rygklapperen-dyrk-brokkeroe.pdf

Er BOB’s kundevendte er de virkelig skadelige.

Jeg har selv haft held til  – via civil ulydighed – at ændre en BOB’s skrevene regelsæt til et uskreven regelsæt, som gør livet mere tåleligt.

Jeg står gerne til disposition for firmaer og institutioner for at afdække BOB’s af enhver art.

Min påstand er,

  • at jeg i anonymitetens tjeneste kan finde mindst een BOB indenfor en time pr. LOB.
  • at jeg kan anslå omkostningerne ved at have den
  • at jeg kan komme med radikale forbedringer til den eller forslag til afskaffelse

Hvordan? Bare ved at stille simple spørgsmål til medarbejderne.

Min drøm er, at virksomheder/institutioner gør det selv. Medarbejderne står somregel i kø for at tale om interne procedurers tåbeligheder. Det kræver blot, at ledelsen skal/forsøger at forstå medarbejderne. 

Jeg har altid selv sagt, at den dag jeg ikke adressere/brokker mig over ligegyldige procedurer, så var det et udtryk for resignation og at jeg ledte efter nyt arbejde(det er dog aldrig sket). En sidegevinst ved at tale om BOB’s er, at det ofte kan afstedkomme højlydt latter dog desværre lige så ofte afløst af total resignation.

2011 skal være året hvor mange BOB’s går en grum skæbne imøde!

Udgivet i Blandet teknik ... | Kommentarer slået fra

SOA, POLPOT og BOB’s

En af de helt karakteristiske ting ved SOA er, at det er en arkitektur/begreb der er så simpelt, at det er – næsten – helt umuligt at forklare. Da jeg er autodidakt i helt-umulig-kommunikation vil jeg vove forsøget efter KISS princippet. Man behøver ikke anvende et højt lixtal bare for at lyde dum …. “Make everything as simple as possible, but not any simpler”, Albert Einstein.     

Dette indlæg tjener til inspiration og eftertanke ifbm SOA og IT iøvrigt.     

Nogle spørgsmål, der måske trænger sig på ….     

  • Er der noget nyt i SOA ?     Næ …
  • Har man hørt salgsbudskaberne tidligere med andre arkitekturer og teknologier ? Ja, i høj grad.
  • Giver SOA nogen mening for en kun del af virksomheden ?   Næ …. Fordelen ligger ofte i stordrift (komponentbaseret udvikling fordrer genbrug)
  • Giver SOA mening for mindre virksomheder ? måske ikke …. værktøjer til stordrift er dyre. TCO (Total Cost of Ownership) under pres.
  • Giver SOA mening for mindre virksomheder som leverer IT baseret services til andre ? ja, i høj grad.
  • Vil man med succes kunne indføre SOA uden hensyntagen til brugerhåndtering a.k.a IDM/IAM (Identity/Access Management)? Ja, men udbyttet bliver begrænset på sigt. Ikke at medtage overvejelser mht brugerstyring vil ramme én med grusom styrke senere. MEN IDM integration kan være meget bekosteligt alene.
  • Er SOA ikke bare en IT teknisk videreførsel af princippet bag Legoklodsen? Jo!
  • Er SOA en god ide ? Ja, i høj grad. Magten tilbage til virksomheden og medarbejderne … hvis de får lov (jvf. POLPOT)
  • Er omkostningstyngden ligesom de-gode-gamle-CASE værktøjer ?  Ja, investeringerne er store i starten, men så kommer gevinsten også (Er det déjà vu  eller clair voyance?)
  • Kan man indføre SOA uden fuld opbakning (prokura og økonomisk råderum til SOAP-team) fra ledelsen ? Aldrig.
  • Kan man indføre SOA uden at flytte ansvar ? Aldrig.

Det var der vist ligeså mange spørgsmål som svar i. Meget kendetegnende for emnet mærker man den blide brise fra varmluftkanonerne(marketing)….     

Hvorfor SOA ?     

Hvis man går et par hundrede år tilbage(tidsmæssigt omkring brug af kugleramme) og ser på de første motivationer for Computeren(Beregneren), lå fordelen I, at den var i stand til at beregne ting, som mennesker næppe kunne gøre indenfor en livstid ; At trække viden ud af data (ofte store datamængder). Selve arkitekturen i computerer har stort set ikke ændret sig – de er blot blevet i stand til større og større ydeevne til mindre og mindre pris. Den mindre pris gjorde så, at PC’en blev en værdig afløser for skrivemaskinen (ETB) især mht arkivering. Næste skridt var så automatisering af manuelle processer. Varelager, regnskab, statistik ja mulighederne var uendelige. Egenudviklede systemer så nu dagens lys i hidtil usete mængder. De tog en evighed at udvikle, men de passede præcis ind og afbilledede virksomhedens måde at drive forretning på. Det var for såvidt også fint i mange år. Produkterne var i centrum og time-to-market var lang. Det er ikke tilfældet længere, hvor forandringsmulighed og forandringsvillighed er blevet meget vigtigt. Hvad gør konkurrenten? Hvad gør vi ved at konkurrenten gør som de gør ? For en offentlig virksomhed kunne kravet været styret af lovgivning eks. beregningsgrundlag for en tilskudsordning.  Systemerne er nød til at blive ændret – ikke opdateret – men ændret! Det tager tid. Her er den eksisterende teknologi har haft det lidt svært. Det har aldrig været let at følge med ændringer i samme tempo som forretningen(IT gap). Summen af kardemommen er, at forretningen ændrer sig hurtigere end man kan nå at ændre sin forretningssoftware. Hvordan kan et princip baseret på Lego-klodser være så svært at implementere? Man har tidligere med vekslende held forsøgt sig med komponentbaseret udvikling – CORBA, DCOM, RMI/EJB, JavaBeans etc … Planen var egentlig den samme, men det viste sig, at disse teknologier og frameworks ikke rigtigt slog til. Masterplanen var business agility/flexibility/interoperability/ maintainability/scalability… det var bare svært i praksis. Men nu tror jeg teknologien er her. Der er dog nogle hensyn af ikke teknologisk art som kan spænde ben (som altid).     

Uanset hvordan man vender og drejer det ønsker man (se figur):
IT skal nemt kunne implementere processer
IT skal nemt kunne ændres hurtigt     

Agility er tidsreduktion mellem processændringer

Agility er tidsreduktion mellem processændringer

Mindst er tre CSF’er være opfyldt/adresseret (“Critical Success Factors” fra de gode gamle Business Process Reenginering(BPR) dage)     

Vi har en P.O.T situaze:     

People – mennesker hader forandring.
Især hvis de ikke selv har bedt om forandringer, ikke forstår dem eller bliver usikre på deres betydning for dem. De kan udvise mere eller mindre civil ulydighed på alle niveauer. Det har altid været vigtigt at “sælge” beslutninger herunder budskaber ifbm indførelse af “ny” teknologi. Nogle firmaer gør sig meget umage med information, andre påkalder sig Amnesty International’s opmærksomhed ;-)      

Organisation – applikationssiloer skal nedbrydes/udjævnes.
Integrationsgevinsten sorterer herunder. I en større virksomhed kan der eksistere meget ens systemer fordelt over flere LOB (Lines Of Businesses). Disse systemer er tunge at vedligeholde og/eller er i bedste fald tæt koblet i form af megen kode – dvs kode der forretningsmæssigt tager langt tid at ændre. På toppen af alle disse siloer skal man placerer en beslutningsstærk enhed af arkitekter/folk for forretningen. De skal have den fornødne prokura til at lave nogle gange radikale ændringer på tværs af LOB’s – en hurtigindsatsstyrke, et SOAP team. Igen kan mennesker – her de ansvarlige for siloerne – komme i klemme, idet ansvaret flyttes. Her rammer “People” dobbelt.     

Technology – teknologien skal kunne implementere/sikre løst koblet systemer, infrastruktur med QoS (Quality of Service ex. sikkerhed, pålidelighed… )     

Det er her SOA og ikke mindst SOA produkter såsom Oracle SOA Suite (BPEL, Mediator, Business Rules, Workflow/Human task), Oracle Service Bus, Oracle Business2Business Suite, Oracle Enterprise Repository, Oracle Service Registry, Oracle Business Activity Monitoring, Oracle WebService Manager, Oracle Enterprise manager, Oracle Business Transaction Monitoring, Oracle Grid Control og loads af technology JEE JCA Adapter’s. Dertil kommer Oracle Web Center Suite herunder Oracle Application Development Framework(ADF) på UI-siden og en palette af IDM/IAM komponenter i Oracle Identity Management Suite.     

Det kan nok være, at hele eller dele stakken kommer til at koste lidt, men teknologien er klar!     

Den sidste faktor, og nok værste forhindring, kommer fra afdelingen for ufatteligt ødelæggende opførsel på tværs af LOB’s. En ofte usynlig variant af “People” nemlig politik. Det kan være meget svært at adressere denne muterbare faktor, men udspringer ofte af vigende ledelse og dårlig information om det fælles mål – vi taler da om “The Queen Mother of POT” : POLPOT.
Derfor INDEN man starter rejsen mod SOA’s forjættede land af forandringsparathed bør man minimum have taget stilling til ovenstående! Man vil sikkert (igen) indse at P+O er og bliver den største udfordring overhovedet …. de færreste vil blot indrømme det.     

Man må også holde sig for øje hvad den ikke-sagte motivation er for transformeringen. Uanset hvad man kommer frem til vil følgende udsagn kunne helt eller delvis være sande. De har altid været en del af den skjulte agenda:     

  • Vi gør det fordi de samme mennesker skal kunne lave mere på den samme tid?
  • Vi gør det fordi de samme mennesker skal give kunder/borgere bedre service?
  • Vi gør det fordi vi vil spare penge på services – afskedige folk eller outsourcing?
  • Vi gør fordi de samme mennesker skal fritages for meningsløst arbejde, så de kan lave noget andet som giver mere værdi for forretningen?

Der kan nævnes langt flere over samme læst – nogle mere sympatiske end andre. Fælles for dem er, at medarbejdere har ret til at vide besked!
Lad os antage, at ovenstående er på plads og den egentlige forretningsudvikling kan påbegynde.     

Hvor starter man?
Jeg ser 2 metoder som ikke er gensidigt udelukker hinanden eller for den sag rækkefølgen, men bør bruges sammen:     

Den første tager udgangspunkt i medarbejderne, den anden tager de eksisterende systemer i ed:     

  1. Måske lidt overraskende vil jeg starte med information og uddannelse af de aktive aktører. ALLE medarbejdere skal stille skarpt på “tankesættet” og ikke mindst ledelsen skal især skal kende betydningen/konsekvenserne af beslutningen.  Beslutningsansvar skal flyttes (SOA Team) og the chain-of-command skal gøres kort! Agility i alle led.
  2. Lav et “Process improvement system” efter KISS princippet (ex. WordPress blog application). Et system, hvor ALLE medarbejdere NEMT kan rapportere forslag til forbedringer af forretningsprocesser.  Alt skal adresseres, vurderes af et SOAP team og ikke mindst kommenteres. En fremragende mulighed for at få diskuteret forretningen igennem og evaluere på eksisterende systemers formåen. Systemet tjener som motionering af alle led i forretningen – nogle gange som gigtmedicin.
  3. Ovenstående system skal også have en ANONYM “stikkerlinie”, hvor brokkerøvene kan udfolde sig bramfrit jvf. (http://ing.dk/artikel/76859-pas-paa-rygklapperen-dyrk-brokkeroeven). Tjener som antiinflammatorisk blokade, når beslutningstagere laver flyverskjul istedet for at handle. Round-the-table-talks kan ligeledes være en mulighed, men har begrænset virkning.

Bevæggrundene for de 2 sidste punkter er, at ALLE virksomheder har en eller flere BOB’s, som gør tilværelsen sværere for mange medarbejdere. BOB’s er processer af typen “Business Obstructive Behaviour”. Det vil sige processer, der er åbenlyst torskedumme, fungere forfærdeligt og/eller mange lider voldsomt under dem. De er karakteriseret ved at være det diametrale modsætning til “Business Agility”, koster enorme summer, men som ingen rigtigt ønsker/tør at måle på eller anskueliggøre konsekvenserne af dem. De er multiresistente af natur (mere i en senere bloog).
Mange af dem udspringer af kontroller, hvor den eneste forretningsmæssige bevæggrund er, at nogle har snydt dvs alle skal straffes. Andre udspringer af et tidsmæssigt perspektiv, som ikke længere er opfyldt, hvilket har tilskrevet BOB’en en deskruktivt karakter, som dræber frit initiativ og innovation. Endnu flere skyldes blot mangelfuld implementering, som følge af økonomiske, politiske eller tekniske årsager, der  udspringer af mangelfuld viden. Ofte er det virksomheder, som tilbeder innovation, som har flest BOB’s – skrevne som uskrevne. ALLE har BOB’s!
Er en BOB kundevendt bliver den skadelige virkning mangedoblet, da den sår kimen til illoyalitet, som er ren gift for virksomheden.     

Et lille eksempel er fra en teleudbyder et sted på planeten. Efter at have erhvervet en mobil skulle jeg via en “Selvbetjenings-webside” registrere automatisk betaling via PBS. Efter endeligt at have bemægtiget mig adgang til systemet, skal jeg indtaste betalingsoplysninger. Siden beder om et “aftalenummer”. Hjælpesystemet beskriver, at aftalenummeret skal fremgå af girokortet. Problemet er bare, at der ikke findes noget girokort kun et betalingsid og fakturanummer på den elektroniske betaling af telefonen via websiden. DERFOR er jeg nødsaget til at ringe til teleudbyderen. Jeg får oplyst mit aftalenummer og ser, at det er del af fakturanummeret. Det oplyser jeg til deres telefonservice og forespørger om de ikke kan tilføje denne information i deres hjælpesystem. Jeg møder en mur af tavsheds og modviljen er stor mod at påtage sig denne opgave. Hvorfor ved jeg ikke, men konsekvensen er, at tusindevis af “Selvbetjeningskunder” på skift kontakter teleudbyderen for denne info, som jo er dyrt for alle.
Løsninger til de værste BOB’s optræder ofte i kategorien “no-brainer”.     

En anden metode er den mest brugte og tager udgangspunkt i en teknisk systemgennemgang:     

For mange kan det virke som en uoverskuelig process at dokumenterer eksisterende processer, datagrundlag og grænseflader. Større virksomheder har heterogene miljøer, som langt fra alle – om nogen overhovedet – kender værdien af (“Rat’s nest” jvf. “Service Orient or be doomed”, Jason Bloomberg og Ronald Schmelzer). Men man skal jo starte et sted, så hvorfor ikke tage Top 10 af de vigtigeste processer i virksomheden. Man kender dem jo i forvejen, så det kan vel næppe være et problem at modellere dem som “as-is”. Under modelleringen dem er man nød til at nedbryde dem i mindre klodser, eller sæt af klodser(services moduler). Nedbrydningen spænder over kategorisering jvf. ex. ”the-six(eight)-domain model” (http://onlineappsdba.com/upload/BEADomainModelForSOA.pdf ). Husk det er iterativ udvikling, men man har mulighed at indbygge “to-be” funktionalitet, wrappers og isolation services. Det vil sige en unik mulighed for at remodellere tidligere tiders mangler!
Det bedste ved SOA er, at magten burde være tilbage hos dem der virkelig forstår processerne. Udviklere reduceres til skibssnedkere med sans for implementeringstekniske detaljer. Sådan har det vel altid været tænkt at IT skulle implementeres.     

Arbejdsbyrden bør fordeles med
50 pct til forretningen/processfolk(ex. Indkøbsprocess),
20 pct til service implementering (Hvordan skal indkøbsprocessen forløbe teknisk),
20 pct til fejlhåndtering(Når indkøbsprocessen ikke forløber normalt hvad så ..),
10 pct til måling af den af forretningen beskrevne process. (Forløber Indkøbsprocessen forløber som den skal?)
Dvs 60 pct af tiden bruges på forretningsværdi kun 40 pct på IT. Hvis Agility lykkedes forbedres denne ratio over tid, hvis ikke, har SOA fejlet.     

Der bliver tit spurgt til “Best practices” ?
Men er “Best practices” ikke bare en kortsigtet erfaringsudveksling, som ofte baseres på workarounds og uhensigtmæssigheder (aka bugs) i teknologierne. Man kunne sige “Erfaring blot en evne til at genkende en fejl, når man begår den igen”. Mange ser “Best practices” som en Schweizer-kniv som skal løse alle problemer, men brug dog den stærkeste resource af alt – tankens kraft! Det gælder i det branche specifikke proceslag, som det teknologiske udviklingslag; der er ingen nemme løsninger! Ægte innovation udspringer enten fra stor viden eller det diametralt modsatte; fordomsfri, abstraktivt uspoleret og ikke-ensrettet tankevirksomhed, som ofte kendetegner mindre børns syn på verden. Efter min mening kommer de bedste ideer ikke fra innovation (i branchen fejlagtigt fortolket som nye tiltag), men fra simple/banale procesforbedringer herunder afskaffelse af BOB’s.     

Selvom motivationen og tankegangen bag SOA er ikke ny, muliggør arkitekturen “Business Agility” uafhængigt af IT systemers mangel på samme. Forskellen er, at branchen har, gennem udviklingen af SOA specifikationerne, stiltiende indrømmet, at IT agility aldrig rigtigt har eksisteret.     

Råd for 2011+ :
Kun en tåbe frygter ikke brokkerøve som brøler “BOB, BOB, BOB”, når nye politikker søsættes.     

Vi lader billedet stå et øjeblik ……     

Godt nytår!

Udgivet i Arbejdsområde | En kommentar

Nordiske kurser indenfor FMW

En lille søgeform til Oracle University designet efter KISS-princippet.

http://soapera.dk/download/utilities/oracleOUSearchPageNordicEnglish.pdf

Fungerer dårligt i 64-bit IE og Chrome browsere.

Udgivet i Oracle kurser | Kommentarer slået fra

Oracle Fusion MiddleWare (FMW) Administrators battleground

Feel free to copy

Man har en management grænseflade på hele stakken, hvor ulykker i netværks-, CPU-, Memory- og databaselaget kan ramme én med grusom styrke. Problemer knytter sig til CPU arkitektur, Operativ system, Virtualisering, WebLogic, SOA Service Engines og ikke mindst eneulykker som JEE applikationer og egenudviklet Web Services, Service Bus Services eller  SCA Web Services (BPEL, Mediator ).

Business Agility Support (BAS), der ligger lige til højrebenet. Det har aldrig været nemmere … eller …

Udgivet i Oracle kurser | Kommentarer slået fra

SOAP operaen er åben …

Dette site er under opbygning … (læs: jeg har ikke tid, hvilket er et positivt problem som nystartet virksomhed).

Jeg har dog valgt WordPress Open Source engine til sitet. Mest på grund af en imødekommende licenspolitik, 5 minutters installation og nem brugergrænseflade. Ord som Business Agility and Flexibility trænger sig på - aka BAF

Kontakt information findes på siden.

Udgivet i Arbejdsområde | Kommentarer slået fra