My name is Keith. I'm a technologist. I solve complex problems elegantly with software. You can find me on LinkedIn.
Skills: tech leadership and vision, manage engineers, tech-forward application design, build, Node.js, MongoDB, automated tested, document systems and designs, GraphQL, Git, GitHub, SQL (Mysql, PostgreSQL), PHP, HTML, CSS, Apache, Linux.
My area of expertise is building enterprise applications. By enterprise applications, I mean the applications that make an organization or business work.
Case Study
The Problem: The existing ordering, contracting and fulfillment system had to go. It was built on old tech that wasn't designed well to begin with and prone to error. Most importantly, it could not support what the sales team wanted to do with product offerings.
The Solution: Build an entirely new ordering, contracting and fulfillment system. The ordering and contracting is "easy," the company went with off-the-shelf solutions and customized those. Fulfillment is different though.
The products sold are internet listings. The internet listings run for the length of the contract. Some contracts start in the future, they all end in the future, and there are renewals.
The downstream legacy CMSs remain, but fulfillment took over the responsibility of turning on and off internet listings in those legacy CMSs. Because they're legacy, they're slow, unreliable and humans can make changes in those systems to break fulfillment - taking away something that the customer purchased, or giving the customer something they didn't order.
Several problems needed to be solved.
- Receive fulfillment requests from CRM
- Schedule fulfillment requests, they can start in the future
- Process the fulfillment requests, communicate with the CMSs to activate or deactivate internet listings
- Make sure it all worked and fulfillment is true (e.i. we're delivering what we said we'd deliver and nothing more)
To solve these problems, I built a series of micro-services written in Node.js and used MongoDB for storage.
The simplest is the API that the CRM uses to send fulfillment requests once an order is complete. This API included a validation endpoint that applied selling rules for a CRM payload. This pulled a lot of customization out of the CRM and put it into the API where it's much easier to maintain - it made for lighter work for the CRM engineers.
From the API, a fulfillment requests then goes to the scheduler. All of the requests go to the scheduler, even requests that are going to be processed immediately. Having one path through the fulfillment system is a better design than having one path for realtime and another path for future start date services. This helps with auditing as well. The realtime are processed within 1 second.
Once the request hits the scheduler, it can be picked up by the fulfillment processor. It's the processor that actually communicates with the downstream CMSs to enable or disable the internet listings. The processor needs to deal with failures and errors from the legacy CMS. Things like random 503s, that are transient errors, to hard errors involving bad data. For the transient errors, fulfillment will put the request in a retry state, this solves for 100 percent of the transient errors. For the hard failures, those go to a failed state that requires human intervention (e.i. someone to fix the data and perhaps retrain someone).
How do we know if it actually did the thing fulfillment said it would do?
That's where the service comes in that checks our work. This service constantly validates that everything is true. So it looks at fulfillment data, contract data and legacy downstream systems to ascertain the truth. This service has been the most valuable of all of the services. It was also part of the project that was a struggle to get buy-in to do. There was a lot of push back that a few reports will be fine, but I knew that wouldn't scale. Now that it exists, everyone loves it.
People and Processes
I don't just build applications. I build applications that integrate with business processes. As in the above case study, I wasn't building a fulfillment system for my team. I was building a fulfillment system for the company - for sales and sales operations. That's why I worked with sales operations early in the project. I asked them the question: "What will you need from us to manage this system when things go wrong? Because things will go wrong."
At the end of the day, what I do is I streamline and automate business processes. And I do that by working with the business owners to build what they need - often they don't know what they need.
You can find me on LinkedIn.