Defining SOA as an architectural style

IT'ers verdringen psychologen en pedagogen als testers

Bij steeds meer bedrijven is de core business afhankelijk van IT: tickets moeten online besteld worden, bankzaken regel je via een site en heel het netwerk van de telecomoperator valt terug op IT. Fouten in de IT worden dus hard afgestraft met een verlies van inkomsten, klanten wiens vertrouwen kwijt raakt of imagoverlies. Wim Demey, testspecialist bij Sogeti, oordeelt dan ook dat het belang van testen mee is gegroeid met het belang van IT in zakelijke omgevingen.

IT Professional: Is testen eigenlijk wel belangrijk? We zien dat het vaak achteraan het ontwikkelproces komt, waardoor er vaak op beknibbeld wordt.
Wim Demey: We merken dat de eisen voor informatica steeds hoger worden. Kijk maar naar websites. Als die niet snel laden, haken surfers gewoon af. Bedrijven die diensten aanbieden via het web kunnen zwaar imagoverlies oplopen als er iets niet werkt. Ook is er kans op financiële verliezen. Denk maar eens aan een telecomoperator wiens netwerk platligt door een bug. Die operator loopt miljoenen euro mis.

De meeste bedrijven kennen het nut van testen, maar nog niet alle bedrijven kunnen op een gestructureerde manier met tests omgaan. Vooral grote bedrijven hebben vaak een testafdeling met een eigen testmethodologie. In België zijn alle grote spelers in de bank- en telecomsector ermee bezig. Bij de kleinere bedrijven zien we vaker een pragmatische aanpak die niet altijd gestructureerd is. En dan zijn er ook bedrijven die zich niets aantrekken van testing zolang er in de productie niets mis loopt. Als er toch wat misgaat is het dan te laat.

Wat met SOA? Verandert dat veel aan het testproces?
Service oriented architectures vragen een heel andere benadering van testen. De tests worden veel technischer, want we moeten de XML-bestanden zelf gaan analyseren. Traditioneel worden de meeste tests uitgevoerd op grafische interfaces, wat zeer visuele tests zijn. Met SOA moet men meer naar de bestanden zelf kijken.

Lees artikel

Bron: www.itprofessional.be

Voor een presentatie die ik moest houden was ik op Google aan het zoeken met de zoekwoorden “SOA” en “testen”. Voor IT’ers een normale combinatie, voor de rest van Nederland een onderwerp waar ze eigenlijk het liefst helemaal niets mee te maken willen hebben. Helaas is semantiek nog niet iets waar Google mee overweg kan.

Het onderwerp waar ik naar op zoek was, was" "hoe test ik mijn Service Oriented Architecture (SOA)". Bij het uitrollen van een op SOA principesgebaseerde architectuur komen steeds meer organisaties er achter dattraditionele testmethodes en gereedschappen niet meer voldoende zijn om decomplexe gelaagde wereld van een SOA grondig te testen.

Het testen van de individuele componenten, de webservices bijvoorbeeld, dat gaat nog wel. De interface is immers goed gedefinieerd in devorm van een WSDL. De gebruikersinterface testen wordt al wat moeilijker, moderne webapplicaties maken steeds meer gebruik van AJAX  (ga daar maar eens op zoekenmet Google) en daar kunnen sommige testtools niet zo goed mee omgaan. Het testen van een complete SOA infrastructuur is een heel ander verhaal. Eendergelijke complexe infrastructuur bevat bijvoorbeeld een BPM product, een ESB, messaging middleware , Enterprise Java Beans en een database. Allemaal met elkaar verbonden en van elkaar afhankelijk. Loosely coupled dat wel, maar hoe je het ook bekijkt een SOA zit vol afhankelijkheden.

Lees artikel

Bron: Computable

"Wij zien dat traditionele testers er best moeite mee hebben, omdat het testen van een servicegerichte architectuur een stuk technischer is dan het testen van een traditionele client/server-architectuur", zegt Jaap Mulder van het bedrijf Parasoft, dat soa's test. Het grootste voordeel van een soa is dat verschillende diensten in verschillende applicaties kunnen worden aangeroepen. Dit zorgt ervoor dat het testen van een soa lastig wordt.

"Bij een normale applicatie weet je hoe iets gebruikt wordt. Bij een servicegeoriënteerde applicatie heb je verschillende delen, maar je weet nog niet meteen hoe je deze gaat gebruiken. Het wordt anders gebruikt dan dat je in eerste instantie voor ogen hebt", zegt Sandra Carter, vice-president van de SOA & WebSphere Strategy van IBM. "Het voordeel is alleen te behalen als je de losse ‘blokjes' zeer goed test", zegt Mulder.

Lees artikel

Bron: Computable

"Wij zien dat traditionele testers er best moeite mee hebben, omdat het testen van een servicegerichte architectuur een stuk technischer is dan het testen van een traditionele client/server-architectuur", zegt Jaap Mulder van het bedrijf Parasoft, dat soa's test. Het grootste voordeel van een soa is dat verschillende diensten in verschillende applicaties kunnen worden aangeroepen. Dit zorgt ervoor dat het testen van een soa lastig wordt.

Lees artikel

Bron: computable

Lees artikel

Bron: Computable

In the ERP world, many companies take whatever their ERP system gives them, but this might not cover some important line of business functionality they require. The good news is that ERP systems have been adding a component called Service Oriented Architecture (SOA). Here's one definition:

A Service-oriented Architecture defines how two or more entities interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. The unit of work is referred to as a service, and the service interactions are defined using a well-defined description language. Each interaction is self-contained and loosely coupled, so that each interaction remains independent of any other interaction.

and Wikipedia's definition: "a computer systems architectural style for creating and using business processes, packaged as services."

SYSPRO was one of the early adopters of Microsoft's .Net Framework, and this has enabled the company I work at to develop customer- and industry-specific line of business applications, using the SYSPRO ERP as the basic information foundation. Effectively, we are able to 'pimp' a company's ERP to give specific functionality that a general ERP cannot do. 

The way SYSPRO's SOA works is via its e.Net architecture. This comprises quite a number of business objects which provide a structured way of directly accessing the business functionality of SYSPRO while retaining the software's integrity, business rules and security.

Getting value out of SOA requires good business understanding and programming skills by the consulting organisation, but also a vision and understanding by the business having the SOA implementation.

Companies like ours have the vision of what we can do with SOA, but without a similar vision by business leaders, the promise and benefits of SOA is not going to get realised. The problem seems that many business people (and CIOs) haven't yet 'got to grips' with the opportunity that SOA offers. I wonder if there's a TV network interested in doing a "Pimp My ERP" show?

Comunque voglio aggiungere qualche considerazione, raggruppandole in sei categorie – il che non implica necessariamente che io ne sappia meno di Paul che elenca 10 argomenti :-) – per dare il mio contributo basato sull’esperienza personale. Sono solo spunti di discussione, perchè non possiamo dilungarci su questo blog: sarei in ogni caso felice di approfondire l’argomento con chiunque sia interessato a condividere le proprie esperienze, quindi scrivete i vostri commenti o mandateci una email, ci farebbe piacere.

Tecnologia

Spesso l’adozione di SOA viene interpretata come un’iniziativa meramente tecnologica e si concentrano (a volte si sprecano) molto tempo e molte risorse nel definire puntigliosamente le caratteristiche dei prodotti che si dovranno usare per coprire ogni eventuale necessità futura.

In questo modo l’avvio di un progetto richiede lungo tempo, e si guardano da lontano quelli che sono partiti in modo più pragmatico. Pur essendo uno dei sostenitori di un’architettura di riferimento ben definita (basata su tutti prodotti BEA o meno, va bene lo stesso: e poi un’architettura non è fatta di soli prodotti) sostengo che si può anche procedere per iterazioni successive, cominciando a sperimentare e facendo tesoro dell’esperienza; definendo una visione di ampio respiro mentre si implementano le cose semplici che sono a portata di mano. Pensando in modo strategico e agendo contemporaneamente in modo tattico. Programmando una roadmap che sia oggettivamente realizzabile.

Tra l’altro, a volte la tecnologia di cui si dispone è già sufficiente per iniziare la realizzazione di quello che serve: ho visto fior di architetture realizzate utilizzando Tuxedo o il CICS, quindi non sempre la tecnologia più attuale è necessaria per ogni progetto.

Governance

Molte decisioni devono essere prese nella realizzazione di un programma SOA di livello enterprise:

• Chi definisce e modifica i servizi?
• A chi è consentito l’uso dei servizi?
• Quale livello di servizio dobbiamo fornire?
• Chi paga per la costruzione del servizio?
• Chi paga per l’infrastruttura per i servizi?
• Come devono essere gestite le interdipendenze tra i servizi?
• Come esporre i servizi all’esterno?

Si devono fare anche queste, ed altre, considerazioni:

• Struttura organizzativa
• Finanziamento
• Processi Operativi e strumenti di supporto
• Standard
• Competenze
• Principi Guida
• Change Management

Non ci si può illudere di non dover affrontare questi argomenti, sicuramente quando sono spinosi: quindi metteteli in conto dall’inizio. In ogni azienda esistono posizioni di potere che possono essere intaccate da una strategia basata sulla condivisione e sulla collaborazione: oltre a una rivoluzione culturale servono regole (rispettate) che consentano all’intero sistema di funzionare, possibilmente con il coinvolgimento attivo di tutti gli attori.

Esperienza

A volte ci si fa prendere dall’entusiasmo, avendo intuito (o anche studiato in modo approfondito) i benefici che si possono ottenere da un approccio SOA. Quindi si parte in quarta: si studia, si organizza, si acquista quello che serve e si inizia un bel progetto.

Se però non si ha esperienza di iniative di questa portata, sia dal punto di vista di una architettura enterprise che da quello della famosa governance, si rischia di ritrovarsi in mezzo a una palude.

I tempi di realizzazione, l’integrazione, il budget o il change management possono diventare dei problemi in corso d’opera. A volte si costruisce un bel prototipo, che però non ha le caratteristiche sufficienti per la messa in esercizio; oppure si realizza l’infrastruttura perfetta, ma nessuno ha un servizio utile da metterci sopra.

Vale quindi la pena di confrontarsi con qualcuno che abbia già intrapreso (e portato avanti con successo) lo spesso percorso, per fare tesoro della sua esperienza e impostare il proprio lavoro nel modo migliore.

Consiglio di parlare con project manager, program manager e architetti che abbiano già realizzato progetti SOA reali per farsi raccontare quali difficoltà hanno incontrato e come le hanno eventualmente risolte. Tra questi potete considerare colleghi che hanno il vostro stesso ruolo in altre aziende, consulenti che lavorano per i system integrator o i software vendor, tra cui ovviamente BEA. Mi raccomando però di verificare le credenziali dei sedicenti esperti, perchè SOA è sulla bocca di tutti e il mondo è pieno di “enterprice architett”.

Iniziativa IT senza partnership con il business

Se la divisione IT di un azienda intraprende un’iniziativa SOA in modo autonomo, di solito lo fa per uno di questi motivi:

• va di moda, quindi se gli altri lo fanno un motivo ci sarà
• è moderno, quindi se lo facciamo possiamo metterci in evidenza come innovatori
• possiamo chiedere una quota di budget per rinnovare le nostre infrastrutture.

E’ invece consigliabile che l’inizio del progetto derivi da un’iniziativa condivisa con i responsabili del business dell’azienda: a seconda del settore, con la produzione, la logistica, il marketing, il demand management.

Se l’iniziativa è fine a se stessa, non produrrà un valore per l’azienda. Non avrà un ROI dimostrabile e non darà lustro ai suoi responsabili. Se invece è condivisa con chi può beneficiare dei suoi risultati in termini di fatturato, dimostrerà di portare vantaggi al business. E’ essenziale un sistema di metriche per dimostrare in modo quantitativo il vantaggio generato. Ma soprattutto è necessario che ogni attività sia mirata alla soluzione di un reale problema che gli utenti di business percepiscono nella loro attività. Se per esempio un processo di vendita richiede troppo tempo, ridurne la durata ottimizzando il processo (eliminando attività manuali, per esempio) può avere effetto sul flusso di cassa. Rendere la produzione più efficiente può diminuire l’immobilizzo di capitale e le spese per la logistica. L’IT dovrebbe imparare a parlare lo stesso linguaggio del business e a interpretarne le necessità (condividendole in modo esplicito ed evitando assunzioni che potrebbero non essere condivise).

Mancanza di pragmatismo

Tra l’altro, la condivisione di una roadmap può evitare che si creino aspettative ingiustificate o, peggio, che non ci siano aspettative. Rendere visibili i risultati ottenuti nelle fasi intermedie della roadmap, secondo quanto pianificato, garantisce il supporto degli sponsor di business e non fa venire meno il sostegno negli eventuali momenti in cui il progetto incontra dei problemi. Per questo motivo bisogna assolutamente evitare approcci di tipo Big Bang, in cui risultati eclatanti vengono promessi alla fine di un arco di tempo troppo lungo: si potrebbe non arrivare mai a dimostrarli...

La figura seguente mostra che – a seconda della situazione che fa nascere l’iniziativa SOA – è opportuno organizzarsi in modo differente: la roadmap conterrà azioni adeguate alla situazione e nella sequenza più opportuna.

Comunicazione

• Marketing interno: come detto nell’introduzione, occorre definire un piano strategico e realizzarlo in modo tattico. E’ importante che l’azienda cominci presto ad apprezzare i risultati, per creare un circuito virtuoso intorno all’iniziativa SOA.
• Riuso degli asset nei progetti: se si realizzano dei servizi utili ma pochi ne conoscono l’esistenza, probabilmente il vantaggio del riuso sarà limitato. Conviene mettere a punto una strategia di comunicazione e gli strumenti a supporto (service repository e/o un portale intranet, newsletter, eventi periodici...).
• Demand management: dare a chi si interfaccia con il business la visibilità degli asset disponibili (possono nascere nuove idee dalla conoscenza dei servizi esistenti) o la possibilità di esprimere i requisiti in modo da iniziare il ciclo di vita dei servizi (o delle applicazioni composite): il repository è sempre utile.
• Diffusione della cultura della condivisione: le modalità dipendono dal contesto aziendale, ma questa attività è quanto mai necessaria.

Both Guerrilla SOA and Web 2.0 emphasize rapid, lightweight Web-based solutions to pressing problems

Now, a discussion by analysts in the latest BriefingsDirect SOA Insights podcast raises Guerrilla SOA thinking to a whole new level — that it’s actually part of the Web 2.0 phenomenon.

(Podcast leader Dana Gardner also provided more insights on the Guerrilla SOA-Web 2.0 connection in a panel discussion I hosted as part of this week’s SOA in Action virtual conference. I’ll post more details as the archived links become available.)

SOA Insights panelist JP Morgenthal said the Guerrilla SOA/Web 2.0 approach is well suited for smaller organizations that don’t have the time and resources to sit and plan grand SOA/EA strategies — they just need to get things done and do what they can to clear up backlogs: “They don’t spend their time sitting there wondering, whether they’re going to do Web services or SOA. It’s more like 1,500 calls coming in a day, they’re being bombarded, and yet they still have to get stuff done.”

Analyst Tony Baer agreed that conceptually, Guerrilla SOA and Web 2.0 are similar. “I’m sure there are probably purists who would probably come up with their own unique definitions to reflect the idiosyncrasies of each of the terms, but, I think it refers to an overall style… It’s the same drive that’s basically made agile-development techniques so popular. The idea is that we have pain points we need to address today, but we need a planning methodology that’s robust enough so that we don’t keep chasing our tails. At the same time, we also need technologies we can use to make this simple.”

Tony also pointed to the irony that REST is considered to be a faster and simpler deployment mechanism than conventional Web services. Not too long ago, conventional Web services were touted as a simpler alternative to an earlier incarnation of SOA, which was CORBA, he pointed out. “As we started getting a little more experience working with some of those Web-services technology, we realized that maybe we didn’t always need those complicated SOAP headers. So, why not dispense with that, because most of our needs right now are for simple things like fetching data.”

The irrepressible Jim Kobelius chimed in with a new acronym, proposing that the new architecture be called GOA, which could mean one of two things — “Guerilla Oriented Architecture versus Governance Oriented Architecture.” Or, taking the WOA acronym a step further, meaning “Water-cooler Oriented Architecture” versus “Web Oriented Architecture.” We all know that this is where the real collaboration and information sharing takes place within organizations. And, in many ways, is Web 2.0 not is making the world one giant water cooler?

Dana also wondered out loud if the horizontal collaboration and service development and sharing that is now possible across organizational boundaries and across the globe is not making the corporate structure as we have know it irrelevant. “The corporations traditionally needed to exist because of the requirement of huge capital brought together in large R&D budgets to solve massive technical problems. They’re being overshadowed by groups of 8 to 10 people that then create a startup using their credit cards, access to Web services, and low-cost computing, storage, and networking.”

Highlights from the report:

1. Companies are shifting to enterprise-wide SOA adoption. Nearly 1 in 5 technology decision makers are currently deploying SOA across the enterprise. In a few short years, SOA has grown from a collection of experimental pilot initiatives to a comprehensive enterprise approach.

2. SOA remains an important long-term priority for the vast majority of organizations.

3. Challenges to SOA deployment are organizational, not technical. Lack of SOA skills or training was cited as the leading challenge.

4. Lack of effective SOA governance is the number one inhibitor to SOA adoption.

Link to this report: http://www.bea.com/framework.jsp?CNT=homepage_main.jsp&FP=/content
-> To download this report (a PDF file), you need to register with BEA.