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 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"_ -- John David Sundberg 235 East 6th Street, Suite 400B St. Paul, MN 55101 (651) 556-0930-work (651) 247-6766-cell (651) 695-8577-fax john.sundb...@kineticdata.com _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
