[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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 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:Marc.Davies@uk.fujitsu.com] Sent: Thursday, October 27, 2005 06:52 To: Beack, Theo; Jones, Steve G; Ken Laskey; Miko Matsumura Cc: soa-blueprints@lists.oasis-open.org 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 E-mail:
marc.davies@uk.fujitsu.com Telephone:
-Hot Desking- 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:Theo.Beack@softwareagusa.com] 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, 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:steve.g.jones@capgemini.com] 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:klaskey@mitre.org] 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:
------------------------------------------------------------------------------------------
Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]