Uncovering lurking design issues and resolving complex dependencies to build a microservices platform that adapts to the needs of diverse manufacturing clients
A global provider of manufacturing solutions had the goal of empowering their own clients to become faster, more agile, and innovate through technology. Historically, the company manufactured mostly complex, small-batch items, but had recently purchased a plant focused on volume manufacturing. It was up to the IT team to make sure that the manufacturing execution system (MES) could accommodate the needs of many different clients, and could be updated with minimal risk to the system and business.
- Existing MES was not agile enough to handle a variety of clients, products, and processes at scale
- The original microservices design worked in local dev environments, but failed in production
- Deploying ongoing updates to parts of the MES required downtime that would disrupt the business
- Complex dependencies surfaced within both the code and the data
- Company needed viable design and project-planning guidelines for continuous improvements to the system
- Conducted a thorough review of the just-built microservices that uncovered roadblocks to optimizing the MES
- Created autonomous boundaries, introduced messaging, and coached teams on NoSQL databases
- Targeted the Packout service to create a blueprint for building independent services that integrate with the MES
- Developed a plan for getting API endpoints running, then refactoring dependencies
- Pivoted from pure coding artifacts to providing mission-critical design/architecture coaching
- New MES system enabled more order processing for both existing and new clients
- Delivered document database guidelines and a mechanism for coordinating document activities
- The Packout success served as a launchpad for breaking the MES monolith into microservices
- Changes to one service can now be deployed independently of the MES
- Introduced a flexible approach to planning, designing, and deploying microservices that will evolve with the business over time
A stunted growth plan
To make volume manufacturing viable, the MES needed to be both flexible and scalable, which meant building out a robust microservices architecture. The company had already begun breaking out a few services and was looking for a partner to create a clear playbook for moving forward, while offering expert guidance on the design and scoping of new microservices. However, what their teams didn’t realize is that there were issues lurking within the code—and the design itself—that would prevent them from ever going live.
Advisors turned partners
The thought leadership for which we were initially approached by the company ended up opening doors to a deeper and more valuable partnership. Connected by a shared ethos, and history of working together, we were chosen to review and offer advice on their current plan. However, a deep dive into the existing architecture and ways of working revealed a better way. We worked hand-in-hand with their onsite teams to find and fix the existing issues, then build a solid foundation for scaling the MES system.
Let's work together. Connect with us today.
Mapping out messaging
The first step to any engagement should be a thorough and thoughtful assessment. Our code review revealed that the microservices wouldn’t work in production, mainly because of messaging issues. Messaging is one of our team’s core competencies, as it’s proven to be a key area for improvement across many projects. During ideation and whiteboarding sessions, we swapped out services and messaging for real-world human communications to illustrate the holes that existed and figure out how to fix them. Presenting this as the underpinning of a successful architecture, we used NServiceBus and RabbitMQ to make the messaging system easy to build and scale.
Right-size and right-use
Getting business boundaries and interactions right is the key to autonomy. The existing architecture was too “micro”—the services were too small to truly stand on their own. We redirected the focus from noun-oriented boundaries to capabilities-focused ones and removed unnecessary asynchrony from interactions. We guided teams on what to use and when, and got them working properly with NoSQL document databases. We even introduced a lightweight mechanism for coordinating document activities when necessary and helped scale back messaging to its essential uses.
Unpacking value via microservices
Once architectural issues were addressed, it was time to start building. Untangling individual services from the MES monolith would require identifying and resolving dependencies in both the code and the data. Starting with the Packout service, we split the approach into three focus areas: UI, backend, and database. The goal was to get the Packout API endpoints working by copying the shared code into the microservice so the core domain objects/data dependencies could be refactored once the service was running independently. It’s hard to know what you’ll find when delving into the dependencies of a monolith: A kanban approach allowed us to uncover new challenges along the way that could be used to modify the backlog and move forward.
A volume-viable system
Our deep dive into the original microservices design saved time and money by solving lurking problems and enabling the MES to actually go live. The number of orders that the system was able to handle jumped significantly. Now, the company is able to do volume manufacturing from its own back-end ordering system, instead of assimilating the purchased factory’s system. This integrated approach will enable the business to better serve all of their clients’ needs going forward.
Flexible foundation for microservices
The problems we uncovered together and solutions we proposed transformed the company’s approach to building microservices —from scoping and planning to design and implementation. What we came up with was a solution that addressed the project’s immediate needs, but also resulted in an infrastructure that could be applied to future projects, without locking them too much into implementation details.
A standalone success that scales
Once we got the Packout API running with shared dependency on the UI and database, we knew we’d hit the mark. Equipping the Packout to run independently of the MES bodes well for the expansion of both the system and the business. This standalone microservices success can be parlayed into a scalable, flexible architecture that will allow the company to better serve individual customers.
“Working together to uncover unmet needs” has always been at the heart of Headspring’s value proposition. Our relationship with this manufacturing client during a time of deeper-than-realized need really brought this value prop to life. What we discovered together during our thorough assessment changed the scope of the project, and also transformed the business for the better. What began as a request for coding artifacts and guidelines, resulted in the very platform they needed in order to launch a new chapter and keep growing.
By balancing pragmatism and idealism, we got a viable volume manufacturing system online, then worked closely with the team to make microservices work well into the future.