It is a fantasy, call me a dreamer; however, I think it's important to have these discussions. The idea was not to change the products (I am not in a position to do this nor do I think any single person is), unless there merit in doing it, but to have a candid discussion about what the products could be so that the idea is out there.
Axton Grams On Fri, Nov 4, 2011 at 1:17 PM, Jiri Pospisil <[email protected]> wrote: > I believe that standardised services (or APIs) would bring a great value if > they were adopted and implemented by many/all vendors. > The services would follow ITIL processes, so there would be Incident > Management Service, Event Management Service etc. > Each service would have a set of mandatory operations with mandatory > attributes, but allowing the model to be extended, so that each vendor can > leverage their specific features and offer them to outside world (or other > products of their own). > Any product that would claim support of this standardised service set would > have to implement all mandatory operations for the process(es) supported by > the product. > > It should then be easy to switch between products as in theory, if I decided > to switch from BEM to HP Open View the interface on Incident management side > is there, well defined and ready to be used, so the cost of switching should > be minimal (from the point of view of integrating with incident management). > > But it is all perhaps a bit of a fantasy anyway ... > > Regards > Jiri Pospisil > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Cecil, Ken > Sent: 04 November 2011 13:58 > To: [email protected] > Subject: Re: Request for Comments > > I would think that any interface designed would be agnostic to processes and > just be concerned with providing the services agreed upon in the contract. No > matter what happens behind the scene, the interface would handle the request > the same whether it be for interactive users, service consumers, other ITSM > apps, or other integrated apps/processes. The interface should be somewhat > abstracted from the underlying forms, processes, and customizations. The > interface contract should be generic and flexible enough to handle/anticipate > customizations and schema changes (similar to xml). > > Elry, I believe Abydos Designer already does most of what you were referring > to about diagramming and creating workflow via a visio type diagram. > > Ken Cecil > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Elry > Sent: Friday, November 04, 2011 9:26 AM > To: [email protected] > Subject: Re: Request for Comments > > This interface discussion is interesting and all , but I do not think > that the ITSM application will readily conform to this approach. I > think we are forgetting that ITSM is meant to be ITIL compliant. For > those who have worked on the process side of ITIL - I am certain that > you will be aware of how tightly coupled the ITIL proceses are... > > Keep in mind that the ITIL process is a blueprint for how things > should work and not necessarily the "cookie cutter" approach for all > organizations. This is why many of us find work "customizing" the > ITSM application. I use the term customize loosely, since this could > mean adding a few fields to revamping large portions of the process > model. Now, if you put fixed structures in place and standardize the > interactions between processes - you are effectively making a flexible > model "rigid". > > I think that if we keep in mind that this is a process driven > application; therefore, it must remain as flexible as possible - then > we would have to conclude that the current architecture - offers the > greatest degree of flexibility. > > BMC has done an excellent job giving us some base structures and > processes as well as amazing integration tools (by BMC and third party > vendors). I believe that Overlays are a great concept - that once > refined will be a formidable tool for our customization tool set. > > To me (keeping in mind that this is an ITIL tool set) - the only > missing component for ITSM is a tool that would enable the BMC > Engineer to modify the ITSM process "on the fly". We have the > technology, and the people (all you arlisters), now all we need for > our tool belt is something that could effectively change a process "on > the fly", or build/re-engineer a process "on the fly". > > Imagine if you would that there is a tool that would: > > 1. Allow you to design your process in Visio. > 2. Link your process to the underlying ITSM structures. > 3. Link your process to the underlying categorization structure, and > product catalog. > 4. Enable customization to be defined through process definitions. > 5. These processes that are graphically designed can then be called > from the ITSM application and executed based on the underlying ITSM > structures and workflow. > > This would mean that: > > 1. You utilize the underlying ITSM application to hold your data and > basic workflow. > 2. Overlays are utilized to make structural changes that or > Organizationally dependent. > 3. Workflow is designed and executed through process diagrams that are > written in a Visio like environment. > 4. API integration would focus on integration between enterprise > applications. > 5. BMC could and will continue to focus on "plugins" for the purpose > of integration. > > Process, process, process... > > This is "my take" on this... > > > > > > > On Nov 2, 3:55 pm, Richard Baird <[email protected]> wrote: >> That works for me Axton. If they wanted to get even fancier, they could >> implement it via the "Interface Form" model I described, and have the saving >> of the form (along with it's attached/embedded XML legal operations, >> exceptions, etc...) automatically create and publish the web service. >> >> That way every integration method/mechanism would have the same behaviour, >> because it would be based on the same source (the "Interface Form" for the >> specific interface) >> >> Cheers! >> >> Subject: Re: Request for Comments >> From: Axton <[email protected]> >> Reply-To: [email protected] >> Date: Wed, 2 Nov 2011 14:45:38 -0500 >> >> ** I envisioned the interfaces implemented as web services, not as an API. >> A web service layer makes plugging into other things easier. One of the >> drivers for me starting this conversation is what I see many of the cloud >> providers offering and leveraging as their interfaces into and out of their >> applications. I have some exposure to the service oriented architecture as >> well, which plays into this paradigm nicely. >> >> If, within Remedy, all the interfaces were exposed as web services and >> Remedy had a native way to consumer those web service based interfaces, it >> opens the door nicely for other things to operate at that level. Web >> services seem to be a common method of integration in the cloud space. SOA >> infrastructure deployments seem to be in their infancy, but I see them >> gaining traction, as long as they are capable of delivering on their value >> proposition.http://www.zapthink.com/2005/01/27/the-roi-of-soa/ >> >> The lifecycle around services is pretty well defined in this space as >> well.http://www.soablueprint.com/whitepapers/SOAPGPart3.pdf >> >> Axton Grams >> >> On Wed, Nov 2, 2011 at 2:20 PM, Richard Baird <[email protected]> >> wrote: >> >> LJ, >> >> Having done lots of OO stuff as well as ARS over the years, I fully grasp >> the concepts you're putting forward, however, I think the goal should be >> "Interfaces", not necessarily "API Interfaces". For most apps built using >> java or .net (or some other OO platform) as a base, I agree that tightly >> defined api interfaces are the way to go. But ARS is somewhat different in >> that the integration tools already in existence are widely used both within >> the ITSM as well as many other third party or custom apps and they afford >> great flexibility, which is one of the reasons ARS became so popular to >> begin with. >> >> I don't see any reason that the capabilities we're talking about can't be >> implemented via a "special" Interface Form type or layering versioning on >> top of existing technology rather than requiring a call to a new C/java/.net >> api. Not everyone uses the api to do integration and for integration between >> apps both running on ARS platform (like the ITSM stuff), whether they are >> BMC or someone else's, most will do it via workflow. >> >> If the "special" form approach is used (and fully documented), then an >> integration using the interface would behave exactly the same if it is done >> via workflow, C API, Java API, .net api, Perl, etc... Nothing to stop BMC >> from doing full error checking, implementing exceptions, etc... for activity >> in the special form, and all the code would be visible so folks could easily >> understand what is happening when they touch the form (or encounter >> problems), regardless of the mechanism used. They could even define the >> legal operations, exceptions, etc... via xml so others could build their own >> Interface Forms for their own apps in a standard way. In addition, we'd be >> able to see exactly how the ITSM apps do their integration between each >> other without searching all over the place for the push/set field workflow, >> since it would all (or at least the majority of the big/important >> operations) be localized to the appropriate Interface Form. >> >> A potential drawback I see with this approach is that visual >> studio/netbeans/eclipse/(insert your IDE here) might not see a specific >> interface defined (i.e. we might still use setentry/getentry, which means >> we'd have to actually read the interface spec....;). I suspect this is >> exactly what some want, and again, there is nothing to stop BMC from adding >> specific versioned interface api calls that interact with the appropriate >> Interface Forms, but I think it would be a mistake to force the use of the >> API, or any other particular mechanism when we don't have to do it to >> achieve the goal, that being consistent, safe, published, versioned >> interfaces between ITSM (or other) apps running on the ARS platform. >> >> Cheers! >> >> Subject: Re: Request for Comments >> >> From: LJ LongWing <[email protected]> >> Reply-To: [email protected] >> Date: Wed, 2 Nov 2011 10:17:47 -0600 >> >> Richard, >> The point of API interfaces is actually reduced flexibility....not really >> the point, but a byproduct. That reduced flexibility is actually a 'good' >> thing though. Remedy, in the way that it works now has absolutely no >> enforced structure. That lack of enforced structure allows you to literally >> 'do what you want'...which is extremely flexible, but extremely hard to >> support and optimize. When you setup API interfaces to a system, you harden >> them and make them less flexible, but because of the defined contract >> between the publisher and consumer you have extremely reliable results. >> Because of this reliability you can guarantee results and ideally >> scalability, and because of this contract you increase interoperability. >> >> Additionally, when you add to this contract, versions of the API...it in >> theory allows you to upgrade from ITSM 10 to 11, but you aren't required to >> upgrade your integrated app, because your integrated app can continue to >> communicate with your ITSM Suite on the 10 version of the API and will >> continue to function EXACTLY the same as it did when you were actually >> running that version. >> >> That's the theory at least :D >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Action Request System discussion list(ARSList) >> >> [mailto:[email protected]] On Behalf Of Richard Baird >> Sent: Wednesday, November 02, 2011 9:46 AM >> >> To: [email protected] >> Subject: Re: Request for Comments >> >> Good to hear David! >> >> Here is a suggestion off the top of my head. Perhaps to help with one of >> Axton's (and my) beefs, the concept of versioned interfaces, you could add a >> reserved field for forms used as "interfaces" to implement versioning. Then >> add checking of this field into the workflow objects such that, workflow >> only fires if the versions match, or something to that effect. Perhaps a >> combination of fields, one to hold the version number and another to >> indicate if it is specific to the version or applicable to lower versions as >> well or the lowest version number supported, etc? >> >> That would allow you to share workflow between interface versions where >> appropriate, and even perhaps have workflow with the same name, but >> different version and also to have workflow specific to a particular >> version, thereby implementing something with similar results to Inheritance. >> >> I'm not sure that additional API calls would need to be defined as that >> could result in reduced flexibility, however the interfaces would need to be >> tightly documented. >> >> Cheers! >> >> Subject: Re: Request for Comments >> >> From: "Easter, David" <[email protected]> >> Date: Wed, 2 Nov 2011 10:00:02 -0500 >> >> ** >> Just a quick comment - later versions of ITSM applications do have interface >> forms that are expected to be used to interact with the applications. These >> are used mainly by web service queries, but would be appropriate for any >> external communication into the application. Those forms are the >> recommended interaction point for external applications and insulate such >> programs from the version-to-version changes in the underlying forms. >> >> Please do continue the discussion - the ideas being expressed can certainly >> enhance and improve upon the architecture - but wanted to make sure folks >> know that the apps are already headed in this direction. >> >> -David J. Easter >> >> Manager of Product Management, Remedy Platform >> >> BMC Software, Inc. >> >> The opinions, statements, and/or suggested courses of action expressed in >> this E-mail do not necessarily reflect those of BMC Software, Inc. My >> voluntary participation in this forum is not intended to convey a role as a >> spokesperson, liaison or public relations representative for BMC Software, >> Inc. >> >> ___________________________________________________________________________ _ >> ___ >> UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org >> attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" >> >> ___________________________________________________________________________ _ >> ___ >> UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org >> attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" >> >> ___________________________________________________________________________ _ >> ___ >> UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org >> attend wwrug12www.wwrug12.comARSList: "Where the Answers Are" >> >> _attend WWRUG12www.wwrug.comARSlist: "Where the Answers Are"_ >> >> ___________________________________________________________________________ >> ____ >> 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" > ******************************************************************* > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom > they are addressed. If you have received this email in error please > notify the system manager. This footnote also confirms that this > email message has been swept for the presence of computer viruses. > www.Hubbell.com - Hubbell Incorporated** > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > ************************************************************************************************* > > This email is intended for the named recipient(s) only. Its contents are > confidential and may only be retained by the named recipient(s) and may only > be copied or disclosed with the consent of LCH.Clearnet Limited and/or > LCH.Clearnet SA. If you are not an intended recipient please delete this > e-mail and notify [email protected]. > LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the > LCH.Clearnet Group accept no liability, including liability for negligence, > in respect of any statement in this email. > The contents of this email are subject to contract in all cases, and > LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment > save where confirmed by hard copy. > Cet e-mail et toutes les pièces jointes (ci-après le "message") sont > confidentiels et établis à l'intention exclusive de ses destinataires. Toute > utilisation de ce message non conforme à sa destination, toute diffusion ou > toute publication, est interdite, sauf autorisation expresse de LCH.Clearnet > Limited et/ou LCH.Clearnet SA. Si ce message vous a été adressé par erreur, > merci de le détruire et d'en avertir immédiatement [email protected]. > LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe > LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au titre > de ce message à moins qu’il n’ait fait l’objet d’un contrat signé. > LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High > Street, London EC3N 1EA. Recognised as a Clearing House under the > Financial Services & Markets Act 2000. Reg in England No.25932 > Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com > LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris, > Chambre de Compensation conformément au Code Monétaire et Financier. > > ************************************************************************************************* > > _______________________________________________________________________________ > 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"
