Should We Rebuild or Renovate an Outdated System?

Motivation

You have an outdated system and want to rebuild or renovate it. You do not know which path is best for you.

Guidelines

Typically you have 2 main options for an outdated system.

Option 1 – Replacement: You can rebuild the whole system and migrate the existing data to the new system.

If you follow this approach then you may consider WordPress if your system is just a brochure website. WordPress is very suitable for building a brochure website.

If you system is a simple software supporting few business processes then you may consider EspoCRM. EspoCRM is very suitable for building simple business processes.

If your system is a sophisticated software supporting specific business then there may be several things you may need to consider when deciding to rebuild your system.

1. The effort to migrate the existing data to the new platform. A deep analysis of the existing data is required to create a reasonable estimate for this task.

2. The effort to integrate the new system with other systems that are integrated with the existing system. An analysis of the existing source code is required to create a reasonable estimate for this task.

3. The effort to implement all the existing business processes in the new system. A list of all business processes with their concrete steps is required to create a reasonable estimate for this task.

4. The possible mismatches of the new platform and the existing code base and data. These may require changes of business processes or removal of some existing features or considerable effort for migration.

5. Are the source code, database and files of the existing website fully available? Some websites might suffer vendor lock-in issue. It may be true that any exported data is unusable without the source code. Therefore no migration tool can help data migration due to specific data structures and constrains.

For example no one-way encrypted user passwords can be migrated to a new system. The best data that might be available for you is just Excel or CSV files. The contents of these files may be imported to the new system manually or automatically but no business logic can be transferred. In this case, rebuilding the whole system (preferably using WordPress) will require manually copying the contents to the new system and partially importing few tables (e.g. emails, first names, last names, page titles) to the new system.

Option 2 – Renovation: You may choose to renovate your system if the existing technology stack is not too outdated.

When choosing this option you may need to consider several things below.

1. The life cycle of the existing technology stack. The existing technology stack should not be deprecated and is still in active support.

2. The ecosystem of the existing technology stack. Most of 3rd party components for the existing technology stack should still be in development and support.

3. The capabilities of the existing technology stack. The existing technology stack should still support your new requirements although the solutions may not be perfect for performance or user experience.

4. The cost of the existing technology stack. You should still be able to afford the cost of the existing technology stack.

 

Should We Use SOAP or REST or gRPC or GraphQL for API Implementation?

Motivation

You want to implement an API for your client to integrate with your system.

You wonder if you should implement the API using SOAP or REST or GraphQL or gRPC.

Guidelines

Technically speaking SOAP is a protocol (developers must respect the protocol specification when working with it) while REST is an architecture style (Developers may not follow it strictly).

Most of software service providers (e.g. Salesforce, Sharepoint) provide both of them (SOAP and REST) for API clients.

The reason why a software service provider may implement both SOAP and REST is that legacy systems or frameworks (e.g. .NET, Java) often have many mature tools or libraries for consuming SOAP API easily while modern systems or frameworks (e.g. Node.js) often have many available tools/libraries for quickly consuming REST API.

If only one approach has to be chosen in order to reduce development cost then selecting SOAP or REST or GraphQL or gRPC for API implementation should depend on the API clients.

So the strategy below may help us select the most appropirate technology.

  1. Introducing your system capabilities to your client first.
  2. Then find out the main programming language that the client is using for their back-end services (e.g. Java, C#, PHP, JavaScript, Python, Ruby, Go)
  3. Find out the main API technology that the client is using for their back-end services or the API technology that they are most familiar with (e.g. SOAP, REST, GraphQL, gRPC).
  4. Then implement your API using the client’s API technology. The API can be implemented using a programing language that you are most familiar with.
  5. Then create the corresponding API developer guide and sample code for the client using their programming language.