[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-blueprints] Anti-Blueprints
I've added these comments to this antipattern on the wiki, I think it's a nice clarification. Booz Allen and some other companies have put together an "SOA Maturity Model", which actually seems to be a model of service maturity (*not* SOA Maturity). This is interesting work, but might be more properly the work of SOA-RM than this TC. I'm always interested in work that can be donated or referenced by our work here. Best, Miko -----Original Message----- From: Beack, Theo [mailto:Theo.Beack@softwareagusa.com] Sent: Wed 10/26/2005 9:14 PM To: Jones, Steve G; Ken Laskey; Miko Matsumura Cc: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints I don't consider the number of services to be an accurate indication of either a good or bad approach. I think that one has to be more precise in measuring the relative maturity of the services that exist. Factors that can help one determine the "maturity index" of the SOA implementation might include: - level of reuse, - scope of the services, - service granularity, - adherence to architectural blueprints, - compliance with standards, etc. This is not a comprehensive list and one can take different views on how to measure the maturity of the services implementation, but the point I'm trying to illustrate is that one has to look at this from different angles in order to determine whether the approach which has been followed is a good or "bad" one. The statement “We’ve got hundreds of web services and it hasn’t helped us at all” is only a symptom of a potentially larger (or real) problem. The lack of reuse can be caused by factors such as: - developers might find it difficult to find the appropriate services, - several conflicting services might exist that provides similar functionality, - instability or lack of performance of services & infrastructure might cause developers to abandon the use of services, - it might even be a cultural barrier; developers might think using services is a waste of time and prefer to integrate their apps in another way In my experience many organizations create services without doing any planning. Many tools allow them to do this in a very easy manner and developers could easily created a large collection of services, without any planning. Following a good services design approach might be an important step to create truly reusable services. Determining the purpose of the service, who the primary consumers will be, usage patterns, interfaces required for the various consumers, service security, documentation, proper metadata, etc. all of these aspects of a service should be considered and might play an important part in making it a usefull and widely used service. Regards Theo _____ From: Jones, Steve G [mailto:steve.g.jones@capgemini.com] Sent: Tuesday, October 25, 2005 17:12 To: Ken Laskey; Miko Matsumura Cc: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints In other words has someone just “right-clicked” on a JavaBean (or C# object) and selected “Create Web Service” from the menu, or was there actually planning and intent? I’ve actually seen organisations where just this sort of exercise has been undertaken creating the thousands of web services problem. Number is part of the issue, its indicative of a bad approach when organisations create thousands of DISTINCT (as opposed to instances) of web services. But the Service should have a qualitative impact on the “real-world” or provide a useful function (e.g. mathematical calculation) this stuff is in the SOA-RM as being the basis of service. In terms of numbers I’d say that volume is an important indicator of bad practice, not a definitive guide but its getting a more and more common statement “We’ve got hundreds of web services and it hasn’t helped us at all”. Clearly its possible to have lots of top quality services, in the same way as in theory its possible for people to write decent multi-threaded code but in practice both are normally indicators of problems. Steve _____ From: Ken Laskey [mailto:klaskey@mitre.org] Sent: 25 October 2005 21:47 To: Miko Matsumura Cc: soa-blueprints@lists.oasis-open.org Subject: Re: [soa-blueprints] Anti-Blueprints The question is less one of number than independence. Does the original interface (method call) provide a capability that is useful beyond the object with which it is connected and can it be used without being part of a sequence with other methods from the same object? Ken On Oct 25, 2005, at 4:10 PM, Miko Matsumura wrote: Good feedback Duane. This is a good topic, thanks for introducing it, Steve. The number of services *is* a quantitative measure, but perhaps not a very helpful one? =) I'm pretty sure there's an antipattern here, and I think perhaps there could be some kind of way to assess this. I think another variable in this mix is the extent to which the registry repository in question can help with respect to discovery and classification as well as governance. The thing that worries me is when I see people assuming that fine grained (object level) services will be reused, when the reality is that OO didnt generate that much reuse from even the guy in the next cubicle, let alone across the company or across the planet. I think this is less of a gross number of services antipattern so much as a coarse-grained vs fine-grained antipattern... Best, Miko From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Tuesday, October 25, 2005 12:57 PM To: soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints I disagree with this anti-pattern. I am not sure that the number of services is really a quantitative measure of SOA. A grid computing cluster administrator may be able to rationalize such behavior, although it may seem absurd in other areas such as Amazon deploying a service for each book it carries vs. deploying one service that allows the consumer to parameterize the book title. Perhaps a better measure would be the development of some test criteria to ascertain whether a contemplated service is a good candidate for repurposing beyond a small number of consumers. This should be based on alignment with LOB and presumably different implementers will have different criteria for quantifying such. Duane From: Miko Matsumura [mailto:mmatsumura@infravio.com] Sent: Tuesday, October 25, 2005 12:41 PM To: marchadr@wellsfargo.com; steve.g.jones@capgemini.com; soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints I just added a "microservice" antipattern where programmers put 10000000 WSDLs into a registry just because their IDE lets them do so. Miko From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com] Sent: Tuesday, October 25, 2005 11:54 AM To: steve.g.jones@capgemini.com; soa-blueprints@lists.oasis-open.org Subject: RE: [soa-blueprints] Anti-Blueprints Steve, Good idea. I put up the first drafts of them at: http://blueprints.jot.com/WikiHome/SOA+Anti-Patterns/SOA%20Anti-Patterns Let me know if I correctly eloborated and named them for you. Thanks, Dan -----Original Message----- From: Jones, Steve G [mailto:steve.g.jones@capgemini.com] Sent: Tuesday, October 25, 2005 11:21 AM To: soa-blueprints@lists.oasis-open.org Subject: [soa-blueprints] Anti-Blueprints The SOA Blueprints will lay down a “best practice” set of guidelines and templates for delivering SOA. This will definitely be a positive thing and help expand and firm up people’s understanding of SOA. One thing that the group states that it will do is define standards and guidelines, does this mean that allied to our blueprints we must also consider the “anti-blueprints” (analogous to anti-patterns) that must be avoided. So for instance focusing on process over service (bad), only thinking of web services (bad) etc etc. Defining the blueprints give guidance towards success criteria, but should we also give guidance on failure criteria for acceptance of a system as being “SOA”. Not sure whether this should be in the TC as its laying down best practice, and not to increase the already large workload… but it needs to be somewhere. My top 5 are 1) If you’ve started with an enterprise “best practice” process map you are NEVER going to be SOA and 90% probability your system will be inflexible or fail. 2) Web Service point to point is STILL point to point, doing a bad practice in XML doesn’t make it better 3) Splitting into two separate tiers of Service and Process with separate rules and governance results in divergent solutions 4) Creating “business” services based on the belief that IT understands the business results in services that meet neither IT nor business goals 5) Building your own proprietary XML-RPC stack to give yourself “control“ The last could still be SOA from one perspective, but I’ve yet to see it done well when the driver was a belief that its better done in house than using standards. When we get the official Wiki it could be something to document via that route. Steve ___________________________________________________________ Steve Jones | Capgemini CTO, Application Development Transformation T +44 870 906 7026| 700 7026| www.capgemini.com m: steve.g.jones@capgemini.com txt: +44 (0) 7891157026 Join the Collaborative Experience ___________________________________________________________ This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]