SaaS & Learning from Malcolm McLean
For those who don’t know who Malcolm McLean is, I’ll give a brief introduction. Malcolm McLean invented the modern shipping container: you know, the ones that come in on cargo ships, are craned onto trucks and trains, and that provide a standard for transporting goods worldwide. So why are his ideas important and what does it have to do with SaaS? I think we should all pay attention to the shipping industry and how he revolutionized it. SaaS and service oriented architectures have the potential to cause a change as profound as the one experienced by the transportation world in the 1950s.
Traditionally, software is notorious for capturing functionality and locking it away in an unsharable fashion. Any other piece of software interested in tapping into some other software’s functionality generally needed access to the source code or some non-standard programmer interface. This isn’t necessarily the fault of any one piece of software, but rather a problem of lack of basic agreement. Software lacked (and still somewhat lacks) protocols, well-defined modular architectures, and an economic model allowing for subscribed functionality that can compensate producers in a producer/consumer model.
In the shipping industry, McLean recognized some significant parallels: across transport mechanisms (trucks, trains, and ships) there was no efficient protocol (everything was break bulk) and economic models in transportation reflected a heavy penalty because of lack of disintermediation (someone had to interfere at each drop point to break down shipments). By introducing shipping containers and associated support infrastructure (crane structures, roll-offs) etc., we saw those issues alleviated. McLean broke the mold by recognizing that lack of standard produced inefficiency and not competitive advantage. This is why these days you’ll see the same shipping container on the deck of a cargo ship, on the bed of a freight train, or on the back of a trailer heading down the interstate.
In the software space, we’re starting to recognize that lack of protocol, economic models, and isolated functionality are in fact hurting us. Service oriented architectures have shown that cross-technology communication and access to non-commodity functionality is possible from a technical standpoint, that applications can in fact be very modular (just look at the mashup craze), and that software as a service has introduced an early framework for monetizing this functionality between parties. Looking back at McLean and what the shipping industry is today, we should recognize that his work and ideas led to the ability to transport goods across the globe as efficiently as possible and that we have a similar duty in the software space.
Over time, do you expect that software space to become more protocol driven and more flexible in terms of functional composition, or have we reached our peak with respect to “functionality on tap”?
Â
Related Posts
Tags
Share This
Awesome post Sinclair! I love how you draw from a wealth of knowledge outside the software space. It makes your writing that much more valuable and interesting in my opinion.
As to your question, I think we are far from our peak. I also think that the rise of open source software and the open source business model has caused the industry as a whole to be much more “open”, as companies realize the need to enable their solutions to “talk to one another”.
In addition, SaaS architecture has introduced a wealth of opportunities for companies to innovate in the area of functionality. The ability for an ISV to leverage their network of users WITHIN their application functionality is one opportunity that I think we’ve yet to see many ISV’s really be creative with. As the industry continues to mature, I don’t think it’s unreasonable to expect that SaaS ISVs that build their applications with similar toolsets (following accepted protocols) could gain immense benefits from being “plugged in” to a common layer. Isn’t that what the OS did for desktop software?
Thanks Jesse. I agree whole-heartedly that we are far from our peak and yes, the OS to some extent did exactly that.
Hi Sinclair,
i think we’ve got a ways to go yet. I don’t think the average consumer implicitly understands that software companies could embrace standards, but can make more cash with lock in. But in shipping, they could understand the economic benefits, it made sense and they could demand price reductions in transportation.
The second thing about shipping is that there are only 3-4 really REALLY big players…. in the SaaS world this is yet to happen… to much elasticity , profits and growth to drive this type of approach…
Cool analogy though
Paul
This is an interesting post on how it is looking at not just the software portion of SaaS, but going after the functionality and economics of it.
To use a real-world example (being in the software industry), my company has developed a SaaS model that offers a complete On Premise solution for the Rental, Sales and Service Industry. Many of our customers are in the logistics and shipping industry and (as an Account Executive) I have been trying to make this industry realize the importance of this new technology. I have spoken with Salesforce.com and even if they do not have the greatest SaaS platform, that have A platform. My company’s new SaaS technology is a turning point in our company’s 25 year history dealing with software.
I think the SaaS platform is the wave of the future for any sort of industry, especially the shipping and logistics industry. My company has had much success with our product, but the construction/equipment rental industries are just too far behind the times to realize the money savings benefits of this technology.
To stop rambling and answer the question, I think that the SaaS platform is far from it’s peak. The big hurdle to face is to get organizations to realize the importance of this new technology.
Greg