Toward a Real-World Application Architecture for Courts: A Component Model (Part 2)

Topics: Access to Justice, Case Management, Efficiency, Government, Justice Ecosystem: Technology, Legal Innovation, State Courthouses

component model

As we discussed in Part 1 of this blog series, the Joint Technology Committee (JTC) offers courts a path from case management system (CMS) products to a real-world application architecture through using a component model. With application components, courts can better meet user demand and performance requirements; but who and what ensures all the components make nice in the same system? The short answer: standards, vendors, integrators, and, if a court is large enough, a dedicated IT staff.

We also discussed court application components that make up traditional CMS products and add-on components, such as electronic filing services and payment processing systems, jury management, online dispute resolution and public access portals. Court application components with system-wide software — such as identity management, search engines and enterprise security — make up the application layer in JTC’s Court Technology Framework (CTF). The CTF comprises four layers: business, applications, data management and technology infrastructure.

The CTF business layer contains the business functions enabled by the application layer and its components. Since various components aim to replace a consolidated CMS, communication among components is critical. The JTF maintains that open standards must be used to communicate between components and orchestrate the interaction among all components. The CTF application layer combines application and communication functions, which brings up the application layer in another framework, the Open Systems Interconnection (OSI) model.


Beyond enforcing common communication protocols among components, courts need to rely on IT staff, vendors and integrators to keep a component architecture coupled together.


The International Organization for Standardization (ISO) produced the OSI model to represent and standardize the communication functions of a computer or telecommunication system. The model comprises seven hierarchical layers from the physical to the application layer. Each layer serves the one below it and, in turn, serves the layer above it. Using application programming interfaces (APIs), the application layer interacts with software applications to determine resource availability and to synchronize communication between applications and resources, such as other applications, content management systems, databases and search engines.

The CTF does not have to re-engineer communication standards at the application level. The OSI model has been doing it for years, providing protocol implementations — such as HTTP, HTTPS, LDAP and NFS — for the application layer. But courts must choose components that integrate with one another, where component deployment and management may be no less expensive or complex than managing an integrated CMS. Welcome to the API economy!

Beyond enforcing common communication protocols among components, courts need to rely on IT staff, vendors and integrators to keep a component architecture coupled together. In large courts, IT professionals on staff can test and verify communication among software components; but these tasks may require training and continuing education for staff to become proficient in supporting component software. Often, some staff will become proficient with certain components while other staff will focus on different pieces of the architecture. Inconsistent and spotty support can lead to increased component downtime. But at least the entire system won’t be down!


What was once a matter of acquiring and maintaining a CMS, with the requisite vendor relationship, is now a matter of supporting the various components comprising a software architecture system and numerous vendor and integrator relationships.


For smaller courts without IT support, vendors and integrators can mesh components into a software architecture. Vendors partner with other vendors to ensure communication between application components. Courts should verify that vendor relationships go beyond marketing campaigns and fully cover technology partnerships with proof-of-concept integrations in other courts or organizations.

Integrators are all about integrating component-level software architecture, hence the name. The ACM presents a large opportunity for integrators to work with courts and court technology to ensure all the software parts are working, talking and listening. With the ACM as a guide to modernization, courts should develop trusted relationships with integrators, because they will need them beyond deployment to maintain and upgrade components and help courts acquire new components to fulfill new capabilities and requirements.

What was once a matter of acquiring and maintaining a CMS, with the requisite vendor relationship, is now a matter of supporting the various components comprising a software architecture system and numerous vendor and integrator relationships. All told, it will require more time, money and people to support the ACM than a consolidated CMS, but it won’t be more costly than technology inertia and social irrelevance.