This blog is a reminder of what has been built, and what it took to get there, and how much of it depends on organizational support. It is also a reminder that when building a system, building the organization that uses the system and supports it is just as important, as the system does not end when the compiler finishes.

• If you are a developer just interested in big systems, reading about big systems is a good way to seep your mind in big software designs. It is not meant to dissuade investigation or planning into “big systems”, but rather to help illustrate just how big and involved big systems can actually become. If anything, it may serve as a reminder to avoid hasty generalization and optimizations in structural design, since every design choice can impose constraints even while it provides some modicum of functionality within the warehouse and purpose beyond the warehouse.

• This may be of use to you if you are a technical intralogistics professional and are curious what a warehouse operating system means to someone who had a hand in making one (perhaps you think you want one for yourself 🙂 ) I was not an intralogistics “expert” before I started my current employment, and might consider myself a professional at this point. But often the people working the technical side are either not intralogistic experts themselves (if they are truly “tech-savvy”), or if they have gained enough to be professionals after years or decades in a warehouse or company, have likely found themselves in technical cul-de-sacs due to the non-commoditized nature of intralogistic WCS and WMS software, or the embeddedness of their job in a singular and relatively static organizational structure that averts change (necessary for a business to do long range planning on investment return).

• If you are a software architect who wants to get a sense of scope on how something that can cover the model of an entire warehouse and its software life-cycles came into being, and how much is actually in something that could be called an “operating system” of a building.

Having strong modern technical chops is obviously necessary (as a developer), it’s also important to know your application field (as an intralogistics professional), and to be able to persuade and coax people to allow you to do what they really need you to do (as a master software builder, or Architect). Follow through is important too!