ECF 5: Open Letter to the ECF TC

["Price, Jim" <JPrice@courts.az.gov>]

Dear TC,

 

I am writing you to express my views about the ECF 5.0 specification relative to this week’s face-to-face meeting in Salt Lake City and my July 10, 2017 no vote for publishing the then existing ECF 5.0 spec for public review.  You should be able to read my no vote justification and obtain copies of Arizona’s supporting ECF 4.01 specification documentation here.

 

My basic premise is that the XML schema alone is not ”the” specification, but a part of one.  There are too many places where interoperability can be compromised due to one person’s interpretation of a “flexible” schema.  Based on several years of implementing e-filing systems in Arizona, it is clear to me that business and technical considerations must be joined at the hip within the specification for it to make any sense.  This is particularly true for implementers and testers, and, ultimately, the stakeholders asked to endorse (read: pay for) it.

 

Depending on the type of court system (consolidated or non-consolidated) that plans to rollout e-filing, the number of stakeholders involved in its delivery can be extremely daunting.  Here are a couple of lessons learned in a non-consolidated court system:

 

1. Most developers do not read or want to read the specification documents.  Developers in this context include e-filing system providers (plural), case management system providers (again, plural), and integration specialists (you guessed it, plural).  Instead, developers tend to want to reverse engineer sample XML messages and hope that they get things right.
2. Because the ECF specification is “flexible” in certain areas, the result of literally months of programming effort will typically fail to produce the expected positive results.

 

Both of these lessons are expensive to correct, cause major dissention among the various development teams, and run the risk of giving the ECF specification a political black eye (“The specification is too complicated.  Why does it make e-filing so difficult to implement?”).  Once political support wanes, regaining it may never happen.

 

The promise of the ECF specification is that it is the key to the golden handcuffs.  The ECF specification should be looked upon by ALL implementers, vendors and non-vendors, this way.  If the specification is a good one, no implementer who follows it can implement proprietary solutions that are costly to develop and integrate, difficult to maintain, fail to cost-effectively scale over time, or, worse, fail to deliver value to the Judiciary.

 

The TC has made significant progress since the July 10, 2017 vote.  Jim Cabral has scheduled meetings once a week since then so that the TC can review issues identified by members and non-members alike, and make constructive changes to the specification accordingly.  Major kudos to Jim C, Gary Graham, Tyler, Green Filing, and other members for their contributions.  There is still, however, much work yet to be done.

 

This week’s face-to-face meeting hopes to resolve the issues that have been identified thus far.  This is goodness.  Ultimately, the TC should be delivering a specification that guides the flow of information seamlessly and consistently throughout the e-filing ecosystem, i.e., between the MDEs.  Achieving a level of specificity that is “good enough” and addresses the lessons learned outlined above, in my opinion, requires consideration of the following:

1. Normative (preferred) and non-normative examples.  Implementers who create the applications that generate, transmit, and receive messages should know exactly what’s expected of their products.  Their efforts should not be hit-or-miss propositions.
2. Clear and unambiguous terms.  Using different terms to describe the same concepts or message structures is confusing for everyone and can cause unnecessary implementation delays (e.g., Submission ID, Transaction ID, Message ID, Filing ID).  The ECF’s lingua should be franca.
3. Use Cases that support the XML schema.   The XML schema should be supported by Use Cases.  If certain elements are not used and do not add business or technical value, then there should be no reason to keep them.  These remnants are unnecessary overhead that invite gremlins to infiltrate applications, impede success, and protract time-to-market opportunities.

 

The TC will be taking another crack at gaining approval for distributing the ECF 5.0 specification for public review.  I simply ask that you take these factors into consideration when casting your vote. 

 

To be clear, no specification is or should be expected to be perfect.  The ECF 5 specification is no exception.  There will always be a need to refine the specification over time due to changing business demands and new technology solutions, so targeting perfection in this regard makes no sense.  On the flip side, having a specification that provides implementers the guidance they need to collectively achieve success quickly and inexpensively makes a lot of sense.

 

Sincerely,

 

Jim Price

Arizona Supreme Court