Interview with Craig Mundie

Craig Mundie, Microsoft's technology chief talks about everything from Vista's low sales numbers, cloud computing, competing with Google, Linux desktop, and his Spotwatch in this long interview . No surprises so far.

• Cloud computing: He believes that the world is not black and white and that people won't ditch their desktop lients anytime soon to completely migrate to software as a service. I think this makes sense. Microsoft is significantly investing into cloud computing via their "live" initiative but the strategy is to complement the on-premise model to achieve the client-server-service deployment model.

• Vista: He admits that number of Vista copies sold so far is a small fraction of Microsoft's overall customer base. He calls it a cycle of diffusion and exploitation and Vista being in diffusion cycle waiting to be exploited. This is a chicken and egg problem. There are not enough Vista consumers out there and that's why developers are not that excited, but there is not enough incentive to migrate to Vista for consumers unless the development community adopts it and adds value to it.

• Google: This is my favorite: "Google's existence and success required Microsoft to have been successful previously to create the platform that allowed them to go on and connect people to their search servers.". This is a twisted argument. He makes it clear that it is not only infrastructure play but a combined infrastructure and client play to reach out to the consumers. He is betting on people needing a desktop and other clients to connect to whatever Google offers.

• Office Open XML Standard: Not there yet, but he promises that it is not far. He says "There are a lot of people who have raised a great many issues which we don't think have a lot of practical merit, but serve the purpose of creating some anxiety during this process." This is a classic standard related problem and people are super cautious when it comes to Microsoft. It is not about technology but how you come clean and make people happy that you are listening to them.

Design thinking and designers

The conversation with Brandon Schauer, design strategist at Adaptive Path, about design thinking is worth reading. Brandon talks about topics such as critical thinking and design thinking, design attitude versus decision attitude, and the importance of business fluency amongst designers.

I agree that for a business problem, you do want to apply design thinking to explore as many alternatives as you can , but you do want to critically think through all the alternatives before you reach a solution and keep your stakeholders informed about your decisions. Not only business fluency is critical to do this but a designer needs to have empathy for the stakeholders as well. Traditional ethnography techniques such as contextual inquiry can be used to understand user's goals and aspirations, but the designers need to go a step further and understand their stakeholders better and for that the designers need to acquire skills in the business and strategy area.

The eBay way to keep infrastructure architecture nimble

eBay has come a long way from the infrastructure architecture perspective from a system that didn't have any database to the latest Web 2.0 platform that supports millions of concurrent listings. An interview with eBay's V.P of systems and architecture, James Barrese, The eBay way describes this journey well. I liked the summary of the post:

"Innovating for a community of our size and maintaining the reliability that's expected is challenging, to say the least. Our business and IT leaders understand that to build a platform strategy, we must continue to create more infrastructure, and separate the infrastructure from our applications so we can remain nimble as a business. Despite the complexity, it's critical that IT is transparent to our internal business customers and that we don't burden our business units or our 233 million registered users with worries about availability, reliability, scalability, and security. That has to be woven into our day-to-day process. And it's what the millions of customers who make their living on eBay every day are counting on us to do."

eBay's strategy to focus on identifying the pain points early on and solving those problems first and keep the infrastructure nimble to adapt to growth has paid off. eBay focused on an automated process to roll out the weekly builds into their production system and tracking down the code change that could have destabilized a certain set of features. The most difficult aspect of sustaining engineering is to isolate the change that is causing an error; fixing the error once the root cause is known is relatively easy most of the times. eBay also embraces the fact that if you want to roll out changes quickly, the limited QA efforts, automated or otherwise, are not going to guarantee that there won't be any errors. Anticipating errors and have a quick plan to fix it is a smart strategy.

If you read the post closely you will observe that all the efforts seem to be related to the infrastructure architecture such as high availability, change management, security, third-party API, concurrency etc. ebay did not get distracted by the Web 2.0 bandwagon early on and instead focused on platform strategy to support their core business. This is a lesson that many organizations could probably learn that be nimble and do what your business needs and don't get distracted by disruptive changes, instead embrace them slowly. Users will forgive you if your web site doesn't have round corners and does not do AJAX, but they won't forgive you if they could not drum up their bid and lost the auction because the web site was slow or was not available.

One of the challenges eBay faced was lack of any good industry practices for similar kind of requirements since eBay was unique in a way it grew exponentially and had to keep changing their infrastructure based on what they think is the right way to it. eBay is still working on grid infrastructure that could standardize some of their infrastructure and service delivery platform architecture. This would certainly alleviate some of the pains that they have from their proprietary infrastructure and could potentially become the de facto best practices for the entire industry to achieve the best on-demand user experience.

eBay kept it simple - a small list of trusted suppliers, infrastructure that can grow with users, and a good set of third party API and services to complete the ecosystem to empower users to get the maximum juice out of their platform. That's the eBay way!

Are RDBMS obsolete?

Today Slashdot has picked up a storycolumn-oriented databases. The story claims that one size fits all approach does not work well for the current data warehousing requirements and that the organizations should explore other options beyond legacy RDBMS. The post says "Hence, my prediction is that column stores will take over the warehouse market over time, completely displacing row stores."

The fundamental assumption here is that somehow the data warehousing solutions are drastically different than OLTP ones and that's why has different storage, or I should say access, needs. What the post is missing is that many modern OLTP applications require real time analytics side-by-side and cannot really depend upon a separate data warehousing. The technology such as in-memory databases and materialized views that run on top of OLTP RDBMS make it feasible for an application provider to just have one hybrid system - OLTP or data warehousing, whatever you want to call it. This was obviously not the case few years back and you could get shot if you propose to run your analytics on a production (OLTP) database. I do believe that there is a need for special purpose databases that are different in architecture for very specific kind of applications but RDBMS is far from being obsolete. I heard the similar arguments in the past when object oriented database vendors claimed that RDBMS would become obsolete when people would switch over to object-oriented programming languages. Deja vu all over again!

SugarCRM hops on to multi-instance on-demand architecture bus

SugarCRM announced Sugar 5.0 which has multi-instance on-demand architecture. This is opposite to multi-tenancy model where many customers, if not all, share single instance. Both models have their pros and cons and adding flexibility for an on-premise option complicate the equation a lot. But the fact is that many customers may not necessarily care what on-demand architecture the products are being offered at and any model can be given a marketing spin to meet customers’ needs.

The multi-instance model resonates well with the customers that are concerned with the privacy of their data. This model is very close to an on-premise model but the instance is managed by a vendor. This model has all the upgrade and maintenance issues as any on-premise model but a vendor can manage the slot more efficiently than a customer and can also use utility hardware model and data center virtualization to certain extent. The customizations are easy to preserve for this kind of deployment, but there is a support downside due to each instance being unique.

Multi-tenant architecture has benefits of easy upgrade and maintenance since there is only one logical instance that needs to be maintained. This instance is deployed using clusters at the database and mid-tier levels for load balancing and high availability purposes. As you can imagine, it is critical that architecture supports "hot upgrade". You take the instance down for scheduled or unscheduled downtime and all your customers are affected. The database vendors still struggle to provide a good high available solution to support hot upgrades. This also puts pressure on application architects to minimize the upgrade or maintenance time.

And, this is just a tip of an iceberg. As you dig more into the deployment options, you are basically opening a can of worms.