With Overlays I am not sure it would be as big of a system issue as it would have in the past. Add the capability to have versioned Overlays might help with process transitions. If the interface API could specify which Overlay version to use it would be possible to have different field requirements as well as different workflow behaviors. Now managing all of the variations between versions may cause a whole new set of manageability issues but I don't think it is too far from being possible.
Jason On Wed, Nov 2, 2011 at 11:10 AM, Lyle Taylor <[email protected]> wrote: > ** > > Yes, I can see that. I see the benefit in testing new processes with a > subgroup, and that would mean you’ve got multiple versions of the process > (and likely interface) in use for a limited period. I suppose so long as > you keep it well controlled and defined (lifecycle), as Axton stated in his > response to my post, you may be OK. **** > > ** ** > > I think that would likely complicate things at a system level, as the > system is usually designed to support a process. For example, we have > decided that these fields are now required whereas they weren’t in the > previous version of the process. That might necessitate a change in the > interface. If you wanted to be able to use both the new and the old > interface, the system needs to be able to accommodate the *transition* in > process (fields being required or not) and not just the current process > (which seems to be usually the case). That makes building/configuring the > system more complicated. However, to your point, big bang switchovers are > complicated and risky as well. For large processes, the extra effort spent > in the system to support the smooth/incremental transition may mean less > overall risk, time and cost in the process transition.**** > > ** ** > > Lyle**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *John Sundberg > *Sent:* Wednesday, November 02, 2011 10:38 AM > > *To:* [email protected] > *Subject:* Re: Request for Comments**** > > ** ** > > ** **** > > ** ** > > Lyle,**** > > ** ** > > I have found the opposite to be the case. You desperately want multiple > versions to run at the same time (not forever - most likely) but yes for a > transitionary time.**** > > ** ** > > ** ** > > It radically reduces change mgmt headaches. For one -- you can "test" the > new process with a "subset" of your change world. That alone has huge > benefits.**** > > ** ** > > If it does not work -- you can roll back easily.**** > > ** ** > > Right now -- we have no option but these massive cutovers -- which are > risky, timely, expensive and problematic.**** > > ** ** > > ** ** > > Unfortunately -- these big cutovers are the norm - so they are accepted.** > ** > > ** ** > > But -- thinking differently -- they really are an optional approach.**** > > ** ** > > ** ** > > ** ** > > Multi-version live processes are the 'cats meow'.**** > > ** ** > > ** ** > > ** ** > > -John**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > On Nov 2, 2011, at 11:21 AM, Lyle Taylor 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"_ **** > > ** ** > > --**** > > *John Sundberg***** > > Save the Date! First Annual KEG - Kinetic Enthusiasts Group**** > > Feb. 29th - Mar. 2nd 2012 in Denver CO**** > > ** ** > > For more information click here - > KEG<http://www.kineticdata.com/Events/KEG.html> > **** > > * > **Kinetic Data, Inc.* > *"Building a Better Service Experience"* > *Recipient of:***** > > ** ** > > WWRUG10 Best Customer Service/Support Award**** > > *WWRUG09 Innovator of the Year Award***** > > [email protected] > 651.556.0930 I* *www.kineticdata.com**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > > > **** > > ** ** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ **** > _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"
