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.
A question that is often asked these days is: “does this mean that SOA as an architectural style should be halted?” The answer is a firm NO as will be discussed below. The current recession offers opportunities to improve the conditions for the successful application of SOA. The answer is targeted rationalization of the IT landscape, in order to ultimately get the right set of business services: Sanitation and Optimization under Architecture as a precondition for Service-Oriented Architecture. Or simply put: SOA4SOA.
Economic boom versus recession
During times of recession other criteria are used to determine which initiatives to launch than in times of an economic boom. During a recession the most attractive initiatives are those that promise short term cost reduction. In boom times there is a strong preference for revenue increasing initiatives. The main driver for Service-Oriented Architecture (SOA1) is increasing agility, requiring investment in the development of a business service portfolio and associated infrastructure. Typically the benefits of SOA will only surface after a couple of years (reuse through time). Investment in SOA requires a long term perspective. A perspective the CIO cannot afford during a recession. Still we persist in our vision that SOA as an architectural style is the way to go. So what should the CIO do now? Go against the flow and continue investing in SOA? Or reduce SOA investments and surrender to the pressure of the organization to reduce cost.
Let us first investigate what the challenges for the application of SOA are in a booming economy. There are advantages and disadvantages. Subsequently we will look into the challenges for SOA during a recession. We conclude by distilling our concise advice.
1) In this article the acronym SOA is used for Service-Oriented Architecture, except where explicitly indicated otherwise.
SOA during economic boom
The application of the SOA paradigm during an economic boom has the following advantages:
Sufficient budget. Sufficient budget means the best consultants can be hired to determine what solution is best and then follow up on that advice and buy and implement the best solutions.
Many business opportunities. Many commercial opportunities exist and therefore many business cases for implementing services [Baarda, 2008].
Application of SOA during boom times also has disadvantages:
Too much budget. This means business management can easily be persuaded by vendors to buy the latest miracle tool and hire an army of product specialists. This often leads to tooling overkill in terms of enterprise service buses, service registers, event handlers, version control systems, business process management tools, specific test tools and so on. Then let the army of configurators do their magic, within budget and timelines of course, and wait for the improved business agility to kick in. Of course this never happens. The complexity has increased rather than reduced, the SOA investments are higher than expected and show much less benefit than expected. The SOA paradigm gets the blame and is left behind, probably for a long time. That the effort required for SOA is often underestimated is generally recognized [van den Berg, Hompes, Truijens, 2007].
Too little attention for architecture. The availability of budget is seen as sufficient. With no need to really think it through, no need to think about the structure and fitting of the solution into the IT landscape. Decision makers are convinced that it is just a matter of buying the best software and the best consultants and that the perfect service portfolio will be created ‘automatically’. There is little patience with architects who only see problems and are hindering progress.
Too little attention for governance. For the same reasons as above the general idea is that there is little need for governance. Without architecture there is little to govern anyway.
Root causes are not addressed. A major obstacle for the realization of a service is a fragmented and low quality backend system landscape. Because a miracle tool is positioned to magically tie it all together with a little configuration there is no need to improve the IT landscape from the source. Also the army of product specialists does not understand the intricacies so it’s better left alone. Just cover it with a layer of integration software and the problem is at least invisible. Obviously an unrealistic and damaging approach. The new tooling increases complexity and also does not really solve the problem.
The conclusion is that even during a booming economy there are a lot of challenges in the application of the SOA paradigm. Let’s see how this looks during a recession.
SOA during a recession
Surprisingly the application of the SOA paradigm during a recession has a number of advantages:
Root causes are addressed. In order to cut cost on IT, existing systems are investigated and rationalized. This forms an excellent chance to improve consistency and coherence as well. While the case is cost cutting, the effect is a much better foundation to build business services on.
No more blind faith in miracle tools. The illusion of miracle tools that make all your problems go away with just a little configuration is quickly exposed.
No more product specialists. Product experts may have a lot of knowledge of the latest tools and methodologies but not of the intricacies of the existing situation, consisting of many point-to-point interfaces and redundancies in functionality and information definitions. While really that is the place a lot of money can be saved. The focus now moves to experts with deep knowledge of the current situation and specialists on rationalizing and migration.
Time to think first. During a recession internal personnel are let go only as a last resort or ‘saved’ for the moment the economy is picking up again. The effect is that there is more time available to think before taking any action. This is true for management, business people and IT personnel as well2.
Attention for architecture. As money is scarce and personnel is available these are really the perfect conditions for enterprise architecture. The organization can no longer afford to make mistakes and have projects fail. Money will be spent on activities which will guarantee results.
Attention for governance. Same arguments as the previous one. Business management takes no risks and does everything that is needed to prevent mistakes or derailments. They are really ’on top’. This is governance. These are ideal circumstances for effective governance.
For the application of SOA during a recession there is obviously also a big disadvantage:
Less budget. Management is hesitant to spend money on IT. As business cases for improving agility through business services will probably dry up entirely as the benefits will only come when there are opportunities for revenue increase. Delaying makes very much sense. The business service portfolio will not be extended. Except in rare cases.
2)Speech by the Dutch minister of social and employment affairs J.P.H. Donner at the yearly conference of the FME-CWM in Nijkerk on November 12, 2008: “Your chairman points to the tension that exists between the need to save skilled personnel wherever possible for your organizations in order to be able to react quickly when demand improves again and the substantial need to cut cost during the current rapid drop in demand”.
Recession advantages
An economic recession is really a blessing in disguise for architecture, governance, rationalization of legacy systems and - indirectly - SOA (by improvement of SOA conditions). In good economic times many initiatives are launched with little attention for structure, coherence, governance and the removal of obsolete IT components. In bad economic times more time is spent thinking before money is spent. There is more interest in saving money by removing obsolete IT components. Especially the clean up creates the conditions for successful application of SOA. Some years ago already Sanitation and Optimizing under Architecture was advocated [Bakker, van den Berg, Deursen, 2003]. The reduction of complexity and cost are the main drivers for the rationalization of the IT landscape. An attractive side effect is that is improves the conditions for SOA. Less overlapping functionality, less applications, less different information definitions and fewer databases not only mean a substantial reduction in maintenance and administration cost. But also make it easier to extend the business service portfolio in the future. Fewer systems means a reduced integration effort. Also a Canonical Data Model may be introduced during rationalization. It provides insight into which information definitions and databases can be removed. This model is also an essential element of SOA as it ensures consistent semantics across services.
When creating business cases we advocate to explicitly investigate the extent they contribute to improving the conditions for SOA. When there are multiple business cases for cutting cost those contributing most to SOA must be selected first. When for example there are two business cases for cost reduction and one concerns rationalization of management information systems and the other the rationalization of the customer information systems it is clear the customer information system case should get preference. Customer information systems generally form a crucial core for many SOA initiatives that will be launched as soon as the economy booms again. As a general architecture principle the improvement of the quality of ‘up stream’ processes and information is more important than the improvement of ‘down stream’ processes and information. Even without SOA this is the preferred approach because ‘down stream’ processes and information depend on the ‘upstream’ quality (garbage in, garbage out).
The diagram below shows where the focus should be during a booming economy and where it should be in times of recession:
Our advice
It is clear that we are in a recession. So let’s start improving architecture and governance and looking for business cases to rationalize parts of the IT landscape. For example the rationalization of backend systems that play a large role in developing business services in future SOA scenarios. Start with those systems containing the core information of the organization like customers, products and contracts. Sanitation and Optimization under Architecture as preparation for Service Oriented Architecture. SOA4SOA!
Piet Jan Baarda (
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
) is Senior Information Architect at Sogeti.
Martin van den Berg is Service Line Manager Architecture at Sogeti, IT-teacher at ProEducation and chairman of the architecture section of the NGI (Dutch Computer Society).
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
3) in English: SOA in The Netherlands, a digital affection?
4) in English: Demolition under Architecture, Keeping the IT-asset portfolio clean in a systematic way. (or to arrive at the SOA acronym: Sanitation and Optimization under Architecture)
Virtualisatie is een steeds belangrijker thema aan het worden in organisaties. Het is steeds meer organisaties duidelijk dat het belangrijke voordelen biedt op het gebied van kosten, flexibiliteit en beschikbaarheid. De mate waarin de technische infrastructuur is gevirtualiseerd is een belangrijke maatstaf aan het worden van de volwassenheid van een IT-organisatie. Virtualisatie is tevens een containerbegrip voor veel verschillende technieken, zowel op hardware als softwareniveau, ieder met zijn eigen karakteristieken. Een goede reden om een aantal belangrijke vormen in meer detail te beschrijven. In het bijzonder geef ik inzicht in servervirtualisatie, clientvirtualisatie, desktopvirtualisatie en applicatievirtualisatie.
Architectuur is in de praktijk nog lang niet altijd doelgericht. Het is daarom belangrijk om de daadwerkelijke doelstellingen centraal te stellen; uiteindelijk is architectuur slechts een hulpmiddel. In de praktijk blijkt het echter lastig om de doelstellingen helder te krijgen. Enerzijds bestaan doelstellingen op verschillende niveaus en zijn ze niet altijd in lijn. Daarnaast zijn doelstellingen vaak persoonlijk en niet objectief. Anderzijds is het lastig om tot heldere doelstellingen te komen. Tenslotte denken IT'ers vaak dat zij wel weten wat de doelstellingen zijn.
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.
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
Friday, 18 January 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
Friday, 11 May 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.
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.
