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
___________________________________________________________