Earlier this spring, I attended a large software vendor’s user forum that focused on its supply chain solutions. I was particularly interested in hearing about the implementation of a warehouse management system (WMS) at a large grocery chain in Europe. Unfortunately, the speaker from the retail chain was from the IT department, and he spoke about master data, configuration switches, and integration with the enterprise system, all delivered in a monotone. As the speaker continued to babble, my eyes began to glaze over. I decided it was better to stealthily sneak out of the room than to fall asleep.
There’s a common saying that supply chain improvements are driven by people, process, and technology, but most supply chain executives that I know are far more passionate about process than technology. When technology is discussed, it is often in relationship to a process–i.e., how an application can enable a new and better process, and perhaps allow for the kind of optimal planning that no human could ever match.
Software architecture affects the depth of an application’s functionality, how quickly it can be implemented, and the speed of upgrade. Architecture also affects the ease with which ongoing changes can be made to supply chain processes, the degree to which information generated by the application can be used to drive continuous improvement, and the ease of collaborating with key partners. There is no single type of architecture that is “best” in all those areas. But certain architectures do allow for much better trade-offs across those benefit areas. In summary, it is clear that software architecture affects the ROI and qualitative benefits delivered by an application. But many of these architectural issues are still not well understood by the broader supply chain community.
The table below outlines what I view as the core architectural enhancements over the last twenty years; the reasons they matter; the applications they apply to most prevalently; and the trade-offs. The architectures are presented in the order in which they appeared in the marketplace.
Here I need to admit that I have never been an IT programmer, architect, or strategist. I’ve never even taken an IT course. My views are based on conversations I’ve had with many, many supply chain executives who have lived through implementations.
In addition, these are generalizations. There are ERP vendors, for example, that have introduced supply chain applications based on a standalone, best-of-breed architecture. These applications have very deep functionality. Further, while most multi-tenant TMS providers will readily admit that their solutions are not as functionally rich as the most robust single-tenant solutions, three vendors with multi-tenant solutions argue that they are capable of optimization every bit as complex and scalable as single-instance solutions. This is something I need to verify through future user interviews.
Some IT folks will notice that I did not include Service Oriented Architecture (SOA) in the table. That’s because every software vendor I know claims they have an SOA architecture. For someone who is not an IT guy, it is impossible to verify if that is really true. Instead, I included Business Process Management configuration engines because even a non-techie can identify this architecture. It involves pulling process objects into a sandbox environment and snapping them together to create a task flow.
I also did not include mini-applications sold in an app store format, although I do consider this a very interesting new development (see “App Stores Come to the SCE Market” for additional commentary). If I were to write a similar commentary in a few years, app stores might be on the list.
In conclusion, the architecture of supply chain applications does matter. Unfortunately, this is a topic that many supply chain managers do not pay enough attention to.
