Hey Ken... I guess what I am trying to say is that - I don't think you could build such a generic interface. Maybe some approximation thereof, but not completely. Once you have this API, then what - build a new suite of toolsets to leverage the API?
We are currently using Abydos - I am extrapolating from this concept - to suggest that process definition/engineering should supersede API augmentation if we are looking at a way to make ITSM more efficient. On Nov 4, 9:58 am, "Cecil, Ken" <kce...@hubbell.com> wrote: > 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:arsl...@arslist.org] On Behalf Of Elry > Sent: Friday, November 04, 2011 9:26 AM > To: arsl...@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: > > ... > > read more » _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
