I just read this reply and the original thread. First off, I agree on everything said about taxonomies and namespaces. They are an important part of understanding the enterprise, and ensuring that you're doing service oriented architecture, and not just service oriented applications.
The comment I have actually has nothing to do with taxonomies. In the original message, Anant asked, "From an implementation perspective, how do we best handle this constant change? How can we design services that can be re-categorized without disruptive changes?" First, I don't believe that re-categorization implies change. A disruptive change would be one that impacts the service interface. To me, categorization is all about finding the service, not necessarily the service interface. Now, if we're talking the actual information content changing, then this will most certainly have an impact. The more important thing was the second question. While I don't mean to imply that Anant falls into this category, there is such a resistance to change among IT workers. Everyone wants to try to define the end-all be-all interface that will never change. I believe that this is the wrong approach. SOA is about better supporting the rapid change in business. How can we imagine that these interfaces will not change over time? My opinion is that a key to success with SOA is excellence in change management, not change avoidance. If the organization can develop mature release management processes, and have a clear understanding of when a change can occur, they will be far better equipped to manage the dependent systems that will be impacted. To me, this is no different than the normal relationship that customers have with vendors. The customer will always be better off if they know that vendor X comes out with a new release every 6 months. They then also know that any new features they want have to be in by a certain date to be included in a subsequent release. They plan their own changes that they must make according to those dates. The whole process is manageable. When a vendor can't stick to delivery dates, that's when things can break down, and the whole process becomes unmanageable. The same will hold true of our internal development teams. If they're not prepared to change when requirements dictate that it needs to, the whole process might break down. -tb On Jan 12, 2006, at 2:26 PM, Eric Newcomer wrote: > > One simple way to think about this problem is in > comparison to what we all used to do with setting up > naming conventions for data items, objects, classes, > files, database tables, etc. > > Now we have another type of entity to name and manage > in the enterprise project. > > As Mukund said there are also often some industry > level ontologies or classifications of entities > important to an SOA. > > So you will probably end up with a blend of in > house developed names and categorization schemes and > external ones. > > But I think the main point is to understand the > ontology requirements of an SOA as more or less > an extension of the existing requirements to > categorize and name IT artifacts. > > Eric > --- Mukund Balasubramanian <[EMAIL PROTECTED]> > wrote: > >> Anant: >> >> You are correct in the fact that creating, using >> (categorize, search) and maintaining taxonomies are >> an important facet of a functioning SOA. >> >> Telecommunications is a great example of where >> taxonomies have emerged and have been used. For >> example our work with some of our large >> telecommunciations customers has uncovered the need >> for completely different kinds of taxonomies being >> applied to the same services: >> >> >> 1. Business Oriented (the taxonomy reflecting who >> owns the services now in the orgn) >> 2. Industry standard (using taxonomies such as eTom >> to categorize the services and their place in the >> telecommunications process lifecycle) >> 3. Customer oriented (what are your customers really >> looking for, how do they percieve your business) >> >> You can see from this approach that two important >> factors in creating and maintaining taxonomies >> emerge: >> >> * Taxonomies are an independent facade layered on a >> service rather than being PART of the service >> * Taxonomies (which _might_ reflect as namespaces at >> times) are better designed if they target their end >> users (as above). >> * Taxonomies need to be governed, ie. The data going >> in must be used and verified and hence needs to be >> coupled with a governance/process framework (service >> can be made available to the public if and only if >> it is categorized by at least one business taxonomy, >> one industry taxonomy and one customer taxonomy and >> all the data has been verified by A, B and C). >> >> Hope this helps, >> >> Mukund Balasubramanian >> >> CTO/Infravio Inc. >> >> -----Original Message----- >> From: Anant Kadiyala [mailto:[EMAIL PROTECTED] >> Sent: Tue 1/10/2006 12:10 AM >> To: [email protected] >> >> Cc: >> Subject: [service-orientated-architecture] Of >> Taxonomies and Namespaces >> >> >> I am trying to understand the best practices around >> designing and maintaining Taxonomy of services. >> Developing the Taxonomy for a given business is not >> in itself that difficult. The challenge lies in the >> aspect that Taxonomies are living structures. They >> need to be updated as per changing business needs >> and trends. New categories and sub-categories >> emerge, some of the old ones become >> obsolete/deprecated, and some others need to be >> re-categorized. The Telco and Energy sectors are >> good examples of industries that have been going >> through rapid revolutionary changes over the past >> few years. >> From an implementation perspective, how do we best >> handle this ‘constant change’? How can we design >> services that can be re-categorized without >> disruptive changes? How are companies addressing >> this problem? Any insights are greatly appreciated. >> Thanks, >> Anant >> >> >> _____ >> >> Yahoo! DSL >> > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http:// > promo.yahoo.com/broadband/> >> Something to write home about. Just $16.99/mo. or >> less >> >> >> SPONSORED LINKS >> Service-oriented architecture >> > <http://groups.yahoo.com/gads?t=ms&k=Service-oriented > +architecture&w1=Service-oriented+architecture&w2=Computer > +monitoring+software&w3=Free+computer+monitoring > +software&c=3&s=108&.sig=6fK_mkZmO-Ja3c3077pabQ> >> Computer monitoring software >> > <http://groups.yahoo.com/gads?t=ms&k=Computer+monitoring > +software&w1=Service-oriented+architecture&w2=Computer+monitoring > +software&w3=Free+computer+monitoring > +software&c=3&s=108&.sig=uGrAl3xkOAL3qi_0zABOeQ> >> Free computer monitoring software >> > <http://groups.yahoo.com/gads?t=ms&k=Free+computer+monitoring > +software&w1=Service-oriented+architecture&w2=Computer+monitoring > +software&w3=Free+computer+monitoring > +software&c=3&s=108&.sig=zwfvL3bn6VwdybrUdt_F8g> >> >> >> _____ >> >> YAHOO! GROUPS LINKS >> >> >> >> * Visit your group >> "service-orientated-architecture >> > <http://groups.yahoo.com/group/service-orientated-architecture> >> " on the web. >> >> * To unsubscribe from this group, send an email >> to: >> >> > [EMAIL PROTECTED] >> > <mailto:[EMAIL PROTECTED] > subject=Unsubscribe> >> >> >> * Your use of Yahoo! Groups is subject to the >> Yahoo! Terms of Service >> <http://docs.yahoo.com/info/terms/> . >> >> >> _____ >> >> >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > > > 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/
