SOA in het perspectief van Enterprise Architectuur
Jaap Schekkerman
maandag, 15 januari 2007
Service Oriented Architecture staat volop in de belangstelling en veel IT leveranciers promoten hun SOA oplossingen via diverse kanalen. Wat hierbij belangrijk is, is om te onderkennen dat SOA geen technologie oplossing onder de IT motorkap is maar dat service orientatie een manier van inrichten en vormgeven van de organisatie is en derhalve een inrichtingsstijl van de Enterprise. Het organiseren van de business in termen van diensten en het doorvertalen van deze diensten naar herbruikbare software services is de ultieme uitdaging. Dat dit kennis van zowel de organisatie als IT vraagt spreekt daarbij voor zich, echter wat organisaties zich vaak onvoldoende realiseren is dat veel IT‘ers moeite hebben met het adopteren van het service paradigma en derhalve blijven steken in de voor hen bekende denkwijzen, waardoor oplossingen ontstaan die geen recht doen aan het services concept. Het hanteren van service orientatie als inrichtingstijl binnen de Enterprise Architectuur helpt om de samenhang tussen organisatie en IT te borgen. Daarnaast biedt het de mogelijkheid om het service paradigma op alle niveaus te projecteren waardoor een geleidelijke transitie naar het services concept mogelijk wordt.
Ik werd laatst gevraagd of ik kon aangeven wat de juiste omvang is van een bedrijfsservice (ook wel: “granulariteit”). Dat was best een lastige vraag en wel om twee redenen. Ten eerste wist ik niet zeker wat hij bedoelde met “bedrijfsservice”; een dienst die een organisatie levert of een dienst die de software levert en die met bedrijfslogica te maken heeft. Daarnaast is omvang iets dat afhangt van het doel dat je hebt, en waar overigens ook hele andere overwegingen bij gelden voor softwarediensten dan voor organisatorische diensten. Voor softwarediensten kom je al snel in hele technische, maar ook in filosofische discussies en is volgens mij al meer dan genoeg gezegd. Laten we dus eens kijken naar “echte” bedrijfsservices.
Zaakgericht werken is een principe dat een belangrijke rol speelt bij lokale overheden, maar zeker ook breder toepasbaar is. Het heeft veel overeenkomsten met service-oriëntatie. Het basisidee is dat je de diensten die je aanbiedt goed definieert en dat je de bijbehorende service levels bewaakt. Er zijn allerlei architectuurbouwblokken die een rol spelen bij zaakgericht werken zoals zaaksystemen, zaakmagazijnen en Persoonlijke Internet Pagina's. De vraag is echter wanneer de verschillende bouwblokken relevant zijn en hoe ze met elkaar samenhangen. Is bijvoorbeeld een zaakmagazijn noodzakelijk voor het publiceren van de status van vergunningen op Internet? In dit item zet ik alle belangrijke architectuurbouwblokken op een rij en laat hun samenhang zien.
Information technology (IT) has been identified as a major organizational resource that enables organizations to achieve competitive advantage or to survive in their market (Brynjolfsson & Hitt, 1996). As business and IT should nowadays cooperate seamlessly, the rigidity of old IT proved to be a bottleneck for sustaining competitive advantage in the markets.
Gemeenten worden geconfronteerd met allerlei ontwikkelingen die van invloed zijn op hun informatievoorziening. Belangrijke ontwikkeling in dat kader is de verplichting om bepaalde gegevens nog maar eenmalig uit te vragen en meervoudig te gebruiken. Dit roept allerlei vragen op rondom de noodzakelijke gegevensuitwisseling tussen applicaties en de wijze waarop deze wordt ondersteund door generieke voorzieningen. Kan zoiets als een Gemeentelijke Service Bus hierin ondersteunen en hoe zou een dergelijke voorziening er uit zien? Dit artikel beschrijft het resultaat van een onderzoek in de gemeente Gouda naar een dergelijke voorziening.
Information technology (IT) has been identified as a major organizational resource that enables organizations to achieve competitive advantage or to survive in their market (Brynjolfsson & Hitt, 1996). As business and IT should nowadays cooperate seamlessly, the rigidity of old IT proved to be a bottleneck for sustaining competitive advantage in the markets.
A Service-Oriented Architecture (SOA) is an architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA adoption can be a solution to integrate the heterogeneous applications in an organization. In a SOA, existing applications are decomposed into application services, and business processes are decomposed into business services. Application services can be reused throughout the organization because their service descriptions are published in a service registry, and they can interact using standards for the exchange of messages. Application services are loosely coupled, and can therefore be orchestrated to automate business processes. By using standards for message exchange, service description and service discovery, functionality residing in different business functions can be composed to automate business processes that span different business functions.
Als het over architectuur gaat begint iedereen over SOA. Jawel, die beruchte Service Oriented Architecture. Ook als de hele klantomgeving een grote monoliet is zoals SAP ERP zal en moet er weer een servicebusje onder. En natuurlijk overal stekkers op basis van open standaarden. Bij NORA struikel je over de bijbehorende geloofsbrieven. Andere geluiden worden niet op prijs gesteld. De nieuwe religie dus.
In rapidly changing markets it is of primary importance for organisations to be able to cooperate in a flexible manner with diverse external partners. in such a joint venture it is readily required to integrate business processes and their associated IT support.
This research approaches the service register as an Information Intermediary. This enables the use of design theories which not only focuses on the technical aspects of delivering the right description to the user, but also the organizational processes and procedures to support this. The result is an attempt for creating an effective design for a service register.
The main goal of this thesis is to describe the relation between SOA and BI, by providing an overview of the opportunities and limitations of using BI in an organization that adopts SOA for building its applications. Opportunities describe how the adoption of SOA can improve the use of BI. Limitations describe the constraints of these opportunities, and the limitations of traditional approaches to BI on SOA applications. The opportunities and limitations are described in concepts and technologies, of which the technological description will be mainly described by the resulting software architecture. Since the academic literature on this subject is rather thin, this research poses to establish a useful source of information to those practitioners and academics working and learning in the field of BI, who are interested in the developments of BI.
Only extraterrestrials just arrived from outer space can have missed the fact that we are in a global economic recession right now. Maybe it will blow over soon, but many expect worse conditions ahead. Organizations prepare for a period with very little room to maneuver. Revenue is drying up and the only way to make a profit is to cut cost and wait for better times. Projects are stopped as it is recognized their business cases are no longer valid. This includes many SOA initiatives, even when based on solid business cases at the time. Only projects that directly reduce cost in a very short term are started or kept alive....
Enterprise SOA failed for lack of business support, drivers and proper preparation, given the project size and implications. The technology usually associated with SOA (ESB, BPMS, WS) for orchestration, discovery, integration is alive and well. Similarly, SOA at the application and suite levels. Take for instance the trend to design applications suites observing SOA.
In this article, I would like to share some experiences with a visualisation for the business in a
SOA environment. MediaWiki is the basis for the visualisation tool because it is a wide
spread and well known environment. For this purpose, the normal static MediaWiki is
enhanced with some dynamic features to support hyperlinks for the inter-relations between
the entities in the SOA environment.
Over the last couple of years there has been a tremendous interest in Service-Oriented Architecture (SOA). It can safely be classified as a hype. As hypes go it follows the Gartner hype cycle. We now seem to be in ‘Trough of disillusionment’. Signals of ‘SOA fatigue’ are appearing everywhere. Professional architects, of course, are not concerned with hypes, and have recognized the true value of SOA from the start. This article will illustrate SOA’s true value by describing practical scenario’s where cases exist for developing services. The actual composition of a complete business case will not be described. Aspects specific for service business cases are treated.
Jim Webber komt de eer toe om als eerste – of op z'n minst één van de eerste – software analist publiekelijk zijn afkeer geuit te hebben van een “fat SOA”. Zijn levendige en amusante bijdrage aan de Qcon 2007 conferentie onder de titel “Guerilla SOA” [1] heeft ongetwijfeld velen aan het denken gezet. De laatste weken zijn vele industrie-goeroes hem in zijn voetsporen gevolgd. Onder hen bekende namen als Martin Fowler [2], David Linthicum [3] en Joe McKendrick [4]. Het onderwerp prikkelt op z'n minst de creativiteit. Kwalificaties als “Mam Boobs”, vergelijkingen met “Junk Food” en woordgrapjes als “Enterprise Service Busted”, “Erroneous Spaghetti Box” en “Same Old Atrocity” zijn niet van de lucht. Het lijkt wel een collectieve actie van de softwareontwikkelaars en -architecten gericht tegen de grote boze leveranciers met hun dikke, dure middleware. Tijd voor een dieet?
Don't try to convince system-scale project leaders of enterprise-scale architectural decisions or you will "die". Especially if you don't have good examples at hand. (Should project leaders be "convinced" of architectural decisions at all? Or should there be a "trust" relationship with the employed architects?
Looking from the business side, there is the composition of business activities into autonomous business functions. On the other hand there is the composition of application constructs.
De weg naar een service georiënteerde architectuur ligt bezaaid met wrakken. Tal van organisaties hebben SOA-initiatieven zien mislukken, of vroegtijdig “geherprioriteerd”. En wat is er nou eigenlijk zo nieuw onder de zon? Services zijn toch ziet wezenlijk anders dan wat eerder componenten werd genoemd in “component based development?” Je zult zien, over een paar jaar dan hoor je niets meer over SOA. Dan heet het al lang SOB of SOZ. Zelfs steeds meer architecten zeggen jeuk te krijgen van de term SOA (no pun intended). Dus kunnen we onze tijd nu maar beter aan iets nuttigers besteden.
You can obtain decoupling (independency), reliability and performance at the (low) cost of redundant data persistency. When you stick to "calling services" you gain benefits at the level of application construction, but at the cost of higher loads, less predictable performance, scalability issues and higher costs in business level reorganizations.
Al een paar maal ben ik het nu tegengekomen; de opmerking dat de term "SOA" in de context van een bedrijf beter niet gebruikt kan worden. Men noemt het liever anders of helemaal niet. Je zou hieruit kunnen concluderen, dat niet alle in Nederland actieve bedrijven onverdeeld blij zijn met de term "SOA"; Dit woord heeft toch een ongewenste bijbetekenis. Het klinkt of je een nare ziekte kunt oplopen wanneer je je aan "onbeschermde" "service-orientation" waagt.
The SOA business services design and orchestration is what people say you must do, not buy. You do have to specify your business services first and then interconnect them with a SOA technology. Can you say implement SOA services once you specified them? You can. But you can equally say that you buy SOA technology to integrate the systems delivering the business services.
Service Oriented Architecture has entered the mainstream of business applications and articles about SOA continue to proliferate. However, texts that share people’s real-life experiences with SOA are scarce. Partly this can be attributed to difficulties in sharing architectural knowledge in a structured way. This article calls for more effort to be put into sharing knowledge through architectural patterns...
Uit diverse richtingen worden signalen afgegeven dat bij de overgang naar "service oriented architecture" (SOA) een goed "governance model" onontbeerlijk is. "Governance" en "management" worden daarbij in een adem genoemd als naadloos in elkaar overlopende begrippen. Toch hebben we het hier mijns inziens over een zeer breed scala van rollen, processen, organisatievormen en hulpmiddelen, die traditioneel door verschillende afdelingen worden ingevuld. En dat moet ook...
The new world, in which everything you could possibly think of will be packaged "as a service" (business processes, applications, information and even infrastructure ...) calls for strict governance and management. After all, how can an enterprise be sure that the services landscape upon which their business depends, does not grow into an impenetrable jungle. We all have seen "enterprise systems charts" that have the shape of complex labyrinths with corners that nobody likes to visit. Most of us have been working on engagements that aspired to bring order in this labyrinth by implementing an "enterprise architecture". In this blog I want to discuss the undiminished need for governance and management in service oriented environments.
Ik las laatst een blog van David Straus waarbij hem werd gevraagd wat er na SOA zou komen. Hij weigerde dat te beantwoorden want 'we kunnen SOA nog niet eens goed op de rit krijgen'. En vervolgens volgt een obligaat lijstje met best practices om van SOA een succes te maken.
A lot of organisations seem to think that Service Oriented Architecture (SOA) is the silver bullet for a lot of organisational issues, and that an Enterprise Service Bus (ESB) is a universal business adapter that can connect everything transparently. I strongly disagree with such statements: SOA and ESB are overhyped, and are mostly pushed by the IT industry.
Tom Schepers, Maria Eugenia Iacob, Rob de Maat, Pascal van Eck
donderdag, 17 januari 2008
De verspreiding van diensten in een Service-Oriented Architecture (SOA) maakt het moeilijk om deze omgeving in controle te houden. Diensten worden op verschillende plekken in de organisatie beheerd, waardoor de samenhang verloren kan gaan. Het concept van SOA governance is ontstaan om een oplossing te bieden voor het sturingsprobleem in SOA’s. In dit artikel wordt een levenscyclus benadering gebruikt om een praktische aanpak voor SOA governance op te stellen. Deze aanpak bestaat uit het definiëren van strategische SOA doelen, het klaarmaken van de organisatie, het beheer van de dienstenportefeuille, beheer van de levenscyclus van diensten, toepassing van reguleringen en het beheer van service niveau’s. ...
The vocabulary we use to communicate about Service Oriented Architecture is vague and is causing confusion. The negative effects caused by the lack of precision are most obvious when we communicate outside of the community of SOA professionals. The “SOA Reference Model” of OASIS provides a solid basis for the needed shared vocabulary but the reviewing has identified some shortcomings. This article elaborates on these shortcomings and emphasizes the importance of four concepts commonly denoted by the terms: service, contract, interface and operation. Additionally, these terms are compared to the terms formalized by W3C.
This white paper starts off with discussing the major trends that fuel SOA as an approach that strengthens communication and planning, in order to achieve business-ICT alignment. It goes on to highlight the architecture and roadmap of the middleware platform that is typically needed to facilitate an effective and comprehensive SOA approach. Finally, it answers commonly asked questions about SOA and the technologies used to support it. We hope this paper helps the reader, whether an IT or business manager, a program manager or architect, to apply the service orientation for effectively bringing together people and services, and realise an ICT environment that can really make the difference.
This white paper examines how an enterprise data integration platform enriches a serviceoriented architecture, and how an SOA provides an ideal framework for implementing data integration technology across the enterprise. After reading this white paper, you’ll understand:
The IT and business drivers behind SOA
The progress made to date and the remaining challenges of SOA
How to take SOA to the next level with service-oriented data integration
The anatomy of service-oriented data integration
Approaches to migrating toward SOA
The convergence of data integration and service-oriented architecture can reduce IT complexity, ensure data consistency, and drive business agility. Data Integration in a Service-Oriented Architecture - A Strategic Foundation for Maximizing the Value of Enterprise Data
In het kader van Enterprise Application Integration (EAI) bij Meavita West, één van de werkmaatschappijen van Meavita Nederland, werd een koppeling ontwikkeld tussen twee applicaties. Hierbij werd gebruik gemaakt van een Tibco Enterprise Service Bus. De koppeling werd ontworpen vanuit een gegevens(uitwisselings)perspectief, maar kon (tot nu toe) niet goed gerealiseerd worden.
In dit artikel beschrijven we hoe de koppeling tot stand kwam, de analyse van wat er fout ging en welke consequenties wij daar uit trekken voor de toekomstige werkwijze bij onze organisatie.
Tenslotte komen we tot enkele meer algemene leerervaringen over EAI, SOA, de businessit- alignment en de noodzaak van een Enterprise Architectuur.
Misschien lag het aan de pragmatische houding van de geodetische ingenieurs en Gis-specialisten. Misschien was het het kleine wereldje. Hoe het ook zij, de OpenGIS Web Map Server Interface Implementation Specification was een feit in April 2000, ruim 2 jaar eerder dan de W3C, die de Working Draft van de Web Services Architecture eind 2002 publiceerde.
U ziet het, webservices zijn al lang Business as usual in de Geo-ICT wereld. In deze niche ging men onopmerkzaam constructief verder met het uitbouwen van een open en interoperabele webservice tot volledige ruimtelijke geodata infrastructuren die organisaties in staat stelt over en weer geodata te delen. Operationeel en geheel in state-of-the-art IT architecturen. Met de komst van Google Maps, Google Earth en auto-navigatie hoeft in ieder geval niet meer uitgelegd te worden wat geo-information is. Sindsdien heeft de wereld niet stilgestaan.
Porter conceptualized, in the 80s, the Value Chain (VC) of an Enterprise. A VC categorizes the business functions of a company in primary (operations) and secondary (support) functions. Porter also introduced Value Networks/Systems consisting of a string of Value Chains contributing to the delivery of the end product or value where each VC is implemented by a separate Enterprise.
This paper reports on the development of a service-oriented architecture in a project that aims to realise a digital archive for long time preservation of digital objects of the municipality of Rotterdam. The architecture is based on the Records Management Continuum, which argues that archiving starts with the creation of an object. The infrastructure, system architecture, archiving processes and services are specified according to this principle.
This paper presents a first attempt to realize a methodological framework supporting the most relevant phases of the design of a value-added service. A value-added service is defined as a functionality of an adaptive and multi-channel information system obtained by composing services offered by different providers. The framework has been developed as part of the MAIS project. The MAIS framework focuses on the following phases of service life cycle: requirements analysis, design, deployment, run time use and negotiation. In the first phase, the designer elicits, validates and negotiates service requirements according to social and business goals. The design phase is in charge of modelling services with an enhanced version of UML, augmented with new features developed within the MAIS project. ...
Design by contract is a well-established paradigm in software engineering. Bertrand Meyer first introduced the rigorous distinction between the responsibilities of service provider and service consumer for fine grain software artifacts (classes). This paper considers service contracts in the context of service-oriented architecture for complex enterprise information infrastructures. Identifying dependencies between applications with service contracts may help to master the complexity of numerous interconnected informationsystems and to ease evolution towards a service-oriented architecture. ...
Als niet voor de hand liggend onderwerp voor haar afstudeerscriptie voor de doctoraaltitel bedrijfskunde heeft Mary Beijleveld, in dienst bij UWV, Service Oriented Architecture (SOA) genomen. Dat is te zeggen: Niet zo voor de hand liggend voor bedrijfskundigen ofwel voor de business. Immers, de in de ogen van o.a. architecten zo noodzakelijke aligment tussen ICT en de business is nog ver te zoeken. In deze scriptie wordt op wetenschappelijke wijze een analyse gemaakt van de voordelen van SOA in bedrijfskundige termen.
In this paper we will present the results of research into factoriented business service modeling. The set of modeling constructs that are defined in this paper are fully ‘compatible’ with the models in the dataoriented perspective in the fact oriented school of conceptual modeling.
Today’s organizations are changing with respect to both structure and internal working processes. As a consequence of trends such as globalization, deregulation and highly volatile markets, corporations are forced to increase their responsiveness to temporary requirements or business opportunities. Most existing organizational theories do not apply to the emerging sort of enterprise which incorporates principles such as structural decentralization, loose coupling of autonomously acting business units as well as complexity hiding on the basis of uniform interfaces. This work briefly elaborates on the concept of Service-Oriented Architecture (SOA) in the field of information technology and proposes a first approach to mapping its major underlying principles to upcoming forms of organizations. We present a model of the Service-Oriented Enterprise (SOE) and leverage use cases of existing companies as well as recent theoretical approaches to demonstrate the analogy between state-of-the-art paradigms in the fields of both technology and organizational theory.
Alain Wegmann, Gil Regev, José Diego de la Cruz, Lam-Son Lê, Irina Rychkova
vrijdag, 11 mei 2007
Many companies expect their IT developers to understand their business strategy and to specify IT systems that will impact favorably the execution of their business strategy. Enterprise Architecture (EA) and Service-Oriented Architecture (SOA) address these issues. In this paper, we present a course that introduces EA and SOA to undergraduate CS students. The course is based on an immersive problem-based pedagogy coupled with role playing. The goal is to have the students conceptualize the theory out of the practical experience they gain in the course. Their experience is developed through a game in which the student teams manage competing companies, specify and then develop an IT system (using workflow and web-services). The course places an emphasis on the enterprise-wide impact of the IT systems. Through their practice, the students discover some of the important good-practices used in the industry. They also learn a systemic and systematic approach to address enterprise-wide problems.
Dit long paper is bedoeld ter kennisdeling in de zorg in Nederland. Directieleden, managers en informatie architecten verkrijgen met dit artikel inzicht in wat SOA en de ESB is en waarom het zou kunnen of moeten worden ingezet om ambities te realiseren in hun organisatie en hoe dat het beste kan worden aanpakt. De tussentijdse lessons learned van dit traject dat nog volop loopt wil Meavita graag delen met andere organisaties in de zorg.
In 2004 heeft Univé Verzekeringen haar vernieuwde visie op de inrichting van haar informatievoorziening gedefinieerd. Een omslag in denken. Een visie die ook binnen de muren van Univé de service-georiënteerde architectuur introduceert. Geen verkokerde systeemarchitectuur maar een samenspel van componenten die de benodigde functionaliteit oplevert. De vraag is natuurlijk: “Is dit meegaan met de hype of een logisch gevolg van hetgeen de bedrijfsvoering wenst/eist?”1. Een technologie push of business alignment? In dit artikel wordt deze vraag beantwoord.
ING Card built an application for its customer base that enables it to link to new websites, implement new product features, and maintain credit scoring rules, easily and quickly. It achieved this by applying three construction principles, one of which was service orientation. This article describes the application, and explains how SOA helped to meet the business needs of a credit card issuer with particular challenges.
With the e-business explosion of the past few years corporations were, and still are, faced with the challenge of time to market more than ever before. As a result the processes and applications that enable the enterprise were heavily augmented, extended, or both. Consequently, corporations currently have numerous disparate applications that provide similar and overlapping functionality and that are based on legacy architectures. These architectures are typically monolithic in nature and based on point-to-point interfaces. Executive management is realizing the inflexibility and cost of these legacy applications, and is looking for ways to innovate the application landscape. This is where Enterprise Architecture and Service Oriented Architecture come into the picture. This article describes the relationship between them, illustrated by a case study.
