How Your System Integration Toolset Can Be Enhanced with a Proprietary Business Analysis Tool from SYTOSS
As you are, most probably, aware, enterprise system integration is not only a System Architecture-driven area, but also one utterly underpinned by Business, System, and Middleware Analysis. It is mostly System and Middleware Analysts who discover, analyze, and document the myriad of nuanced interactions that arise when one or more major software systems are integrated. Their role is pivotal to any major system integration effort, and the larger the number of systems involved, the harder and more challenging is their task.
The results of a system integration project, including both the quality of the delivered solution and its time-to-market, are, thus, greatly influenced by your BAs’ qualifications and the methodologies and tools they use.
As a Business Analysis team, we have been part of a number of system integration efforts and majored in the provision of telecom system integration services: an area, in which a large and diverse number of systems are, usually, integrated. As a rule, we have seen only conventional tools being used by most other BA teams, no matter how advanced or experienced. The primary one of such conventional BA tools, which has been around since time immemorial, and which we have, certainly, been using too, is Use-Cases (also referred to as System Cases).
So, what do conventional Use-Cases allow you to do and why do they, frequently, fall short when more than two software applications need to be integrated?
Conventional Use-Cases and What They Are Good For in System Integration
When two or more software systems are integrated, Business and System Analysts describe the interactions that arise between them, between them and the users of these systems, or between them and some third-party systems. In other words, they create Use-Cases. These Use-Cases represent sequences of steps or actions that need to be performed by systems and/or humans for an interaction to take place. They also indicate the result of the interaction that has occurred.
Seemingly, this should suffice for the performance of system integration tasks, after all, why should it not?
However, this isn’t always so.
With conventional Use-Cases, what can, often, be a variegated panoply of sophisticated systems and different user roles can prove extremely difficult to capture in terms of the interactive relationships involved.
In essence, with conventional Use-Cases you can reflect, mostly, the vertical integration flows and describe (up to an extent) the user-system or system-system interactions they involve.
Simultaneously, the user-triggered system-to-system interactions, taking place on the horizontal level (in order to enable a user action), are, generally, either overlooked, or float up at a later stage and result in development adjustments or some other unwanted consequences.
In order to be able to capture the entirety of such possible system interrelations by means of conventional Use-Cases, you would, sometimes, have to create a 300 pager of a document that would be hard to navigate and use.
Some innovative change was required. In our case, the innovation was fomented by the ever growing workload and the arrival of just another major enterprise-grade project that involved a boatload of system integration. We decided to try a different approach. More specifically, we decided to spend more time and describe the system integration processes and goals more comprehensively. This is how a new type of our Use-Cases, Integration Use-Cases, came into being.
Integration Use-Cases, - What Are They?
As we felt the need to describe in detail the system-to-system interactions that occur as the actions, covered by a Use-Case, take place, we began to create one more type of use cases, bearing on such interactions and complementing the conventional Use-Cases.
Here is how this is done:
-
The BA team, working on the project, creates a set of Use-Cases. These Use-Cases cover the functional requirements that stem from the client’s business needs.
-
A System Architect, in cooperation with Integration (Middleware) Analysts and System Analysts, determines which of the systems involved are responsible for enabling the above Use-Cases.
The System Architect must be knowledgeable of a wide range of system integration principles and techniques and be able to use these principles and techniques regardless of the size of the systems being integrated, or programming languages and databases, utilized for this purpose.
-
A Middleware System Analyst and a System Analyst determine the kinds of system-to-system interactions that need to take place for the Use-Case-described action to be performed. They use the following well-known BA techniques to capture the related Transition and Integration requirements:
-
Functional Decomposition
-
Interfaces analysis
-
Data Flow Diagrams
-
Data Modeling
-
Data Dictionary and Glossary
-
Sequence and State Diagrams
Business Analysts: Who Do You Really Need to Help You Automate Your Business?
-
Next, the Middleware System Analyst uses the result of the analysis to create a set of Integration Use-Cases. These Integration Use-Cases embed the already existing conventional Use-Case into the integration flows, associated with such business cases, as, for example, “Introduce a New Customer in the System”, or “Order a New Product via an Online-Shop”.
As a rule, Integration Use-Cases are structured as a table. The horizontal column of this table contains the integration flows that implement business cases. The vertical column of the table contains the system interactions through which these business cases are implemented.
The following is a template of an Integration Use-Case, used by our BA team:
And this is an example of a complete Integration Use-Case, used by the SYTOSS BA team:
Also read: Optimizing Requirement Management in Business Analysis
How You Can Benefit from Using Integration Use-Cases
We have been using Integration Use-Cases for quite a long spell now and have found them to be massively helpful. At this point, we can observe the following benefits of using Integration Use-Cases to implement projects for Telco and other major companies which have, at least, 3-5 software systems:
-
When a change is introduced to any of the systems being integrated, one can easily identify all the impacted Integration Use-Cases across the entire integrated solution. All you need to do is review the system vertical to see all the flows that have been impacted and require reconsideration.
-
When a change is made to any of the business cases, represented by the Integration Use-Cases (for example, the way it happens when GDPR is introduced), one can easily identify all the impacted systems. You just need to review the impacted integration flow, described in the horizontal column, to see all the systems that need to be redesigned for them to be able to support the newly introduced requirements.
-
You can make a lot more precise estimations, thus minimizing your customer attrition and increasing your brand loyalty.
-
The integration efforts are facilitated immensely as one can quickly and with much greater precision identify the integration points and instruct the Development and QA Teams accordingly.
-
The integrated solution’s time-to-market is reduced significantly.
-
Your system integration project is rendered a great deal more manageable.
-
You can achieve quite tangible cost savings due to better resource management.
