Consider the value of an Application Programming Interface (API) where needed

[greggersh]

Question/Comment on this U.S. Tax Court RFP

Name and affiliation

Greg Gershman, CEO, Ad Hoc LLC

Section of RFP documents

User Stories

Question/Comment

The draft RFQ clearly outline a set of user stories that detail the features of the application. In reviewing, there does not appear to be any user stories or requirements related to an Application Programming Interface (API). In addition to functionality that will be used by humans, it is often beneficial to build an application with a consideration for how it's data and business logic would be utilized by other systems. For example, there may be other systems with the US Tax Court, or systems outside the Tax Court, that may want or need to integrate information or functionality provided by the new system into their systems. The best way to do this is through an API.

When building a new system, many developers will take an API-first approach. This approach encourages an architecture that separates user-facing functionality from business logic and data. This allows, if needed, business logic and data to be accessed by other systems, either internally or externally, with relatively little effort. Using a RESTful approach to structuring an API also encourages good data modeling practices at the data layer.

If Tax Court sees this as something relevant, it may be worthwhile to define some requirements around an architecture that incorporates an API, and document some users stories for some of the systems that would use that API.

In addition, to the Tax Court's desire to avoid COTS products, an API could help alleviate the risk that the Tax Court takes on by incorporating a COTS product into their architecture. The most effective approach to avoiding vendor lock-in when developing a new system is to ensure that the customer (the government) has control over the data. When a customer gets locked in, it's often not as much the software from a vendor that facilitates the lock-in, it's access to the underlying data and its structure which makes moving to a new solution most difficult. With an API-driven architecture, the Tax Court could define the important data required by the system and its users, and then safely build and incorporate into their solution COTS products that are customized or adapted to utilize that data.

As an example, case management solutions are very common. There are many solutions on the market that provide a wealth of features with a relatively minimal amount of effort. These case management solutions can be integrated with a Tax Court system API so that the case management tool is not the ultimate source of the data; that would be the Tax Court's new system. Some parts of the system, such as the parts that the public interfaces with, could be completely custom-built, while other parts, which can be implemented using commercial products, can be easily integrated with the system's API. This flexibility will enable the Tax Court to leverage both custom and COTS solutions to their ultimate benefit, while at the same time ensuring the Tax Court can transition to another vendor of a COTS product (or decide to build their own version) at any point, since Tax Court owns and controls the data.

[randyhart]

Thank you for your comment. We will consider making adjustments to our final RFQ accordingly.