Hi Dennis; You are absolutally right about "could use an evaluation matrix for any kind of solution you want to govern." Let us think about one of the specific criteria that distinguish a SO solution from other kinds of solution: Business to IT alignment. Or better to call it business to IT alignment through SOA: If we follow any methodology such as RUP SOMA method, or other methodology of course, we can define its goal as: increase traceability of IT assets to business goals and drivers and ensure service commissioned for development have direct traceability to business goal. We can use the following metrics: - Number of services in the portfolios that have direct traceability to business goals. ( this is very important) - Number of services that pass the business alignment service litmus test. the service litmus test is part of RUP SOMA method, which provides a filtering mechaism to assess and evaluate which services should be exposed and hence implemented as a service.
If we consider every aspect of SOA concept and build the proper metrics and use the proper tools I do think we can achieve the goal of aligning business and IT as well as distinguish SO solution from the other. All the best Ashraf Galal Dennis Djenfer wrote: > > > Ashraf, > > You could use an evaluation matrix for any kind of solution you want > to govern. What are the specific criterias that distinguish a > service-oriented solution from other kinds of solutions? And honestly, > are those criterias really objective? > > // Dennis Djenfer > > > Ashraf Galal wrote: > >> >> >> There is always a way to evaluate SOA services. >> >> We need an objective way to assess services and their alignment with >> business needs. >> >> We need an evaluation matrix for the design of SOA services. >> >> We have to use the evaluation matrix throughout the process of service >> design and implementation. >> We can categorize them according to alignment, design, technical or >> housekeeping, for example. >> >> Within each perspective or category, there are several characteristics >> pertaining to the category and questions to ask about how well the >> service satisfies that characteristic. >> The collected answers to the questions in the matrix indicate how well a >> service fits into an SOA solution. >> >> These questions need an experts and brainstorming between different >> business and IT people. >> >> The evaluation criteria allow you to rate the service in an objective >> manner. >> The results provide insight into how well the service satisfies the key >> requirements, such as reusability or alignment with business goals and >> needs. >> >> Throughout the design and implementation process, each perspective >> checks the services against the evaluation criteria that fit within >> their concern. >> In general: >> >> · The Business Perspective is concerned with the Alignment >> Characteristics. >> >> · The Design Perspective is concerned with Alignment and Service >> Characteristics, along with a selection of Technical and Housekeeping >> Characteristics. >> >> · The Implementation Perspective is concerned with Alignment, >> Service, Technical, and Housekeeping Characteristics — basically, the >> entire matrix >> >> This is should be done when we start the governance process and must be >> agreed upon between business and IT, and well documented. It needs too >> much effort between IT, business and Financial department. >> >> >> All the best >> >> Ashraf Galal >> >> >> Dennis Djenfer wrote: >> >>> >>> >>> In the example from Michael, where he considered one solution to be >>> more service oriented than another, the business intent was the same. >>> As far as I'm able to interpret his exemple, the difference was in the >>> choosen technology and the implementation of the technology. >>> >>> Actually, after all this years with service orientation, I think we >>> have learned a lot, but we still can't unambiguously define a service >>> and tell a service oriented solution apart from a non-service oriented >>> solution. The grey zone is as big as ever. >>> >>> On the positive side I think SOA has helped many people in IT too >>> think more about the business side of solutions to problems that >>> involves IT. I also think SOA and the principles of service >>> orientation has raised many important and worthwhile questions and >>> discussions during the years, but I find it ironic that it still is >>> very hard to unambigously tell if a solution is service oriented or not. >>> >>> // Dennis Djenfer >>> >>> >>> Steve Jones wrote: >>> >>> >>>> Technology v Business intent. Integration solutions are purely about >>>> the connection of pieces of technology that may at a 2nd remove >>>> deliver a business value. A service is directly about the delivery >>>> of the business value. >>>> >>>> In other words (and I think the SOA-RM does this brilliantly) its the >>>> difference between technology infrastructure (the Execution Context >>>> in the SOA-RM) and the actual capabilities and service. Integration >>>> solutions place the technology at the heart and then plug things >>>> together, SOA places the capabilities and services at the heart and >>>> relegates the internals to just plumbing. >>>> >>>> Steve >>>> >>>> >>>> 2009/12/29 Dennis Djenfer <[email protected] <mailto:[email protected]>> >>>> >>>> >>>> >>>> Ok, so what is the behavior of your solution that makes it >>>> qualify as service oriented and not as a pure integration solution? >>>> >>>> >>>> >>>> // Dennis Djenfer >>>> >>>> >>>> Michael Poulin wrote: >>>> >>>>> Qualification 'into service', IMO, is not in the interface but >>>>> in behavior of the entity. >>>>> - Michael >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Dennis Djenfer <[email protected]> <mailto:[email protected]> >>>>> *To:* [email protected] >>>>> <mailto:[email protected]> >>>>> *Sent:* Sun, December 27, 2009 5:11:11 PM >>>>> *Subject:* Re: [service-orientated-architecture] Descriptions vs >>>>> Contracts >>>>> >>>>> >>>>> >>>>> I wonder if that is enough to qualify as a service oriented >>>>> solution. With that kind of reasoning a Web Service slapped on a >>>>> database because an application needed the data would be service >>>>> oriented. >>>>> >>>>> // Dennis Djenfer >>>>> >>>>> >>>>> Michael Poulin wrote: >>>>> >>>>> >>>>>> Service orientation in my solution is in Documentum service >>>>>> offered a service (via JMS) and all interested (the ATG Dynamo >>>>>> servers) were able to use it. In the contrast, the >>>>>> Documentum's solution was based on blind push of information to >>>>>> pre-defined IP address with no mechanism for the consumers to >>>>>> change them at wish (but only through the negotiation with and >>>>>> reconfiguration of the Documentum server). I think that my >>>>>> solution was service-oriented while the Documentum's one was >>>>>> much more traditional P2P integration. This is the about "the >>>>>> right way of thinking" or freedom for consumers (specific to >>>>>> SO) rather than technology comparison. >>>>>> >>>>>> - Michael >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* Dennis Djenfer <d...@algonet. se> <mailto:[email protected]> >>>>>> *To:* service-orientated- architecture@ yahoogroups. com >>>>>> <mailto:[email protected]> >>>>>> *Sent:* Sat, December 26, 2009 10:23:30 PM >>>>>> *Subject:* Re: [service-orientated -architecture] Descriptions >>>>>> vs Contracts >>>>>> >>>>>> >>>>>> >>>>>> I don't get why your solution is service oriented. All I can >>>>>> read from your exemple is two kind of solutions for an >>>>>> integration problem. They have different technical solutions >>>>>> and quality attributes, but I don't get why one of them is >>>>>> service oriented. >>>>>> >>>>>> // Dennis Djenfer >>>>>> >>>>>> >>>>>> Michael Poulin wrote: >>>>>> >>>>>> >>>>>>> I think, Sun Tzu in his /T >>>>>>> >>>>>>> <http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html>he >>>>>>> Art of War >>>>>>> >>>>>>> <http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html> >>>>>>> / has >>>>>>> given us the receipt for SOA implementation for >>>>>>> downtime saying "Nothing is as important as having the right >>>>>>> way of thinking." >>>>>>> >>>>>>> SO is about SO thinking; SO needs technologies and expensive >>>>>>> systems at the very last, if ever, moment. SO is not in >>>>>>> technologies like BPEL and others. You can build service >>>>>>> orientation into regular code if you think first about it. >>>>>>> >>>>>>> For example, several years ago I had a problem to solve: our >>>>>>> Documentum server prepared Web content, which had to be used >>>>>>> by the Application/ Web Servers (ATG Dynamo that time) to >>>>>>> publish on the Web, but did not notify ATG Dynamo when the >>>>>>> content was ready. Our Business publisher authored the content >>>>>>> but could not manage the publishing time. In my SO Solution, I >>>>>>> placed Documentum' s meta-file about prepared content into >>>>>>> MOM/Topic and made all ATG Dynamo servers to subscribe to the >>>>>>> Topic announcements. The ATG Dynamo servers used to be >>>>>>> re-booted nightly but they were able to get all missed >>>>>>> information and the new one due to the durable subscription to >>>>>>> the MOM Topic. Where ATG Dynamo servers were shut down and >>>>>>> where they (or their replacements) came up on-line (i.e. their >>>>>>> IP address) did not matter to the solution. [When Documentum >>>>>>> learnt this solution from us, they provided a free integration >>>>>>> Documentum-ATG Dynamo via Web channel. In their >>>>>>> solution, Documentum not only updated the data-store with the >>>>>>> prepared content but also sentthe appropriate Web 'requests' >>>>>>> to the registered ATG Dynamo servers. It looked fine except >>>>>>> for the cases when ATG Dynamo servers lost all information >>>>>>> when being down and had to get on-line with exactly the same >>>>>>> IP address they registered with the Documentum server before. >>>>>>> This was pure integration solution while I can consider my >>>>>>> solution was much more service oriented.] >>>>>>> >>>>>>> - Michael >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> *From:* Hitoshi Ozawa <htshoz...@gmail. com> >>>>>>> <mailto:[email protected]> >>>>>>> *To:* service-orientated- architecture@ yahoogroups. com >>>>>>> <mailto:[email protected]> >>>>>>> *Sent:* Fri, December 25, 2009 10:56:29 PM >>>>>>> *Subject:* Re: [service-orientated -architecture] Descriptions >>>>>>> vs Contracts >>>>>>> >>>>>>> >>>>>>> I think you've hit the major difference we're having. I'm in >>>>>>> an actual project and tailoring my service so they can >>>>>>> actually be implemented with the current available technology, >>>>>>> development members, and other constraints. Also, with the >>>>>>> economic slow down, it is also necessary to reduce cost. >>>>>>> There was a mention of BPEL in the other thread, and I think >>>>>>> the basic technology is interesting, but the current situation >>>>>>> requires too knowledge of too many specifications that it >>>>>>> almost impossible to educate development members to complete a >>>>>>> project in time. Of course, in a small project, I can just do >>>>>>> it myself but in a large project, that's impossible. >>>>>>> >>>>>>> SOA is dying not because the theory behind it is bad, but that >>>>>>> what most people are preaching can not currently be >>>>>>> implemented in a project. The tight economy is also sifting >>>>>>> the emphasis from "to be" more toward "can be". >>>>>>> >>>>>>> Anne's cartoon showed a "SOA dinosaur", but IMHO the dinosaur >>>>>>> really isn't the concept of SOA itself, it more of us who's >>>>>>> not adjusting to the current economic market. >>>>>>> >>>>>>> Happy Holidays, >>>>>>> H.Ozawa >>>>>>> >>>>>>> 2009/12/25 Steve Jones <jones.steveg@ gmail.com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm designing them in this way but unfortunately in >>>>>>> implementation there isn't the technology to support this >>>>>>> stuff. WS-Contract or WS-SLA never happened and there >>>>>>> isn't anywhere near the formalism required. >>>>>>> >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> 2009/12/23 Hitoshi Ozawa <htshoz...@gmail. com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> So Steve, you're designing all your services these way. >>>>>>> >>>>>>> H.Ozawa >>>>>>> 2009/12/23 Steve Jones <jones.steveg@ gmail.com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I can't see why not, although I'd reword it to be >>>>>>> >>>>>>> >>>>>>> In order to ship the carton a valid set of legal >>>>>>> constraints, written in French, must be agreed. >>>>>>> >>>>>>> >>>>>>> Take Air Traffic Control, there are two official >>>>>>> global languages for ATC there is English (used in >>>>>>> 99% of the world) and there is French (guess where >>>>>>> that is used) but they are both official languages >>>>>>> at the service description level. Now some >>>>>>> people can constrain their description to say "we >>>>>>> only accept English" but this is still at the >>>>>>> service description level as an individual >>>>>>> contract (with a plane) has not yet been entered into. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> 2009/12/22 Hitoshi Ozawa <htshoz...@gmail. com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> We're talking about service description. Is it >>>>>>> alright to have "ship the carton with a valid >>>>>>> set of legal constraints in French"? >>>>>>> >>>>>>> H.Ozawa >>>>>>> >>>>>>> 2009/12/23 Steve Jones <jones.steveg@ >>>>>>> gmail.com <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I can't see why a contract of send invoice >>>>>>> via SOAP would be a problem with the >>>>>>> description being "send invoice", why >>>>>>> would it be a problem? >>>>>>> >>>>>>> >>>>>>> I think we are in danger of disappearing >>>>>>> into semantic holes. I could argue that >>>>>>> if the objective (service description) was >>>>>>> to woo a lady then the choice of the >>>>>>> language (service contract) could be >>>>>>> either English or French. In French we >>>>>>> could take the Cyrano de Bergerac approach >>>>>>> while in English we could fall back on the >>>>>>> Bard of Avon. Here the language is the >>>>>>> piece that seals the deal and is linked to >>>>>>> the specific consumer of the service, in >>>>>>> other words the language chosen (the >>>>>>> contract) is linked to the specific >>>>>>> engagement between the producer and consumer. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2009/12/22 Hitoshi Ozawa <htshoz...@gmail. >>>>>>> com <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> Hi Steve, >>>>>>> So are you implying "send invoice >>>>>>> using SOAP" is alright? >>>>>>> If you are, I sure would like to see >>>>>>> the system with such a design. :-) >>>>>>> >>>>>>> French and English are languages >>>>>>> people use to rely concepts. British >>>>>>> law is a concept. Concepts described >>>>>>> in the British law does not (should >>>>>>> not) change whether it's written in >>>>>>> English or in French. >>>>>>> >>>>>>> H.Ozawa >>>>>>> 2009/12/21 Steve Jones <jones.steveg@ >>>>>>> gmail.com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I actually think that French and >>>>>>> English is fine. It is like >>>>>>> having a shipping contract, there >>>>>>> are a huge number of different >>>>>>> legal jurisdictions that you could >>>>>>> potentially use to ship the >>>>>>> product from A to B (the >>>>>>> description) but when you >>>>>>> formalise the contract you pick a >>>>>>> single legal country as your >>>>>>> escalation point. >>>>>>> >>>>>>> >>>>>>> So in other words the description >>>>>>> of A to B just says "ship the >>>>>>> carton with a valid set of legal >>>>>>> constraints" while the contract >>>>>>> says "ship the carton with British >>>>>>> Law as the legal framework" >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> 2009/12/19 Hitoshi Ozawa >>>>>>> <htshoz...@gmail. com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> Andrew, >>>>>>> I think you're beginning to >>>>>>> understand the concept, >>>>>>> but your example is missing >>>>>>> the point. >>>>>>> Your analogy with French and >>>>>>> English is inappropriate >>>>>>> unless you're thinking of a >>>>>>> translation service. >>>>>>> >>>>>>> Service description describes >>>>>>> the semantic capabilities of >>>>>>> the service while service >>>>>>> contract describes the set of >>>>>>> rules used in an instance of >>>>>>> an interaction. >>>>>>> H.Ozawa >>>>>>> 2009/12/18 Andrew Herbst >>>>>>> <herbst_andrew@ yahoo.com >>>>>>> <mailto:[email protected]>> >>>>>>> >>>>>>> >>>>>>> Greetings: >>>>>>> >>>>>>> Another question from an >>>>>>> SOA neophyte. Thanks for >>>>>>> responding to my earlier >>>>>>> questions. >>>>>>> >>>>>>> So, roughly speaking, a >>>>>>> service description is >>>>>>> like me announcing to the >>>>>>> world: “I can interact in >>>>>>> French *or* in English”, >>>>>>> whereas, a service >>>>>>> contract is like me >>>>>>> agreeing to speak French >>>>>>> with a specific other >>>>>>> person in the context of >>>>>>> some very specific >>>>>>> interaction. >>>>>>> >>>>>>> I realize this is a very >>>>>>> basic question, and it may >>>>>>> well not really be the aim >>>>>>> of this group to deal with >>>>>>> such basic things. I will >>>>>>> therefore take no offence >>>>>>> if no one addresses this. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Andrew Herbst >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> >> >> >> ------------------------------------ >> >> Yahoo! Groups Links >> >> >> >> > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
