Software system development consultant: https://consult.revtel.tech/

With the explosion of technology today, it is difficult for system development to be completed by itself from start to finish. It is quite common to integrate third parties into your own systems. But if you accidentally misunderstand the scope of the task, tragedy often ensues (see the thickness of the function? - starting from community login and tweet ).

An interesting question is, what is the so-called system integration and interface? What should we do?

Tragedy Caused by Exploding Orders - Operational Difficulties Caused by the Paralysis of the ERP System

Let me share an example first.

E-commerce orders get rid of some restrictions on physical sales, and can be well combined with online marketing. As the epidemic accelerates its development, it is becoming more and more common in our lives.

When I go out to do business, I always hope to receive an order and get a hand cramp, but is more orders really a good thing?

Recently, a partner has cooperated with us to develop its exclusive e-commerce business. Under the condition of high customization, it has indeed solved the dilemma that the previous operation has limited working hours and cannot accumulate members, and it is also very good in the case of continuous accumulation of orders. Precipitate data into more detailed services to lay the foundation.

A few days ago, they launched a schedule activity. While the front-end was acquiring customers and receiving orders, the ERP at the back-end had problems due to instantaneous large traffic. To make matters worse, because the schedule happened to be on Friday, the ERP in the accident was shut down over the weekend, which made the factories that were ready to take orders to stop production.

In fact, ERP has been upgraded in software and hardware before the event, but it may not be effective due to the structure. As the front-end, we can do very limited, probably that is to assist in sorting out the list for subsequent processing.

There is an interesting question behind this case. Is it really that simple to interface with a seemingly simple order?

System interface actually includes risk transfer

Thinking back to the essence, the purpose of system interface is to divide labor and responsibilities.

The division of labor and responsibility may come from the following reasons:

1. Professional Considerations : Send out the parts that are not good or cannot be executed by concatenation, such as cash flow services
2. Cost considerations : Obtain high-quality services at low cost through concatenation, such as cloud databases
3. Information acquisition : obtain information that the system does not have through the connection, such as third-party login
4. Resource allocation considerations : reduce development risks by concatenating, such as using some SDK packages

But there are always two sides to everything. In addition to getting some benefits, we actually hand over controllability and introduce uncertain risks .

For example, if your system supports FB login, you will find that you often need to adapt to the terms and conditions in the background during maintenance, otherwise the system will not be able to use without changes. This is a typical case of incorporating external changes into a native system.

Careful risk investigation is the real core of the task

So what should we do? I think the point is to build a cognitive system to encapsulate these introduced uncertainties .

1. The scope of system tandem is not only mechanical combination, but also risk exclusion must be included
2. When planning how to connect tasks, don't stick to existing documents and examples, but also include business logic, error diffusion scope, etc. into the list that needs to be understood.

Proper planning is always the first step to avoiding failure, remember

• Set a reasonable schedule for the requirements, which should include testing and some import verification
• Planning itself needs to think about resource allocation, and be careful of possible errors caused by short-board effects
• Understand the current state of the system and prepare for filing as much as possible to avoid over-focusing and ignoring the overall situation

The overall risk assessment should also be complete, and try to avoid underestimation.

• A solid understanding of business risk : a solid grasp of the cost of mission failure
• Do understand engineering risks : pay attention to expected mobilization of resources (eg, quality of engineers) and stability of access systems
• Do understand operational risk : have a complete assessment of subsequent planning after integration is complete

Finally, a very often overlooked but often the key point of success or failure - people . For example, in the previous example, whether or not it is possible to grasp the cooperation enthusiasm of ERP manufacturers in the final analysis probably determines most of the aftermath and subsequent improvement.

Consider the following three roles when integrating systems :

1. End user : If something goes wrong, what is the impact on the user?
2. Internal Relationships : What is the overall mission within our organization? Is there a political factor?
3. External Relations : What is the overall status of the tandem counterpart? Are they willing to assist?

Conclusion: Do not mistake essential problems for technical problems

The Man-Month Myth book mentions that the task of software engineering has two natures: essential and subsidiary. The latter may gradually improve with improved tools (such as better programming languages and IDEs), but the former is the real complex and difficult to overcome.

The same is true of system tandem, which itself is often mixed with these two problems at the same time. Perhaps it would be a good idea to plan the sub-items along these two categories before all our tasks are carried out. After all, it is the most appropriate state of mind not to take everything lightly from the very beginning.

Real world problems are always more complex than we think!