BMC uses BMC solutions to run IT.

Since the acquisition of Remedy by BMC, the BMC IT department has used the 
Remedy
solution for running the people process portion of the IT environment.  Beyond
Remedy, the BMC IT department uses all the BMC products for the running of 
internal
IT.

The IT team is customer 0 for new releases.  They are generally up and running 
(at
least are in test if they are not already running) with new releases before they
are released to customers.  They provide some key feedback on the product to the
development team.

Across all BMC products, you will find them running internally and being used to
drive the business.

SRM has been in use for going on three years now.  It is the one stop place for
asking for ANYTHING that an employee wants within BMC.  Whether it be an IT 
request
or an HR or Finance or Facilities or anything request.  All of that is driven 
from
a single request catalog using SRM.  All areas of the company use Incident
Management and Change Management to drive those aspects of their business.  
ADDM is
used for discovery, BPPM for monitoring, Server/Network Automation for updating.

As has been noted, the IT team regularly shows customers and prospects our 
internal
operations using BMC solutions.



As for the performance and scale, my points are absolutely still true.

You can take any specific feature and say that you wish it was faster -- so do I
by the way.  But the topic isn't just startup time (the one observation made).  
It
is about interactive performance and the ability to scale to large numbers of 
users.

With FULL PROCESS, we get good interactive performance across the WAN.  Even 
when
compared to "process lite" solutions that just take data typed on a screen and 
store
it with no process flow, we compare well with current releases.

>From a scale perspective, we scale to 1000s of concurrent users.  We have a 
>customer
up and running (and has been for over 7 years) with 10,000 -- yes, ten thousand 
--
concurrent users on a daily basis.  And this is not the only large environment, 
we
have a number of customers north of 4,000 concurrent users.

We have features like server groups that allow you to scale out for load and 
balance
and isolate interactive vs. programmatic load.  This also provides significant
reliability/availability in the environment by eliminating single points of 
failure.

I could continue on with this topic for hours with what is actually happening in
the real world with customers and with product capabilities around the area of
scale and performance.

Can someone always find some point issue where there could be better 
performance --
absolutely.  And, we continue to work on those areas (for example, startup time
with correctly configured system using startup threads that were introduced a
couple of releases ago start up dramatically faster than systems who are not 
using
that feature -- just to name one thing) and introduce improvements and fixes 
across
releases.

And, with performance, there is ALWAYS something that is the long pole and needs
work because no matter how fast or efficient you make things, something is 
always
the slowest or least efficient part of the mix.  The key is whether there is the
continuing focus on improvements in those areas and continual improvement -- 
even
when the result is good, it can be better.


I hope this helps,

Doug Mueller

-----Original Message-----
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of John Baker
Sent: Thursday, July 05, 2012 2:49 AM
To: arslist@ARSLIST.ORG
Subject: BMC Remedy ITSM Vs Service Now

Tauf,

Do BMC use BMC ITSM or customised AR System applications internally?

Doug,

I don't believe your points about performance are still true. It's clear
that when you were running the show, there was a great emphasis on
performance/scalability, but that is no longer the case. 

When we're performing a webex SSO Plugin install, we're always asked how
long it takes: we make the point that it's a quick process (ie 20
minutes), but waiting for AR System to restart is increasingly the
longest part of the process. And then Mid Tier restarts and locks up as
it caches workflow that should be stored on disc as JS files. Perhaps
this is fixed in ITSM 8 :) 


John

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.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"

Reply via email to