I don't really have the time for this, but let me jump into the fray with a few somewhat related but disparate points of my own...
First, with regard to the "bad resources" issue, I've been seeing pattern for years. On three separate occasions in my career as a Remedy Developer contractor, I've been brought in by clients who had a custom Remedy application which were in varying degrees of being train wrecks. The types of problems included extremely poor data architecture, hundreds of forms and many with no use (and names such as "Test" *in production*), thousands of workflow objects with no use and no useful naming conventions, escalations spinning out of control, etc. In two cases I was able to "tame" the systems, but in one case it was so bad I outright refused to even try (I suggested they either find another resource or allow me to build a new system from scratch..fortunately they chose the latter). I came to realize that there were two main factors that had enabled these situations. First, the fact that the Remedy ARS system makes it so easy to perform development operations - create forms, create workflow that does useful things, etc. - that many people who have no business architecting and developing applications where doing just that. In candid conversations with clients, I've describe this situation by saying that "any idiot can develop in Remedy, and unfortunately many of them do". This was compound by second factor, which is (was) the confusion Remedy themselves created in the early days by collapsing the notions of "administrator" and "developer". When I was originally taught to use Remedy, the topics about how to install & configure Remedy were taught right along side the topics about how to create forms and workflow. The documentation largely followed suit. In fact it's only relatively recently that the main development tool actually has the word "develop" in its name and is *not *the (BMC) Remedy *Administrator*. So these Remedy administrators - people who perhaps had the background to understand and been taught to perform actual administrative tasks - were then asked to implement changes to the system because, in everyone's mind, the notion of "Remedy administration" naturally extended to performing such changes. These people then go on to create a few forms and some workflow successfully. They created their Customer form and they created their Inventory form and some workflow around all of this. And, at first, everyone's happy because they were able to get this done so quickly. Time goes on and they're repeatedly asked to extend the system, and for a while everyone remains happy. What happens next (which is what happened in each of those three "train wreck" systems I've described) is that at some point the system grows beyond the "developer's" ability to manage. In my experience it seems to happen somewhere around a few tens of forms and perhaps a few hundred logic objects. In all cases by the time I was brought in the original developers were gone, but my own forensic analysis of those systems suggested to me that at this point in the growth of the application the original developer was no longer able to fully comprehend what was going on. Before this point they were able to keep it all in there head and knew where to find things, but at this point the system just became too large for this approach, and their lack of skill and coding discipline (e.g. good naming conventions) meant they had no other recourse. Problems (bugs) would occur but the developer was unable to debug the problem. And instead of identifying and correcting the root cause (which in many cases were due to fundamental problems with the data architecture), the developer would add a "patch" to fix the problem: e.g. the client expected the result to be 100, so they add a filter to set it to 100 at the end. So instead of *reducing *the problem set, these developers actually expanded it. This pattern would continue for a while until the momentum of the system eventually ground to a halt, leaving a barely functioning system on which no one present could implement any changes for fear of making it worse and the client complaining loudly that none of their changes, even simple ones, were not being done. I've only been occasionally or peripherally involved with the canned apps - what's ITSM now, and what were the component apps (e.g. Help Desk) a long time ago - but from what I've seen the pattern there was similar: people with administrator level skills at best were asked to implement changes, and for the same reasons eventually reducing the system to being unchangeable and largely unusable. And the nearly indelible feeling that everyone - the users and management understandably, and even some of these so-called "developers" (not so understandably) - takes away from this experience is that "Remedy sucks". Does this sound familiar? It's all really unfortunately because the problem of course has nothing to do with the core workflow engine itself. And while I, as a long time developer of this system, have a long laundry list of complaints about it from the development perspective (why can't I get my integer table columns to left justify?!?), it really is an amazing system on which you can build amazing applications. And this is a reasonable segue into my next (disparate) point... It's my own fault that I've only recently resubscribed to ARSLIST and now have been really trying to join the conversation (I've only infrequently and briefly joined in the past) , but why does it seem that ITSM is the only application anyone is interested in? I ask this question rhetorically - people are interested in what they are interested in, and of course ITSM is the big app being pushed by BMC. But I'm still amazed that seemingly 75% of the postings are directly or peripherally about ITSM, with another 20% (or so) having to do with system configuration and how to integrate with other third-party systems. Here we have a system capable of building *any *database application, and yet ITSM dominates the conversation. I'm more interested in core development topics and doing interesting things with forms, workflow, UI, API programming, etc and seems that only the remaining 5% (or so) of the postings have anything to do with these topics. It's becoming increasingly clear from all this that custom application development using Remedy is dying (other posters have mentioned this recently too). It does seem to me that BMC is only really interested in selling ITSM, when you'd think they'd also be doing all they can to broaden the base of customers using ARS itself. I do agree with a few other posters that BMC could do a hell of a lot more to change all this. For one thing, and as others have mentioned, make the education on the system more readily available. What is it now, like $500/hour for their WBT? *For web based training?!? Are you $%^#* kidding me?!? * As an independent contractor, it's hard for me to foot the cost of this, much less the instructor led courses. Another thing they could do is give away developer copies of ARS. Yes, I said *give it away*. When I'm not working for a client (or made other arrangements), I have no access to a fully functioning ARS server. During such off times between clients, I'd *like *to do development work on my own applications with an eye toward possible future sales, but I can't afford to purchase and maintain a server license, so I'm effectively shut down. It's stupid, because interest in any applications I might create might convince potential customers to buy ARS. In an effort to ensure a solid following of their products, companies like Microsoft and Oracle practically give away development copies of their software. Oracle does, outright, give it away: promise that you won't use it for production purposes and you can download anything you want from their web site. And for $50<http://www.amazon.com/SQL-Server-Developer-Edition-2012/dp/B007RFXQAM/ref=sr_1_1?s=software&ie=UTF8&qid=1394561889&sr=1-1&keywords=sql+server+2012> you can buy a developer license to MS SQL Server which is pretty much functionally equivalent to their enterprise edition. Both companies provide tons of online documentation, tutorials, WBT, etc. *for free*. Why can't BMC adopt such a model? I have to believe that their bean counters tell them that it'll be a negative ROI, but that doesn't seem to be the case with MS & Oracle. Anyway, enough rambling & back to work. -charlie On Tue, Mar 11, 2014 at 8:31 AM, James Smith <bmcremedyarslis...@gmail.com>wrote: > I agree. Bad resources lead to the failure of projects. > > I got some link which shows pitfalls in service now > > > http://seekingalpha.com/article/1111961-after-interviewing-more-industry-insiders-i-am-even-more-bearish-on-servicenow > > Worth reading > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
