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 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 different physical servers/databases) that leverage only the
> interfaces the applications provide as a means of communication****
>
> ****
>
> Such a change to the current paradigm would open the doors to a lot of
> things that are simply not feasible at this time, all of which start with
> better interoperability. This is something that is important in the cloud
> space. A proper implementation of the above ideas would lead an
> application that is easily pluggable into a SOA backbone so that the
> services the applications provide can be used by any other application that
> is able to reach out to the SOA backbone.****
>
> ****
>
> I think that running each application within ITSM on separate servers
> would be a good gauge of an effective implementation of this paradigm.****
>
> ****
>
> I look forward to your thoughts.****
>
> ****
>
> Regards,****
>
> Axton Grams****
>
> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ****
>
> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_****
>
> ** **
>
> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ****
>
>
> *************************************************************************************************
>
>
>
> This email is intended for the named recipient(s) only. Its contents are
> confidential and may only be retained by the named recipient(s) and may
> only be copied or disclosed with the consent of LCH.Clearnet Limited and/or
> LCH.Clearnet SA. If you are not an intended recipient please delete this
> e-mail and notify postmas...@lchclearnet.com.
>
> LCH.Clearnet Limited, LCH.Clearnet SA and each other member of the
> LCH.Clearnet Group accept no liability, including liability for negligence,
> in respect of any statement in this email.
>
> The contents of this email are subject to contract in all cases, and
> LCH.Clearnet Limited and/or LCH.Clearnet SA makes no contractual commitment
> save where confirmed by hard copy.
>
> Cet e-mail et toutes les pièces jointes (ci-après le "message") sont
> confidentiels et établis à l'intention exclusive de ses destinataires.
> Toute utilisation de ce message non conforme à sa destination, toute
> diffusion ou toute publication, est interdite, sauf autorisation expresse
> de LCH.Clearnet Limited et/ou LCH.Clearnet SA. Si ce message vous a été
> adressé par erreur, merci de le détruire et d'en avertir immédiatement
> postmas...@lchclearnet.com.
>
> LCH.Clearnet Limited, LCH.Clearnet SA et les autres entités du groupe
> LCH.Clearnet Group, ne peuvent en aucun cas être tenues responsables au
> titre de ce message à moins qu’il n’ait fait l’objet d’un contrat signé.
>
> LCH.Clearnet Limited, Registered Office: Aldgate House, 33 Aldgate High
> Street, London EC3N 1EA. Recognised as a Clearing House under the Financial
> Services & Markets Act 2000. Reg in England No.25932
>
> Telephone: +44 20 7426 7000 Internet: http://www.lchclearnet.com
>
> LCH.Clearnet SA, Siège Social, 18 rue du Quatre Septembre, 75002 Paris,
> Chambre de Compensation conformément au Code Monétaire et Financier.
>
>
>
>
> *************************************************************************************************
>
>
> _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"
