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:arslist@ARSLIST.ORG] On Behalf Of Cecil, Ken Sent: 04 November 2011 13:58 To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG] On Behalf Of Elry Sent: Friday, November 04, 2011 9:26 AM To: arslist@ARSLIST.ORG 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 <richard_ba...@sympatico.ca> 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 <axton.gr...@gmail.com> > Reply-To: arsl...@arslist.org > 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 <richard_ba...@sympatico.ca> > 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 <lj.longw...@gmail.com> > Reply-To: arsl...@arslist.org > 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:arsl...@arslist.org] On Behalf Of Richard Baird > Sent: Wednesday, November 02, 2011 9:46 AM > > To: arsl...@arslist.org > 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" <david_eas...@bmc.com> > 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 postmas...@lchclearnet.com. 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 postmas...@lchclearnet.com. 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"
