This
is starting to sound like conversations about how many use cases are adequate in
a RUP based project.
Maybe
there is a bit of metrics that can be applied based on the complexity of the
given business problem versus the size of the company.
A
payroll company may be small in nature but might have a varying degree of
services depending on the states they manage payroll, type of companies they
manage payroll, etc.... This starts to become an analysis of what type of
business problem can have a certain amount of services. Not sure we want to try
and take this on within this TC or not. Maybe there is a way to take a
couple business problems and provide a theoretical probability
distribution?
-
Dan
-----Original Message-----
From: Davies Marc
[mailto:]
Sent: Friday, October 28, 2005
8:59 AM
To: Beack, Theo; Jones, Steve G; Ken Laskey; Miko
Matsumura
Cc:
Subject:
RE: [soa-blueprints] Anti-Blueprints
Theo – I agree with
your expanded view regarding number of services approximates to a degree with
the size/complexity of a business. It strikes me that it would be an
interesting exercise to map scenario’s – if we could gather examples of
businesses of different sizes and assess the number of services each in turn
had implemented – would we end up with a metric that could provide a ‘rule of
thumb’ that said “Organisation of size {x} would typically deploy services of
quantity range {a-d}”. Clearly, there are exceptions to any rule but (and this
scenario is particularly Devilish :-), one thing I haven’t seen previously is
any clarity/agreement on what would constitute an ‘appropriate’ number of
services – or even an approximation.
It’s entirely
possible that several people on this list have done just that, and/or have
already obtained a view based on their conversations with colleagues etc. From
my perspective I’d say that every time I have a conversation with an Analyst,
I get a different number/range. In terms of my companies’ clients – well they
are sufficiently different in each case (at this time) to make a statistically
relevant analysis problematical.
Still – as has been
pointed out elsewhere on this thread – (and to stay mildly on topic)
anti-blueprints can frequently be of real benefit, IMHO its almost always
easier to begin a definition by deciding (even as a Straw Man) what *isn’t*
applicable.
Regards,
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: 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.
