Components and Reuse Tom Carlson National Center for State Courts

The Problem ► The problem  IEPDs were being developed from scratch, often in isolation  Model gives loads of flexibility  Similar concepts implemented in dissimilar ways ► Short example: PersonFullName versus PersonGivenName combined with PersonSurName ► Makes interoperability hard

What We Did ► Developed a bunch of court IEPDs ► Looked for commonalities  For example, most included: ► People of some sort ► A court of some sort ► Built court components using those commonalities

What It Looks Like ► Data Modeler Domain Model Thingie

What It Looks Like ► Data Modeler Domain Model Thingie

Limitations ► Locked in a proprietary tool  It’s a nice tool, but it’s proprietary ► No mechanism for sharing these components, outside of the proprietary tool ► No mechanism for using components built by others in other ways

Why It Doesn’t Matter ► Moving to a Service Oriented Architecture resolves the problem ► Exchange-based IEPDs will become Service-based IEPDs ► Those services will be composed of micro-services  Composability is a principle of SOA  Think fractals ► Those micro-services become the components ► The process of defining these services creates the components too! Sweet!

What We All Need To Do Instead ► Stop defining IEPDs in terms of exchanges  Services based on “as is” exchanges result in services that codify “as is” processes  Need to be able to create “to be” processes from the services ► Think of a code library  If based on legacy code…  …then will only be good for coding legacy apps

What We All Need To Do Instead 1.Start doing Functional Decompositions of the Business  What is it that we really do 2.From that decomposition, we can determine the services available 3.Then we can create new business processes from these services  This could be done with JIEM, with some significant changes ► We will need the Justice Reference Architecture (JRA) in order for this to happen

For More Information ► Contact Me:  Tom Carlson  ► For Service Oriented Architecture (SOA)  Scott Fairholm  ► For Justice Reference Architecture (JRA)  Tom Clarke 