I'm in an interesting quandary.

we have some internal CRM systems I work on and write code for.
A need has come up, which is pretty natural, for demo accounts in the CRM so sales can do demos.

However the PHB wants me to duplicate our entire CRM chain (databases, portal, ticketing system, licensing system etc etc etc), just for demos, when a few tweaks would enable the current system to handle demo accounts (and get rid of them) pretty cleanly. I can adjust things so the sales guys only see demo accts and the rest of the company only sees paying customers, or any possible permutation. I can just add a new enum field to the accts tables (ENUM DEMO|PROD), group, new bitmask, some SQL filters and BAM done.

Last year I integrated LDAP and added bitmask user/group security so controlling things like this is incredibly fine grained. The whole reason I did this was because I knew requirements like this would come up. If I'm adding security to something, I'm doing it right.

This essentially nullifies all the work I did in this regard, and is a pretty ass backwards way to approach this solution. It's downright retarded.

For some reason they want the demo data _and_ hosts/code base completely separate from the paying customers, yet if there's a conversion, they want all of it copied over from the demo system. The system is to be duplicated exactly.

This system is a fairly large integration of 5 very complex systems. Duplicating it would, without any uncertainty, double my patch load as well as my stress. I don't know about you, but dealing with two of these setups, plus the difficult to deal with sales guys would be a little too much for me to handle.

The PHB will not budge. I like my job, I really do, but where do you draw the line with stupidity and consider finding new employment?

I have 3 choices, none are very palatable.
Do I:
a. tweak the existing system, throw a new vhost with different name pointed at the same directory, and do it the right way, keeping my life sane but risk getting caught.
b. do what I'm told
c. find a new job

I've tried talking to them til I'm blue in the face, explaining how things work from every angle, but they just don't get it.

Up til now, this has been a great place to work, but I'd like to get to go home once in a while and I really hate to essentially throw the Really Smart Things(tm) I've done with this system into the chipper.

Maybe I'm the one that's being unreasonable. Give me a sanity check.

-Viz

Not an easy position to be in. I can quote many examples of people doing what they were told and then getting flak when things did not work.

Your course of action depends--in some degree-- on how secure you feel in your job and/or your "mobility"--ie. your prospects for other employment.

First, have you calmly explained to your immediate supervisor (is that the PHB?) that you are uncomfortable following the exact directions? Don't make this a debate about specifics---the idea is to communicate that you feel you need to be part of the decision process. If you can't have this conversation, then start updating your resume.

If you go down the road of following their direction, make sure that your concerns are documented.

A later conversation with your boss might occur when you have in hand a job offer from someone else. Don't make this confrontational--simply explain your concerns, tell them you would really like to stay, but that you will have to be more part of the process. (Tell them that you have the other offer.)

I'd make sure they have some sane reasons for that.

I would suggest you find out their reasons for wanting it done that particular way, because to stand a chance changing things you have to understand the other party. If you can you might be able to use their reasoning to your advantage, confront them in their own territory. But maybe there is more to this story than just the facts? Maybe you already feel ill-rewarded and the stuff you do not getting the recognition it deserves? Already testing the waters? If confrontations are not your style or if you can't open comms then I fully agree with what Pixellany said.


* From my POV keeping demo data and data of paying customers strictly separated is nothing more than common sense. You only have to look up security news to see what the risks are. Any solution that, regardless of the reasons, mixes both data sets is IMNSHO not the qualitatively best solution one would want to be forced to support.

thx for the input. I needed some outside opinions on this. I'll check back on this thread.
good advice...

I am just horribly unprepared for this situation because I've never been in one quite like it before.

unSpawn:
From my POV keeping demo data and data of paying customers strictly separated is nothing more than common sense.
---
Even if our internal people are setting up the accounts? The prospective customers can't do this by themselves, the sales person will have to set it up, and they only have access to set up a demo acct and make a 7 day key. Every one they make gets logged and creates an email to someone that walks over to their cube and asks them who it's for.

The only people with permissions to convert them and build a real key are in accounts receivable (which also get logged and check/balanced). You need to show them the money for that to happen.

The person running AP is a director in the company and knows about and has to approve every license that goes out the door.

As well, isn't doubling the amount of code you need to maintain creating additional risk? It will all use the same web and database servers...

-Viz

It looks as though the PHB is focusing on the "how" rather than the "what". I would mention, politely and diplomatically, that the better way forward is for the PHB to present a problem and then ask for a solution, rather than present a problem and a solution and make someone go away and complete it. the reason for having an IT department is that they are the ones who are best placed to discuss solutions and provide the means for informed decisions.

Good luck and keep us posted.

While I sympathise, I agree with unSpawn (FWIW, I've been in IT for 20+ yrs).
You have to assume that something will go wrong eventually, maybe not with that nice secure front-end, but just a programming glitch and the 2 datasets will get mixed.
Another thing that happens is that they run a demo, but accidentally login as non-demo user... easily done, result prod data exposed to customer..
You won't always be the one-and-only prog on this system...

Instead of patching both systems, you do (of course) make backups right... ?
This gives you an ideal opportunity to see if your restores work (Prod -> demo). Old saying: if you haven't test restored your backups (and run the resultant system) what you have there is just bunch of tapes/coasters....
Also, enables youto show PHB that your section of DR (disaster recovery) works

Basically, your PHB has two options:

• Make you do it his way, building a complete separate system. That way he can go to sleep every night, knowing there's no way in hell they'll ever get mixed up.
• He can let you do it your way. He'll just have to trust you and hope you'll never stand before him with your shoulders hanging, stuttering something about how you were so sure and never expected... -- I'm not saying that will happen, but he will have to fear that it will.

I'd say your PHB made the right decision.

lol, this same fear dictates that one customer may see another's data. If I can't keep a demo customer from seeing a customer's data, how can I keep any customer from seeing another customer's data?

If customer demo123@shangrila.com logs in and see's billgates@microsoft.com's data, I have a real problem, one that isn't limited to demo customers. It means production customers can see each other's data too. It's the same code right? Same database?

Using this argument, I need to build a separate system for each customer with a different database so they can't ever see each other's data. _It's the same thing_.

Sorry I'm not buying this argument, it's not based on sound logic. This argument states there can't be more than one user on a system or there's a security risk that they'll see each other's data. It implies that multi user systems are inherently insecure so they are to be avoided.

Give me a break...

-Viz

Well, I think you rather missed the point. Yes, that is the same risk - but I think the point being made here is that the *actual* risk doesn't matter. Indeed, you probably are better at judging the actual risk than a PHB. The point is *perceived* risk. Your PHB probably doesn't understand the mechanisms you have in place for security, and thus (s)he worries.

If you want to go around it, tell the PHB exactly what every PHB likes to hear - "it'll save us money/time/productivity." Explain that by integrating the two, you will save this time, then go through the 5 minute rundown of *why* it's no less secure. It sounds to me like he's engaging in the CYA necessary in his job. If you can show him that it's already covered, then maybe he'll be more willing.