2022 General Meeting Presentation: JRS

Print Date: 12/3/2024 12:06:57 PM

90th General Meeting Speaker Presentation
“Introducing JRS – The National Board Jurisdictional Reporting System”
Mark Mooney and Jacques Couvillon (Featuring Lonnie Standridge)

The following presentation was delivered at the 90th General Meeting Monday General Session, May 2, 2022. It has been edited for content and phrasing.

INTRODUCTION: Mark Mooney is the National Board's Director of Operations - Software and Services, JRS. Mr. Mooney has 35 years of industry experience as a boilermaker, operating engineer, inspector, and manager. Mooney was the Massachusetts chief boiler inspector for 12 years before joining Liberty Mutual. A former member of NBBI’s Board of Trustees from 2001 to 2009, Mooney is a past chair for the National Board Inspection Code Subcommittee on Inspection.

Jacques Couvillon is the National Board's Director of Product Management, JRS. Mr. Couvillon is responsible for the creation of an inspection management solution for the boiler and pressure vessel industry in North America. He spent 16 years as the Director of Regulatory Software for Praeses, a software and IT services company, where he served as the business leader for Jurisdiction Online, a software that supported jurisdictional object workflows for state governments and the insurance carriers required to report to them.

Mr. Mooney and Mr. Couvillon’s slide presentation can be found here.

MR. MOONEY: Let's talk about JRS.

MR. COUVILLON: That sounds good. It's been almost two years since we started the project. We've hired over 20 people since then.

MR. MOONEY: It's been a very short period. Before we start that, let's bring up our Director of Development, Lonnie Standridge. Lonnie, come on up. Lonnie has been integral in hiring a development team among the 21 developers that we've got, as well as the development of the process. Lonnie, thank you so much. Lonnie, why don't you introduce our team?

MR. STANDRIDGE: Ladies and gentlemen, the JRS development team, please stand up.

MR. MOONEY: They have done an amazing job. And I appreciate all the hard work that you've done. Jacques, as you know, JRS product is a product built by the industry, for the industry.

MR. COUVILLON: Mark, why don't you share what you mean with the audience.

MR. MOONEY: Well, as you know, we started creating an Advisory Task Group consisting of jurisdictional members, including Donnie LeSage from Louisiana; Matt Sansone from New York; Eddie Wiggins from Alabama; and Steve Townsend from Prince Edward Island.

We also have three carriers on the Advisory Task Group consisting of HSB, Scott Brodkorb; FM Global, Phillip Cole; and Travelers Insurance, Bill Barbato.

In addition, we've been reaching out to all the insurance carriers as well as trying to reach out to all these jurisdictions to get as much input into our program as possible, so it's truly a system that is getting a lot of input in the design throughout the industry. And thanks to everyone for their continued input. We seek to continue to have that input.

Now, for the release of the first quarter of 2023, it's going to support the complete boiler and pressure vessel inspection workflow. Although the manufacturer data reports and repair records will not be part of the first release, these documents will eventually be available within the system completing the complete lifecycle of the pressure equipment.

Now, Jacques, why don't you give the audience a peek into the JRS system and its timeline.

MR. COUVILLON: To start this afternoon, let's talk about the system's purpose. As Mark mentioned, the purpose of the program is to support the complete lifecycle of boiler and pressure equipment. So many of us have probably been subjected to systems that were built for one purpose but modified for a different purpose. We might have a permitting program that was modified to support inspections or a risk management program that was supporting equipment.

And we know that these systems, while they can work, we might end up with just not a natural user experience. The benefit and the purpose behind JRS are to very specifically support that boiler and pressure vessel workflow.

There are a couple of key themes that I want to share with you that we use to rally around within the JRS team. One of those key themes is standardization. We're trying to move the system to standard NB 6 and 7 set of fields. We've got four fields that are at the policy, the location, and the equipment level, as well as the inspection level, but we're supporting the ability to configure and customize the system with user-defined fields. And I'll share that with you here in a bit.

Our second key theme is built by the industry, for the industry. As Mark mentioned, we've leveraged the wisdom of a great Client Advisory Board. We have staff that's been helping. We've been presenting to both jurisdictions, inspection companies, and carriers. Everyone has provided feedback and that feedback has really informed our development roadmap, informed our design and has really been a very critical part of our development process.

There's also a couple of key core values that I'd like to share that we hold near and dear to the JRS project. The core values of the National Board: Quality, integrity, customer support, and teamwork.

There's a couple of those that I want to touch on this afternoon, but the first one of those being teamwork. You guys just got introduced to our JRS development team. That team, along with the rest of the National Board staff, guys like Mike Burns, Luis Ponce, we've really benefited from that wisdom, as well as the Client Advisory Board and everybody else that's sharing their time and giving attention and input into the product.

That second core value is customer support. When I came here, it was a very, very warm reception. It started with our Executive Director Joel Amato. It's been a very customer friendly environment. Joel has really driven the fact that we need to take care of our clients, whether it's an insurance company, a jurisdictional member, an inspection company, really the entire ecosystem. One of our focuses is really highlighting that National Board core value of teamwork.

The last thing I'll share with you on this line is our mission. It really compliments the National Board's mission, and it's to enable safety in the boiler and pressure vessel space; the under pressure equipment space.

In terms of workflow, the jurisdictional workflow that will be supported inside of JRS starts with that ability to plan work in anticipation of performing the inspection. Once we perform the inspection, we'll have data capture screens that allow us to manage contact and location information, as well as an ease of use to enter inspection/violation data. From there the jurisdictions will be able to perform QA or review those inspections or changes that are submitted. And then they'll move on to the next step in the workflow, which is managing their fees and invoicing either the location owner, the appropriate party for either the certificate or the inspection. We'll take that all the way through entering all the accounting process, recording the payment information, and generating that certificate.

On the carrier side, we'll start with integration with policy management systems. We'll support location matching for taking on new locations that are part of the policy. We'll then allow the inspectors to plan their work, build appointments to go out and perform those, plan their routes, enter those inspections, violations and/or recs and then capture those ancillary workflows, like time and expense, building a letter. We'll make that data available for data marts and all reporting purposes.

As we mentioned in the opening, we've been in development for about 16 months now. We've completed quite a bit of our roadmap. And we're happy to demonstrate that to anyone at any point in time, but users now can log in, hit a homepage. They're able to configure policy, location, and equipment, user-defined fields in the system. We're able to successfully complete the inspection submission, including the ability to add a violation to a piece of equipment or a rec to a location.

We've got a good bit of work to do over the next nine months. And this is what we'll be focused on. We'll be focused on the carrier workflows, facilitating things like creating a letter and adding a letter to the location, things like location matching, and adding time and expense to the system.

For our jurisdictions, we'll be focused on the accounting process, the ability to add and manage a fee schedule for your jurisdiction; the ability to do all of the accounting from generating an invoice to adding a payment to complete that accounting process.

We'll also work on finishing out the QA review process. All the while we'll be focused on getting data into the system and testing the system along the way so that in the first quarter of 2023, we're ready for the product to come to market.

In summary, JRS is a system that's going to start with the inservice inspections and then over time incorporate the registration process, which includes the manufacturer's data report and repairs. All of that will be done in a centralized database and the system will be accessed by the user's device of choice.

Mark, that completes our product update for the day.

MR. MOONEY: Great job, Jacques. Thank you so much. Lonnie, from a development standpoint, did you have anything to share with the audience?

MR. STANDRIDGE: Sure. Thanks, Mark.

For us to reach the level of excellence of the National Board that you guys are accustomed to, we, as the development team, need to develop a technical edge. And I don't just mean on the industry. I mean on technology. How do we go about doing that? Well, one of these terms that I've been circulating quite a bit lately is futureproofing.

What does that mean? Think of it this way — you all have phones, right? I want you to look at it and say this is outdated. And you're like, well, I just got my phone. Well, I know it's outdated, because what's being developed today and what's being sold is what's going to be sold in two years, three years. And for us to have that kind of leverage on the industry and on technology, we need to be building technology for tomorrow. This is a huge philosophy for me and my team. We're not just using the technology of today; we're looking at the technology of tomorrow.

How do we do that? We must stay ahead of the curve. We must be looking at what's happening in the future with technology. We want to have this product be resilient to change. That means that the product needs to be agile. We need to be able to adapt. I'm sure some people in this room are used to hearing we can't make that change because we need to rearchitect the system or we need to redesign the system. I'm an architect outside this, so we need to be building this product in a way that we can change out parts and do different types of things without having to rearchitect the system so that this product is resilient for the next 10, 15 years and can adopt to the technology as it changes with it.

To do that, we must stay current. You know, we're all victims of technical conditioning and that's what developers do. But if you don't believe me, go into one of these elevators and see how many times you try to press a button once you get inside, right? We're all victims. I mean, how many times have you checked emails since you sat down? This is something that even developers must work on in order to stay current. We must do some continuing education. We must see what's happening with some of the big players, the big hitters in the market so that we know what's coming and we can develop for that.

We need to start inventing and not reinventing. This has been a little bit of a challenge for me being an architect. I've been in business 26 years designing, implementing, and architecting software at the enterprise level. And I'm a little bit of a control freak when it comes to code. I want control of the code. But we're in a day and age right now where a lot of this technology is done for us in such a way that we can probably walk away from 75 percent of the infrastructure that we build with our technology and just focus on the invention of what we're trying to solve.

Stay close to the problem and solve the problem, right? And that's what we're trying to do. So how do we go about this? How do we go about having this technical edge inventing and not reinventing? We leverage cloud technology. I would imagine by now cloud doesn't just mean a white puffy thing in the sky for you guys, but as more a place to store files. Cloud means that we can store infrastructure. Five years ago, this was all done on premise. Now we can have our infrastructure managed by people that do nothing but that, so that we can just focus on the product. And this is a huge thing.

Some of the things that it also brings us is load balancing and auto scaling. As we bring on more clients and the system is getting hit maybe at peak times, the infrastructure will scale automatically so you won't get those timeout types of calls. You can manage an infrastructure on your own in your own data system.

Service integrations, that means that all the cloud service integrations that are going to be provided to us — and I'll talk a little bit about those, I don't want to take too much of your time today — but those will all be integrated together through our cloud service provider. Again, a lot of these things we must do ourselves. We must architect this. We must engineer it. We must write the code for it, then we must maintain the code for it. If we can offload some of that, we can be able to push the product forward much faster and in a much more stable manner.

One of the other things that we get with service integrations is federated security. Those are big words. It basically means that as an engineer, we need to not only let you call a piece of code, any of our code, we need to know who you are. Are you able to call this piece of code? And write all the code, be able to manage all of that and then maintain it. By using cloud technology, we get that for free as well.

Some other things that we're bringing to the table is automated testing. When we make a change to the system, we don't want to have to go retest everything by hand. We want to be able to press a button and have the entire system be tested and impression testing and all the things that we know need to be tested and all the things we don't know that need to be tested.

CI/CD pipelines — that's not just a fancy acronym. CI stands for Continuous Integration and CD stands for Continuous Deployment. And what that means is that we can streamline changes straight to production. I'm sure up until recently you guys are used to a change to the product taking weeks, months to see. By developing with more modern technology using this kind of deployment, we can deploy changes in a streamlined fashion fast.

We're also using agile methodology. Earlier I mentioned that we needed to be agile as a development team with our technology. So that applies to our processes internally, but also to our code. We need to be able to change, right? We can't get to a place where we get so far with the product that, we say that we can't change this thing unless we go and rewrite it. By developing with this agile methodology, we can support this kind of thinking.

We're developing a business rules engine. This you guys will absolutely love. So, this will separate the actual logic of the rules for, let's say the jurisdiction, that means a certain criteria and another criteria and another criteria. And you want to add another criteria to that. Up until now you would have to compile the code into a whole deployment of the code for that to happen.

By separating our rules for this from the actual code that calls the rules, we can manage those rules outside the application and just have other teams be able to make these types of changes in these conditions on the fly, which basically means real-time.

So, in the works there are some cool buzzwords maybe you guys have heard already. If you haven't, a quick blurb on this.

Microservices just basically means that we're looking at breaking our core application into smaller little services that can be managed independently so that we can deploy these services independently. This plays right into the CI/CD pipelines that I mentioned. Also, it helps us be able to scale and make changes to different pieces of the system without disturbing other pieces of the system. This is a popular approach to development that's really hit the industry very hard. And, again, as we're future proofing this application, we're thinking about our pieces of coding with this in mind.

Serviceless architecture. This is another thing we're taking a hard look at and starting to implement. This means we'll be able to serve up code without the server. Cloud technology today allows us to execute code without having a physical server not only locally or in a data center, but also in the cloud itself. A lot of cloud providers provide this and we're looking at using this technology as well.

Event driven design. This is another term that is becoming very popular in the industry. This allows us to be able to have our services communicate with each other, which is good for us. But in terms of how it affects you guys is that we can expose some of these things so that we can take on events or changes that are happening inside of your systems, if you have any systems that we're integrating with, and be able to make those changes or import that information on the fly.

Data and big data tooling. We have all kinds of new modern tooling that helps facilitate the things that we can do with data. Data is a very important piece to our system in all the information, so we want to be able to give you guys the ability to be able to do it and learn from it.

So, what does this mean for you?

Faster integrations. If you are integrating with our system, by taking the approaches that we're taking right now, you will be able to stand up with our system much faster.

Near real-time data exchange. Maybe you're used to doing batch processing where you send a file, we process that entire file, it takes overnight or something like that. By providing a near real-time data exchange, we can just take in one record as they're coming in in a different type of format where we can process the information while it's happening, or we take your file overnight and we process it through ours in the same way until you can get to that, but we'll be able to provide that kind of integration for you.

Authentication integrations. This is really big if you want single sign on. If you want to integrate your sign on with JRS, we'll be able to provide that by using the technologies that we're using today. If you already have an authentication provider, you'll be able to log into that and integrate with our system.

And, of course, fast deployments. This is a big thing. We want changes. We need to see changes get to the system as quickly as possible, so this is another thing we'll be able to bring to you.

If you have any questions related to any of the technology, please see me after.

MR. MOONEY: Great job, Lonnie. Thank you, team. You're doing a fantastic job. Really appreciate it.

In summary, JRS is going to be a product that gives the birth to death tracking of equipment, including EDT. EDT is Electronic Data Transfer. It covers the manufacturer data reports. That is now transitioning to something we call JRS Register. So, what we're developing right now is JRS Inspect. JRS Register works great and well with JRS Inspect. And in doing that and creating the JRS Register, we have developed an Advisory Task Group for that, included two boiler manufacturers, two pressure vessel manufacturers, two repair organizations and two insurance companies, and one jurisdiction to make sure that, in fact, we have continued to create a product that is built by the industry, for the industry.

It's going to support the specific workflow using centralized database. As I said, it is built by the industry, for the industry. It's going to influence inspection and violation of standardization across jurisdictions. It's also going to have the ability to work directly with stakeholders to address the needs of the entire ecosystem. And it's completely managed by the National Board as a nonprofit. And as a result, JRS will never be bought or sold.

I want to thank you for the time you've taken. We're going to release this in the first quarter of 2023. If you have any questions regarding the system or you'd like us to present to your company or your team, please contact Jacques and I or Lonnie after the meeting. We appreciate your time and attention. Have a great day.