It’s been very interesting to watch how the Cloud has had an impact on Enterprise Content Management in the Life Sciences market over the past year or two. I doubt that there are too many observers with knowledge of the market that believe that its impact has been anything other than positive. But as with most “no brainer“ disruptive technologies, it’s still finding that the path to adoption is not quite as simple and straight forward as it might at first appear.
Clearly, the opportunity for Life Sciences companies to outsource their IT infrastructure and some related services is a derivative benefit of utilizing Cloud. In addition, subscription pricing, synonymous with Cloud solutions, has the benefit of moving CapEx to OpEx and realizing the financial benefits of doing so, appeals to many companies.
OpenText Documentum is a full-fledged and mature server-based Document Management System which is accepted e.g. by the FDA and therefore widespread in pharmaceutical companies.
Compared with cloud computing technologies that are very strong in providing elastic (scalable) services OpenText Documentum products could be regarded as inflexible and monolithic / layered applications. Although they seem to be the exact opposite of the flexible Microservice architecture approach used for cloud native application design, there are ways to combine OpenText Documentum products with cloud computing technologies.
I usually write blog posts about general IT trends and about the paths and aberrations of digital transformation. I have always avoided writing articles about us, fme AG. Today, for once, I want to break that rule. Sometimes you walk out of a customer meeting and ask yourself: “What in God’s name do some so-called cloud consultants tell clients? Why are they confusing their clients more than neutrally showing them the options for the way to the cloud?
The list of ways a company can leverage its applications into the cloud is long. Thus also a term variety prevails which is confusing.
Containers, here I will call them more specific Linux containers, are in short modularized software installations. Think of a container as an isolated area with a self-contained service. The container consists of all dependent software the service needs to run. Each container / service can connect to other containers / services. Because the containers are isolated to each other, they are not able to interfere with others in terms of software versions and runtime behavior. For each container you can plan separately on which Linux operating system, web server, language interpreter, etc. your service will rely on — which best fits to your needs. That means, that for example for excessive use of threading or performance needs a single service could be written in Go Lang based on Alpine, while another one uses Apache with PHP also on Alpine and a third one needs to comply with prerequisites using Tomcat with Java on CentOS. All this is possible with containers even running on the same host.
In the regulated life sciences environment, the management of controlled documents such as SOPs (Standard Operating Procedures), procedural instructions or work instructions is of great importance. Change management processes ensure that these documents are properly revised, approved, trained, distributed and, where necessary, suspended. In addition to well-known use cases within change management, there are special cases that are handled differently from company to company.
One of these applications is the rare case of so called Temporary Document Change (TDC).
From 1997 to 2007 I was employed at Documentum in Munich and was responsible for the technical sales issues for Central & Eastern Europe, Middle East and South Africa. I witnessed the birth of the fme – Documentum partnership in 1998 at close quarters. With fme Documentum had found the ideal partner to realize projects in Germany. Since then I have always followed the development and international growth of fme. That’s why I’m all the more pleased I joined the fme in 2015 and am now responsible for content management and cloud business as a board member of fme AG.
At fme we are proud that this year marks the 20th anniversary of our partnership with Documentum, now part of OpenText. It is a success story with countless successful client projects, a world renowned product that has been certified for more than 10 years, extensive platform and industry-specific process know-how and a great team of highly specialized employees.
I really enjoyed my first Working Out Loud Circle: fixed appointments, changing tasks for processing my goal, exchange with colleagues that I less knew before, receiving and suggesting ideas. How I experienced the first 6 weeks Working Out Loud @ fme AG, you may have already read in my > »mid-term review«.
Where do I stand after 12 weeks of Working Out Loud?
Am I open-minded in the work context, do I share my work status at any time for feedback and do I connect with people all over the world like general WOL goals expect?
What do you see in the picture? Two faces looking at each other or a jug? Both?
In music it’s easy: You put a few musicians together, hand out music sheets, everyone knows how to read them correctly and you hear the desired music in the right rhythm.
Similarly with construction: A construction drawing is made and each construction expert can extract exactly what the draughtsman meant.
Skew tones in the business world
And in our business world, where we encounter presentations, diagrams, graphs and tables every day? Here often a completely different music plays.
We know that an organization has to be agile and ready for constant change in order to survive. But who decides which changes come, when they come and who is involved? Who follows the implementation process and at the same time has an overview of all current changes in the company?
Managers in particular should deal with these 4 questions in order to successfully implement changes:
This blog article looks at OpenText’s Documentum REST API and provides insight into its technology, basic functionality and extensibility capabilities. Here I report from my own experiences and I am happy if I can help other “techies” like me a little with it 😉
What is the “Documentum Rest API”?
In principle, the term Documentum REST API refers to a web interface introduced with Documentum 7 that allows access to objects and functions of OpenText Documentum. This is based on Spring-Boot, is delivered as a WAR file and must be installed on an application server – e.g. Apache Tomcat. This interface can be used to write customized clients, apps, or plug-ins of other systems.