Excellent Points... Now how do we do that - that is the million dollar question.
They would probably have to rebuild the application from the ground up! I do a lot of R&D in this space and we are working on a prototype with similar capabilities that would allow the client to do "plug and play" with the different modules (Change, Incident, etc.). Not only that, but it would have auto-archiving built in... The ITSM 7 product could be rebuilt and re-engineered to do what you are suggesting, but we may have to wait for version 10. On Nov 1, 7:59 pm, Axton <axton.gr...@gmail.com> wrote: > This is more a high level discussion and is concept/design oriented. > Please feel free to chime in with your thoughts. I look forward to the > collective wisdom of this list. I is my hope that a a constructive > discussion can happen around this subject and the powers that be can gain > insight gleaned from the discussion. > > First, a little background. I was in the Help Desk/ITSM space, left that > arena for a few years, and have since returned. After working with the > ITSM application for a few short months I am realizing how > tightly ingrained these applications are with one another (incident, > problem, asset, change, cmdb, etc.). The tightly coupled integrations make > certain tasks exceedingly difficult, for example: > - using an outside system for change management (or any other process, for > that matter) > - upgrading a single application in the stack (e.g., change management) > - integrating outside applications with the ITSM applications > > Non-remedy or custom remedy applications are unable to easily or > effectively communicate with the ITSM applications in the same way that the > ITSM applications communicate with one another. Even different versions of > the applications are unable to effectively communicate. > > Consider that each application facilitates a well defined process. Each > process has inputs, outputs, and actions. The ITSM applications could have > (and leverage, internally) interfaces to communicate their inputs and > inputs, outputs, and actions. Java Interfaces are an implementation of > this design pattern that are a prime example of the flexibilities that this > can afford. > > *Interfaces form a contract between the class and the outside world...* > *-- *http://download.oracle.com/javase/tutorial/java/concepts/interface.html > > Interfaces can be versioned (e.g., 'Create Incident' interface version 1 > supports a field ,Priority; 'Create Incident' interface version 2 supports > a new field, Urgency, etc.). By creating an interface (i.e., a contract) > and back-end instrumentation to implement the interface, applications could > be upgraded independent of one another; all the communicating components > need to know is the version of the interface and that dictates the > capabilities of said interface. With this idea, I am borrowing from the > approach that many of the SOA stacks are implementing: > > *One the most popular approaches for dealing with changes is versioning. > Versioning assumes simultaneous existence of multiple (different) > implementations of the same thing, with every implementation > distinguishable and individually addressable. In the case of SOA, service > versioning equates to coexistence of multiple versions of the same service, > which allows each consumer to use the version that it is designed and > tested for (see Figure 1). In this case, a new version of a service is > created based on the requirements of one or more consumers, which can start > using this new version immediately. The other consumers of this service do > not need to switch to using the latest version immediately, but can > continue to use the versions of the service they were designed for and > tested with. They can switch to the latest version of service, based on > their own development and testing schedule. Multiple coexisting versions of > the same service in the system allows for the independent life cycles of > services and their consumers and minimizes the overall impact of the > introduction of changes. Although the necessity of such versioning > mechanism may be obvious to anyone who has ever dealt with services, this > topic still has not penetrated the mainstream of SOA publications and > implementations. * > --http://msdn.microsoft.com/en-us/library/bb491124.aspx#jour11version_t... > > A few key concepts here: > - Interfaces and versioning > - Well defined interfaces > - Interface life-cycle (e.g., the last 3 major versions of the interfaces > will remain supported, after which, they are deprecated) > - Loosely coupled applications (to the extent that the applications could > run on different physical servers/databases) that leverage only the > interfaces the applications provide as a means of communication > > Such a change to the current paradigm would open the doors to a lot of > things that are simply not feasible at this time, all of which start with > better interoperability. This is something that is important in the cloud > space. A proper implementation of the above ideas would lead an > application that is easily pluggable into a SOA backbone so that the > services the applications provide can be used by any other application that > is able to reach out to the SOA backbone. > > I think that running each application within ITSM on separate servers would > be a good gauge of an effective implementation of this paradigm. > > I look forward to your thoughts. > > Regards, > Axton Grams > > ___________________________________________________________________________ > ____ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
