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”?
Â
Links
View Technorati Links
SaaSBlogs Tags
Tagged with: Business Models • SaaS Trust • SOA
(2 votes, average: 5 out of 5)
Loading ...
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?