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 which 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:

  1. 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.

  2. 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.

  3. 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:

A template of an Integration Use-Case
A template of an Integration Use-Case

And this is an example of a complete Integration Use-Case, used by the SYTOSS BA team:

An example of a complete Integration Use-Case
An example of a complete Integration Use-Case

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:

  1. 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.

  2. 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.

  3. You can make a lot more precise estimations, thus minimizing your customer attrition and increasing your brand loyalty.

  4. 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.

  5. The integrated solution’s time-to-market is reduced significantly.

  6. Your system integration project is rendered a great deal more manageable.

  7. You can achieve quite tangible cost savings due to better resource management.

Related Articles

How to Avoid One of the Typical Telecom Software Implementation Problems
Software Development , Application Integration

How to Avoid One of the Typical Telecom Software Implementation Problems

Taking the wrong approach to the migration of Product Catalogs during the implementation of a new Billing or Ordering system by a Telecom company is fraught with a number of problems, increased costs being just one of them. What mistakes do Telco providers make in this situation and what should be done by them instead?

Read More
The Benefits of Java Enterprise for Major Telco and Other Enterprise Projects
Software Development

The Benefits of Java Enterprise for Major Telco and Other Enterprise Projects

Telecom projects of all types are developed using different programming technologies, but, in our view, there is one technology, whose capabilities are more in keeping with the specifics of major Telco projects and allow one to respond to the needs of Telecommunications companies more efficiently. This technology is Java Enterprise. What makes us think so and why should you necessarily consider using Java Enterprise while implementing your Telco project?

Read More
IT Project Recovery: How Software Development Projects Can Be Rescued
IT Outsourcing

IT Project Recovery: How Software Development Projects Can Be Rescued

A vast number of IT projects fail to reach their goals and result in wasted opportunities, reputational damage, and financial losses.

It is, certainly, better to entrust your project to a well-reputed and seasoned software provider and keep things under control at all times. However, if your project is already under implementation and seems to be spinning out of control, you should start taking action immediately before it’s too late.

How should you go about that?

Read More