There are some SOA anti-patterns that will
be common to general software but there will also be specifics to SOA (like don’t
start with process). I’ve no idea who said it but I recall reading once
a phrase something like “IT is 5% what to do, and 95% what not to do”.
Having anti-patterns is at this stage almost more valuable than proper patterns
as they act as breaks on development expense that would be pointless. I know
of a few clients I’ve saved money for by pointing out what is wrong who
are now taking the time to move towards a more controlled blueprints type
approach.
Not only does IT need the “This Way”
signs, we also need “There be dragons”.
Steve
From:
Matt MacKenzie [mailto:]
Sent: 25 October 2005 22:35
To: Miko Matsumura;
Subject: RE: [soa-blueprints]
Anti-Blueprints
Why is it valuable to
define an “anti-pattern” such as the one discussed here?
Doesn’t this anti pattern apply to pretty much all programming
models? It looks like y’all are fishing here.
Just my CAD$0.02…
-matt
From:
Miko Matsumura [mailto:]
Sent: Tuesday, October 25, 2005
4:10 PM
To:
Subject: RE: [soa-blueprints]
Anti-Blueprints
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:]
Sent: Tuesday, October 25, 2005
12:57 PM
To:
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:]
Sent: Tuesday, October 25, 2005
12:41 PM
To: ; ;
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:
[mailto:]
Sent: Tuesday, October 25, 2005
11:54 AM
To: ;
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:]
Sent: Tuesday, October 25, 2005
11:21 AM
To:
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:
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.
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.
