Starting a Huge Integration?
My biggest takeaway from just finishing one
Here at Ritual, we recently completed a behemoth of a project. We successfully launched and integrated our company’s backend API with an accounting ERP called Netsuite. And we did this with a small team of three.
What is an ERP?
“At its most basic level, ERP (Enterprise Resource Planning) software integrates essential business functions into one complete system to streamline processes and information across the entire organization.” — An edited quote from Netsuite’s site
For our purposes, we were integrating this for our finance department to help automate their accounting and reporting.
I’m going to introduce myself before we move on. My name is October Comstock and I’m a software engineer currently working on Ritual’s platform squad.
I know what you’re thinking…
…
Yes, I was born in October.
Mooovin’ on 😆
The Takeaway
There were many MANY takeaways I took from this project, but today I want to focus on the one I felt was most impactful. And that is…
Work closely and constantly with your stakeholder.
Why’s that? What does that mean? What the heck October?
Read on dear reader. Read on.
The Problem
A really important point is that this project was self-driven as a collaboration between engineering and finance. Our requirements were completely derived from our stakeholder and she was figuring out those requirements as we went along. This was a problem that nobody knew how to solve and nobody in the company had prior Netsuite experience except for her. But even she didn’t know everything, Netsuite is a gigantic integration. There are literally THOUSANDS of pages of Netsuite documentation to dig through. I’m not being hyperbolic, that’s a fact.
So how do you tackle a project where nobody knows what the requirements are to get it integrated with your system?
Teamwork makes the dreamwork.
Team Composition
Our team comprised of 2 engineers and 1 member of our finance team. The finance team member being the stakeholder.
At the beginning of the project, we met about once a week. But once the project got going there was so much new information to share, it wasn’t enough. So we moved it up to daily 10–15 min syncs. This is also on top of a Slack channel that we used to stay connected and communicating.
We had to write up all of our tickets and product/project manage everything ourselves as well. This made those daily syncs even more crucial. But one of the pros of working on a small team is that the feedback loop is much simpler, easier, and there aren’t as many people you need to speak to to get things done.
Domain Knowledge
This project required a strong knowledge of finance that we, the engineers, did not have offhand.
Which meant a lot of back and forth just to understand certain terminologies and what it was that finance needed to see. We essentially had to establish a common language between engineering and finance.
Because for every SINGLE type of Netsuite record we were creating, testing, and updating, we needed confirmation from finance that everything looked the way it was supposed to.
Being able to get these quick confirmations from our stakeholder allowed us to iterate rapidly.
Encountering Blockers
The Netsuite integration is not flexible. I will save you the details, but essentially, early on we thought we could circumvent a particular part of the integration surrounding discounts and do things in a way we liked better. We agreed on a solution, implemented it our way, and moved on with the rest of the project.
But then weeks before launch, we discovered that the way we implemented discounts in Netsuite wasn’t allowing them to get handled correctly in their system.
So we had to pivot and rewrite the implementation so that it followed Netsuite’s conventions. Being able to communicate and iterate quickly with our stakeholder was critical when this issue occurred.
We were able to brainstorm to find a solution that we all agreed upon rapidly. We were also able to move past a huge blocker and prevented the project from potentially being pushed back. That wasn’t the first or last time something like this happened either.
But each time it happened we were immediately in a call with each other.
Managing Expectations
Expectations were also managed better. If a blocker came up (like the discount example above), we would communicate quickly about it. Doing this not only helped us find solutions but also resulted in all of us on the same page regarding the status of the project. So if something occurred that did push the project back, we all knew what it was, what we were doing to fix it, and how to communicate outwards about it.
Communication
Having our stakeholder working closely with us also meant she could be sending communications to our 3rd party vendors with our questions immediately after our syncs. Like asking Taxjar about their Netsuite integration or diving into the ocean that is the Netsuite documentation. This helped expedite those 3rd party conversations while we could focus on other problems to solve.
Being able to communicate every day in our daily syncs allowed us to rapidly iterate and move past any questions or blockers that came up. These could easily have compounded and become a spiraling time-sink situation where we would have worked on things only to find out we couldn’t use it later.
Friendship
We also developed a strong friendship and honestly had fun during our daily syncs and conversations together, which helped with morale on such a long and intense project.
Wait October, did you just say friendship helped get this project out the door? You bet I did. While not a necessity it certainly makes those tough days more fun. It also helps if you’re all really into Animal Crossing.
Fin
Due to the newness of our finance team’s needs and the complexity of Netsuite’s integration, this created numerous unknowns that only a strong partnership and regular communication with our stakeholder could overcome.
So if you can, work closely with a stakeholder on your next integration project. You will save yourself so much time and pain.
