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.
Regards
Theo
From: Jones, Steve G
[mailto:]
Sent: Tuesday, October 25, 2005
14:21
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.
