Video Screencast Help
Endpoint Management Community Blog

To Customize or not to Customize - that is the Question!

From both inside and outside - how to make the product work for you and STILL get good support!
Created: 17 Apr 2014 • Updated: 18 Apr 2014
Thomas Baird's picture
0 0 Votes
Login to vote

Should we customize our solutions to better fit our needs?

I've worked both sides of this coin in all three of the common positions related to product use: support, consulting, administration.  Having JUST come off the support end, I have a unique perspective many customers don't see.  For instance, I was the LAST line of defence for a customer, worked directly with Develpment and had their view-points, and worked with Sales, Marketing, Product Management, and Management to see their perspectives.

On the flip side, I've been an admin and a consultant, and I understand the very real need to make things fit YOUR environment.  I'm back to consulting now with a partner: XCEND, so does my story change from when I was in support only a month ago?


Why not?  because after years of practice, I found a practical approach that most if not all can live with.  It works, and I'd like to share it with you.

Why you should avoid Customizations

I'm assuming that most reading this already know the benefits, so we'll avoid that subject in this discussion. Suffice it to say, there are valid reasons to customize something.

So, let's talk about the real cost of customizing a solution.  First is the cost of doing so.  Who gets to maintain it?  Who documents it?  Who takes the blame if something doesn't work?  Who takes the time up-front to make the changes, only to then be saddled with the costs just mentioned?  That's right - it's you.  OK - so maybe your consultant friends did it for you, but are they always around if something goes wrong?

I like to believe XCEND is a very responsible company.  We have very solid long-term relationships with our clients and are frequently called back for repeat business.  But let's face it - when we're done with your site, there are other customers that need help.  We don't just sit around waiting for your call with no schedules in case something goes wrong.

We'll always be there, but who gets hit first?  You.  If you're lucky, you know exactly what to do.  If you're lucky, we'll be there to respond on short notice.

But what if you're not so lucky?  Well, you can't call Symantec about it!  What will they do?  Generally, tell you it's unsuppported.  Yeah, well THAT helped!

There are however other costs, even if you ARE lucky (Hey, all XCEND customers are lucky - right?).

  1. On upgrades, most of the default items in the product are simply replaced with new.  If you've modified anything out-of-the-box, there's a good chance of it simply being GONE after upgrade.
  2. Support and Development at Symantec often simply say "denied!" to supporting anything that is not standard out-of-the-box fair.  They figure, appropriately, "hey, who knows what you did to it that may have broken something?"  There ARE ways around this - discussed below.
  3. Confusion on the part of others that come and look at your customizations.
  4. Lack of a Baseline to test against if you modify things that were "out of the box"
  5. Missing or misunderstanding of default features and the improvements those features get.
  6. Lowered feedback to the company of how to improve the products.

Anyone reading these items above will realize quickly that not all of them apply to YOU, and some you may frankly not even care about.  But you should look a little closer before dismissing them.  As a Backline Engineer at Symantec, I ran into each of these at some point or another.  Otherwise, I'd not be thinking about them, since other than this document, I can't think of any "To do, or not to do" docs on this.  Let me speak to a few of them briefly:

  1. It's funny how we will get a call on this one.  Someone calls in saying a collection is no longer working, we compare with ours, and it's just fine, has results... they look at it and say "but but - the query is all wrong!" and yup - sure 'nuff, they had customized it and upgraded.  Do you KNOW all the things you changed? There's a right-way and a wrong-way to do so - discussed below.
  2. I hear this ALL the time.  And more.  I was one of the FEW who would handle customized environments, only because it was fun and I really wanted my customers to be happy.  But it's written right there in the docs -  you modify it, you're out of support.  Sort of.  Again, we'll discuss this later.  :D
  3. Oh my - I can not tell you how often I see this.  Both from support engineers who look at something and go "wha- huh?" or from Admins who say "well, I dunno - I just sort of had this project thrown at me after so-and-so left..."  All the time!
  4. This is harder to measure, but it happens.  Your custom collection isn't working.  Is it your collection?  Or are the default ones also not working?  What default ones?  Yeah - problem here.  Again, there is a way around this.
  5. Recently we ran into this in Deployment Solution.  DS 7.0/7.1 had a really limited DA process.  So everyone built their own custom one.  The DA process was updated to work really well - no one knew.  Why?  Everyone was using their custom one!  Yes, it was Symantec's fault for not having a better method to begin with, but IMO - it's the client's responsibility to keep up with improvements if you deviate from the "norm" in a product as well.
  6. REALLY hard to measure, but no one complains about a feature no one uses, right?  Symantec's fault here, in some cases, but it's still valid.  If you feel a need to customize, may I recommend you FIRST let us know why, so PM can respond?

Yeah, but I NEED a custom solution!

All right, to be fair, let's talk a bit about REALITY.  I get it.  I did even when I was in support, which is why I helped several of you even with custom solutions.  Now I'm a consultant and paid for it.  I really get it.  There are times you just have to do something different.  There are several reasons:

  1. A bug you have to work around until it's fixed.
  2. A product limitation
  3. Custom needs you have that are unique in the industry - do you really think they should add that - just for you??
  4. Integration with other aspects of your business / software.

I'm sure you all could come up with more.

Recommended Methods of customizing a product.

Specifically, I'll be speaking to the Symantec Management Platform underwhich this is posted, but the concepts may carry to other products as well.

NOTE: In this discussion, I'm not talking about a "custom" task or "custom" software delivery product - the product is designed to handle that and you already know you support your own software.  I'm speaking specifically about modifying how the product works "out of the box" to fit your needs.

  1. Use clones.
  2. Leave what is there in-tact as far as possible (be creative)
  3. Use the built-in infrastructure as much as possible even with your custom solutions
  4. Find ways to quickly back-out if necessary
  5. Have a test system that is NOT modified
  6. Test your changes in a lab FIRST
  7. When calling support, be VERY cautious about asking about your custom solutions.

I'd like now to simply explain each.

1. Use Clones.

In the SMP, you can clone almost everything.  If you find a report you like but it needs to be modiifed - don't change it, clone it and change the copy.  MUCH better. For policies, this is even more important.  You WANT all the default policies still in tact or weird things might happen.  Trust me on this - clone things that came out of the box rather than modifying them.  If possible.

2. Leave what is there in-tact as far as possible

Relating to #1 above, but there's more.  As you make your changes, be careful not to shuffle things around too much.  Make your own custom menus if you must, or whatever, to provide links back to what was there instead of moving things around and changing everything.

Look, if you die one day and someone has to suddenly take over, if they know the "generic" product, they can at least get around, right?  THEN they can warm up to your customizations.  More important, if you call support and they can't find anything, don't you think they'll be even MORE likely to throw in the towl and call the "It's not supported" trump card?  Uh - Yup.  Don't give them any more tools to deny you than they already have.

1a, 2a  Remember that for BOTH of the above points, every upgrade will reset the "default stuff" so leaving that "stuff" alone is by FAR in your best interest.  Just repeat to yourself: "Must Clone... Must Clone!"

3. Use the Built-in Infrastructure as much as possible, even with your custom solutions.

This came up just the other day in a forum thread.  Someone needed a custom DS solution and was going to build an HTA to deliver it.  Great.  Someone else though (not me this time - RATS) suggested that they use a built-in menu from DS to CALL their HTA, removing a good portion of the logic they'd need, ensuring security out-of-the-box, and well, generally, making good use of the product.  Brilliant!

4. Find ways to quickly back out if necessary.

This is for your own good as well as "supportability".  I had one customer who was denied support (I was their RPS) and I took a look at the situation and felt it was NOT their customizations that was the problem.  Luckily I knew the product well, we quickly moved their customizations, shuffled things around just a bit to use only the "default" stuff, and voila - got support, and eventually a fix.  Frustrated me to have to do that, but don't you think it was worth-it to get an answer?

5. Have a test system that is NOT modified

This sort of depends on how much you have to change, but think about it like a Developer who is modifying the code for the next major release.  You have to KNOW what the previous release did to compare against the new, right?  That's what your unmodified version is for you - a baseline you can refer back to if you get ... mixed up.

6. Test your changes in a lab first.

Face it, no one gets things right first time.  Do you really want your mistakes to be in production first?  What if you can't back out?  Wouldn't it be best to have production nice and safe and generic while you go blow up the lab?  I think so...  Plus it gives you a reference point when you're working in Production to look back to if things did NOT work as expected!

7. When calling support, be VERY cautious about asking about your custom solutions.

Try to ask about things that are NOT custom.  I'll give an example.  Let's say you have a script that calls one of your company's custom apps to modify the registry.  No, I have no idea if someone does this or not, but let's just "say".  You call in and say "my registry tool isn't working because the task is failing."

Really?  You want "ME" to fix "Your" solution?  Right.

Now, that's not what you meant.  What you meant is that your solution works, but something in the task is not.  Fine.  Proove it.  Pull your app out of the picture and see if other things fail too.  That's what I'd do if I received your call.  Do so first.  If you whittle things down to isolate your app, you'll get better and faster support.  It's called smart calling.  :D  It works too.  I've used it on both ends of the phone.

Wrapping it up

Everyone will need to do something "out of the box" at some point in time with a product.  The Symantec Management Platform is one product all but PRIMED for this, but there are still limitations to what it will do, should do, and especially what can be supported.  Making SMART choices about your customizations will make a difference for you.  Oh, and for your support!  :D

Happy Customizations!