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
**
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"_
_attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
--
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
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 www.kineticdata.com
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
