[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 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] 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] 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]