Acheron’s Top 5 Steps to a Successful OpenText Integration with CHILI publisher.

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.

Acheron’s steady evolution towards the best approach

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!

Key Steps in a successful API-based integration of OpenText

1. Discovery phase – understanding the customer’s needs

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:

• How critical is solving this issue to your business?
• What outcome do you want?
• What is your required timeline for a working deployment?

During this discovery phase, once we have established the very big picture, we start work on capturing details, such as:

• What attributes and information need to be pulled from the integrated systems?
• How does the information need to be displayed?
• Should the integration use Single Sign On (SSO) for Authentication and Authorization for accessing the resources or can it use a Service Account, etc.
• What are the security settings and procedures?

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.

2. UX Design – ensuring CX success

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:

• If the business already has a certain type of UX in place, it will be hard for them to adapt to new designs.
• Businesses often follow certain important branding or theme requirements across their applications. In order not to dilute their brand, we need to honor these existing requirements.

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.

3. From draft to craft – establishing the System Architecture

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:

• Which ports across which networks will be required for the systems to talk to each other?
• What will the load on the network be? In terms of platforms, systems, and users?
• Will updates to the platforms/systems/network be required?

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.

4. Technical Design

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:

• Listing all the metadata information, which is required for the integration, both functional and technical.
• Finding, testing, and documenting the list of APIs required for integration and any interceptors. This is where creating the UX design upfront comes in handy. If done right, it has already provided us with an exact list of required APIs and provides information about how the Request/Responses should look so they can be easily rendered in the Proposed UI.
• Finalizing things like where user management is handled, how SSO will work, Auth Provider, Session Expiry, etc.

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.

5. Implementation and Delivery

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.

In summary

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!