Some thoughts on software development, management in general and whatever else is on my mind...
Sunday, December 13, 2020
Serverless Nirvana
This year, 2020, I took some well deserved time off from enterprise software. That does not mean, however, that I did not design and code any software. On the contrary!
During our shelter-in-place, my youngest daughter discovered the ancient board game of Mancala, and we started playing this game daily. After a while, we discovered some patterns in the game, which inspired me to start coding a back-tracking algorithm in Python that would be able to play Mancala against me and other members of my household and win (at least some of the time).
After a couple of days of a disciplined test-driven design (TDD), I was already playing against my freshly minted algorithm looking 7 steps ahead on my laptop using a simple command line interface.
Then I figured it would be cool if I could make this available to other members of my family, either to challenge my algorithm, or each other. But I also did not want to permanently dedicate any hardware to support it. Wouldn’t it be nice if this game would be 100% available, scalable to any imaginable number of players, and at the same time easy and affordable to operate?
Having previously used Amazon Web Services (AWS) Lambda Functions and API Gateway, I already knew this was possible for the back-end services. So I used these two serverless technologies to build back-end ReST APIs for playing Mancala, managed via Serverless Application Model (SAM). By leveraging principles of hexagonal architecture, I was able to reuse the Python code that was already supporting the command line interface by simply adding a lambda handler adapter on top of it.
Then I did some more research and found out that it is very much possible to also have the front end be serverless, as long as one uses one of the modern front-end frameworks to build the web client (e.g., React, Angular, or Vue.js) and publishes the front-end via AWS Simple Storage Service (S3).
After some further research, I picked Vue.js because it's the most recent of those three, it seems to be picking up mindshare, it seems to strike a nice balance between design philosophies of React and Angular, and it seems to have optimal start-up and run-time performance. But perhaps most importantly, Vue.js is also being touted as the framework that allows the quickest developer ramp-up of the three. Indeed, within a week, I had already deployed an initial version of the web user interface that allowed me to play against my algorithm.
Once I started using this early version of my web UI, I realized it was important to allow playing a single game over multiple browser sessions, for which I added persistence in DynamoDB (AWS’s no-SQL serverless database), again by adding an adapter in the back-end Python code. That means I could switch to a different data store without any changes to the rest of either front-end (JavaScript), or back-end (Python) code. But considering DynamoDB’s single-digit ms latency (both reading and writing), I doubt I’ll need to switch any time soon.
It took another week (of 2-3 hours of development per day) to implement a few other features (like animation of computer moves, allowing full control over who plays against whom, and listing rules of the game) before I could say that this serverless Mancala was ready to provide some joy not only to me, but to others as well. If you’d like to use it, feel free to do it here.
The link above should work for any modern browser; I’ve tested it both on current versions of Chrome and Edge on Windows, Chrome and Safari on MacOS, as well as Chrome on Android.
My early adopters (i.e., the members of my family) have so far played over 200 games. How much did AWS charge me for hosting those games? Nada! Zip! Zero dollars! All of the services used (S3, Amazon API Gateway, AWS Lambda, Amazon DynamoDB, CloudWatch and CodeCommit - AWS GIT repository storing my source code) are available within the AWS free tier, and so far I have not used more than 1% of their monthly quotas available.
Besides being a lot of fun, this little project of mine has demonstrated that web (or even mobile) applications today can and should be built using managed services (a.k.a. serverless). Using dedicated machines, even if they are virtual and managed by your cloud infrastructure provider is quite obsolete, and extremely non-economic!
Sunday, August 30, 2020
Tom Siebel's Dilemma
I still vividly remember entering Peninsula Golf & Country Club in San Mateo, California, the venue that was hosting Siebel Systems’ 1999 Holiday Party. Best Russian caviar and vodka on ice were greeting us at the very entrance, followed by countless offerings of gourmet food and open bars. Live band entertained over a thousand of Siebel Systems' employees and their guests, which danced well into the night.
Fast forward three years, and I was celebrating holidays with my colleagues over hot dogs and hamburgers, no guests invited. And I still worked for Siebel Systems! What happened? How could the fortune of a company change so drastically within just a few years?
I’ve thought of several different answers to this question over the last two decades, but I’ve recently read two books that allow me to provide the answer based on a solid scientific theory: The Innovator's Dilemma by Clayton M. Christensen, published back in 1997, and its follow-up from 2003: The Innovator's Solution, which Christensen co-wrote with Michael E. Raynor.
The Innovator's Dilemma and The Innovator's Solution, are just as relevant today as they were when they were written, because they explain market forces that are caused by human behavior, which evolves much, much more slowly than the technology. Both talk about disruption, which is a word that has become often used by technologists, not only in Silicon Valley, but all around the world. Yet, while virtually every start-up seeking funding from a venture capitalist is likely to claim its product or technology is disruptive, most start-ups fail in their effort to disrupt the well-established market leaders. These books define disruptive technologies as those that have the potential to bring the established market leaders down, and new entrants up, and help identify such disruptive technologies by recognizing their common properties. The Innovator's Solution goes beyond that in distinguishing strategies that can be used to successfully pursue disruptive opportunities from those that are doomed at the outset.
It is intuitive to think that every technology that makes a particular kind of product significantly better would be disruptive, but Christensen found, through his research of hard-disk market evolution over several decades, that this is not so, and that most technologies that improve existing products are what he calls sustaining technologies. It turns out that market leaders have an excellent track record of adopting sustaining technologies, regardless how different they are from their predecessors. Thus, a start-up trying to disrupt the market based on a sustaining technology is doomed to fail.
Distinction between sustaining and disruptive technology is primarily in its effect, which is visible only after the market forces have played out their interactions, so how can this distinction be used to predict the future, and choose the best strategy for dealing with a particular new technology?
It turns out that any disruptive technology, when it first emerges, is never good enough to satisfy the needs of the existing market. It is always inferior to the established technology of the day, at least when looking at the quality attributes that current market values most. Disruptive technology thus gets shunned by the market leaders, not because these companies don't want to adopt it, but because their current customers are not ready to buy products based on this technology. So, a company that embraces such disruptive technology early needs to find a new market for it, where quality attributes are differently ranked than in the main market (e.g., size instead of speed). That emerging and growing market can be then used to drive and finance the continuous improvement of chosen disruptive technology.
The rate of improvement of almost any technology (regardless whether it is sustaining or disruptive) is higher than the rate at which the needs of the market it is serving are increasing. Therefore, sooner or later, disruptive technology becomes good enough not just for the emerging, but also for the low end of the previously established market. Once that happens, the company that established itself as the leader using disruptive technology in the emerging market has an insurmountable advantage over the incumbents in the established market that had not already mastered this disruptive technology. This causes the incumbents to start losing their market share in the lower end of the established market, and move towards the upper end of the market, which typically also happens to be more profitable. But this trend inevitably continues, and eventually the incumbents have no upper market to migrate to, and are driven out of business. This process takes time, but its course seems to be very predictable.
The Innovator's Dilemma outlines, and The Innovator's Solution dives deep into the strategies that managers of established market leaders can use to cope with disruptive technologies. They explain that the only way incumbents were able avoid disruption was to create an autonomous organization chartered exclusively with the task of finding an emerging market that can be served by the disruptive technology and establishing itself as a leader in this new market. The best way for this organization to have a decent chance of achieving its goal is to start with a small, cross-functional team capable of not only innovation, but also establishing its own processes, values and culture, typically very different from those of the incumbent’s.
Now let us apply this theory to analyze and explain how Siebel Systems got disrupted and why its strategy in defending its market leadership turned out to be completely ineffective.
Siebel Systems was founded in 1993 by Tom Siebel, who had previously been a successful salesman at Oracle corporation. Siebel Systems disrupted established packaged enterprise software vendors by establishing an emerging market for Customer Relationship Management (CRM), riding the wave of ever-increasing performance of personal desktop and especially laptop computers that allowed salespeople to bring all the relevant information about their existing and potential customers with them, and share them with their coworkers, even when travelling. Siebel Systems based its architecture on an easy-to-use graphical user interface leveraging Microsoft Windows (and underlying MFC library), connecting directly to a central database server, powered by Oracle's relational database.
This product was radically different from existing packaged enterprise software products dominated at the time by SAP and Oracle, which were designed to run on mainframe and minicomputers, and so their user interfaces were designed to accommodate character-based terminals. Siebel Systems created and heavily patented its proprietary data replication technology, which allowed relevant subset of data to be synchronized between individual salespeople's laptop computers and the central database.
All that ensured Siebel System's virtually unchallenged leadership in the fast-growing CRM market throughout the 1990s, resulting in exponential sales growth, focusing its large and growing direct sales force on large, Global Fortune 500 clients as the most profitable segment of the CRM market. This market position allowed Siebel Systems to become a publicly traded company in 1996. Life was good, and the company was also growing exponentially the number of its employees, both organically and through mergers and acquisitions, reaching 1500 employees in 1999, and up to 8000 in 2000.
When I joined Siebel Systems in the spring of 1999, first thing I noticed was that all the code base was in C++. At the time, that was still the dominant programming language in the software industry, but a new programming language called Java, and its underlying technology of Java Virtual Machine (JVM) was gaining in popularity. At the time, Java indeed had properties of a disruptive, rather than sustaining technology: its run-time engine was significantly slower than C++. It also had three different, very attractive advantages over C++:
- the same code ran without any modifications on a wide variety of operating systems and, thus, hardware platforms
- development sped up by automatically managing the internal memory of a program running on JVM
- vibrant ecosystem of open source libraries and tools for emerging technologies like XML, web services, TDD etc.
- Software-as-a-Service (SaaS): hosted on Salesforce.com
- accessed exclusively through a web-based GUI
- charging a monthly subscription fee
- no customization allowed
- deployed by the customers on their premises
- accessed via thick Windows client
- licensed for indefinite use by charging a large up-front fee
- heavily customized by system integrators that would defer deployment by many months and often not bring the promised benefits
I know I'm asking for impossible, but I don't care!In order to provide such functionality in a web-based GUI, Siebel Systems' front-end engineers decided to run a bunch (more than 1 MByte) of JavaScript code in a Web browser. But the web browsers at the time were not optimized for running large amounts of JavaScript code. That caused Siebel 7.0, when it was finally released in September 2001, to be completely rejected by the customers, as its web-based GUI was unacceptably slow! At this point, the only way Siebel Systems' front-end engineers could think of how to speed the web-based GUI was to rewrite most of its functionality in C++ packaged as ActiveX controls. Again, because of Siebel Systems' culture of big, slow releases, it took them almost a full year to make this Siebel 7.2 release generally available. This significant delay of usable Siebel 7 release caused Siebel Systems to start losing a lot of sales deals. And not only was it losing its market share to the disruptor, Salesforce.com, on the lower end of the CRM market, but now it also started losing high-end customers to PeopleSoft, an incumbent that had invested heavily in rebuilding its enterprise product suite on top of Java platform! Notice that PeopleSoft adopted Java platform as a sustaining technology, because its performance was by now good enough for enterprise customers. But even once Siebel 7.2, with a fast-enough web-based GUI, was finally available to its customers, now it could only run on Windows, in its Internet Explorer web browser. And because of the long release cycle, Siebel 7.2 ended up using the older, version 5 of Internet Explorer, even though version 6 came out before Siebel 7.2 was released. At the time, this seemed like a perfectly acceptable compromise, as Microsoft had just won the The First Browser War, with Internet Explorer 5 and 6 together reaching 96% market share. However, Siebel's dependence on Internet Explorer became its Achilles heel in the long term. When, a few years later, Internet Explorer lost its market share to Google's Chrome, which provided a simpler and faster user experience, Siebel CRM’s inability to leverage Chrome’s optimized JavaScript engine has been one of the main reasons for replacement of Siebel 7+ installations with Salesforce.com in recent years. With 20/20 hindsight from 2020, it is quite clear to me now that Tom Siebel's failure to see web-based GUI as a disruptive, rather than sustaining technology (because it was not yet able to satisfy Siebel Systems' existing customers needs) caused Siebel Systems to reach an inflection point, where the revenue’s growth slowed down. This then caused Siebel Systems to lose more than 70% of its market evaluation, which then forced Tom Siebel to do a series of lay-offs, which caused employee morale to plummet in a vicious cycle that eventually led to the acquisition by Oracle. In the 4th quarter of 2003, Tom Siebel tried his last attempt to defend from disruption: he acquired a financially struggling direct competitor to Salesforce.com called Upshot. At the time, Upshot had roughly 1000 customers, while Salesforce.com already had 7500. Siebel merged Upshot engineers with engineers from an earlier acquisition, a Canadian company called Janna, to form a semi-autonomous, physically distributed engineering organization chartered with building and hosting Siebel OnDemand. This was a direct response to the Salesforce.com, which by then became good enough to start making inroads to the mid-market and even high-end of the sales automation market. Unfortunately for Siebel Systems, this was too little too late: even though Siebel Systems at the time had an order of magnitude more resources than Salesforce.com, Siebel's newly formed OnDemand organization could use only an order of magnitude less resources than Salesforce.com, so competing head-to-head against it was a losing proposition from the outset. The reason why Siebel could not use all of its engineering, product management, marketing, sales and other resources to fight against the disruption was due to the fact that the majority of its revenue was still coming from the product that was built on technology stack (C++, MFC and its awkward port to Unix platforms, proprietary web engine, ActiveX, Internet Explorer 5) that was already obsolete, but by now switching to a newer stack was prohibitively expensive. At this point, Siebel Systems was investing roughly 96% of its research and development budget on its main-stream product and its proprietary, obsolete technology stack, ~ 3% on its OnDemand product, and ~ 1% on building a brand new platform. The latter was kicked off as an engineering effort by a team of ten most senior engineers and a single product manager, tucked several blocks away from the headquarters. While this again sounds very much like following advice from The Innovator's Dilemma how to embrace a disruptive technology, it was a completely misplaced strategy: first of all, just like Sales.com few years earlier, it was trying to solve the problem that only Tom Siebel saw as relevant: how to write applications that can run both on Sun's JVM and Microsoft's .Net platforms. Second, at that time, neither of these technologies was disruptive to Siebel's customers; those customers had typically already adopted one or the other, but not both. Given this artificially created problem, this group of engineers came up with a compromise solution: use a very old version of Java (1.1.3), which predated Microsoft's .Net fork from Java, so that the same source code could run both on JVM and .Net run-time engine. They did not seem to care that, just like the usage of ActiveX controls in Siebel 7, this would prevent this "wrapper" platform from leveraging any new features introduced in either Java or .Net platforms, both of which were at the time (and for many years afterwards) still being enhanced at a very high rate of innovation. It should then come as no surprise that this new platform development effort did not yield any business value, or useful artifacts, even though by summer of 2005 it was wasting time of ~30% of Siebel Systems' engineers, until Oracle executives swiftly killed it upon acquisition of Siebel Systems in early 2006. If I were to abstract this whole story of Siebel Systems in a single sentence, I would say it is indeed a classical example of disruption. Neither first, nor the last one, for sure. But it could have been avoided if Tom Siebel weren't so arrogant, thinking he knew all there was to know about both business and technology. This caused him to completely miss the opportunity to recognize that web-based GUI and Software-as-a-Service, sold under subscription model, were indeed complementary disruptive technologies that had to be groomed together in an autonomous, cross-functional organization with different culture, values, processes and cost structure than that of Siebel Systems, which would make it capable of finding an emerging market for those technologies. If he used Sales.com in such a way toward such a goal, he would have avoided the disaster of Siebel 7 release trying to use web-based GUI on top of C++ platform as a sustaining technology. If Sales.com engineers had been given enough business and cultural autonomy in 1999, they would have easily figured out that Java at the time was already a better platform for web-based GUI, and that appropriate emerging market for web-based GUI consisted of small and medium size businesses. And by 2003, Sales.com, powered by enhancements in Java platform and web browser technology, would have enhanced its product enough to be able to fight off Salesforce.com, and be good enough to have some of Siebel's high-end customers adopt it as well. After acquiring Siebel Systems for $5.85 billion in early 2006, Oracle continued selling Siebel System's flagship product and kept Siebel as its trademark, easily recovering its investment with handsome dividends. But by summer of 2020, just like the theory in The Innovator's Dilemma predicts, the disruptor (Salesforce.com) has moved up in the previously established (CRM) market (more or less abandoning the low end of the market amid fierce competition) and the vast majority of incumbent's (Siebel Systems) customers have become disruptor's customers. Despite two major recessions that have happened since its IPO, Salesforce.com has continued growing its revenue exponentially with still no end in sight. I don't know for sure, but I'm guessing that Marc Benioff, unlike Tom Siebel, had actually read The Innovator's Dilemma!
Subscribe to:
Comments (Atom)

