How? is not a question I am in a position to answer. It's an idea, and I like to think it's a good idea; that's why I threw it out here, to see what others think. If it's good enough idea it will stick and be adopted in varying degrees. It may not be adopted within the ITSM arena, but there are plenty of other application vendors, Remedy and non-Remedy alike, that may consider the merits of such an approach. I imagine it's more than a million dollar question, and probably more than a million dollar answer ;) One thing I hope to answer with this discussion, is what components are missing from the AR stack to make this a possibility.
Thanks for the feedback. Axton On Wed, Nov 2, 2011 at 8:28 AM, Elry <elryal...@gmail.com> wrote: > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
