A small project was implemented at the beginning of the year. The requirements are described as follows:
The customer organization has a business system with a C/S structure. It has been running and maintained in year 56 and is distributed across more than two hundred counties and cities in the province. The software is developed and maintained by a third party. A gis function module is required to query and locate business data on a map. Considering the difficulty of software procurement costs and GIS data maintenance, it is decided to provide services through WebGIS and integrate it with the existing system. Similar to calling Baidu map in an existing business system to query and locate, this "Baidu map" is provided by us.
In the preliminary design and discussion with the CS system developer, due to lack of experience from colleagues who participated in the preliminary stage, the developer of the CS system did not know much about GIS, we only want to push our work to us as much as possible. The design scheme we get is that we provide a MAP website, similar to Baidu map, and this map website also provides the vast majority of business functions of existing CS, for example, all functions such as query and input are implemented once. In the CS system, you only need to embed a form into the WebBrowser control to access the URL of the MAP website. In addition, the developer is willing to provide all the database information and necessary CS source code to us. There are also documents on the database design. There are about 50 tables and more than 100 stored procedures in the database.
When I was sent to the site for technical guidance, my colleagues were carefully analyzing the table structure of the business system, and then simulating the CS system to port the function to the website, developers can rest and answer questions. I was not involved in the project in the early stage, so I was not clear about the situation. When I learned about the project's needs and background with my colleagues, I was shocked because I did not pay for it, there may also be serious expiration and failure. Moreover, this is not really an integration. It can only be regarded as embedding a browser in CS and browsing a fixed website.
In my experience, this does not seem to conform to the principles of integration and integration. I think it is a more reasonable and simple solution:
1. Each system should only focus on its own functions. The interaction between BS and CS programs communicates with messages through interfaces, so you do not have to port the entire CS program function again.
2. the two systems are integrated in the same interface and can interact with each other. For example, the left side is the CS interface, and the right side is embedded in the map browser.
3. The background databases of the two systems are separated and cannot be accessed from each other to avoid increasing the risk of database maintenance.
As follows:
So what should I do if I want to overturn the original design scheme?
1. One afternoon, we made a Demo to demonstrate the effect of integrating the two system interfaces and interacting with each other (using the script execution feature of the WebBrowser control). The customer was satisfied.
2. Inform the customer of the risks of the original solution: the project extension and later maintenance are more difficult.
3. it clearly tells the developer that the original design does not conform to the docking principle, shows him the effect of the new solution, and explains the Demo example to let him know that it is easy to integrate the new solution, there is no technical difficulty or workload.
In the end, both the customer and the developer agreed to the new solution and implemented it in two weeks.
Summary:
I personally think that system interconnection should follow the following principles:
1. The integration of the two systems should be able to interact and transmit messages (service calls ).
2. The two businesses and codes should be separated as much as possible. Each system should only focus on its own functions and communicate with each other through interfaces and messages, so as to avoid liability disputes when the system crashes in the future.
3. the databases of the two systems should be separated and cannot access each other to avoid increasing data risks.
As follows: