Transport Canada’s Marine Safety and Security (MSS) have several applications designed to register and store vessel information, all of these systems are independent of each other and no data is shared nor common services used. The focus of this readiness review is on two core MSS systems: the Small Commercial Vessel Registry System (SCVRS) and the Ship Registry Computer System (SRCS), also referred to as Large Vessel Registry or the Canadian Register of Vessels.
SCVRS is a Classic ASP application built upon a custom Oracle Database servicing vessels, owners and vessel registry functions. Business rules and database queries are embedded directly in the application’s internal code.
SRCS is a thick-client desktop application written in an older .NET technology stack and an Oracle relational database. The application is constructed upon customized complex business framework built by consultants nor longer at Transport and it was used only within this one application. The continued use of such a framework makes it difficult for DSD-Marine staff to maintain and for new team members to learn the application.
While both systems are simple to scale and deploy, its design does not make it simple to maintain, test, or provide updates to a new Transport Canada infrastructure. Both of these systems are currently seeing the impacts of the monolithic design that they are built upon, in summary:
New members are not able to easily come up to speed and become productive in fixing or enhancing the applications
Code is harder to understand, SCVRS classic ASP is not difficult to use but the procedural and embedded nature of the code makes it more difficult to follow and maintain. SRCS is built around a custom business rules framework and one would need to first understand, before even figuring out the application business rules and where implemented.
Neither system is easily updatable to use emerging technologies, while SCVRS could be moved to cloud it would most likely be under an IAAS platform and not able to take advantage of PAAS and cloud databases. SRCS is a desktop application and as such would not be a candidate for cloud host.
Although the two systems do implement a similar business capability of Registration and Vessel management the databases are not shared in any way and not designed using even a similar model.
As data is stored in multiple systems we do not maintain a single system of record, searches are typically done by looking in multiple locations before either finding the matched data or no data at all. This causes a chatty communication model and slower system response times. As well, development teams not familiar with all the places where data is stored either think it is not available and duplicate the data or even create another new system to store vessel tombstone data.
The approach is taken when looking at these two systems as a potential for updating we did not look in detail at the current designs but instead focused on the business and what are the core contexts of a registry and vessel management. From there several core business contexts were extracted and a design plan to look at a modern cloud-ready architecture that could be done in strategic components without an initial large impact on the current applications in production was investigated.
The following figure represents a high-level design of how such an infrastructure and architecture could be done.
The proposed approach is one that will allow developers to build and refine the service architecture in an agile and incremental manner without impacting existing applications or any new applications that may use the services in the future.
The proposed approach is to be implemented in multiple stages to ensure the existing system will continue to function until enough services are built where then new UI and interfaces can be built to replace the legacy systems.
Phase 1:
Build new service API for owner and vessel. In this case, the Owner service will be a newly branded service referred to as Stakeholder. The services will only contain what they need to do the intended job and not all existing database elements or functions may be required. The existing system will continue to function as currently designed updating all existing data elements. In this initial phase, the existing legacy systems will undergo modifications that will send Vessel and Owner transactions for creating and amendments to the new services to keep this data in sync between the old and new systems as well as a consolidation of the data into a single source of information.
The plan would be to build a single simple integration job to migrate the data from the two core systems into the new centralized service layer.
Phase 2:
Once the system is verified that data is flowing into the new service and we have started the process of vessel consolidation, the construction of a new Vessel search should be undertaken. New systems would be able to utilize this new API for all search capabilities and lay the groundwork needed to use Composite UI Microservices to decouple the UI changes into service approach (https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout).
Phase 3:
Investigate and implement a registry service layer to consolidate the registry data and services. This would follow the same approach as the Phase 1 where the integration is both updating the existing and new services layer data.
At this time it must also be noted, that based on the Single Responsibility Principle (SRP) and the common Closure Principle of Microservices the team may recommend that multiple services are required. For example, the Pleasure Craft Licensing may be different from the Small Vessel registry so we end up with both a License and Registry system.
The SRP defines the responsibility of a class as a reason to change and states that a class should only have one reason to change. As an example, consider a module that compiles and prints a report. Imagine such a module can be changed for two reasons. First, the content of the report could change. Second, the format of the report could change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should, therefore, be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.
(Wikipedia https://en.wikipedia.org/wiki/Single_responsibility_principle )
In the Common Closure Principle classes that change for the same reason should be in the same package. Perhaps, for instance, two classes implement different aspects of the same business rule. The goal is that when that business rule changes developers, only need to change code in a small number, ideally only one, of packages. This kind of thinking makes sense when designing services since it will help ensure that each business rule change should impact only one service.
(Wikipedia https://en.wikipedia.org/wiki/Package_principles)
Phase 4:
Assuming at this point that the new architecture and services built can do the work of one or more existing registry applications the team can either decide to continue to add more services or start to modernize the UI stack to better leverage the services layer while refining the capability of the existing services. A new UI later for the administration of the Registry process needs to be constructed to remove the dependence on the legacy monoliths. When the users can perform the basic duties using the new services the teams can then look at building a new online stakeholder Registry Intake process that does not rely on the forms, thus providing a full digital registry offering for Small and Large Vessel.
SRCS may require a few more components to complete the design, i.e. mortgage capability, before fully replacing that system. However, as the team matures in the design and since all services are essentially independent and loosely coupled, the introduction of new services can be developed in parallel by separate teams.
Phase 5:
Online Intake, incorporating more vessel registry systems into centralized services. Systems such as Port State, SIRS, as well we have some systems the read and duplicate the data can all be looked at.
NOTE: In the agile processes will be assessing functionality with the product owner and business stakeholders, new services and features will be identified throughout the phases to assess the viability of decoupling from the legacy monoliths.
RoadMap
Create the Microservices for Vessel and Stakeholders
"Vessel" represents the details related to the characteristics of a vessel shared across SCVRS and SRCS.
"Stakeholder" is those parties that a required to interact with a vessel registry system and include, Individuals, Corporations, Indian bands, Federal and provincial governments.
In this case, we are mapping out the core features for vessels and ownership, which include but are not limited to Adding a vessel, making amendments to a vessel, tracking ownership, maintaining a stakeholders
Build an Integration layer to map owner and vessel data from legacy data sources to new Services
Identify required methods and create a Backend For Frontend gateway (BFF GW) layer for SRCS
Identify required methods and create a Backend For Frontend gateway (BFF GW) layer for SCVRS
Identify and update the applicable business rules layer in SRCS to call BFF GW. Calls would be done post updating of existing functions. With logging functionality and applicable resiliency in case of failure, we want to be able to track and handle a replay.
Identify and update the applicable business rules layer in SRVLS to call BFF GW. Calls would be done post updating of existing functions. With logging functionality and applicable resiliency in case of failure, we want to be able to track and handle a replay.
Create a new search service that uses the new centralized Vessel service.
Create a new registry service using a process similar to what was done for Vessel and Stakeholders
Assessment of service functionality/build unified Registry Processing UI functionality and refine existing services. Identify any remaining services needed to remove the dependency on SCVRS. At this point, we should be able to start removing users from the legacy system.
Mortgage services allowing for the removal of the SRCS dependency.
Digital process for Registry intake