OpenText has rapidly established an enviable reputation amongst the big-player Information Management tools. A key element in this success is OpenText’s ability to integrate with other platforms via its comprehensive API tools. This has made OpenText an ideal content source for powerful, data-driven design workflows.
Integrating software at this scale requires expert process know-how in both planning and integration. In this guest blog post, we asked Nandhakumar Shanmugam and Raj kumaran Malli of leading enterprise-class applications developers, Acheron, to share their best practices on how to approach an API-based integration of OpenText with CHILI publisher.
Information management integrations at enterprise level must meet a huge diversity of needs. In some ways, the very goal of a good API is to make this possible, and that’s definitely the case with OpenText.
Acheron has been planning, developing and integrating data-driven solutions based on OpenText for close to a decade. In that time, not only have we created a wide range of solutions, but we’ve also seen the APIs and customer business requirements we use and serve evolve rapidly.
Our approach to integration and deployment at Acheron has evolved in tandem with this change. And thankfully, we’ve been taking notes along the way! With so much experience in data integration now under our belts, we have identified some tried and tested best approaches to get a large-scale integration that works well through nearly all markets, industries, and systems.
For output-driven design projects at enterprise scale, Acheron have regularly turned to CHILI publisher. CHILI publisher plays well at enterprise level, and thanks to its robust and full-featured API, we can integrate it with OpenText in diverse industries and markets, like retail, finance, and automotive for valued Fortune 100 clients. Developers know that two great APIs are better than one, but before we write even one line of code, there are several key steps to take in a successful integration in the most timely and cost-effective manner. Let’s take a look at them now!
The first thing to do in every project is to talk to the customer and get a clear idea of the issue or inconvenience they are trying to solve. Along with this, it is also essential to ask and answer the following:
During this discovery phase, once we have established the very big picture, we start work on capturing details, such as:
Obviously, there are many details that depend on the nature of the project but hopefully you get the idea: discovery is about making sure you have a clear understanding of the project scope with clear outcomes.
If we’re working on a content-driven design integration with CHILI publisher, for example, we’ll fully detail which types of printed and digital output the customer wants to automate and pair that with the robust capabilities of CHILI publisher. We’ll also get clarity on what content and content types are going to move across the APIs from OpenText to CHILI publisher.
As we work, we clearly document all this information then share it with the customer in order to get sign-off. Once approved, this Software Requirement Specification Document (SRS), will act as the Guide for User Experience (UX), Technical and System Architecture Design.
Based on this SRS, our next step will be to get the UX Design underway. The UX Design will serve as the basis for the System Architecture and Technical Design to follow, and so is the natural next step.
Before designing a brand new UX for the project—however tempting that might be—we always check with the customer first, in case they already have a user experience requirement in place. This is important for two reasons:
Regardless of whether we design a new UX for the customer or take inspiration from an existing system, the next step is always to do a workshop with the business to clarify expectations and work together on the proposal.
If we’re working with an existing UX, at this moment we’ll check for any existing pain points which we can address during the project. This is usually a welcome added benefit in projects we build on top of an existing UX.
Once we have gathered all the information we need, we build a responsive/clickable prototype and share it with the customer so that they can play around with it and get a feel for how the proposed system and features will work. This proactive approach eliminates any potential misunderstandings, and the customer knows exactly what will be delivered at the completion of the project.
Now we get down to the nitty gritty. Working from the SRS document and the now-established UX Design, we can list all the systems and applications which need to be integrated.
For example, OpenText, CHILI publisher and other tools might all be required for an enterprise-level content-driven design solution. Other tools might include Digital Asset Management (DAM), Product Information Management (PIM), Content Management System (CMS), all of which will need to be linked up one way or another.
As the project becomes increasingly technical, we’ll also be looking to understand key factors like:
When we have answered these and other architectural questions, we produce a System Architecture document and share it with the customer for review and approval.
We’re now at step 4 in the process, but we still aren’t ready to crack open the IDEs and get coding. At this stage, we still need to thoroughly understand, plan and document every technical aspect of the design. By getting this right now, we can avoid specification creep later on… and unhappy customers.
Some of the essential steps during the technical design phase are:
Once again, all these technical design aspects will be finalized, documented, and sent to the customer for review and approval. When deploying enterprise-level platforms like OpenText and CHILI publisher, familiarity and experience using these tools will be of huge value in providing a comprehensive technical design document.
For enterprise-scale projects, the journey to step 5—Implementation and Delivery—may be a long one, but it is essential in order to get clarity on the scope of the project in order to meet the customer’s exact requirements and expectations.
Before implementation begins, it is critical to freeze the project requirements and design, then get final approval on everything discussed above. Only then do we start the implementation.
Generally, we recommend following an Agile methodology for the implementation. This provides great flexibility compared to other options. Moreover, if any new requirements crop up during implementation, Agile makes it easier to adopt and deliver them.
Using Agile also allows us to demo our work-in-progress at the end of every sprint. This is great for keeping all stakeholders up-to-date and avoids any deviation from the customer’s expectations.
In our experience, we frequently see a pattern where customers expect 100% of their requirements to be implemented, tested and, signed-off before go-live. This is out-of-sync with an Agile approach and, more generally, will almost never work, as new requirements and enhancements will regularly come up during the implementation phase.
For this reason, we suggest going live as soon as possible with a Minimum Viable Product (MVP). After go-live, the dev team at Acheron can always add new features and enhancements to the MVP Version. This approach allows feedback coming from the business to be addressed quickly and added to new releases deployed at the end each sprint.
For Acheron, the goal of an OpenText integration is to address a business pain point and deliver a good Return on Investment to our customers. When customers require a content-driven design project, we use CHILI publisher for its powerful tools, comprehensive API, and enterprise-level performance and scalability. Projects of this scope require careful planning and will benefit from the foresight that experience brings.
And as experienced OpenText and CHILI publish integrators, we hope this outline of how we approach such projects can give you some spicy food for thought!
Your go-to OpenText business optimization partner for creating content at record speed, without approval hiccups or output variation delays offering a single sign-on for CHILI publisher.