......................................................................
Well done Jeremy. This is a very thought provoking article that left me wondering about how your software characteristics analysis impact platform wars? And more specifically; productivity systems?
BEA founder Bill Coleman once famously said that Silicon Valley is always all about "owning the platform". So i'm wondering what the current world view is when expressed in terms of a rapidly converging communications-content-collaborative computing and connectivity platform? Who are the platform contenders? Are their platforms open or proprietary; HTML5 or Hybrid? Which Cloud Computing contenders are on track to own or dominate the productivity systems platform of the future?
You have laid out four platform waves (?) as distinct software development eras. Interestingly they match up closely to the traditional platform waves of mainframe, workstation, personal computing, networking, and internet; as identified in an infamous 1998 Economist magazine article, "The Fourth Wave". (I think the concept of "epoch marking era changes" called "waves", dates back to an Alvin Toffler "Future Shock" where he introduced a concept called the The Third Wave, circa 1980). IIRC, the Economist Fourth Wave article combined the pc / networking era into one wave, projecting the Internet era as the Fourth Wave. Perhaps giving the early days of sneakernet unprecedented recognition :)
My thinking is that Bill Coleman would say that platform and software development models roll forward together, riding the same wave. The Fourth Wave Internet ushers in a new era of universal access, exchange and connectivity. I for one thought the pc - networking era of great computing, crap communications and connectivity would be rapidly replaced. As management expert and business guru extraordinaire, Peter Drucker, observed, the era of personal computing and client / server networking did not improve productivity. At best it was a wash; with factors like connectivity brittleness, high cost of systems build and maintenance, high cost of change and zero chance of improvement or adaptation, and time consuming data entry often far outweighing the benefits of computational output and information management. Yet here we are. Still waiting for the productivity explosion of the fourth Wave to kick in.
Drucker did note that the 1995 advent of near universal access to the Internet did improve productivity. Dramatically so. But for unexplained reasons that continue to defy logic. The platform convergence of communications and computation had an incredible impact on productivity, but we really need to understand this phenomenon before software development can truly leverage it. Unfortunately the leading thinker on business productivity systems and historical trends, Peter Drucker, has passed away.
Still, i can't help but wonder why productivity has yet to go hockey stick vertical. Like so many, i'm hoping that an Open Web based on HTML5+ (HTML5, CSS3, JSON, SVG/Canvas, and JavaScript) holds the key to that long awaited leap in productivity. A replay of 1995 but on a tsunami scale deserving of what the Internet is today.
I actually thought we hit the breakthrough point with the perfect storm of 2008. A number of push factors hit that year, some technological, and some economic, starting with the release of the iPhone in late 2007 and the start of the mobile Web revolution. This coincided with the ISO standardization of "Tagged PDF", also in late 2007. Tagged PDF made it possible to convert volumes of static, (legacy ad current) business documents and forms to Web ready "interactive" business documents. Throw in the 2008 leap in functionality of the then nascent Amazon EC2 Cloud Computing platform, and for technology it was clearly game on.
Rarely is technology enough to compel massive and sudden change though. The next level of Fourth Wave computing needed a push. And that came in September of 2008, when we had a financial crisis and near world wide economic meltdown. To survive, corporations had to conserve cash and cut costs without compromising competitiveness. The easiest and fastest way of doing this is to cut labor cost and consolidate operations. And that means systems automation. Do more with less. I thought for sure we we're entering an era of unprecedented transition to software productivity systems based on highly efficient - low investment cost mobile ready, Cloud Computing platforms.
When it comes to the transition to high productivity Cloud Computing systems, an inevitable movement seemed especially compelling since it was easy to see that the cost of labor was about to go hockey stick vertical as new government regulations, requirements, and taxes tore into the cost of operations (ex: unemployment and healthcare costs). As the risk of traditional business improvements rises, the more secure the ROI of Cloud platform based productivity software systems. Or so i thought. It's been four years since the perfect storm hit, and no one seems to have hit "it".
Unlike most people i know, i put the bulk of the productivity problem on Microsoft. They own and control the client and workgroup side of the legacy productivity environment for upwards of 98% of business systems. The core issue is that most businesses would prefer a gentle "transition" of their current business systems and processes to the Cloud, as compared to costly and highly disruptive "rip-out-and-replace" Cloud Computing services. They expect Microsoft to deliver a cost effective and non disruptive transition path for their legacy productivity systems. But we're all waiting for Microsoft to figure this out.
Sadly i'm old enough to remember the early days of the Windows platform. I witnessed first hand the explosive growth and expansion of the Windows productivity environment from the perspective of the contact management software sector. Interestingly, even though the Windows OS owned the end-users at bootup, the contact managers owned the center of everything that happened after bootup. Integrating with Office Productivity Suites and connecting to workgroup and corporate servers was just as essential a role for contact and project management systems as managing time, people and contact resources. These early software productivity systems were quickly strapped into business automation processes; all built on the underlying Windows platform of application and network protocols such as shared DLL's, DDE, OLE, ODBC, MAPI, COM etc. These connectivity components evolved into ActiveX and eventually .NET instantiations.
Of course, Microsoft soon enough eliminated thousands of contact management software companies with the mere announcement of Outlook. And as the saying goes, the iron fisted grip on their monopoly platform was complete :)
So what's the hold up? Where's the transition from the Windows productivity platform to a Microsoft Cloud Computing platform? And why are the masters of Redmond stuck on the same rip-out-and-replace methodology competitors like Google and SalesForce.com are forced to offer?
IMHO, if you can answer this question with HTML5, you will own the Fifth Wave. Anything short of that and sadly Microsoft is your daddy for years to come.
Compound Documents and the Lessons of Massachusetts:
I mention this to you Jeremy because i know you understand the bitter soup and slog surrounding the issue of business productivity systems and the importance of compound documents to those systems. When it comes to automated business productivity systems and processes, compound documents are the fuel.
It also seems to me that even though the convergence of communications and content rich collaborative computing systems are the magic behind both the Fourth and Fifth Wave of computing, building that functionality into a new, HTML5 ready compound document model becomes the essence of a Formula One, productivity fuel.
One of the "Lessons of Massachusetts" is that the compound documents fueling the Commonwealth's business processes were incredibly platform dependent and extremely brittle. So brittle that we came to call the unfortunate effects of accessing and exchanging these documents "Reuters Rule"; which simply states that the conversion will break a document. Specifically, conversion will break both the visual layout and, more importantly, the underlying business process embedded in that document.
The background for these observation is the massive "SOA" study the Commonwealth of Massachusetts conducted in 2005 - 2006. The study resulted in the now infamous "Request for Information" regarding the possibility of an Open Document XML format plugin for the Microsoft Office Suite. The study, which involved hundreds of government workers testing Web ready - SOA sub systems and open source/ open standards based productivity applications, was summarized in a 300 page report written by Sam Hiser. The conclusion was clear. Break the compound documents and you break the business process they are a part of. Break the business process and work stops.
Some other things were are clear. Interestingly, end-users tended to focus on the "visual" aspects of a compound document, and not the underlying, incredibly brittle, embedded software components that were the real gears driving the content, data and continuity - workflow mash that make for an interactive and automated business process.
Another point of near total breakage was the fact that Massachusetts IT fully expected the XML Documents to not only replace the mess of binary compound document formats, but to ALSO be WEB READY!! Yes, and scare quotes hardly does justice to these expectations.
The simple truth is that XML formats were not made for the Web. They were made to replace the proprietary binary formats of legacy office productivity suites with standardized and transparent markup designed to separate a documents content, presentation and behaviors - without having to rewrite the legacy application suite or re-engineer the all important layout engine. Since XML is often touted as "a language for creating languages", it was perfect for the task of writing application specific formats. HTML and HTML5 are near universal Web languages, with every browser expected to correctly read and properly "layout" the format as served. Web specific yes. But not application specific. Just the opposite of the XML document formats.
We ended up coining the terms "Visual Documents" and "Visual Productivity" as a means of discussing how to get legacy compound business documents to the Web - without breaking them. And, more importantly perhaps, keeping them "interactive". Anyone can take a business document static via a PDF print conversion. The real value of a "visual" (Web ready) compound document though is in keeping it interactive and fully connected even as it transitions across a Web of interconnected Cloud Computing platforms and services.
The key to the visual document / visual productivity methodology was to avoid conversion of the "native" application and platform specific version of the document, and instead rely on temporary representations designed to meet the purpose of the moment. For instance, the "local" document is authored in a local productivity application and must remain in it's native format to properly service the legacy business process. However, in the background the native document can be uploaded to a Web server where access is managed, and viewing is enabled by purpose and device specific "viewers". We called this process "Fixed, Flow and Flock".
Want a perfect "Fixed" layout view of the native document? The Web Server provides a PDF or SVG conversion view. Want a "Flow" representation of the native? That's an HTML5 - responsive view.
"Flock" is a far more interesting view of the native. This is an HTML5 view with a collaboration panel connecting participants and their comments to specific sections of the document. These comments are then fed back into the native documents "comment/collaboration" feature set.
The corollary of Reuters Rule is to keep visual documents in the "native" format while providing fixed-flow-flock purpose oriented representations. But there remains a few other challenges before the leap from visual document to visual productivity can begin. The application and platform specific embedded components - the gears that drive a business process- must be replaced in the native document with Open Web ready alternatives.
Here's an example of the problem, coming out of the 2005 Massachusetts study. On a widespread daily level, information workers were exchanging spreadsheets and forms as email attachments. Theses documents were rife with automated data feeds connecting to both local and wan database and data transaction processing systems. The moment they became "attachments" the information went dead; er went from interactive and dynamic to "static". Recipients were constantly having to verify the original date and time stamp of the attachments. Knowing the break point was essential to understanding the value of the documents information. Verification was so costly, time consuming, and error prone as to render the access and exchange process next to worthless.
Early on in our analysis of Sam's report, and the volumes of feed back at the studies web site that he analyzed, we realized that a Jabber router could go a long way towards solving the brittle connectivity problem. Florian Reuter came up with an incredibly innovative solution, but we would have to re jigger the Microsoft Office interface, enabling a special, data connectivity instance of an XML panel to facilitate a Web ready binding. The MSOffice XML panel wasn't complicated, and we were not sure how long Microsoft would leave this window open once they saw the full range of functionality possible. But a more basic problem remained; how to connect local and wan data servers to a Jabber or JSON Web Server without upsetting the high priests of the database empires. It wasn't a technical problem as much as a political one.
The thing is, Massachusetts had expectations that Open Web / SOA technology existed or could be created so that the great transition from the legacy Windows productivity platform to the We could begin. They expected Web ready and fully standardized open formats for Office Suite compound documents. They expected Web ready productivity systems they could transition to. They expected to avoid costly rip-out-and-replace. They expected Web ready open source / open standards based software systems on both client and the server. They got zip.
But here we are, near seven years later, discussing whether the language of the Web is going to be the language of the future. For sure Massachusetts, along with anyone else who had half a brain, assumed this issue had been settled as far back as 1995, when the Web burst onto the scene, promising to obliterate every other platform with it's magic of converged communications, collaborative computation and universal access. Yet here we are.
Thanks for the interesting post Jeremy - and sorry for the rant. Getting caught in the grind and stomp of behemoth corporations fighting for the future of computing platform is not pretty. There are a thousand stories to be told. I wanted to tell mine, and tell it in this particular HTML5 context, before finally be ground to dust as what "could have been" becomes our collective loss.
Hope all is well,
~ge~
