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 <*> 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/
