Todd, +1.
Hindsight thinks it is blessed with total clarity. In practice it is coloured by its own snapshot perspective of the world, a perspective is often soon to appear outdated. It is very easy in ICT architecture to look back and say, "if only they had done x or y we would not face this problem." People deal with situations as they see them at the time. It is not just a question of planning or otherwise for the future - it is impossible to make even a vaguely accurate commercial or technical prediction more than a few years ahead with any reasonable certitude. If you go and visit a large insurance company that wants to integrate their legacy systems (integrate not ditch, because they work and have a level of reliability undreamt of in a Windows PC environment)into a modern heterogeneous, distributed, touchy-feely etc. system, you are probably looking at COBOL, CICS, 3270 etc. (they have probably at least replaced SNA with the less deterministic IP). When these systems were first built probably no one had invented object-orientation, GUIs, client/server, probably not even LU 6.2. They were designed for operators using 3270 terminals. They were designed to perform well defined tasks, repetitively and reliably. They were designed for a boring business that steadily made lots of money. Obviously when designing a system which is meant to stay the course we need to make it as adaptable, reusable and evolvable as possible. That after all is the whole point of SOA. But don't for a moment imagine that you know what technology, protocols and interfaces you will be using in 15 years' time. Don't for a moment imagine that you know for sure what the business needs will be in 3 years' time. All we can do is to try our best to future-proof it... Gervas --- In [email protected], Todd Biske <[EMAIL PROTECTED]> wrote: > > 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" > > <it@> 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/
