I
added a bit more anti-patterns:
-
Nobody Home Anti-Pattern - Creating a service with no real
client
-
Shiny Nickel Anti-Pattern - New technology implemented without a business case
in relation to incorporating an ESB say with only one service provider in the
enterprise
- Too
many cooks in the SOA Anti-Pattern - Essentially a bunch of departments start to
implement the same service over and over again without looking for something to
meet their needs in the registry. Could also be called a Service by Any Other
Name Anti Pattern
- UBER
Service Anti-Pattern - building on one service and adding irrelevant
functionality to the same service creating a monolithic service. Similar in
nature to the point-to-point problem Steve mentioned.
Miko,
I
wonder if the wiki should have read-only access without a
login.
This
way everyone can start to look at the progress but doesn't have to get a login
if they didn't want to deal with that.
-
Dan
-----Original Message-----
From: Jones,
Steve G [mailto:]
Sent: Tuesday, October
25, 2005 2:55 PM
To: Matt MacKenzie; Miko Matsumura;
Subject: RE: [soa-blueprints]
Anti-Blueprints
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.
