In the last article, we covered the basics of enterprise software & enterprise integrations. Now that we have an understanding of what integration means, let’s get a bit deeper into how we do it by looking into the complete life-cycle of an integration project. We are going to start where every project starts – understanding the requirement.
Scenario: Consider the case of a large (fictional) multinational organization ‘ACME Inc’ that has its operations in India and Germany. Over the last 20 years, ACME managed its HR operations for the two legal entities by having different systems for both the countries. Recently, it has decided to unify them by upgrading to a new cloud HR software that offers improved UX and enhanced capabilities to their employees. However, due to certain (weird but possible) reasons, ACME cannot discard the old systems completely and needs it for country-specific payroll processing.
The above scenario is a typical case where we require integration to keep different systems in sync with each other. Let’s try to map this digital transformation scenario step-by-step.
Understanding the current landscape
While dealing with an integration project, the building blocks of a requirement gathering exercise are the different software systems involved & their interactions.
One of the easiest ways to understand this is to create a visual representation of the software system landscape. In our scenario, the two oversimplified systems might look something like the diagram on right. This landscape diagram focuses just on the 2 HR systems and a few of their entities.
In a more real-world scenario, we should also consider the other connected systems like Identity Management, Finance, Supply Chain, etc. But for now, we are going to keep things simple 😉
Visualizing post-integration scenarios
Once we have a good understanding of the current landscape, it’s time to see how it will be affected by the introduction of a new system. To create this proposed landscape, we can just copy our existing design and start making changes. After some quick tweaks, here’s how it might look like:
In this proposed post-integration world, we can see the addition of our new cloud HR system which will become the primary system for all employee interactions (like leave request, performance management, organization tree and more). We also see our legacy systems for the two countries still in place, but with slight changes. As per the proposal, we have denoted the Global HRsystem to be the master system for ‘Org Data’ and ‘Employee Data’ and added a data stream for both these entities to the IND and DE systems.
To put it simplify, it represents that the Org & Employee Data (like name, age) will flow fromthe Global HR system to IND & DE systems via the integration flows.
Building on the same concepts, we can start designing slightly complex scenarios as well. Below is one such sample (still simplified) real-world scenario involving SAP SuccessFactors and SAP HCM.
Conclusion & Next Steps
Thanks to this simple design exercise, we now have an understanding of the different systems at play and how the data should flow between them. In terms of an integration project life-cycle, such an exercise is usually done in collaboration with the customer prior to the start of the project. Designing these ‘As-is’ and ‘Proposed’ scenarios plays a critical role in defining the project scope & effort required.
In the next articles, we will be covering the next steps in the life-cycle of our integration project and look at data transformation.
—————
NOTE: All diagrams added above have been created using the INTEGRTR Digital Transformer . Drop us a message if you would like to try it out or use the integrtr platform to boost your integration projects.
