Realistic estimation of the integration of two or more systems

Fang Jin
Nerd For Tech
Published in
5 min readMay 10, 2023

--

Photo by Acton Crawford on Unsplash

There’s one thing that we do all the time in computer science, which is making a new system composed of two systems, there’s a lot of terms to describe this behavior, such as composition or system integration. These days we may have done the integration too often to the point we don’t realize there’s a cost associated with the integration, leaving alone how to measure it.

In this article, I’ll briefly mention a way to estimate the cost in the business level. To be honest, after reading this, you would wonder how else people estimate the cost. That’s exactly the point I want to deliver.

A or B

One of base case I’d like to first mention is that, before the integration, we normally starts with one of the system, either A or B. Thus the time spent to use the system A or B becomes a constant, say a or b.

A + B

Suppose we start at A, and we add B to the party. Can you make a guess the time it might take for a system composed of A and B? Yes, it depends. How about the simplest estimation? If we first do A and then do B, the cost it takes will be a + b.

In reality, a + b isn’t the correct answer. We are missing one big factor in the cost estimation. That is the trip from A to B. Imagine A and B are two locations, you can get the first job done at A and second job done at B, thus in theory you need a + b. But now the trip cost comes out to be T. What’s the total cost if we have to do A and B in serial?

(a + b) + T

Please don’t question me by not telling you it takes time to travel, this is the common sense. You’ll learn it anyway, most time, the hard way. Of course you can try to learn it in your first adventure.

The reason T needs to be introduced is that T can be as high as a or b , or even higher. One important reason why T was never in the picture of single system A or B is that, there isn’t any travel in a single system. Everything within one system can be done so efficient that it makes the illusion that the whole world might behave like that as well.

In short, not only everything has a cost, to reach anything takes an additional effort. Say you have to commute from your home to your job every day, the commute cost will be T . One day after you reach the office , you realized you forget to bring your lunch. You then rush back home to get it, what’s the cost of that day?

(a + b) + mT

In our example, it’ll double your days’ travel. What does this tell us? It says, when we move from a single system to multiple system, not only we have an additional cost, but also that cost depends on how many round trips we’ll take between two systems. Things that was easily accessed from home isn’t accessible that easily anymore once we land in the office. Bummer! Even when T is relatively cheap, if m becomes too frequent, we’ll be exhausted in the end. Just imagine you have to commute 10 times a day to your job.

Let’s simplify our discovery a bit more. Say we know to accomplish a job involving two systems inheriting the cost of a + b, the additional cost we should remember from now on is mT where T is the unit cost and m is the multiplier. Depending on the situation, most likely T and m are hidden from the picture, you need to be smart enough to identify them and then give some estimation on the scale. Why? Because the ratio between mT and a + b will be a strong factor indicating the efficiency of the final system. Say you have to spend 2 hours to commute and 2 hours to do the job when you get to the office, then we should anticipate the boring life you’re getting into.

BTW, I’m only evaluating the cost based on the cost itself. We don’t know the gain from your job, so we can’t tell you whether you are profitable from the cost vs gain factor. This analysis is based on the cost only! But already it tells you something whether you should raise your attention or not.

A + B + C

If we don’t want to stop at two systems, say we have three systems, the analysis can be applied similarly. The simplest estimation can assume the trip cost between any of two systems are constant T . Thus the total cost would be

a + b + c + mT

Once again throwing out the natural cost a + b + c , the additional cost becomes mT where m is the sum of all round trips between any two of the system traveling. Neat?!

What’s more we can get from here? In a three body systems, the communication (traveling) multiplier can be hardly less than 10, thus the magnitude is one level higher than the two body systems. This means, a small travel cost can add up very quickly when the number of locations increase. Which means if m is large enough, we might even be able to forget about the a + b + c and just focus on the mT .

The relativity between mT and a + b + c becomes the most important factor in the more complex problem due to

  • we have already factor in the cost of each individual system
  • we have too many round trips in between anyway

Doesn’t it sound odd to you? The answer leans more towards mT rather than a + b + c while we are asking you to estimate based on a , b , and c at the first place? Interesting.

How to reduce the cost?

I think the side product of this exercise is to see whether there’s a way to reduce cost given all the information above, say we look at the mT directly.

If a smaller T can be found, of course we want to take it, this is referred as shortcut, literally this is called shortcut. If you ever find one, you most likely will become expert of something.

More often, T is a given. In case there’s no shortcut, we need to try as hard as possible to reduce to a smaller m. If three round trips is what we take usually, in order to reduce the cost, we have to do at most one round trip. Even if in that single round trip you have to do more, overall it can be still worth it, because lowering the trip count would instantly make the system integration worthwhile just because the ratio between the additional cost and the natural costs is drastically reduced. Maybe there’s some human factor to it, but in reality, this could flip your project from failure to success. If you ask a customer to wait for 3 seconds, it might be ok, but when you ask the customer to wait 1 more second, he’ll go away and never return. So do you say 3 second is the threshold? I don’t know.

--

--

Fang Jin
Nerd For Tech

#OpenToWork Front-end Engineer, book author of “Designing React Hooks the Right Way” sold at Amazon.