Re: Request for Comments: multi-vendor vs single-vendor
John, I think the question is less about if the tools you use come from one vendor or not, but how those/that vendor handles the separate products. If as you say that the 'suite' is only released as a suite, and if one portion of that suite is 'hung up' for some reason, they don't release the suite.that can cause issues. But tell me this.when was the last time MS released Word before it released Excel of the same version? To my knowledge it hasn't happened.MS chooses to sell its Office Suite as a suite, and as such, you must wait for all components to be ready before you get the next version. This discussion goes back a bit to last week's discussion regarding interfaces between modules within the same suite. I think it's awesome that there are competitors to BMC in some spaces of the Service Desk arena, but I can't honestly fault BMC for delaying a suite install because some components needing additional tweaking J From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Sundberg Sent: Wednesday, November 09, 2011 10:23 AM To: arslist@ARSLIST.ORG Subject: Request for Comments: multi-vendor vs single-vendor ** What are the thoughts around multi-vendor vs single-vendor? Michael Poole - from our company recently wrote a good blog post on the subject: http://blog.kineticdata.com/vendor-strategy/are-we-living-in-a-one-horse-tow n/ My observations are in-line with the blog post. A single-vendor approach puts companies on the path of the vision of that vendor -- and quite frankly not on their own company path - which should be business agenda driven. I find it IMPOSSIBLE for a single-vendor approach to be able to fit the REALITY of today's larger organizations. As witnessed by the size of projects and the length of projects to deploy the single vision. (And then - to address the updates - when they come out) Weird stuff happens: - Forced pricing changes, leverage is to the vendor - and these are against your suite typically - and therefore -- all products at one time - Dropped product RFEs - dropped because it is slowing down all the other products (Next release is 2 years) - Release slowdowns - since everything is tied together - you have to wait for unrelated items to get fixed before the release is out (So - you might care about Incident -- but the next release of Incident is not coming out until Change gets fixed (which is behind schedule) etc...) From a business perspective -- BAD PLAN - IMHO. Do others feel different? Is the Big Suite - a vendor benefit - or a customer benefit? I look forward to the comments. -John -- 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 john.sundb...@kineticdata.com 651.556.0930 I http://www.kineticdata.com/ www.kineticdata.com _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
Re: Request for Comments: multi-vendor vs single-vendor
Hi, To take this one step further, any Out-Of-The-Box application will control the customer, but a home-grown application will be all based on customer requirements... If you rely on a platform, like Remedy, you need to adapt your requirements to the limitations of the platform. A. If you have a single vendor with a suite, you will have to adapt more, and wait for the suite to be released. B. If you have multi-vendor OOB applications, you will have to deal with the integrations. C. If you build everything in C, you can get anything, but it will probably take some time and money until you are done... I for one hope that the pendulum will move back toward home grown applications. Maybe not for everything, but at least for some tasks. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. John, I think the question is less about if the tools you use come from one vendor or not, but how those/that vendor handles the separate products. If as you say that the 'suite' is only released as a suite, and if one portion of that suite is 'hung up' for some reason, they don't release the suite.that can cause issues. But tell me this.when was the last time MS released Word before it released Excel of the same version? To my knowledge it hasn't happened.MS chooses to sell its Office Suite as a suite, and as such, you must wait for all components to be ready before you get the next version. This discussion goes back a bit to last week's discussion regarding interfaces between modules within the same suite. I think it's awesome that there are competitors to BMC in some spaces of the Service Desk arena, but I can't honestly fault BMC for delaying a suite install because some components needing additional tweaking J From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Sundberg Sent: Wednesday, November 09, 2011 10:23 AM To: arslist@ARSLIST.ORG Subject: Request for Comments: multi-vendor vs single-vendor ** What are the thoughts around multi-vendor vs single-vendor? Michael Poole - from our company recently wrote a good blog post on the subject: http://blog.kineticdata.com/vendor-strategy/are-we-living-in-a-one-horse-tow n/ My observations are in-line with the blog post. A single-vendor approach puts companies on the path of the vision of that vendor -- and quite frankly not on their own company path - which should be business agenda driven. I find it IMPOSSIBLE for a single-vendor approach to be able to fit the REALITY of today's larger organizations. As witnessed by the size of projects and the length of projects to deploy the single vision. (And then - to address the updates - when they come out) Weird stuff happens: - Forced pricing changes, leverage is to the vendor - and these are against your suite typically - and therefore -- all products at one time - Dropped product RFEs - dropped because it is slowing down all the other products (Next release is 2 years) - Release slowdowns - since everything is tied together - you have to wait for unrelated items to get fixed before the release is out (So - you might care about Incident -- but the next release of Incident is not coming out until Change gets fixed (which is behind schedule) etc...) From a business perspective -- BAD PLAN - IMHO. Do others feel different? Is the Big Suite - a vendor benefit - or a customer benefit? I look forward to the comments. -John -- 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 john.sundb...@kineticdata.com 651.556.0930 I http://www.kineticdata.com/ www.kineticdata.com _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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
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
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
Re: Request for Comments
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
Re: Request for Comments
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
Re: Request for Comments
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 jiri.pospi...@lchclearnet.com 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: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
Re: Request for Comments
Completely agree, Remedy would need enhancements to handle the complex nature of Web Service calls internally.but I agree with Richard that we don't want to be making WS calls internally..the overhead of that would be huge to have apps on the same server communicating with each other through MidTier.. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Wednesday, November 02, 2011 2:11 PM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** I see limitations to the form approach that could be counter productive and/or limiting. xml (encapsulated in a web service) provides a richer set of capabilities to describe, store, and validate data. For instance, if one of the services to get a list of things, be it incidents, changes, tasks, etc., a single response could be returned as an xml document. Part of the request could be what to query on, the other part of the request could be what to return. The same for a service like create an incident, it could handle any number of tasks, work info records, related items, etc. that are desired at create time. I don't see an easy or good way to achieve similar results using a form. Again, I would expect this to all be native within AR, a new type of workflow action, if apps are to consume services from one another. Some type of interface where, within the workflow, you could browse the available services (and why stop at just Remedy services) and select the appropriate one and view the definition of the service. This is not so far from the current web service implementation, but a richer set of capabilities would be required. Axton Grams On Wed, Nov 2, 2011 at 2: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: arslist@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
Re: Request for Comments
Excellent Points... Now how do we do that - that is the million dollar question. They would probably have to rebuild the application from the ground up! I do a lot of RD in this space and we are working on a prototype with similar capabilities that would allow the client to do plug and play with the different modules (Change, Incident, etc.). Not only that, but it would have auto-archiving built in... The ITSM 7 product could be rebuilt and re-engineered to do what you are suggesting, but we may have to wait for version 10. On Nov 1, 7:59 pm, Axton axton.gr...@gmail.com wrote: 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_t... 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
Re: Request for Comments
How? is not a question I am in a position to answer. It's an idea, and I like to think it's a good idea; that's why I threw it out here, to see what others think. If it's good enough idea it will stick and be adopted in varying degrees. It may not be adopted within the ITSM arena, but there are plenty of other application vendors, Remedy and non-Remedy alike, that may consider the merits of such an approach. I imagine it's more than a million dollar question, and probably more than a million dollar answer ;) One thing I hope to answer with this discussion, is what components are missing from the AR stack to make this a possibility. Thanks for the feedback. Axton On Wed, Nov 2, 2011 at 8:28 AM, Elry elryal...@gmail.com wrote: Excellent Points... Now how do we do that - that is the million dollar question. They would probably have to rebuild the application from the ground up! I do a lot of RD in this space and we are working on a prototype with similar capabilities that would allow the client to do plug and play with the different modules (Change, Incident, etc.). Not only that, but it would have auto-archiving built in... The ITSM 7 product could be rebuilt and re-engineered to do what you are suggesting, but we may have to wait for version 10. On Nov 1, 7:59 pm, Axton axton.gr...@gmail.com wrote: 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
Re: Request for Comments
Hey Axton, I agree completely that what you are describing is a better technical design. I guess the big question in terms of BMC's ITSM apps is, is that kind of design in BMC's interest as much as it is in a customer's interest? I'm not crapping on BMC specifically for this, but the goal of all large software companies that create integrated apps is to sell those apps. Thus, they don't want to make it too easy to mix and match with other vendors tools, but rather want to pass muster on the purchasing checklist that says it can be done. The larger a software company becomes, the more true this is. From an ARS platform perspective, Remedy/BMC have done an excellent job, better then most, at making the tools available to integrate any way you want. When it comes to the apps themselves, it is a different story, at least so far. I suspect in the battle for development funds, making it easier to integrate some other vendor's app as a replacement for one of the ITSM suite apps will always come second to new features/apps, better performance, etc... The only way that will change is if the market demands it or some other internal BMC driver forces it as a way to sell something new. That is just a business reality. But from a technical design perspective, I think your RFC dart is in the bullseye! Cheers! _ From: Axton [mailto:axton.gr...@gmail.com] Sent: November 1, 2011 7:59 PM 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
Re: Request for Comments
Yes - you have hit on one of the missing features of ARS - a lack of an API for apps. ITSM is using the natural way to use ARS. ARS has no concept of an API - everything is open - everything is a global variable (there is NO public/private API concept) all fields are fair game. As a result - if your form has 10 fields -- you effectively have 10*9*8*7... ways to communicate to your form. Then -- take a look at ITSM Incident with 150+ fields -- and now you have 150! (aka - more ways to communicate with it than there are protons in the universe) Which is a long term problem when it comes to changing your system... If you want to make a change -- you have (in theory) 10*9*8*7 ... possible tests to run. vs... If you created an API -- and only exposed 3 or 4 ways to talk to your form -- you could actually potentially test them... (And possibly document them) This API concept would create a more standardized technique of communication and therefore more stable applications. In addition -- since you would have an API -- you could in theory have multiple versions of processes in existence at the same time etc So - yes ITSM is a bit of a bowl of jello -- you touch it here - it wiggles here, here, here, here and here and here too. In order to get rid of these cross-dependencies and highly-coupled nature -- the concept of an API needs to exist and be enforced. (AKA ARS 10.0 or so) The decoupling of the systems - and creating well defined interfaces - now gives the customer choice -- is this function good for us? Is that function good for us? and if not -- they can do something about it. Where the current architecture -- you get the whole thing - and nothing but. (which - by the way - sells more licenses -- pure genius from a marketing/sales perspective) Not sure if you saw my last Friday funny comment about Best of Suite ??? -John On Tue, Nov 1, 2011 at 6:59 PM, Axton axton.gr...@gmail.com wrote: ** 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
Re: Request for Comments
Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could 'mix and match' solutions as you saw fit. This type of approach could have eased the SRM discussion the other day because the user in that situation considered ITSM 'THE' solution.and while BMC I'm sure strives to make that the perception, we that pay attention know there are alternatives to the BMC ITSM Suite, and alternatives to specific modules where others see fit to produce those alternatives. So.while it may benefit the customer.I don't think it benefits BMC for exactly the same reason it benefits the customer. Because of this, I doubt that BMC is likely to move in this direction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORG 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
Re: Request for Comments
I think the cloud landscape is changing that. Playing in the cloud means working with other cloud based applications or SOA infrastructure. Being a silo in the cloud is going to be a tougher sell than being an easily integrated application in the cloud, at least this is my projection based on what I've observed. http://en.wikipedia.org/wiki/Service-oriented_architecture http://www.salesforce.com/company/news-press/press-releases/2007/05/070521-1.jsp http://blog.programmableweb.com/2007/05/21/salesforcecom-soa-and-web-apis/ If incorporated into the ITSM stack, another benefit is the ability to upgrade components independently of one another instead of having to upgrade an entire stack of applications all at once. On Wed, Nov 2, 2011 at 9:39 AM, LJ LongWing lj.longw...@gmail.com wrote: ** Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could ‘mix and match’ solutions as you saw fit. This type of approach could have eased the SRM discussion the other day because the user in that situation considered ITSM ‘THE’ solution…and while BMC I’m sure strives to make that the perception, we that pay attention know there are alternatives to the BMC ITSM Suite, and alternatives to specific modules where others see fit to produce those alternatives… ** ** So…while it may benefit the customer…I don’t think it benefits BMC for exactly the same reason it benefits the customer. Because of this, I doubt that BMC is likely to move in this direction. ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Axton *Sent:* Tuesday, November 01, 2011 5:59 PM *To:* arslist@ARSLIST.ORG *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
Re: Request for Comments
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. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, November 02, 2011 7:40 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could 'mix and match' solutions as you saw fit. This type of approach could have eased the SRM discussion the other day because the user in that situation considered ITSM 'THE' solution...and while BMC I'm sure strives to make that the perception, we that pay attention know there are alternatives to the BMC ITSM Suite, and alternatives to specific modules where others see fit to produce those alternatives... So...while it may benefit the customer...I don't think it benefits BMC for exactly the same reason it benefits the customer. Because of this, I doubt that BMC is likely to move in this direction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORG 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
Re: Request for Comments
Start of a solution: (suggestion) Problem: Push fields -- is wide open Get fields (set field external) -- is wide open Create 3 new form actions: 1) API Set fields (create) 2) API Update fields (modify) 3) API Get fields (read) 1) API Set fields... Would be a list of create APIs for all the different forms (each form - could have multiple APIs)... You select the API you want -- it then presents a list of required and optional fields. 2) API Update fields... Would be a list of update APIs for all the different forms (each form - could have multiple APIs)... You select the API you want -- it then presents a list of required and optional fields. (Obviously - a key field of some sort would need to exist to represent the record to be updated) 3) API Get fields This function would take parameters -- and return a result, multi results, etc... This w(c)ould eliminate inefficient queries spread all over the system. So - instead of the developer whipping up any old query they want -- they do not even have that choice -- they can only select from the existing getter type functions. Now - once those exist: The next effort is to rapidly go through ITSM / CMDB etc... and get rid of push fields and set fields functions... I realize there are many holes etc... this is just a start. So then --- if you find that SRM does not meet your need -- you can take the 20 or so API and override them. etc... -John On Nov 1, 2011, at 6:59 PM, Axton wrote: ** 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
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 at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Request for Comments
David, Having dealt with quite a bit of this in my own custom application, the problem with interface forms in general is that the application itself doesn't use them. Interface forms are a great thing, but when the application doesn't use those interfaces itself.you basically must maintain two branches of the code.the one that interacts directly with the incident form.and then the ones that interact with the incident interface form. I think the discussion is around the fact that if ALL interaction with Incident went through Interfaces, then ALL communication with Incident would be standardized, and other applications would then be able to interact in the same way that say.Change does.but Change doesn't use the interface form to create incidents.so it's not a standardized API. It's really a divergence from the Remedy way of thinking..as said by a separate poster, when you want the data you just do a setfield with whatever qual you feel is right to get the fields you want.but if there was an API to 'get' that information, then the API would define what fields were required to get the information, and define what information is returned. This mentality would simplify the query structure, would make it so that indexes could be ensured to be used because you define which fields will be provided to get this data, and that's the only way to get it. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David Sent: Wednesday, November 02, 2011 9:00 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** 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. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, November 02, 2011 7:40 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could 'mix and match' solutions as you saw fit. This type of approach could have eased the SRM discussion the other day because the user in that situation considered ITSM 'THE' solution.and while BMC I'm sure strives to make that the perception, we that pay attention know there are alternatives to the BMC ITSM Suite, and alternatives to specific modules where others see fit to produce those alternatives. So.while it may benefit the customer.I don't think it benefits BMC for exactly the same reason it benefits the customer. Because of this, I doubt that BMC is likely to move in this direction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORG 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
Re: Request for Comments
Richard, The point of API interfaces is actually reduced flexibilitynot 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:arslist@ARSLIST.ORG] On Behalf Of Richard Baird Sent: Wednesday, November 02, 2011 9:46 AM To: arslist@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 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
Re: Request for Comments
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:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORG 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
Re: Request for Comments
To put some context around these interfaces, incident would have these types of interfaces (limited listing): - Open Incident - Get Incident Details - Relate to Incident (could be a CI, a problem, a change, etc., that the interface would define) - Close incident - Add worklog entry The interfaces would be operations common to incident. The same with Problem: - Open Problem - Get Problem Details - Update Problem - Relate to Problem - Close Problem - Add worklog entry The idea being that incident does X, and outside applications or events trigger Y within incident, nothing more, nothing less. The intrinsic benefits may include: - application/version independence (anything can talk to incident to use it to do what incident does) - loosely coupled integration points that are well defined and easily understood - a method by which the interfaces to an application can be expanded or re-defined in a way that does not break interoperability - open and well defined interfaces that are available for widespread consumption These things translate into more tangible benefits, such as: - eased upgrade path (no more upgrade the entire stack, just one part at a time) - eased integration methods (any event can consume the services that an app provides to leverage that app) - reduction in customization to the apps to develop integration points - increased interoperability with other applications/service providers - less breakage/integration redesign as a result of changes or upgrades/updates to the applications With this said, incident is still incident, and when you work with the application directly, all the capabilities inherent to incident are available to you, but as soon as something moves outside incident into incident or moves from inside incident into another app (e.g., problem), it uses the bridge that is the interface to perform that operation. This results in more defined integration points, which may reduce flexibility, but it has a number of benefits at the same time. The interfaces, over time, would mature to meet the needs of outside consumers. A good starting point for defining those interfaces are the ways in which the applications interact today. If an interface was defined that implemented all the capabilities required for the entire ITSM stack to work together, chances are it will cover most of the things that anything outside the ITSM stack would require. Axton Grams On Wed, Nov 2, 2011 at 11:00 AM, LJ LongWing lj.longw...@gmail.com wrote: ** David, Having dealt with quite a bit of this in my own custom application, the problem with interface forms in general is that the application itself doesn’t use them. Interface forms are a great thing, but when the application doesn’t use those interfaces itself…you basically must maintain two branches of the code…the one that interacts directly with the incident form…and then the ones that interact with the incident interface form. I think the discussion is around the fact that if ALL interaction with Incident went through Interfaces, then ALL communication with Incident would be standardized, and other applications would then be able to interact in the same way that say…Change does…but Change doesn’t use the interface form to create incidents…so it’s not a standardized API. ** ** It’s really a divergence from the Remedy way of thinking….as said by a separate poster, when you want the data you just do a setfield with whatever qual you feel is right to get the fields you want…but if there was an API to ‘get’ that information, then the API would define what fields were required to get the information, and define what information is returned. This mentality would simplify the query structure, would make it so that indexes could be ensured to be used because you define which fields will be provided to get this data, and that’s the only way to get it. ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Easter, David *Sent:* Wednesday, November 02, 2011 9:00 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: Request for Comments ** ** ** 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
Re: Request for Comments
In addition -- if BMC were to do this -- then they could have multiple versions of their apps. Example: Incident-lite Incident-normal Incident-ServiceProvider Change-lite etc... Then -- they could charge different amounts etc... for them. As - right now - the whole sales pitch is to layout a Nirvana of some sort -- and then have ALL COMPANIES in the world chasing after what BMC thinks is the end-goal... This is a CRAZY APPROACH for a ServiceProvider -- it is unwise to put your future direction in the hands of best practices -- you want your practices etc... This is a CRAZY APPROACH for a small company -- it is unwise to put your company into a system designed for ServiceProviders... (I feel one size fits nobody) So - BMC could provide differentiated versions of the processes -- and guide companies via assessment -- where they should go. This would actually be a consultative sale -- and the customer would feel that what they got is right for them. I suspect that would be a far better feeling than how they feel now (based on my many conversations). -John On Nov 2, 2011, at 11:00 AM, LJ LongWing wrote: ** David, Having dealt with quite a bit of this in my own custom application, the problem with interface forms in general is that the application itself doesn’t use them. Interface forms are a great thing, but when the application doesn’t use those interfaces itself…you basically must maintain two branches of the code…the one that interacts directly with the incident form…and then the ones that interact with the incident interface form. I think the discussion is around the fact that if ALL interaction with Incident went through Interfaces, then ALL communication with Incident would be standardized, and other applications would then be able to interact in the same way that say…Change does…but Change doesn’t use the interface form to create incidents…so it’s not a standardized API. It’s really a divergence from the Remedy way of thinking….as said by a separate poster, when you want the data you just do a setfield with whatever qual you feel is right to get the fields you want…but if there was an API to ‘get’ that information, then the API would define what fields were required to get the information, and define what information is returned. This mentality would simplify the query structure, would make it so that indexes could be ensured to be used because you define which fields will be provided to get this data, and that’s the only way to get it. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David Sent: Wednesday, November 02, 2011 9:00 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** 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. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Wednesday, November 02, 2011 7:40 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could ‘mix and match’ solutions as you saw fit. This type of approach could have eased the SRM discussion the other day because the user in that situation considered ITSM ‘THE’ solution…and while BMC I’m sure strives to make that the perception, we that pay attention know there are alternatives to the BMC ITSM Suite, and alternatives to specific modules where others see fit to produce those alternatives… So…while it may benefit the customer…I don’t think it benefits BMC for exactly the same reason it benefits the customer. Because of this, I doubt that BMC is likely to move in this direction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORG Subject: Request for Comments
Re: Request for Comments
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 tayl...@ldschurch.org 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: arslist@ARSLIST.ORG] *On Behalf Of *Axton *Sent:* Tuesday, November 01, 2011 5:59 PM *To:* arslist@ARSLIST.ORG *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
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:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORG 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
Re: Request for Comments
I believe that if you truly want to encapsulate all the functionality into API calls to allow loose coupling, the API would have to implement all actions that users can perform within the application (and there is many!). If I take Incident as an example. There should be at least two variations of API call for submitting Incidents. One using template (possibly needing API for searching and defining templates) and the other without template (and potentially more). Then there should be API for assigning Incident to a group or an individual after it was created (with different variations depending on whether you want to use IDs or names etc.). Another type of calls should allow the Incident status to be progressed to in progress, pending, resolved, assigned, cancelled (all with relevant attributes). Then there are work log records to add, get, update. Same applies to relationship records. Various attributes of Incident can be updated, so there should be API to update them, i.e. Impact, Urgency, Priority, various categorisations. Then there should be various searches defined, i.e. by Assignee Group, by Status, by Create Date, by ID etc. Finally, there should be an API allowing service targets to be hooked to incidents. And perhaps many more. Same then would need to be available for all other modules including the shared components such as company, people, assignment, approval modules etc. To me it looks like a massive piece of work with the questionable benefit at the end. Just my 2 cents. Jiri Pospisil LCH Clearnet From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: 02 November 2011 14:53 To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** I think the cloud landscape is changing that. Playing in the cloud means working with other cloud based applications or SOA infrastructure. Being a silo in the cloud is going to be a tougher sell than being an easily integrated application in the cloud, at least this is my projection based on what I've observed. http://en.wikipedia.org/wiki/Service-oriented_architecture http://www.salesforce.com/company/news-press/press-releases/2007/05/070521-1.jsp http://blog.programmableweb.com/2007/05/21/salesforcecom-soa-and-web-apis/ If incorporated into the ITSM stack, another benefit is the ability to upgrade components independently of one another instead of having to upgrade an entire stack of applications all at once. On Wed, Nov 2, 2011 at 9:39 AM, LJ LongWing lj.longw...@gmail.commailto:lj.longw...@gmail.com wrote: ** Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could 'mix and match' solutions as you saw fit. This type of approach could have eased the SRM discussion the other day because the user in that situation considered ITSM 'THE' solution...and while BMC I'm sure strives to make that the perception, we that pay attention know there are alternatives to the BMC ITSM Suite, and alternatives to specific modules where others see fit to produce those alternatives... So...while it may benefit the customer...I don't think it benefits BMC for exactly the same reason it benefits the customer. Because of this, I doubt that BMC is likely to move in this direction. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG 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
Re: Request for Comments
A single interface for creating incidents could be defined that optionally allows the use of a template. Use the structure of an XML document as a guide. XML documents have elements and attributes. Elements can be defined as having one, zero or more, etc. The same is true of attributes; they can be optional or required. The interface, if defined as an XML DTD, could have a number of optional elements and attributes. incident group=Support Group1 prority=Urgent tasks task sequence=1 group=Support Group2 /task tasks /incident The elements and attributes that the interface defines could be defined as required, optional, etc. as a DTD allows. This allows 1 interface to create an incident with the information that is available, as long as the prerequisites are met. I do not know that it is necessary to encapsulate all capabilities in the interfaces, just those that need to be exposed to allow other applications to interact with the application in the ways that things need to interact with the application. A single service could be designed to accept either a group name or group id for creating an incident. It would still be a single service. Similarly, a search incident interface would need to be defined, but that could allow 1 or more fields to be searched. You could expose all the fields to search against, that is fine, they do not all have to be required. You use the ones you want when talking to the interface and it parses your request and processes and returns as it should. It would be a massive effort indeed, and it may go nowhere. This is an exploration of how things could be, not where they are or where they are going. Many times, discussing the possibilities is the first step in making a change. Discuss the ideal scenario and take away from it what you can. Will the takeaway be 100% of the ideal scenario, doubtful. Axton Grams On Wed, Nov 2, 2011 at 12:00 PM, Jiri Pospisil jiri.pospi...@lchclearnet.com wrote: ** I believe that if you truly want to encapsulate all the functionality into API calls to allow loose coupling, the API would have to implement all actions that users can perform within the application (and there is many!). ** ** If I take Incident as an example. There should be at least two variations of API call for submitting Incidents. One using template (possibly needing API for searching and defining templates) and the other without template (and potentially more). Then there should be API for assigning Incident to a group or an individual after it was created (with different variations depending on whether you want to use IDs or names etc.). Another type of calls should allow the Incident status to be progressed to in progress, pending, resolved, assigned, cancelled (all with relevant attributes). Then there are work log records to add, get, update. Same applies to relationship records. Various attributes of Incident can be updated, so there should be API to update them, i.e. Impact, Urgency, Priority, various categorisations. Then there should be various searches defined, i.e. by Assignee Group, by Status, by Create Date, by ID etc. Finally, there should be an API allowing service targets to be hooked to incidents. And perhaps many more. ** ** Same then would need to be available for all other modules including the shared components such as company, people, assignment, approval modules etc. ** ** To me it looks like a massive piece of work with the questionable benefit at the end. Just my 2 cents. ** ** Jiri Pospisil LCH Clearnet ** ** ** ** ** ** *From:* Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] *On Behalf Of *Axton *Sent:* 02 November 2011 14:53 *To:* arslist@ARSLIST.ORG *Subject:* Re: Request for Comments ** ** ** I think the cloud landscape is changing that. Playing in the cloud means working with other cloud based applications or SOA infrastructure. Being a silo in the cloud is going to be a tougher sell than being an easily integrated application in the cloud, at least this is my projection based on what I've observed. ** ** http://en.wikipedia.org/wiki/Service-oriented_architecture http://www.salesforce.com/company/news-press/press-releases/2007/05/070521-1.jsp http://blog.programmableweb.com/2007/05/21/salesforcecom-soa-and-web-apis/ If incorporated into the ITSM stack, another benefit is the ability to upgrade components independently of one another instead of having to upgrade an entire stack of applications all at once. On Wed, Nov 2, 2011 at 9:39 AM, LJ LongWing lj.longw...@gmail.com wrote: ** Axton, I agree with a few of the other comments on this subject. I agree that it would be better for the customer for the reasons that you point out that you could ‘mix
Re: Request for Comments
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:arslist@ARSLIST.ORG] On Behalf Of John Sundberg Sent: Wednesday, November 02, 2011 10:38 AM To: arslist@ARSLIST.ORG 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:arslist@ARSLIST.ORG]mailto:[mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG 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
Re: Request for Comments
I guess my thought was that the interface and process will be closely related for some things, and that the interface generally needs to match (or be compatible with) the process in use. If a change in process necessitates a change in the interface, then, by definition, the old interface is no longer compatible with the new process, so it wouldn't be valid to call the old interface as you moved into the new process. However, if we take an incremental (not big bang) transition approach as suggested by John, then that would work with the lifecycle management of the interfaces to transition applications to the new interface over a period of time. I would expect that you would not want to support the last X interface versions, though, since you ultimately would want the interfaces to stayed synched up with the process. That would mean that you would generally only support one version of the interface except during transition periods, where you support 2 versions, but only during the transition period. In some cases, it may be possible to leave the old interface in place while trying to account for the differences between the old and the new one behind the scenes in the system. For example, if you've added new fields, perhaps there are reasonable defaults that could be applied if the old interface was called instead of the new one. Where that is possible, you could then have multiple interfaces for an extended period of time. However, certain process changes may require that only the current version of the interface be used after the transition period. Lyle From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Wednesday, November 02, 2011 10:28 AM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments ** 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 tayl...@ldschurch.orgmailto:tayl...@ldschurch.org 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:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Axton Sent: Tuesday, November 01, 2011 5:59 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG 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
Re: Request for Comments
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 tayl...@ldschurch.org 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: arslist@ARSLIST.ORG] *On Behalf Of *John Sundberg *Sent:* Wednesday, November 02, 2011 10:38 AM *To:* arslist@ARSLIST.ORG *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:arslist@ARSLIST.ORG] * On Behalf Of *Axton *Sent:* Tuesday, November 01, 2011 5:59 PM *To:* arslist@ARSLIST.ORG *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
Re: Request for Comments
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: arslist@ARSLIST.ORG Date: Wed, 2 Nov 2011 10:17:47 -0600 Richard, The point of API interfaces is actually reduced flexibilitynot 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:arslist@ARSLIST.ORG] On Behalf Of Richard Baird Sent: Wednesday, November 02, 2011 9:46 AM To: arslist@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
Re: Request for Comments
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.cawrote: 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: arslist@ARSLIST.ORG Date: Wed, 2 Nov 2011 10:17:47 -0600 Richard, The point of API interfaces is actually reduced flexibilitynot 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
Re: Request for Comments
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: arslist@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: arslist@ARSLIST.ORG Date: Wed, 2 Nov 2011 10:17:47 -0600 Richard, The point of API interfaces is actually reduced flexibilitynot 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
Re: Request for Comments
I see limitations to the form approach that could be counter productive and/or limiting. xml (encapsulated in a web service) provides a richer set of capabilities to describe, store, and validate data. For instance, if one of the services to get a list of things, be it incidents, changes, tasks, etc., a single response could be returned as an xml document. Part of the request could be what to query on, the other part of the request could be what to return. The same for a service like create an incident, it could handle any number of tasks, work info records, related items, etc. that are desired at create time. I don't see an easy or good way to achieve similar results using a form. Again, I would expect this to all be native within AR, a new type of workflow action, if apps are to consume services from one another. Some type of interface where, within the workflow, you could browse the available services (and why stop at just Remedy services) and select the appropriate one and view the definition of the service. This is not so far from the current web service implementation, but a richer set of capabilities would be required. Axton Grams On Wed, Nov 2, 2011 at 2:55 PM, Richard Baird richard_ba...@sympatico.cawrote: 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: arslist@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
Re: Request for Comments
Richard, I'm sorry...I got hung up on the term...I completely agree with you...when I was using API I wasn't specifically talking about C/Java/etc...I was discussing exactly what you were just describingthat to interface with application X, you do a 'call' to the Interfacebe that a Service action or whatever...the point is that the interaction with the application be through that interface, for both integration purposes as well as communication inter-app, so change, SLA, etc and any other app you want to integrate all communicate through that interfaceI think we are all saying the same thing :) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Richard Baird Sent: Wednesday, November 02, 2011 1:21 PM To: arslist@ARSLIST.ORG Subject: Re: Request for Comments 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: arslist@ARSLIST.ORG Date: Wed, 2 Nov 2011 10:17:47 -0600 Richard, The point of API interfaces is actually reduced flexibilitynot 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:arslist@ARSLIST.ORG] On Behalf Of Richard Baird Sent
Re: Request for Comments
Agreed LJ. Axton, the reason I was leaning toward some kind of form solution is that calls to Web Services are (relatively) expensive in performance terms, particularly when the mid-tier is on another system, which it usually is. Not that whatever is designed shouldn't include a Web Service access option, but do we really want every create, lookup, or modify operation between apps within ITSM itself to have that overhead? I would think it would be particularly expensive to access the cmdb info only via web services as that data is constantly being hit. Plus, this type of approach would allow third party ARS based apps to adopt the same model, using the same tools. I was thinking more in terms of some kind of special form definition or perhaps it is a new object of type interface. That way you could publish it for use in something like a Service action model locally and as a web service remotely, but use the same definition to build both, thereby keeping it consistent while avoiding the performance hit of accessing the mid-tier. The Interface type could then connect to multiple back end forms via mappings (similar to joins/web service definitions) to address your complex transaction types, contain the rules and exceptions, etc...all in one place, so the interface is defined once (or maybe once per interface version) and from that single definition, the local (Interface object and associated access method) and remote (Web Service) interfaces are generated. You might even allow filter workflow to run on it when it is accessed. Granted this may be a bit more ambitious, but it would give fast performance locally between apps on the same server/group and consistent local and remote interfaces. Cheers! Subject: Re: Request for Comments From: LJ LongWing lj.longw...@gmail.com Reply-To: arslist@ARSLIST.ORG Date: Wed, 2 Nov 2011 14:23:04 -0600 Richard, I'm sorry...I got hung up on the term...I completely agree with you...when I was using API I wasn't specifically talking about C/Java/etc...I was discussing exactly what you were just describingthat to interface with application X, you do a 'call' to the Interfacebe that a Service action or whatever...the point is that the interaction with the application be through that interface, for both integration purposes as well as communication inter-app, so change, SLA, etc and any other app you want to integrate all communicate through that interfaceI think we are all saying the same thing :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
