Building an enterprise system is a challenging process. You are building a piece of technology that is going to help your enterprise operate its business, and sometimes the entire enterprise will be directed and run from this system. What is the best method for planning and building such an important piece of software?
Building any kind of software is often compared to a construction project—like, say, constructing a bridge. In the early days of software development, this idea was common and was called the waterfall method. When you build a bridge, you visit the site, measure the distance of the gap, and consider the soil and what kind of a foundation you have to work with. Once all the variables are considered, you select the best design pattern to use—perhaps a beam, arch, truss, or suspension bridge. You hire an architect to create an architecture document and then hire contractors and build it out. This is very similar to the waterfall method of software development: you see a problem, build a plan, and create a solution.
However, the waterfall method only works when you know all your requirements in advance. An enterprise system can take years to build out. Do you think you can know all your company’s enterprise software business needs two years in advance? If you do, then waterfall is for you. But if you have a constantly moving target, then you need to find a new methodology.
I’ll give you an example from my own life to see where waterfall goes wrong. I was hired by an automotive manufacturer to create the application that connects a computer at the mechanic’s shop to the vehicle and communicates with the on-broad computer to receive diagnostic information. This company had followed the waterfall philosophy and had created a massive set of design documentation. At that time, I was still a fan of waterfall, and I was so excited to see such a detailed plan. I thought, “This software is going to be so easy to write.”
On day one, I was handed a packet that detailed all the functions I needed to write and which functions I needed to call from where, and I started working away. I got 10 or so pages in when I noticed a problem with my documentation. A huge portion of my task was to build the web services. They needed to download a large dataset from their servers onto the client. Whoever designed it didn’t know that a web service can return more than one value at a time. In order to download this large dataset, they had created a way of downloading the data row by row, cell by cell. Most of my packet dealt with converting the data from the database format into a single integer value and then having the client convert that back into a row and cell in the local client database—a tedious process that surely would have crashed their web services. At our first status meeting, I asked if I could just download an array of all the data at once. The project manager and lead technology guy looked at me with shock and said, “You can do that?” Yes, was my reply, and I tossed out my entire packet. What had been scheduled for six months of work I finished in a few weeks. How much wasted time and energy had been put into my packet? A simple question destroyed all that effort.
Since then, several different methodologies have emerged—words like Agile, Lean, Kanban, Scrum, and Extreme Programming are tossed around. And they all address these kinds of issues in different ways. It’s the unknown unknowns that will kill any software project. How you handle them is going to make the difference between a successful launch or a failed project.
If we think back to the bridge example, there are many different patterns you can use to build a bridge, but none of them will work if you are trying to cross Lake Washington. Here in the Seattle area, we have a problem. Nestled alongside of the city of Seattle is glacier-carved Lake Washington. It’s 20 miles long and five miles wide at its narrowest point. Because it was carved by a receding glacier, the bottom of the lake is mud. Too wide for a beam or truss bridge and so much mud that the cost to build a proper foundation for towers is too expensive to be practical. So how did we figure out how to cross it? We threw out all the existing design patterns for bridges and instead built the world’s first floating bridge. Architecturally a cheat, but practically it works.
So, when it comes to designing an enterprise system, you need to have a Swiss Army knife approach. You need to understand all the different methodologies out there and find the one that works for your team and project. You might use two different approaches at the same company on the same project. And when no pattern fits, don’t feel like you must follow one anyway. Build a floating bridge if you must.
Now I do think there are some very important considerations you should make when building out a large system. Instead of building one massive system, break it up into many different parts, and be sure to think about how all the services you create need to work together. A common interface between services will be key to getting all your systems working with each other. I would call this the Lego approach to software systems. You can’t have one team working with Duplo blocks and another team working with standard Legos. Everyone needs to use the same sized Legos, or the services will never be able to integrate with each other.
My overarching software development philosophy is integration. You do not need to use the same coding technologies: it’s OK for one team to use JAVA while the other creates something in .NET as long as the two systems can integrate with each other. One of the simplest ways this is accomplished today is through REST-based API services. The REST API interface is universal across all major software languages and can be manually handled if nothing is built into your language.
Another thing to consider when creating a large enterprise system is that you will likely need to integrate third-party products into your system. When considering third-party products, the first thing to check is their REST API documentation. If they don’t have it, you need to be careful about whether the products will integrate into your overall system. You can always build a floating bridge into their system if needed, like creating your own APIs that connect to their database.
Where do plans come in? In my opinion, they don’t come in much at all. I like the saying, “Plans are worthless, but planning is everything.” So how do you plan without making plans? To me, it’s about identifying the most important needs and executing as fast as possible to solve these needs. I think the Agile method of having a prioritized backlog is the best tool for this in my Swiss Army knife. Building a Minimum Viable product would be my next tool (Lean programing), managing the day-to-day of the project via a Kanban board and then getting key stakeholders’ feedback about the result would be last. Every project should be treated differently, and you need to use the right tool for the job.
I’ll give you an example from my own startup, thriftbooks.com, which is now one of the largest online retailers of used books. In order to sell books online, you need to build a catalog of your inventory. On day one, we had no system to catalog books, or anything. And so I wrote a piece of software in which you entered the ISBN number and matched it to an inventory sticker, and then we hired a team of employees to start processing books. That is all the software we had on week one. As our employees began processing books, I started writing software to track what shelves they were being placed on. By week two, I had a handheld device with software that could scan the inventory tracker barcode and the shelf barcode, and we were able to track the location of the book. Once we knew which books we had and where they were located, I created software that linked the ISBN number to their title and other information. Then I created a system to load the books for sale on Amazon.com. Soon, orders started pouring in, and I had to create a system to pull and ship the books. While each of these steps were in the back of my mind from the beginning, I created each piece as needed, when needed.
Building an enterprise system is like building a giant puzzle. You need to keep the big picture in the back of your mind as you create or buy each puzzle piece to ensure it all fits together in the end. And that is the approach I am taking here at Officium.
At Officium, we have taken on the challenge of creating what we call Talent Place. Officium strives to help companies improve their customer’s experience. Our talented and experienced CX team has helped countless companies see CX as a revenue stream instead of a cost center. And Talent Place is the marketplace we are creating to help deliver these solutions to our clients. One of our offerings is to have work-from-home CX agents plug into our clients’ infrastructure and act as their own CX agents. These agents can even be deployed in a burst capacity model if one of our clients has a sudden need for more agents, like what is happening with the COVID-19 pandemic.
So how do I build such a complex system? What are all the needs now and in the future? Well, I can identify what is needed now, but I can only guess what will be needed in the future. And so, I focus on the now and design the system to work with the future. During this COVID-19 crisis, many of our clients are experiencing a surge in business. Some clients deliver food and other essential products to people’s homes, while other clients create computer games. With so many people staying at home, their businesses have boomed in ways they could never have imagined. Suddenly, they have a huge increase in sales and in the customer inquiries that come with that. These clients do not have the staff to answer all of their customers’ questions, and it’s a long process for them to hire more. And so, we embark on our mission to solve this problem for them.
Our needs now are to ramp up our Talent Place CX agents, and so I’m juggling a number of questions in my mind. Should my team create an applicant-tracking system, or should we purchase an existing solution? What criteria should we weigh when evaluating third-party tools? I have already begun looking at several third-party solutions—after verifying that they have the key features we need, I start digging into their documentation to make sure they have some kind of an API that we can plug our software into. Even if we don’t need to plug into their system this way at the moment, it’s vital for us to have this in place for the tool to fit into our larger picture. If we went with a third party that didn’t have an API, I could only justify it as a temporary solution until we could build our own alternative.
I am starting to explore other topics for later. When we add a few thousand agents to our pool, how are we going to track their time? How are we going to make sure they can get trained? How can we make sure they can do their jobs? How are we going to communicate with them? How are we going to get them scheduled to work? These questions are important for us to be successful, but they don’t need to be addressed immediately. Once we finish our current top priorities, these will quickly move up in our backlog. I am researching options. The moment a solution is needed, I will be ready to execute.
By Daryl Gordon, CTO of Officium Labs