I don't envision version 2 of a process, just of an interface. Using Change as an example, interfaces could include things like: - Create a Change Request - Resolve a Change Request - Get Change Request details - Relate something to a Change Request
Version 1 may support some set of attributes for "Create a Change Request", whereas version 2 would accommodate some new attributes or it may deprecate some attributes. The change process may change over time in such a way that new interfaces are required, so an interface could be introduced in version X of the application that was not available in previous versions of the application. There is a lifecycle around the management of these interfaces that would have to be defined and adhered to for this to be a reliable approach. Axton Grams On Wed, Nov 2, 2011 at 11:21 AM, Lyle Taylor <[email protected]> wrote: > ** > > I agree with the idea of making the applications more loosely coupled. > However, I don’t know about the idea of versioned interfaces in this > context, especially when those are in support of an application that > supports a business process. If you have a Change Management process, and > you make changes to the process (i.e., go from version 1 of the process to > version 2 of the process), you generally do NOT want to support the old > version of the process. You generally only want one version of a business > process going on at a time, except perhaps for during a transition period. > I suppose that might contradict my statements above somewhat…**** > > ** ** > > In general, though, I would think that if we move to version 2 of our > Change process, we would expect all systems integrating with the Change > module to be updated to support the new process rather than calling an > older version of the interface that didn’t support the new process.**** > > ** ** > > Lyle**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Axton > *Sent:* Tuesday, November 01, 2011 5:59 PM > *To:* [email protected] > *Subject:* Request for Comments**** > > ** ** > > ** **** > > 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_topic3 > **** > > ** ** > > 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**** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > > > > NOTICE: This email message is for the sole use of the intended > recipient(s) and may contain confidential and privileged information. Any > unauthorized review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply email > and destroy all copies of the original message.**** > > _attend WWRUG12 www.wwrug.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"
