Gervas, you made some of the same comments that came to my mind. Robin's comment was:
> In addition to that, I think general vs. specific is not a good factor > to measure "well-designedness". Personally, I disagree with this comment. The extent to which general vs. specific is a measurement of a well-defined interface is dependent on whether or not the service is general purpose or for a specific purpose. Both Gervas and Greg have pointed this out. This winds being a very good example of how the contents of the service portfolio must be continually updated to maintain consistency with the business strategy. At the time the Pizza service was developed, the company's strategy may have been to be the best pizza restaurant around. Ultimately, revenues from that begin to flatten, and the company decides to branch out into other areas. As soon as that strategy is established, someone in IT needs to be thinking about the implications of acquiring the chinese food chain down the road. They should begin mapping the path to a more general purpose "place food order" service from the existing "place pizza order" service. This doesn't imply that the original service was not well-defined. It points out that what constitutes well-defined is only applicable for a certain point in time. As things change, so must the service interfaces. There are still too many people out there in the industry who think that interfaces should be set once and never touched. -tb On Feb 27, 2006, at 11:42 AM, Gervas Douglas wrote: > Robin, you are in a food-conscious country, so this Pizza/Sandwich > example resonates :). > > Supposing the sandwich company bought a pizza outlet down the street > and decided to leverage its existing daytime office customer base to > sell more pizzas. They might decide to keep the retail and production > aspects of the business separate but integrate food delivery and > customer relationships for both businesses. A trivial example in the > world of enterprise apps, but it illustrates, albeit very > simplistically, the problem faced by, say, financial services > conglomerates who wish to present one business face to the customer > for a variety of products and services, aspects of whose autonomy they > still want to retain. Unless handled with an intelligent and adaptive > architectural approach, this sort of scenario can end up as a systems > nightmare. It is after all essentially a business issue, and being > a business issue, it is liable to change at any moment, thereby > necessitating a highly flexible response from IT. There is nothing > original or novel in this, but at times it can get easily forgotten > in the technical minutiae! > > Gervas > > --- In [email protected], "Robin" > <[EMAIL PROTECTED]> wrote: >> >> Bill, I agree with you 100%. >> In addition to that, I think general vs. specific is not a good >> factor >> to measure "well-designedness". >> >> Extending a system that ships Pizzas to also ship Sandwiches would be >> a good idea if Sandwiches and Pizzas do have lots of similarities in >> their shipping process but also in their own nature (which might be >> the case here). >> If extending the Pizzas service to support Sandwiches result in an >> increase of interface complexity; red-alert, it's a bad design >> decision. In that case, it would be better to separate Pizzas from >> Sandwiches and consider those 2 as different services. >> An intermediate option would be to bundle operations for Pizzas and >> Sandwiches with operations that are truly Pizza or Sandwich >> independent in a single service. >> Not a black and white decision, this is not architecture but design. >> >> Robin >> http://blogs.ittoolbox.com/eai/applications/ >> >> --- In [email protected], "Bill >> Appleton" <billappleton@> wrote: >>> >>> There is a total trade off between being specific and powerful and > being >>> general purpose and requiring lots of additional work. The more >> universal an >>> interface is the less chance anyone is going to use it, it would > be too >>> hard. There are a bunch of w3c standards no one uses for this >> reason. The >>> most used services (at least for us) do a specific thing for a > specific >>> vendor. >>> >>> Bill Appleton >>> CTO >>> DreamFactory Software >>> tel. 408-399-7454 x 102 >>> fax. 408-351-9005 >>> cel. 408-656-3024 >>> <BLOCKED::mailto:billappleton@> >>> billappleton@ >> > > > > > > > > > > > > Yahoo! Groups Links > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
