Dieser Blogbeitrag ist nur in englischer Sprache verfügbar. | This blog post is only available in English.
By now you may be getting the idea that the red line connecting our blogposts is a crazy subtitle. So why do I feel like doing DCTM support is like starting to cook without having everything ready on the counter? Well… it’s because of the ever-changing environment landscape, it’s due to all the possibilities we have while interacting with dctm, the possible depth, complexity of a setup, and the niche technology that Documentum is.
Let’s start with the last – The Niche
Imagine that you are just starting fresh, in a company that does Documentum development or support. Or just remember. There are about zero chances you ever heard about Documentum during your study or in your late-night non-incognito internet binging sessions. But you are in. You get a ton of books and begin reading into Documentum stuff. Then you get a specific training for whatever you’re going to work on. And then you crash into your first serious DCTM problem when none of the seniors are around. Well good luck with googling for that! Oh, wait! What? You don’t have an EMC Community (later OpenText) account yet? Because that’s about the only place on the planet where you will be able to find some specific information for your problem. Or you can go through those 800 pages of outdated documentation again. Congrats! Niche technology – makes you special. I guess that’s one of the reasons these “EMC World” events are being held. So that you can see that other human beings like you and your team, (and that Indian guy, whose blog you keep bumping into) actually exist.
Anyway… managing niche technology is hard because you never have all your tools and information available when you need it, even later on. Like cooking in somebody else’s kitchen. Do you want a more mature example? I started on a D2 configuration project this summer. There was a little configuration quirk for the O2 integration that we needed done, nobody I asked knew how to help, and it was my task. I kept chewing on the latest documentation form OpenText. Pretty niche, pretty brand-new. A German colleague came up with the idea that I should look over the older documentation from EMC. And there it was! In version 1.0 of the documentation was critical information that was omitted, for whatever reasons, in later releases. And that was probably the only one place in the universe where that information existed.
Seriously, in the niche technology world, one can only enjoy the work by keeping track of the changes of the newer releases, while always scraping for knowledge and keeping that personal or collective documentation archive tidy, and of course, knowing the expertise areas of other colleagues, so that when you really need to bother someone with questions, you pull the right one out of her/his work.
And then, there is – The complexity of a DCTM setup.
It’s new, it’s always new. Does not really matter if you have been working for years for the same customer. In the long chain of mirrored databases, application servers, docbrokers, switches, cables, firewall settings, SSO AD integration, Kerberos, new Java rollouts, flexible end-user environment settings there will ALWAYS be something that fails in a new and surprising way. Yes, of course, if it would be not failing in new and surprising ways, we, supporters would be out of business. I’m just saying in the long chain sometimes it’s really hard to figure out the cause of new issues, especially if you are not working often with back-end as well as with front-end components and don’t have a huge map pinned to your wall, you may loose yourself in the woods before getting the overview and locating the problem. You may have a good chance of finding the salt and pepper in the cupboards around the stove, but maybe they’re somewhere else… it’s never your kitchen. And when you start thinking it is your kitchen, your mother drops by and decides to re-arrange it properly.
So yes, if you want to stay ahead of the game, you will need to get that general map pinned to the wall, the wall of the room or head, be involved in backend as well as frontend support as much as possible, and be member of all relevant mailing groups that announce outages and update rollouts of interest to your area. And if you happen know more than the rest of your team, always remember to share! Because sharing is caring; caring for yourself. Because sharing makes for a strong team, and that will prevent your inbox of being full of pending requests when you happen to return from a sick leave.
There is of course much more to say about the smaller things, like helping users to manage thousands of Permission Sets and hundreds of thousands of groups, while you try to understand their very local business construct just to understand their initial vague request, while equalizing for their accent and tuning up your microphone sensitivity because they can’t hear you well, and they can’t hear you well, because the customer before them said your microphone is too loud and Darth Vader is so out.
This and more in another episode. Stay tuned!