I’m working on a large project that has evolved over time and is composed of several independent subprojects, each developed by a different team. While these applications have their own distinct purposes, they are interconnected and together form part of a complete workflow.
For context, an example would be:
• Application A manages the creation of a request to build a building.
• Application B is responsible for drafting the project with the architects.
• Application C handles the necessary permissions for the construction.
• Application D manages the hiring of staff to carry out the construction.
In total, there are about ten independent applications that together form a single functional process. The challenge we’re facing now is the creation of a “parent” application that centralizes and visualizes the information from these applications, providing a global view of the project’s status and details of each phase.
My concern is how to approach this “parent” application in a way that doesn’t overly depend on future changes in the “child” applications. For example, if in the parent BPM I query data from Application A to display in a table, but later new fields are added or the structure of the data changes, it could cause issues in the parent application without us realizing it. Additionally, since the development teams are separate, it’s difficult to ensure that every change in a child application is properly coordinated with the parent application, especially as the child applications will be constantly evolving.
My question is: what would be the best approach to structure this parent application to avoid dependency issues with the child applications, particularly when they undergo modifications or evolution? Are there best practices that could help mitigate these risks in a BPM environment like Appian?
Discussion posts and replies are publicly visible
I think a good approach is to define a certain set of information that each application has to "deliver" to the parent app. Then you can define the content and format and this does not interfere with changes internal to these apps.
Hello, thank you for your response.
The issue we are facing is that we have inherited these applications, and they were also developed by different teams, meaning that each one did things their own way. Now the client is asking us to somehow provide information on everything happening within these applications, as the combination of all of them forms a single functional process. What would be the best strategy to address this?
I understand. But that is not an easy challenge and going shortcuts becomes technical dept you will have to pay later for.
I still think that the approach I outlined is a good one.