As an example I’ve walked into an
organisation that had “several thousand” services thanks to a right
click integration approach. They were big and complex but even so they
should never have that many. I’ve been to others with “hundreds”
who are similarly optimistic in their view.
As a guide, BT (UK’s fixed line
telco operator) did a presentation at BEAWorld here in the UK, they had identified under 60 top level services to be re-used across the board, they
are a massively complex business who’ve started with architecture
and yet aren’t looking to the hundreds.
At each level (except Level 0 which is
normally max 5) I’d say that the number of services varies from around 2
to 8 or so. Within a complex organisation (4 @ Level 0) with a maximum
spread of 8 and 4 levels (to Level 3) (a huge depth and spread in my
experience) you’d only get just over 2000 services. More normally I’ve
found an average of 2 services at Level 0 and detailed down to Level 2 with a
spread average of 4 would give 32 services (each would have several
processes/methods).
That is a rough guide that I use to
indicate the quality of service numbers.
Steve
From:
Beack, Theo [mailto:]
Sent: 31 October 2005 13:00
To: Jones, Steve G; Davies Marc;
Ken Laskey; Miko Matsumura
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints
Hi Steve,
when you refer to "lots of
services", how many services are you thinking of? Likewise, what do
you consider to be a low number of services? Can you give some examples or
service ratios that you think would be "too much" and "just
right".
Regards
Theo
From:
Jones, Steve G [mailto:]
Sent: Monday, October 31, 2005
07:30
To: Beack, Theo; Davies Marc; Ken
Laskey; Miko Matsumura
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints
Given the maturity of most SOA elements
(Ovum had a great report recently on the “missing M and silent A”)
the number of services is, for me, a bell weather on how a company is
approaching SOA. Lots of services has, so far, always meant a technically
driven approach with “right click” integration styles,
organisations with services in the low numbers have normally planned their
first set of services.
Once the world is more mature in SOA then
it will be less appropriate to use size as a guide, but right now its extremely
unlikely that an organisation has an established architecture that has resulted
in several hundred services being created from it.
Steve
From:
Beack, Theo [mailto:]
Sent: 28 October 2005 00:46
To: Davies Marc; Jones, Steve G; Ken Laskey; Miko Matsumura
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints
Hi Marc,
I wrote that email quite early in the
morning, so I was not as precise in my wording as I would have liked. Anyway, I
would like to further qualify my statement with regards to the number of
services.
I don't consider the number of
services to be an accurate indication of either a good or bad
approach, *if taken at face value*.
You need the appropriate context around
the numbers to make sense of them. Let me use an example to illustrate. When
city planners are working on a new city master plan, how do they determine whether a
city or certain borough within that city might be overpopulated? How do they
determine whether there is sufficient infrastructure and resources available to
support the existing population? How do they determine whether the
existing infrastructure can support future growth? Do they only look
at the number of people in the city and then make a judgement call whether it
is overpopulated or not and whether it can support future growth?
I would venture to say that their
calculations and models would be far more complex and incorporate a large
number of different factors, in order to accurately determine the appropriate
population size.
As an example, if a certain city had a
population of 3 million, would that be an indication that the city if overpopulated?
It is difficult to say. If one knew that the city is Hamilton, MT one would be safe to assume that Hamilton would be wildly overpopulated. If the city on
the other hand, was the borough of Manhattan one would be quite safe in
assuming that the city is not overpopulated, due to the fact that it has
adequate housing, transport infrastructure, utilities, water supplies, etc. ..
.. .
I think some of same principles apply to
SOA implementations. Organizations vary in size; their IT environments also vary
in size and complexity. A small company of around $100M - $200M with an IT
department of around 100 people and 10-20 different systems would most likely
not require hundreds of services. If you told me that they had 400-500
services, then I would most likely question the appropriateness of this number
of services.
If the organization in question is a
large multi-national corporation with revenues of several billion $, one can be
certain that it will have a much larger IT infrastructure to support the business.
The application ecosystem will be large, with a lot of complexity and
integration requirements. If the number of services deployed is also within the
400-500 range, it would still be difficult for us to tell whether there are too
many services and whether they are making good reuse of all these services. I
think it would be prudent, in both cases, to investigate and do a proper
analysis to determine whether good SOA design principles have been followed.
So in summary; I agree that the number
of services should be one of the factors that one need to incorporate into the
analysis, while factoring in the context of what you know about the overall
application infrastructure, complexity, integration requirements, etc.
Regards
Theo
From:
Davies Marc [mailto:]
Sent: Thursday, October 27, 2005
06:52
To: Beack, Theo; Jones, Steve G; Ken Laskey; Miko Matsumura
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints
Sorry Theo but, I think Steve is on to
something with anti-patterns and I *do*
consider the number of services to give an indication
of approach. In particular your comment:
- it might even be a cultural
barrier; developers might think using services is a waste of time and
prefer to integrate their apps in another way
…Implicitly indicates to me that (in
that example) this is not an SOA
environment. An SOA journey must have strong centralised (architectural)
control ensuring developers do not just ‘do it’ how they think is
the best way forward for “their” application (which in reality of
course, isn’t their application – it’s the business’
application, a fault many of us have suffered from at some point in our
careers, I’m sure :o)
SOA is not WS (IMHO), SOA does mean strong
Governance and adherence to standards, and this may frequently upset
Developers!
M.
Marc
Davies
Fujitsu
Business Unit
Chief Technology Officer
Architecture
& Design Group
Core Services
Mobile: +44 (0) 7867 825118
E-mail:
Telephone:
-Hot Desking-
http://uk.fujitsu.com
This e-mail is
only for the use of its intended recipient. Its contents are confidential and
may be privileged. Fujitsu Services does not guarantee that this e-mail has not
been intercepted and amended or that it is virus-free.
From:
Beack, Theo [mailto:]
Sent: 27 October 2005 05:15
To: Jones, Steve G; Ken Laskey;
Miko Matsumura
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints
I don't consider the number of
services to be an accurate indication of either a good or bad
approach. I think that one has to be more precise in measuring the relative maturity
of the services that exist. Factors that can help one determine the
"maturity index" of the SOA implementation might include:
- level of reuse,
- scope of the services,
- service granularity,
- adherence to architectural
blueprints,
- compliance with standards, etc.
This is not a comprehensive list and one can take different views on how
to measure the maturity of the services implementation, but the point I'm
trying to illustrate is that one has to look at this from different angles
in order to determine whether the approach which has been followed is a good or
"bad" one.
The statement “We’ve got hundreds
of web services and it hasn’t helped us at all” is
only a symptom of a potentially larger (or real) problem. The lack of
reuse can be caused by factors such as:
- developers might find it
difficult to find the appropriate services,
- several conflicting services
might exist that provides similar functionality,
- instability or lack of performance of
services & infrastructure might cause developers to abandon the use of
services,
- it might even be a cultural
barrier; developers might think using services is a waste of time and
prefer to integrate their apps in another way
In my experience many organizations
create services without doing any planning. Many tools allow them to do this in
a very easy manner and developers could easily created a large collection of
services, without any planning. Following a good services design approach
might be an important step to create truly reusable services. Determining the
purpose of the service, who the primary consumers will be, usage patterns,
interfaces required for the various consumers, service security, documentation,
proper metadata, etc. all of these aspects of a service should be considered
and might play an important part in making it a usefull and widely used
service.
Regards
Theo
From:
Jones, Steve G [mailto:]
Sent: Tuesday, October 25, 2005
17:12
To: Ken Laskey; Miko Matsumura
Cc:
Subject: RE: [soa-blueprints]
Anti-Blueprints
In other words has someone just
“right-clicked” on a JavaBean (or C# object) and selected
“Create Web Service” from the menu, or was there actually planning
and intent? I’ve actually seen organisations where just this sort
of exercise has been undertaken creating the thousands of web services problem.
Number is part of the issue, its
indicative of a bad approach when organisations create thousands of DISTINCT
(as opposed to instances) of web services. But the Service should have a
qualitative impact on the “real-world” or provide a useful function
(e.g. mathematical calculation) this stuff is in the SOA-RM as being the basis
of service.
In terms of numbers I’d say that
volume is an important indicator
of bad practice, not a definitive guide but its getting a more and more common
statement “We’ve got hundreds of web services and it hasn’t
helped us at all”. Clearly its possible to have lots of top quality
services, in the same way as in theory its possible for people to write decent
multi-threaded code but in practice both are normally indicators of problems.
Steve
From:
Ken Laskey [mailto:]
Sent: 25 October 2005 21:47
To: Miko Matsumura
Cc:
Subject: Re: [soa-blueprints]
Anti-Blueprints
The question is less one of number than independence. Does the original
interface (method call) provide a capability that is useful beyond the object
with which it is connected and can it be used without being part of a sequence
with other methods from the same object?
Ken
On Oct 25, 2005, at 4:10 PM, Miko Matsumura wrote:
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.
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
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.
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.
