Welcome

Welcome to the PPLSI Blog. At PPLSI, we started a transformational technical journey a couple of years ago. We’ve had some great success, made some mistakes, but always learned along the way. We decided to start this blog to share some of these learnings.

As a first post, we’ll give a little background on where we started and how this journey began.

PPLSI is a 50-year-old company founded by Harland Stonecipher. Finding himself in a car accident, Harland realized that having access to equal legal protection was something all people could use, leading to the creation of LegalShield.

This was in 1972 and was well before the advent of modern-day computers. Outside of a few rare exceptions, people didn’t have personal computers in their homes or businesses. And certainly, Harland’s accident wasn’t caused by someone using a mobile device.

Naturally, the company integrated technology over the years. In the early 1990s, the company adopted a popular platform based upon IBM DB2 running on an AS400 iSeries.  This was the backbone of the company for several decades.

During the years, more modern technology was introduced through mobile and web applications. But the core system continued to run on the IBM Workhorse.

An attempt was made to replace this system with a more modern cloud-based architecture in 2018, but this project was struggling.

The team had taken an “all or nothing” approach to the design and deployment. When dealing with a 30-year-old platform, this is an extremely risky bet. There were multiple skeletons in multiple closets in the old system, and discovering and unpacking these would have taken years.

Equally problematic, the team was designing the new system as a monolith. There was one database, one middleware API, and one front end. While this may work well for a small team on a small to medium-sized project, it wouldn’t scale well from a development or deployment point of view.

In 2020 the company decided to head in a different direction. Instead of an all-or-nothing approach to a monolithic architecture, the company switched to taking a more modern approach. The team would leverage a common architectural pattern using micro-services. Smaller “bite-sized” backend components would be built and adapted individually.

On the front end, a similar decision was made. Instead of one monolithic website, smaller websites would be built that were specially purposed.  Logging in, accessing an account, and using individual products could all be smaller web applications.  A similar pattern could be adopted for other tools and services used by employees and partners. We call these individual small web applications “microsites”.

Our first decision was to standardize the platform for building this.  One for the backend and another for the frontend.

For the backend, there were many choices.  The company had experience with Java, .Net, Python, PHP, and Ruby. Our requirements narrowed things down quickly. We wanted a language that was strongly typed. And we wanted something a bit more mainstream to widen the talent pool.  We settled on .Net as our backend platform of choice.  Java was a close second, but in the end, we felt .Net required fewer “decisions” for us to make.

For the frontend, the team had a great deal of experience with Angular; but little in the way of standardization, shared code, or patterns.  Based on some of the experiences of our newly hired personnel, we went with React on the Web and React Native on mobile.  Since we were starting a lot of our work from scratch, this was an easy decision.

Once we picked the technology platform, we needed to figure out where to start. And since the core of any platform is identity, we started there. Users needed to sign in across web applications and access backends, and a strong notion of identity would be the glue for the entire system.

The identity architecture itself is simple and powerful. Users would sign in using a username/password. As part of this process, we would write a cookie as a JSON Web Token (JWT) into our root domain.  Individual microsites and microservices would receive this JWT, verify the token, and allow access as appropriate. JWTs are a standard, with many tools and libraries for creating, parsing, and validating them.

To build the identity system, we needed a backend to store the data and verify users and a frontend application for the user to sign in. We established a pattern and tooling to build backend microservices to make this rapid and easy. To build frontend applications, we created a library of React Controls and other UX Components to allow rapid but consistent development.

The next two posts will get into the detail of the frontend and backend architectures built to support this and future initiatives.

• Category: Uncategorized