[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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: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 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: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 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]