Service Oriented Architecture

My JSON Resume

No, this is not my resume for JSON skills, although you might want to check out my REST Primer for F&I.

This post came out of a running dialogue, on Twitter and LinkedIn, about how to format your resume. The observation, not original with me, is that it’s silly to worry about formatting when your resume will be parsed into an Applicant Tracking System (ATS) anyway.

There should be a global resume template, and you should be able to transmit it as JSON directly into the ATS.

There is general agreement that job seekers should be able to write their resume once, and then submit it effortlessly to job listings. Yes, I know, people may shotgun their resume indiscriminately, but that’s what the ATS is for. Relying on the “friction” of resume uploads is not a great way to filter applicants.

In this post, we’ll look at the HR Open standard, JSON Resume, and LinkedIn Easy Apply.

HR Open Standards Organization

The HR Open Standards Organization is an ambitious plan to put everything HR on an API, including screening, benefits, and payroll. I signed up and acquired release 4.4 of the schema. This release includes several features of interest to recruiters, such as:

The Learning Employment Record (LER-RS).
Focus on skills and competencies, versus job titles and duties.
Digital verification of credentials and achievements.

The resume-like elements are in the Person Profile type, which resides in the Candidate type.

Candidate may include data that is not typically included on a Resume, such as remuneration requirements and position preferences.

You can tell that much of the work was done in XML before adding JSON in release 4.0. The schema is intended for integration among commercial HR systems, and that’s who the organizers are. So, no surprise they’re SOAP oriented.

The schema has roughly 350 high-level elements, and nests down 28 levels. My automotive readers will note the analogy with STAR. When I was at AutoNation, we developed the first XML standard for credit applications (CAF). We had the top auto lenders onboard, including Chase Auto Finance.

Chase spun off Dealertrack, which launched on CAF and later went to STAR. STAR is deep and detailed. CAF, while thorough, was quick and dirty by comparison. Similarly, where HR Open is the official industry standard, JSON Resume is the scrappy startup.

JSON Resume Ecosystem

You can tell JSON Resume is built by developers, for developers. In addition to the JSON schema, the ecosystem includes:

Command Line Interface (CLI)
Export utilities
Chrome extension
Latex rendering
Multiple “theme” formatters
Hosted registry
YAML, TXT, and QR Codes

This is so comprehensive that I had to laugh. My JSON resume is here. Now, I can generate it as a PDF in one of the thousand available themes. I used the included editor to develop this resume, which it automatically publishes as a Gist on my GitHub.

JSON Resume also hosts a registry. That is, it automatically generates a web page based on the JSON file. I didn’t have to lift a finger. Here is my resume online. Other great things are in prospect, like vectorizing resumes and using cosine similarity to match them with job listings.

The tools are user-friendly enough, and I’d love to see more people in the registry, but right now it seems to be mostly just developers.

LinkedIn Easy Apply

LinkedIn Easy Apply is basically a preprocessor for the client’s ATS. It does the work of parsing a PDF resume and merging it with the already-structured data in your LinkedIn profile. Then, it uses proprietary APIs to talk to Workday, Greenhouse, et al. If you’ve used it, you know the parsing is often bad.

The easiest enhancement would be to accept JSON as input, validating against the JSON Resume schema. LinkedIn could even allow users to edit their online profiles as JSON, basically cribbing the JSON Resume editor. They already have your profile in an object model, internally.

Input could also include the standard questions about race, nationality, disability, and work eligibility. While these are technically not part of the resume, they could be included as metadata in the same file. They’re already in the HR Open standard.

Caching the Rate Response

Every so often, I am asked to write on a specialist topic for F&I technology, like surcharge processing, term bumps, or credit life math. Today’s topic is well known in dealer system software, but bears repeating for the new generation of digital retailers. This is the problem of how long it takes to receive rates for protection products from the provider’s web service, also known as “latency.”

The good news is that all providers today expose their rates via web service, so they’re always up to date and tailored to the current deal. It wasn’t always thus. We once had to scan reams of paper rate guides, and walk ten miles in the snow. The bad news is that the web rating call can take several seconds to run.

A savvy rate response already has Squish VIN in it, so you just smack the whole thing into Mongo and you’re good to go.

In the typical scenario, a menu system calls the provider’s web service directly, passing the VIN and the dealer number. The dealer number is required because product pricing and selection may vary with the dealer. This may not be the case for digital retail. You may have a standardized slate of products (or just one product) with a mandatory fixed retail price, and not care about dealer-specific costs and packs.

You still have to pass the VIN, in any case, because most products are risk-rated by model. Then you wait. At MenuVantage, we set the timeout for twenty seconds. If a provider couldn’t respond within twenty seconds, they couldn’t be on the menu. Digital retail, of course, requires a much faster response.

The rate response for an old-school SOAP call, returning all products for a single model, is about 500 KB, or 10,000 lines of XML. I have seen them exceed one megabyte (you know who you are). A well-done web service can transmit the rate response in about one second, and then another second or so for the integration hub.

Most menu systems do not interface directly with the provider. They go through a central hub like PEN or F&I Express. These are the main ones (full disclosure: both are clients) but there are others, and a slow rate hub can add seconds of latency. Digital retail is more likely to be using REST and requesting a specific product. The biggest product is a service contract, weighing in around 2,000 lines of JSON or 100 KB.

Ideally, all networks and services would be fast, and you would always send the request. “The network is the computer.” On the other hand, maybe you ought to cache the rate response. To do this, simply save each response in a database, keyed by dealer number and Squish VIN.

If you’re in the “don’t care about dealer” scenario described above, then omit the dealer number. If you expect to rate specific products, as opposed to the menu scenario, then take apart the response according to its (provider-specific) product segmentation. A savvy rate response already has Squish VIN in it, so you just smack the whole thing into Mongo and you’re good to go.

The point to Squish VIN is that, of the 17 characters, only ten really matter. The first eight identify the model and trim, and the tenth position encodes the model year. This is what the provider uses to risk-rate by VIN.

Common practice for digital retail is to pull an inventory list and rate every vehicle on the lot. That’s some redundant rate requests. A dealer might have 500 cars on the lot, but only seventy unique VIN patterns. Even if you’re compulsive about stale cache, and you want to rate every night, this is still a sevenfold improvement.

So, the procedure is: every time you want to rate, either in batch or on demand, go first to the cache. If there is no matching Squish VIN in the cache, only then must you take the hit for a live rate request.

Menu systems generally do not do the lot-scan thing. This seems to be new with digital retail. Generally, we would just expire the cache at midnight and start rebuilding with the next day’s deals. The first Cherokee takes a hit, and then the first Wrangler, and after that you’re rating Cherokees and Wranglers all day long from cache.

Also new with digital retail are various use cases that don’t require a dealer number. This vastly improves the efficiency of the cache. Instead of seventy VIN patterns per dealer, you might have seventy for the whole country.

Full Lifecycle API for F&I Products

I have just wrapped up design work on a web service to cancel and refund F&I product contracts. Whether a refund is owed to the customer, from an early termination, or to the lender as recovered funds, it is in the provider’s interest to support an efficient automated process. On the lender side, it is also a compliance issue.

This job was rewarding for me because it completes the lifecycle I began automating, ten years ago, with electronic rating. MenuVantage was a leader in rating and originating product contracts, and many providers adopted our model specification.

I then did related work at GMAC Insurance, which was to include claims processing. Sadly, the crash of 2008 ended that project. GMAC also had the bright idea to check for an earlier contract, and apply the refund to the results of the rating call.

The industry has been developing web service support piecemeal. First, there was a need for rating and contracting, supported by companies like MenuVantage. Now, there is financial and regulatory pressure to automate terminations, supported by companies like Express Recoveries.

In hindsight, a savvy provider would have looked at the core processes and developed web service support for the whole lifecycle. It would look something like this:

Dealer and vehicle information ⇒ Return customized rate structure
Deal information with chosen rate ⇒ Originate contract
Form request ⇒ Return contract as PDF
Form with digital signature ⇒ Store in secure archive
Blank form request ⇒ Return blank form
Void request ⇒ Void contract, if eligible
Remittance query ⇒ Return remittance log
Remittance notify ⇒ Post pending payment
In-force query ⇒ Return contract data
Claim diagnosis ⇒ Verify coverage
Claim estimate ⇒ Approve/deny claim
Claim entry ⇒ Issue payment
Vehicle data from contract ⇒ Return cancellation quote
Contract data plus authorization ⇒ Cancel contract, issue refund

You could do one big API to manage the product from cradle to grave, and build provider portals and such on top of it. This would have the usual benefits of decoupling the back-end from the presentation layer, and it would facilitate integration with dealer and lender software.

Business Process Modeling

I am doing a Business Process Reengineering (BPR) project for LoJack Corporation. It is to their credit that a mature organization like LoJack is willing to examine its business processes. This is part of a broader effort to increase F&I penetration, and it promises to be a lot of fun. Readers of this blog know how much I enjoy BPR, and Dr. Hammer.

After much deliberation, we chose Business Process Modeling Notation (BPMN) for the project. My main concern was having diagrams that would be easily understood by everyone on the team. Not everyone who is an expert in F&I is also an expert in BPR. I also wanted notation that would keep track of data flows, and was well supported by textbooks and software tools.

If we had only IT people on the project, I might have recommended UML or ODBA, but both of these are too technical. Also, UML doesn’t do a great job of combining process and data flows. I think the absolute best notation on this point is Event Process Chain (EPC) but it, too, requires special training. There is a great paper out of Harburg Tech, by the way, comparing UML and EPC. The windup is that UML is better for software and EPC is better for process.

As to support, BPMN is an Object Management Group (OMG) standard. Visio 2010 not only supports BPMN, but it includes a syntax checker. This will be important for people new to the tool and the notation. I also found a number of good recent textbooks, including The Micro Guide to Process Modeling. This is a concise “how to” that will serve us well, and it includes some good style tips. Happy modeling!