|marc...@wellsfargo.com||Oct 25, 2005 11:54 am|
|Miko Matsumura||Oct 25, 2005 12:41 pm|
|Duane Nickull||Oct 25, 2005 12:58 pm|
|Miko Matsumura||Oct 25, 2005 1:09 pm|
|Ken Laskey||Oct 25, 2005 1:47 pm|
|Jones, Steve G||Oct 25, 2005 2:11 pm|
|Miko Matsumura||Oct 25, 2005 2:14 pm|
|Matt MacKenzie||Oct 25, 2005 2:35 pm|
|Miko Matsumura||Oct 25, 2005 2:38 pm|
|Matt MacKenzie||Oct 25, 2005 2:40 pm|
|Miko Matsumura||Oct 25, 2005 2:48 pm|
|Jones, Steve G||Oct 25, 2005 2:55 pm|
|marc...@wellsfargo.com||Oct 25, 2005 4:31 pm|
|marc...@wellsfargo.com||Oct 26, 2005 9:02 am|
|Miko Matsumura||Oct 26, 2005 11:15 am|
|Beack, Theo||Oct 26, 2005 9:14 pm|
|Beack, Theo||Oct 26, 2005 9:49 pm|
|Miko Matsumura||Oct 26, 2005 11:10 pm|
|Miko Matsumura||Oct 26, 2005 11:16 pm|
|Davies Marc||Oct 27, 2005 3:51 am|
|marc...@wellsfargo.com||Oct 27, 2005 9:57 am|
|Beack, Theo||Oct 27, 2005 4:45 pm|
|Beack, Theo||Oct 27, 2005 4:53 pm|
|Beack, Theo||Oct 27, 2005 5:59 pm|
|Miko Matsumura||Oct 27, 2005 9:24 pm|
|Davies Marc||Oct 28, 2005 8:58 am|
|marc...@wellsfargo.com||Oct 28, 2005 9:12 am|
|Jones, Steve G||Oct 31, 2005 4:30 am|
|Beack, Theo||Oct 31, 2005 4:59 am|
|Jones, Steve G||Oct 31, 2005 5:21 am|
|Miko Matsumura||Oct 31, 2005 6:40 am|
|Subject:||RE: [soa-blueprints] Anti-Blueprints|
|From:||Miko Matsumura (mmat...@infravio.com)|
|Date:||Oct 26, 2005 11:10:22 pm|
I do agree that the primary purpose is to explore blueprints and develop them. Best and worst practices are something of a way of filtering business requirements down into patterns.
I am excited about the Cap Gemini donation of a business "front end". Having a rigorous way to express business use cases, goals, constraints and requirements makes the rest of the work easier and clearer.
I have modified the wiki front page to provide more context and reflect the logical flow of documents and their position within the Blueprints ecosystem. Feel free to make suggestions and/or edits.
-----Original Message----- From: Beack, Theo [mailto:Theo...@softwareagusa.com] Sent: Wed 10/26/2005 9:49 PM To: Jones, Steve G; soa-...@lists.oasis-open.org Cc: Subject: RE: [soa-blueprints] Anti-Blueprints
When faced with a complex problem I usually start by eliminating elements that is not causing the problem. Starting work on this TC however, by looking into what are not a blueprints, seems counter productive to me. We could potentially consider a very large number of things that are considered to be "anti-patterns" and yet not do much work on producing good, solid blueprints/patterns. My preference would be to explore potential blueprints first.
I'm pretty sure that we could find many "anti-patterns" in the cause of our work. In fact, I'm sure that when we examine the blueprints we will find that many (if not most) were born out of the experience of this group and much of that experience would have come from observing mistakes made and finding ways to correct them. I suggest that as we progress and create blueprints, we should add a section to each (or find a way to document) the factors that might prevent successful creation/implementation/reuse of services.
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 Jones | Capgemini
CTO, Application Development Transformation
T +44 870 906 7026| 700 7026| www.capgemini.com <http://www.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.