CMS 360

Software Architectural Roadmap – Court CMS

Version 1.0:  2/29/2024

Author:  Richard Watts

Executive Summary

Brief overview of Court CMS software architecture landscape and the planned architectural changes to address technical debt, improve scalability, and enhance performance.

The Court CMS (CMS360) is a web-based application built on .NET Framework 4.8 with a tightly coupled business layer and data layer.  The system only supports Microsoft SQL Server databases.   

There are several ancillary programs that use the Court CMS business layer and/or databases. These include web services, console applications, and additional secondary applications such as EZ-Filing and PayYourTix.  All these applications are using .NET Framework 4.7.2 or .NET Framework 4.8.  Many of these programs use the Court CMS business layer via a reference to each individual project (tightly coupled).  Some applications directly query the databases themselves.

Thoughts on Modernization of Court CMS

It is my opinion that the Court CMS can be modernized in pieces over time, without having to risk a full rewrite that would take years to do without anything to show for it until it was complete.  The initiatives indicated in this document illustrate the path to modernization.  A brief summary of these steps are as follows:

1. Update the business and data layer to a modern .NET version.

1. Create an API application layer that utilizes the updated business/data layer.

1. Remove the business and data layer coupling from the UI and point it to the new API layer instead.

1. At this point, the back end could be further separated into individual microservices.

1. A new UI could now be written and pointed to the new API layer.  The new UI work could be started at any point after step 2.

The above would allow for the current product to be enhanced for improved performance and scalability while a new modern UI was created.  Both new and existing UI would be pointing to the single back end.

Current Architecture Assessment

Overview of technology stack

·         Front End:

o   .NET Framework 4.8 (C#)

o   UI built with Webforms

o   JQuery

o   JQuery UI

o   AjaxControlToolkit

o   Gleamtech.DocumentUltimate for PDF/Word doc display

o   Telerik components for UI

o   ActiveReports for reporting functionality

·         Back End:

o   .NET Framework 4.8 (C#)

o   Microsoft Entity Framework

o   Aspose Total (Words/Pdf/Imaging) for mail merge, pdf, and image manipulation

o   Twilio for Text Messaging

o   Microsoft SQL Server databases

o   Open-source database triggers are used for database auditing

Assessment of system scalability, performance, and reliability

Scalability is limited to horizontal scaling (i.e. adding more servers within a load balancer).  Due to the lack of asynchronous functions, performance can be slowed by an increase in the number of users that are in the program and/or by long running processes.

Identification of architectural bottlenecks and pain points

• The system currently does not take advantage of async technology on the backend which results in bottlenecks and slower performance.  Large reports are often a bottleneck as well due to the increase in CPU and memory which negatively affects other applications on the server.  The primary delivery of client content to the server is via server postbacks rather than a more modern API service call.  The current approach causes the entire page to refresh unnecessarily and results in slower page load than more modern methods.

Evaluation of security posture

• The system uses Forms authentication to login to the program, meaning a user must login with a username and password to access the system.  Password policy is available but not required for most customers (enforcing this for hosted customers is currently being worked on).  Two factor authentication is not currently available but will be added via support for Catalis Identity Server (planned for 2024 release).  Updating third party components/references has been done for our next release, but updating these components is needed more often for improved security.

Review of development and deployment processes

• Current deployment involves a manual publishing of the product on a local development machine and copying updated code into place in each application.  Database scripts are run on each set of databases to deploy changes.  Both are time-consuming and result in slower rollouts to customers.

Vision and Goals

Adoption of modern cloud-native technologies:

·         Add AWS S3 bucket support.

·         Move sensitive configuration information to AWS Secrets.

·         Move CSS and scripts to a CDN using AWS CloudFront for improved performance.

·         Review functionality in CMS360 and secondary programs to see where Lambda functions could be utilized.

Microservices architecture for improved modularity and scalability

·         An API layer needs to be added to separate the UI from the backend.  This would also allow the system to be updated in pieces (backend to .Net 8 first, then UI can be handled later).  Updating the backend will also allow for separate containerization from the UI so it can scale as needed on its own.  The current business layer has some separation into service class architecture, but this needs to be reviewed and updated to a more microservice driven architecture.

Containerization and orchestration for efficient deployment and management

·         We have been able to successfully deploy the CMS into a containerized environment for dev and QA sites.  However, this needs to be extended to deploy containers into production environments to ensure a full CI/CD path.  Serverless architecture should also be considered if possible.

Enhanced security measures to protect sensitive data

·         The database needs to be changed to ensure that sensitive data is encrypted at rest.  This will require changes not only to the database but to any applications that use this data.  In transit data should already be encrypted with SSL, but further review should be performed to ensure the best level of protection is being utilized.

Automation of development, testing, and deployment processes

·         CI/CD is already in progress but needs to be moved to DevOps (it is currently on a Jenkins server).  The ability to deploy straight to production server will be needed as well, including the ability to create new for new customers.  An enhanced database deployment procedure should be investigated.

Architectural Principles

• To modernize the Court CMS, we need loosely coupled layers that can be more easily replaced as technology changes.  Adding an API layer is of the upmost importance.  Not only for the internal modernization of the product, but also to allow for third parties to take advantage of it to interact as needed with the system.  Most RFP documents I have seen over the last couple of years have asked about an API layer.  Full CI/CD is also a must as the current method of deployment is slow and requires too much manual work.

Key Initiatives

Description of major architectural initiatives or projects planned to achieve the desired future state, including (where applicable):

Initiative 1:  Microservices Migration

·         Description:  The business layer is currently broken up into C# service classes.  These classes interact with each other directly at times within the code.  Boundaries need to be put into place so these class services can be moved to microservices and separated properly. 

·         Objective:  Improve agility, scalability, and fault isolation.

·         Timeline:  Q4 2024-Q1 2025

·         Key Milestones:  Refactor codebase, improve and isolate existing service boundaries.

Initiative 2:  Cloud Migration

·         Description:  The hosted Court CMS is now fully in AWS.  However, enhancements need to be made to make the system more integrated with cloud technologies.

·         Objective: 

o    Add support for S3 buckets for all file routines, including images, template storage, temporary cache folder, etc.  

o    Move CSS and script files to a CDN using AWS CloudFront to improve performance and caching.

o    Move any sensitive configuration to the AWS Secrets vault.

·         Timeline: Q2 2024-Q4 2024

·         Key Milestones:  Improve performance and security by taking advantage of cloud technologies available in AWS. 

Initiative 3:  Move to full CI/CD Deployment

·         Description:  Complete move to full CI/CD Deployment.

·         Objective:  Move CI/CD to Azure Devops instead of the current Jenkins Server.  Make sure all phases of the process from build to production are operational.

·         Timeline:  Q3 2024-Q4 2024

·         Key Milestones:  Improve efficiency and rollout of updates to all hosted customers via a full CI/CD deployment path.

Initiative 3:  Update back end to .NET 8

·         Description:  The Court CMS will need to be updated to a modern .NET version (.NET 8 at the time of this writing).  It is my opinion that the back end should be separated from the front end and targeted for the update first.  An API layer will need to be written and the current UI pointed to it to de-couple the business and data layer.  Functions and procedures should be updated with the async keyword to reduce bottlenecks that currently exist.

·         Objective:  The current back end should be modernized to use clean architecture and better separated to true microservices.  The data layer is currently a mix of Entity Framework, SQL, and POCO classes.  A decision should be made as to whether to fully embrace Entity Framework or move to another OEM such as Dapper.  The back end should also be enhanced to support multi-tenancy.

·         Timeline:  Q4 2024-Q4 2025.

·         Key Milestones:  Complete separation of the UI layer from the back end to allow containerization of the back end for scaling on its own.  Support multi-tenancy in the back end.  Set up a path for the next generation UI to be built from while also allowing the current UI to use the new back end.

Initiative 4:  UI Modernization

·         Description:  The current UI is written with Microsoft webforms technology.  A rewrite of the UI to have a more modern look and use modern technology will be necessary.  Since many Catalis products seem to be moving to Angular for front end design, that may be the best path for Court CMS as well.  However, further discussion may be needed.

·         Objective:  Create a new UI using modern technology while maintaining full functionality that exists today.

·         Timeline:  Q1 2026-Q4 2027.  This would be dependent on the resources available to the project.

·         Key Milestones:  Have a fully modernized UI layer that is scalable separate from the back end.  Ensure the UI is a single application that supports the multi-tenancy that the back end will have once it is modernized.

Initiative 5:  Database modernization

·         Description:  The Court CMS currently utilizes up to 6 separate databases.  A common install could consist of a Common database, Accounting database, Civil database, and one or more databases that would include Criminal, Juvenile, and Magistrate.  Table names and column names are 30+ years old in some cases.  Some tables have over 200 columns in them.  The databases need to be modernized with more descriptive names, utilize normal form design, and move to either a single database or at the very least fewer databases (this would need to be reviewed and discussed by development).  Database auditing is currently handled via a third-party open-source trigger-based system.  A more modern and preferably database product native alternative should be considered.  Supporting non-Microsoft SQL databases such as PostgreSQL should be a goal.

·         Objective:  Condense the number of databases needed for the product and modernize the design for better performance.  Update auditing to use more modern methods and hopefully ones that are native to the database provider.  Support at least one non-Microsoft based database that better integrates with AWS database services.  This will also allow for cost benefits.

·         Timeline:  Q1 2026 – Q4 2026

·         Key Milestones:  Have a modern and normalized database structure that utilizes less databases than are needed currently.  Add support for a more native AWS RDS.

Initiative 6:  Research and implement ways to enhance the product using AI/Machine Learning

·         Description:  With the arrival of modern AI technology, we should begin to research how the Court CMS can be improved using machine learning and AI.  Some areas to initially focus on could be autosuggestions in various areas of the program.  For instance, auto-suggesting a set of sentences based on prior sentencing of similar charges to the one the user is working on.  A more ambitious goal might be to allow users to use AI to create their own reports.  This, however, would need additional research and may depend on other products in the market.

·         Objective:  Research and implement ways to improve user efficiency by utilizing AI in the Court CMS product.

·         Timeline:  This is something that could be started and built upon at any point.  A decision would need to be made as to whether to wait until modernization efforts are complete or start with the current product.

·         Key Milestones:  Improve how the users interact with the product.  Increase product efficiency using new AI techniques.

Timeline and Milestones

It is difficult to determine a definite time frame as other projects are in the works.  The time frame for changes could need adjustments as issues arise during each step.  Major milestones would include:

·         Demo of the current UI using the modernized back end.

·         Demo of the new UI at various stages, including but not limited to:

o   Basic CRUD operations

o   Reporting (including mail merge)

o   Batch Processing

o   Transmits

o   Administrative screens

Dependencies and Risks

Web services and console applications that use the business layer and/or current databases need to be identified and updated to ensure any changes to the main Court CMS are accounted for.  The public web search would also need to be updated.  Ideally these programs would be updated to use the new Court CMS API Layer once it is in place.

The number of developers and resources available for all initiatives could affect timelines.  Other projects, integrations, etc. will probably cause timelines to have to be moved or adjusted.

Further discussion of the new UI will need to take place to determine the proper path.  Some decisions that will need to be made include (but are not limited to):

o   UI Framework (Angular?)

o   Should the system allow for tabs like the current system has (may not fit modern UI principles but has proven to be useful).

o   Position of main menu (Left side?  Top?  Configurable?)

o   How to replace current Ribbon Bar (current UI uses a Word-like ribbon bar, which is not a component available in more modern components that I am aware of).

Resource Allocation

Additional developers working on the project would be good to have.  Some parts of the modernization effort could possibly be done with the current resources we have if more time and focus can be allocated to the modernization effort than other projects.  However, at the very least additional developers will most likely be needed for the UI modernization in order to speed up the time frame to reach MVP.

Governance and Oversight

·         Maintain current functionality of the program to provide a seamless transition.

·         Run security scans on the code and project as it is implemented.

Communication Plan

Before initiatives begin, generating a separate document with diagrams outlining the planned changes might be beneficial to have.   These could be reviewed by the vertical architecture group and management to get different opinions on how plausible each architecture step would be and to identify any “gotcha” scenarios.  Prior to new UI work, possibly have demos comparing the old and new back end to see performance improvements.  Once new UI works has started, regular demos can be planned in additional to the usual sprint demos. 

Metrics and KPIs

CPU and memory usage can be used to gauge how performance looks prior to and after each architecture initiative.  Load tests can be performed before and after as well to see how the system has changed when under stress.  We are just getting settled into AWS, but I believe there are some reports there that would be beneficial as well.

Review and Update Process

As the program is updated, we need to be aware of changes in current technology and be able to adjust the architecture plans.   No doubt newer .NET versions will be released during the modernization journey and the system should be updated to use it as they are released.  The same will be true of any UI framework that is used.  If new technologies or principles are introduced during the update, those should be looked at to decide if it is worth moving to, and if so whether it should be done immediately or be planned for a future enhancement.