Hello Everyone,
Well, after nearly 23 years with first CA and then Broadcom, it has come time to say "Farewell" - at least for now.
The Communities and people in it have represented an important part of my time here, so I'd just like to acknowledge everyone who has been part of that. There are too many names and I might leave some important people out if I attempted to name everyone, so I'll just say "Thanks." Suffice to say though, the people and the contributions in these Communities have been outstanding. The depth of knowledge and willingness to share has been second-to-none - and I say that as someone who has experienced a great many communities, in both a user and admin. capacity.
A quick walk down memory lane in the Service Management space.
I started with Service Management when it was marketed as "Advanced Help Desk 4.0" - or AHD. This ran full Java clients on Windows 3.1, with the most popular server being a chunky Solaris box and Oracle or Ingres database. There was a very basic web interface for those on the cutting edge of technology.
Even in those early days, this was a rebuild of the "Paradigm Help Desk," back in one of "CA Technologies" (as it was called then) acquisitions - from a University if my memory is correct.
Astute observers will note that the terms "AHD" and "paradigm" live on in the underlying file structures. A little like archaeology, you can date the age of layers of code for when they may have been first introduced - although they may have been rewritten from the ground up several times over by now. For example, "AHD.dll" file is one of the oldest ways of getting data into Service Management, and the name suggests (correctly) that this has been one earliest features, carried over from the AHD 4.0 days.
Similarly "pdm_d_manager" refers to "Paradigm daemon manager." If you didn't know why "pdm" cropped up in the utility names so often (pdm_load, pdm_k_reindex, pdm_backup), now you do.
There followed a host of name changes - Service IT, Service IT for Workgroups, Unicenter Service Desk - before it stabilised around Service Desk Manager. At this point, uptake of the internet had reached the mass market, and a full featured web client became the base delivery model.
This was perhaps the "golden age" of Service Desk, as there was a robust product which was routinely in the top right quadrant of the "Magic Quadrant." It had cutting edge features for businesses, backed up by solid technology, with several features which differentiated it from the competition:
* Out of the box robust "Service Desk" business functionality
* Yet was highly customisable (screens, files, code, images)
* A wide range of integration points (mail, DLLs, data loads, direct integration to many CA and other products)
* On solid "standard" infrastructure, yet also could run on many different configurations
* Multi-lingual support
* ITIL compliance before it was fashionable
Time marches on, and a host of new functionality (SaaS, new web interfaces, encryption etc) and technology updates have been added, to bring us to the current point. Older technology has been retired.
Anyway, after fielding countless support calls from the routine to the emergencies, writing knowledge documents and updating documentation, to my time on Communities, it's time to shelve the manuals for the time being.
If I were to leave any advice, it would be this:* Read the documentation.
Many problems are avoided by this step, and many problems resolved by completing it.
* Documentation is usually correct as read
precisely, even if it is not clearly understandable on the first pass.
* Find the experts. Someone who can bring deep knowledge to an issue is worth a stack of documentation.
* Get as many eyes on a complex issue as you can. Different fields (eg DBA, network, application specialist etc) have different insights which are worth having, even when applied outside of their direct field of expertise.
* Have a test system.
No, seriously, do this one. Hardware is "cheap" now. There is little excuse for launching a change to enterprise software without "checking the plug" as it were.
* Virtual systems are great for quick tests and rollbacks. They're just great.
* Genuinely "intermittent" problems where most "normal" causes have been eliminated can be hardware in origin. Trace tools are your friends in these cases. These cases are very rare, but the hallmark is that they are "bizarre."
* Always have a rollback plan.
* Make sure your "restore" functionality actually works.
There's probably a lot more that I - or you - could add to this list. However, if you manage to tick off as many of those as you can, you'll hopefully avoid the full-on catastrophes.
I'll be around for a few more days yet. I'll try to retain access to my "Kyle_R" account here if possible.
Other than that though, my plan is to take a break - the first long one in many decades. I am very much looking forward to that!Bye for now,
Kyle_R.