Hardware company mantra. Part II

I thought a lot how to write continuation for previous blogpost, because I have my own OpenText experience and I’m looking forward to share it, on the other hand OpenText has recently shared their Documentum “roadmap“, so I want to share my thought on it as well. Today Alvaro de Andres has inspired me to write a blogpost about second topic, i.e. roadmap. Actually, I would completely ignore this blogpost if it was written by a sales person, who was hired a couple of months ago and has a KPI to sale as much D2 licences as possible, but statements like “migrate to D2 because you can configure it” sound ridiculous if you are an architect with 20 years of experience. Well, let’s discuss this topic more thoroughly, and let’s begin not with Documentum 🙂

Simple question: what is the worst bugtracking software ever?

I do know it is not correct to use universal quantifiers, because my experience is limited only by four bugtracking systems:

but without doubts I can say that in my opinion Atlassian JIRA is the worst bugtracking software ever – it is so uncomfortable that every opening of JIRA dashboard causes a vomiting attack. Simple case: imagine that I need to create an issue in my bugtracking system, what steps I had to perform in order to do this? There is nothing special: I need to login into bugtracking system, open special page, provide short/full description, steps to reproduce, information about environment and versions, attach log files and submit an issue. Now how it looks in JIRA:

What is the hell? First of all, Atlassian guys, who think that modal window is extremely convenient, must to commit a suicide as soon as possible, at second, JIRA offers to fill a lot of irrelevant information but misses the important thing – adding attachments. Now how the same functionality looks in another bugtracking system:

It is awesome! Another case: every evening I want to review all recently submitted issues in order to check that those issues has been properly classified and assigned, JIRA search functionality:

the same in YouTrack – after JIRA it is like a big gulp of clean air:

Well, why is there abysmal gap in “user” experience between YouTrack and JIRA? The answer is pretty simple: YouTrack is a specialized software, which was designed to support development activities, JIRA is a software which allows you to setup/configure processes which look like trouble ticketing, i.e. you can use JIRA both as bugtracking and ITSM system, but in both cases it’s functionality lacks some crucial points, for example, in case of ITMS trouble ticketingincident management is not the only discipline, there are also problem management and configuration management – take a look at this marvel: JIRA as CMDB (actually, there is a third-party CMDB module for JIRA, but it’s existence just proves that JIRA lack some functionality). And the real question is: if I want to support some processes in enterprise, what is the best option: buy specialized software or use a single system, which is definitely not ideal for particular processes but, it general, covers about 80% of required functionality?

Now let’s return to Documentum. Why did I provide a user experience comparison between JIRA and YouTrack? Because it perfectly fits to the following statement from the original blogpost:

These days, the goal is more likely to be user acceptance, or better put – user adoption – making users happy and productive. The business side now typically drives decisions about which products and solutions will be implemented, and this makes total sense: Users must derive a business benefit from any implementation, otherwise, why implement? So the focus now is more on User Experience in terms of ease of adoption (including level of training needed), ease of use, speed of use – essentially, does the solution drive productivity or hinder it?

Hey, talented team, why are you still on JIRA if YouTrack provides better user experience? YouTrack also reduces TCO because it is cheaper – compare: YouTrack Standalone License and JIRA, hosted on your server. And, moreover, it is obvious that your users fail to adopt JIRA:

How was it possible that webtop CR became a part of D2 release? There are only two options:

But in both cases I do think OpenText must immediately migrate to YouTrack, otherwise the statement about TCO and user experience seems to be inconsistent – you suggest customers to migrate to another software due to certain reasons, but fail to do the same for your organization. And more vital question: if I think that webtop does not fit my needs well, why do I need to migrate to D2 and stay with OpenText? Why do not prefer another ECM vendor? If you think that your ECM processes are so simple that you are able to “transparently” switch between Webtop and D2, I swear: for you it won’t be a challenge to change ECM vendor. Moreover, if we start comparing ECM vendors using TCO and user experience metrics Documentum will demonstrate the worst results. My personal suggestion: never ever try to calculate money in someone else’s wallet – TCO is just a last resort when you are trying to compare competing products – if these products do not compete you statements looks poor, during long period of time Microsoft was trying to do the same and as the result we have a MSSQL running on Linux servers.

Now we are ready to talk about Documentum roadmap.

Frankly speaking, I didn’t expect much from that webinar due to following consideration: the “roadmap” term assumes that you clearly understand what is your current location and where is your final destination, and roadmap just defines a set of steps (milestones) you need to perform to reach your final destination, and, if you think that 30 minutes is enough to present “Documentum roadmap” you are bloody idiot – even a couple of days is not enough to do that, moreover, 90 days are not enough to think the current situation through and define a final destination and milestones, so, I was expecting that OpenText reps would use some populist slogans like: we are going to improve support, documentation, security, stability, integration capabilities, etc… – sounds poor from technical perspective, but it is exactly what Documentum customers were expecting, but even these low expectations didn’t come to true – all what we got was: we have acquired a 25-years old building and what we are going to do is change it’s signboard (change version numbers) and paint a facade (change D2 UI – actually, this analogy seems not to be perfect because D2 is just an outbuilding which has been constructed using dirt and cane, but on the other hand OpenText reps do think that D2 is our future, so, this analogy is correct). And when you are suggesting customers to migrate from Webtop to D2 you are actually suggesting to move from 25-years old building into an outbuilding – it is ridiculous.


Hardware company mantra. Part I

Many people, I have worked with, insist that I have a following habit: if I want to prove my opinion I like to emphasise some “inaccuracies”, provided by opponent, and such amplification turns opponent’s opinion into a piece of dog crap. Let’s try do to the same with following statement:

The faith of Documentum has always been hanging around in limbo. However, it feels like this acquisition finally marks the end of the uncertainty about Documentum’s future. I am not saying this based on enthusiastic statements made by OpenText, I am saying this because the acquisition makes sense to me in many ways, and at least makes more sense than its situation with EMC. As we all know EMC is a strong hardware company, while Documentum is a software firm, and naturally, EMC didn’t support Documentum enough as it wouldn’t have served them to sell more storage. On the other hand, OpenText is a software company that offers a platform armed with a rich enterprise information management around its content management system. With this in mind, the ECD products such as Documentum, InfoArchive, and LEAP make this acquisition a natural fit. Besides these, there are also complementary products. For instance, the Life Sciences industry is considered Documentum’s strength, and OpenText already highlighted the values of having Documentum in its Life Sciences Solutions Suite that can immediately benefit both OpenText and Documentum Life.

which was provided in OpenText CMO on the Future of Documentum & ECM Trends

Well, I have no idea who had started to spread the “EMC is a strong hardware company” myth (my guess is: “The Departed” – Dave DeWalt and Documentum), but this myth is so strong that even IIG/ECD employees do believe in it:

moreover, even Documentum competitors were trying to take advantage of this myth: somewhen in 2010 OpenText sale was trying to involve us into OpenText business assuring that Documentum is bad because OpenText is “hardware independent”. So, let’s try to emphasise this myth (actually, it is how “hardware company” mantra sounds from my perspective):

During years Joseph M. Tucci was bringing together IIG/EGG stakeholders and was saying: you know, we are a hardware company, so you must do your best in proving this statement: you must provide poor support, create poor software and never ever write a correct documentation

Sounds ridiculous? Yes, it is how “hardware company” mantra sounds to me. So, why is this myth wrong?

First of all, it seems that the “hardware” epithet is used as an inappropriate antonym for “software”: when we are talking about “hardware companies” we actually assume hardware manufactures, but EMC do not manufacture computer hardware, actually their business is to combine OEM parts into storage unit and sell it at a higher price – it has nothing in common with hardware manufacturing. It would more correct to say that EMC sales do know how to sell storage units but have no idea how to sell software and services, but in this case I have no idea how this was affecting Documentum: EMC acquired a mature company, which already had its own employees and divisions. In my opinion “hardware company” myth was invented to hide some internal conflicts between Documentum stakeholders and EMC executives.

At second, what did forced IIG/ECD employees to provide poor software and services? Was it a “hardware company” title? Definitely not! I, being a professional, always do my best at my work, no matter what is the company title, because if I do not do my best I already not a professional – I do not need to get a bad reputation. The truth here is that ECD/IIG had failed to compete with new ECM players and the “hardware company” myth was so attractive in hiding their own incompetence that it was a crime to not exploit it.

Degradation of Documentum developers

About two months ago I was talking with my former colleague, and he was complaining that “modern” documentum developers fails to perform basic CS routines like creating/modifying jobs or acls using IAPI scripts – instead of leveraging functionality provided by IAPI/IDQL they are relying on functionality provided by Composer or xCP designer, and in most cases results what they get do not conform their expectations (just because both Composer or xCP designer are poor tools). What do you think what is the reason of such degradation? In my opinion it is caused by the fact that EMC has stopped to publish Content Server API Reference Manual