Having been a developer for years here are some of my experiences:

1.  Remedy is great for rapid development.  You can't develop an app any faster 
that will offer as much functionality as ars will offer in such a short amount 
of time.
2.  Remedy allows you to make changes on the fly.  (#1 feature in my book ... 
can't do that with custom apps).  It is possible to have the system up very 
close to 24*7 even when making changes.  Some changes do require the users to 
be locked out ... but usually it isn't very long.
3.  Remedy/BMC has solved a lot of difficult problems already for you (Users in 
multiple time zones seeing their correct time, Business time calculations, 
SLAs, notifications, ITSM suite, integrations with auto discovery/alarm 
systems, migrations from one environment to another).
4.  Debugging is going to be offered in version 7.5 if I understand right.
5.  High Availability using Server Group.
6.  Multiple API interfaces.
7.  Per User custom table field settings is really a cool feature.
8.  Data driven functionality in ITSM 7.  Pretty cool.
9.  AIE is awesome.

Some issues I have run into with Remedy:

1.  Custom apps will always run faster.  Especially when doing mass updates.  
When doing a "Modify All" in remedy it updates one record at a time because it 
has to do the filter processing.  Even on a "Push field" action.

2.  Databases are difficult to report against and are confusing to a reporting 
person.  This is mainly due to the "ztmp" fields and such that aren't necessary 
for the data but are necessary for workflow.
                        -- Another caveat to this is I find (myself included) 
that the naming of fields gets kind of lazy w/ Remedy developers.

3.  Data isn't normalized in Remedy development.  I know it can be done ... but 
generating workflow to do it is rather difficult sometimes.  Here's a good 
example ... I add a field to a "Client" form that stores "Client Type".  Rather 
than having a separate form that stores V for Vendor, C for Client etc,  We as 
remedy developers store the entire word.  This is so the type can show up in 
the "Results List".  We could use a filter that sets the field on "Get Entry" 
... but then it doesn't show up in the results list.  So now we have already 
built our form and discover that it needs to be a join form between "Client 
Type" and "Client".  This gets really difficult if you have 15 fields like that 
.... ( a join between 15 tables???  that would be about 16 remedy join forms 
you would have to create for one "Client" entity).

4.  Graphics are next to impossible to do in Remedy unless you are a 
java/jsp/html developer.  I can see my manager saying "I see there is a 
calendar view in ITSM for change tasks ... can you make me a calendar view for 
tracking Hours worked just like that?".  This couldn't be done using Remedy 
workflow.  Maybe it could be done w/ some fancy java and or javascript ...   
While I am on this it would be difficult to have a Cad drawing of your 
datacenter, double click on a "Rack" and see all of the computers in the rack 
which interact with the cmdb.  This can be done via data visualization modules 
... but it isn't as easy as creating an active link or filter.

5.  Distinct selects ... although the Tree view does solve this a little bit.

6.  Active links do not have an "On key press" event.  It doesn't have an "On 
change flag" event either.

7.  Can't do transactional saves.  For example I have an object like "Client" 
which has "Customers" and "Sites" that I added upon creation.  Let's say I 
decided not to do create a "Client".  I can't do a "Roll back" of all of the 
sites/customers that I added to the client without some significant amount of 
workflow.  Not saying it can't be done ... just saying it is a lot more 
difficult than just calling a "Roll Back" command.

8.  Complex views have to be created at the db level and cannot be created via 
the Admin tool.  This could solve issue # 6 and #3 if they build this into the 
tool.

9.  Why the heck do they mix C and java at the server level for Remedy??  Why 
not program the whole thing in C or the whole thing in Java.  Stop mixing the 
two -- I really hate that.  It's like looking at a drawing using colored 
pencils and magic markers.  It would be nice if the server was just written in 
Java.  Then we would probably get better support.  One code set instead of one 
code set per OS.

10.  Poor email engine/notification performance.  It would be nice if they 
would tightly integrate Alarm Point w/ Remedy.  It integrates but with quite a 
bit of work.

11.  Every form still must have an "Assigned To" field and a "Summary" field 
even though these fields aren't used half of the time.

12.  Upgrading Remedy from one version to the next is a nightmare!! Especially 
for ITSM stuff.  If you use the word "Rollback the db" after a failed itsm 
install ... managers get angry.
ARS upgrades aren't that bad but can be.  Support always require you to be on 
the latest release when it can takes 2 to 3 weeks to months just 
install/test/migrate all of your environments to patch x.  By the time you 
finish patch x+2 is out.  I would love for support to have fewer releases and 
more QA!!!!

13.  Figuring out hard crashes in the remedy system is difficult.  First of all 
... you have no clue what caused it.  Was it workflow? was it CMDB? a plugin? 
Reporting? aremail?  If you do have a hard crash in production you have logging 
turned off so users can have the best performance.  Then you turn logging on to 
try to trace the issue and support asked for the logs.  You wait.  Sometimes 
days to see the issue happen again.  It happens again.  You send logs to remedy 
and guess what?  They ask for more logs.  You then get those only to get the 
response "Please upgrade to the next version."!????  See #12.

14.  Admin tool is really slow.  Especially when saving an active link or 
filter when you have ITSM installed.  Maybe version 7.5 fixes that.  I am 
currently on 7.0.1 patch 6.

15.  Can't do multi-select in a tree view.  (We are on 7.0.1 so maybe a later 
version supports it).

16.  I don't know about anyone else but "Related Workflow" has never worked for 
me in version 7.  It will go part of the way and never finish.  We were given a 
dll that supposedly fixes it but had no luck.

17.  It would really be nice if Remedy had a "Counter" widget that did a count 
in real time.  "24 minutes till the vp is giving you the pink slip ... 23 
...22...21... whew you resolved the issue you are saved for now"!!!

18.  Expensive

19.  CMDB has a lot of redundant data w/ ITSM.  "AST:Organization" and 
"Company".  "AST:Person" and "CTM:People".

20.  It would be nice if BMC would give you Remedy preinstalled with 
everything.  You simply license the stuff you want.  (I think this is available 
somewhere).


I am not saying all of these things to bash ARS.  I love ARS as a tool and feel 
that it provides a lot of value.  I feel that by sharing them maybe there are 
some things of value that BMC could address in future releases.

Thanks,

Sean


-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Pierson, Shawn
Sent: Thursday, July 24, 2008 9:00 AM
To: arslist@ARSLIST.ORG
Subject: Pros and Cons of ARS development - was Buy vs. Build

I want to change the topic slightly and go off on a tangent that keeps coming 
up repeatedly.  That topic is of the power of ARS for development.

While I agree that ARS is great, I would have to qualify that to say that if 
you want to build an application that is within its capabilities, it is great.  
However, having worked with Visual Basic, PHP, Perl, and a few other things, I 
see plenty of limitations in ARS as a development tool.

For example, there is no such thing as a variable in ARS.  Yes, you can add a 
field to a form, even a Display Only field, but you can't instantiate fields 
during runtime on the fly.  You have to purposely create fields for usage later 
on, and this limitation causes us to often re-use certain fields as generic 
variables, which can make troubleshooting difficult sometimes.  I've worked on 
a system that someone else built that I had to troubleshoot something on a 
field that had many different Set Fields actions occurring at different points 
with different tables.  It was definitely possible, but since ARS is missing 
another major capability that most development platforms have.

ARS doesn't have a way to step through code.  We can't start up processing on a 
form, and pause it to see what is going on.  All we can do is 1) go through log 
files and recreate the workflow in our minds, or 2) pop up messages after each 
piece of workflow we want to troubleshoot.  If there was a way to step through 
each piece of workflow that is running, that would be a tremendous help to us.

Another issue that is more of a matter of taste I guess, is the inability to 
generate flat source-code.  Yes, I have learned to read .def files to some 
extent, but it should be easier to read.  Instead of values like " 
4\1\1\179\2\4\32\Change Level IA - Implementation\" in workflow, the definition 
files should display what we see in the Admin tool.

These are the somewhat major problems I have with ARS for development.  If you 
want to build an application with a database back end, a web interface, and 
have most of the standard controls (save, search, displaying tables, etc) just 
work automatically, ARS is a great too.  There isn't anything out there that 
I've worked with which can top ARS development in terms of speed.  In some 
cases, you do have to make sacrifices for more complex functionality, but it's 
still a great development platform for what it does.  I just wish BMC would 
change the things I mentioned above, plus a few other minor ones (I'd like to 
be able to use arrays if they implement variables, I'd like to be able to have 
workflow triggered off of typing in specific fields, not just pressing enter 
and gain/lose focus, etc.)

What are your thoughts about the pros and cons of ARS as a development tool?  
Perhaps we can put all of our heads together and go back to BMC and tell them 
what we want, plus come up with enough positive things about it to show our 
clients and employers that ARS is a great development tool.

Shawn Pierson

Private and confidential as detailed here: 
http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the 
link, please e-mail sender.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to