Olympics Event = Software Platform Strategy

Ok so ive been living in a cave and have not been following on the Olympics (the only most watched event!) until I came across that Abhinav Bindra had won the first Gold Medal for India. Searching for the Olympics event lead me to nbcolympics.com and after watching some of the event videos the geek in me sprung back into life and I was wondering how they build their content publishing solution ?

Only after digging a little deeper then did it come clear that it wasn’t only China preparing to host the Olympics, Microsoft had been steadily preparing as well. If you’re a platform company like Microsoft you would use every possible (global)event to showcase your platform. After some more investigation, found that Microsoft had really planned for the event from multiple fronts to showcase their platform:

• Silverlight - All the Olympics video are based on Silverlight. Its been a while that Silverlight had been released and with Silverlight 2.0 Microsoft had really pushed the envelop in the RIA space. However, the basic challenge was for MS to get people to install the Silverlight runtime. So far Silverlight has only a fraction of the install base as Adobes Flash. Microsoft is using the Olympics event as a means to drive Silverlight adoption, and by the looks of it its working well.
  
• Search - Microsofts Live.com likely isnt your favorite search engine, but when it comes to enterprise solution Microsoft Search Server and MOSS have been making steady progress, not surprisingly MS had used MOSS to power search. As per the case study , Beijing Organizing Committee for the Olympic Games had evaluated Googles Search Appliance (GSA) but decided to move with SharePoint possibly after evaluating some of the challenges they could potentially face with GSA.
  
• MSN - MS is trying to woo people into installing the new MSN toolbar by focusing on Olympics content
  
• Others - MS is using Xbox and Zune to publish Olympic content as well
  

So whats the big deal you ask?

Its an awesome strategy! Microsoft is using a global event like the Olympics to:

1. Increase platform adoption (read Silverlight)
2. Demonstrate viability of current technologies
3. Gain mind share
   

IMHO I think it’s a brilliant strategy and also demonstrates Microsofts capabilities outside the enterprise. Other than Adobe, MS is the only other vendor that has a complete vision in its stack to deliver a broad spectrum of end user experiences and was able to demonstrate it.

But does Microsoft get everything right? Hardly, interestingly the video on the homepage is driven by Flash. Theres always room for improvement :)

How do you qualify something as "Cloud Computing"?

Cloud computing must be definitely be the next big thing, practically every one with an online business model is now referring to their service as cloud computing - starting from your average Joe hosting firm all the way to the SaaS/S+S vendors, every wants to ride the next buzzword wave, and thus distorts the cloud computing term all together. Part of the reason being that historically the term "cloud" loosely referred to anything that’s available online/on the internet. Ask a bunch of geeks and you would get a different explanation of cloud computing from each person (if you ever asked a bunch of people what Web 2.0 is you know what I mean). So how can we qualify if a service is really leveraging the cloud computing model?

That’s a tough question. An easier way to answer this is by first examining the behavior of services provided by some of the well known cloud computing vendors. Lets take Amazon and Google as two examples, both have different business models but under the hood when we use their cloud computing service within our application/service the 3 common behavior that we see from it are:
a. Scalability
b. Availability
c. Economical/cost effective

Lets discuss scalability first. Imagine your tasked to design an online application/service that should be "Internet scalable". Imagine (if you will) that your designing the next big social networking/ the next big Youtube etc. How do you go about designing it to support millions of users? For that matter how does anyone do it? The short answer - you do that iteratively. Iteratively is a good euphemism, the reality is that you do that after several design blunders and limitations :). In the iterative approach you would first design a cost effective solution to scale for a smaller audience and then when you start seeing more traffic you add more hardware till the point it doesn’t improve anything then you start to redesign for better scalability. This is how Amazon and Google have grown as well and have designed their overall system to support such high scalability - but interesting they have abstracted their design to a degree that it could be repackaged into a subscription based service - a cloud computing service.

But first how do you build a massively scalable solution. How would you build your architecture to accommodate linear scalability?

Any architecture can be described as being composed of two types of components
a. Stateless components
b. State-full components

Stateless components are those that only do some processing on data and don’t persist state - hence are easily to scale via a scaled out design which as a byproduct also gives you higher availability, also using scaled out architecture you can keep adding inexpensive boxes to the system thereby reducing your cost while the system continue to keep humming.

Statefull components on the other hand are those that persist state of resources that it need to work with - for e.g., File system, databases, BLOBs etc. traditionally the only option to scale these would be to via a scaled-up approach - i.e. beef up the hardware on the server. This is more expensive than a scaled out architecture and introduces single point of failure. Traditionally we have been using approaches such as data replication etc to scale out these components but it introduces several complications. Fundamentally statefull components are the ones that impact overall performance and scalability of a system.

Statefull components may be notoriously difficult to scale, however even stateless components can present scalability challenges when your planning for massively scalable/internet scalability scenarios. Cloud computing vendors have made significant investments in technology to ensure that compute intensive processing can been parallelized and distributed to the max. Googles MapReduce is a elegant approach to solving these challenges.

We need a new breed of products to handle how stateless and statefull components can be scaled and distributed, the traditional approach of persisting state in the database etc just doesn’t make sense, increasingly we see that the trend is not to store atomic level transaction information in a database as we used to but store it in the form of blobs, but at the same time ensure that we do so while managing resources economically. Large part of Amazons and Googles innovation (their magic sauce if you will) in cloud computing involves developing these proprietary components.

Another way of looking at the scalability that cloud computing gives you is the ability to scale your computing resources as an when you see demand - after all it’s a pay as you go model. Traditionally online companies have been provisioning for hardware to meet spikes in traffic (like holiday seasons etc). That would also imply that they are unnecessarily paying for the extra scale which they don’t leverage all the time. By hosting it via a cloud vendor they can dramatically reduce their operational cost.

Well its not just Amazon and Google that are thinking in this direction, several platform vendors like Microsoft and other open source groups are releasing products are that will address these challenges. You can expect to see some radically different products being released from these vendors that address the distributed massively-scalable challenges. You can also expect (hosting)companies to leverage these prepackaged cloud computing capabilities and provide it as a subscription service.

Cloud computing vendors are able to provide Internet scalability at an affordable cost and can potentially give you a better SLA that if you were to manage your own infrastructure - that’s the overall package that makes cloud computing so compelling, probably best described by Jef Bezos - "You don't generate your own electricity, why generate your own computing?". Arguably there are other factors that influence your vendor decision but we hope that the next time your evaluating a cloud computing vendor/solution or building your own, you know what to look for.

Is Cloud Computing Right For You?

With cloud computing receiving so much attention it makes you wonder that if cloud computing delivers so much why wouldn’t companies immediately jump on the cloud computing bandwagon?Well like several IT trends in the past, cloud computing too is evolving and (re)shaping every minute. Some of the challenges that an organization could face if they move to a cloud computing model include

• 
  Vendor lock in - it’s almost like the age of the OS wars are over, the next major war are going to be the cloud computing platform wars, yup - cloud computing vendors don’t just provide you a service they provide a platform for you to build your apps, and once your hooked to one vendors platform its going to be very difficult to make it support another vendors platform, im sure even MS is aware of this and would push heavily for cloud computing initiatives via Red Dog, Zurich and the Oslo wave.The reality is that once you choose a cloud computing vendor its going to be extremely difficult to switch to another vendor and its also difficult to design your solution to work against multiple (but similar) services from different cloud service providers.
  
• Pricing - this is one of those gotchas that you just cant escape, clients may opt for cloud computing as a cost effective mechanism, however in a this model they are not paying a one time cost - it’s a subscription charge they are paying and the service vendor can hike the subscription charges at a later time, that compounded by vendor lock in (above) would raise serious questions on moving to cloud computing.
  
• Service Level Agreement (SLA) - like in case of pricing (above), SLAs have a similar story - you move to a cloud service for better SLA that what you can economically manage - however now your at the mercy of the service provider. Recent downtimes by providers such as Amazon tells you that all is not always well in a cloud computing model
  
• Application design - Look at most OLTP apps today, it would have some form of tiered design approach. Traditionally these tiers would be designed to work in close proximity to the other tiers - with the cloud computing model there is going to be a radical shift in how we design applications and services. Several SOA best practices (patterns and anti-patterns) would apply to design applications that leverage cloud computing as well.
  
• Scalability bottlenecks - This is closely related to application design but explicitly called it out cause in many ways an application can be developed via composition of service from various cloud computing providers, however keep in mind that scalability on only as strong as the weakest link in the architecture, incorrect selection of one vendors service can compromise the performance of the entire application. Many vendor (like Googles AppEngine) provide a end to end cloud computing platform, this makes it more compelling for companies to adopt such service provider that others.

Like any evolving technology, cloud computing will see its fair share of growing pains. However, its one of those disruptive technologies that come once in a while that can radically change how we build, manage and consume software.

ISV Wish List

In the past couple of months we have been working with several ISVs to help them modernize their existing solutions/re-platform the existing application, and after some time a common patter start to emerge across all the ISV requirements - a ISV wish list if you will, which would like to summarize as:

a. Rich metadata driven extensible interface
b. Flexible and highly configurable business processes
c. Support for multiple back ends

In case of a and b (above): ISVs usually have their own professional service group that does the deployment for a new client, traditionally for each customization required by the new client the professional service group would custom develop it, however these ISVs going forward want to leverage a metadata driven approach whereby the UI and validation is dynamically created.

Up until now we have had to custom build many of these capabilities, however now with .NET 3.x several of these challenges can be met using the out of the box capabilities:

a. Rich metadata driven interface : WPF with XAML based declarative approach combined with loose XAML, the new data binding and data templatization model works extremely well for metadata driven solutions, additionally Prism (now WPF composite framework) can be used as the composite application framework container for building a thick client WPF application.

b. Flexible and highly configurable business processes: One stop solution, Windows Workflow Foundation (WF) in .NET 3.x. WF can be used to easily model complex business processes instead of writing large amount of code. Additionally we can leverage XAML activation - whereby the WF can be dynamically build and executed (i.e. dynamically compiled), this provides professional service teams with incredible flexibility to tailor/configure the business process for a given client.

c. Support for multiple back ends: Microsoft Entity Framework currently in CTP provides an entity modeling capability (ORM tool) that abstracts away the underlying DB product. All CRUD operations are performed on the entity data model and the entity framework can translate the CRUD operations to the specifics of the respective DB vendors. Additionally Entity Frameworks works nicely with WCF, all the classes that are generated behind the scene when you create the entity models are created with WCF serialization in mind.

Microsoft also informs us that they too see many ISVs having the same "wish list" and its expected that .NET 4.0 will support more of these capabilities natively.

Why Architecture is strategic

Every once in a while when we engage our clients/prospective clients on a consulting engagement they question the involvement of an technical architect in the engagement, cause they find that its an unnecessary expense and that the architecture can be developed/recommended by one of the existing development resources. Well that brings an interesting question. What is software architecture? Ask a bunch of people and a common response you get is that a software architecture defines the high level design and components to be used in the proposed system. Its correct but unfortunately that’s a very narrow perspective into what goes into defining an architecture, architecture is not just a technical decision of various software components - its strategic!. Its strategic because the architecture defines how you can monetize the product/service, the software architecture you define is what can help your product compete with other vendors in the same space and give you that edge. Not thinking of architecture as something that’s strategic is being shortsighted. To illustrate this let me give you an example.

Early this week we were on a call with Microsoft and a large enterprise in financial services to identify the high availability and disaster recovery (HA/DR) solution for their MOSS environment. The discussion finally lead down to identifying a suitable product for DR and we were discussing the many DR product options available in the market that work with MOSS. Microsoft with System Center Data Protection Manager 2007 (DPM 2007) presented a strong candidate for the client to consider from the sheer integration/understanding of the product and MOSS, however there were other vendors in DR space for MOSS as well and the financial service client was in favor of picking one of the other vendor, Microsoft sales knows how to play their cards well and dealt the trump card - Data Protection Manager (DPM) had architected their solution to leverage only the exposed MOSS APIs (which if your familiar with MOSS tells you that there are several limitations to this approach) and hence DPM is supported under Microsofts premium support where as several of the other DR vendors did not leverage the (limited)APIs but instead did direct DB access, this "hack" was easier to do and gave the vendors products more features to sell - however their product would not be supported by Microsofts premium support, i.e. if the client has any problems with their MOSS solution and calls Microsoft for support, Microsoft can deny support because they were using a DR product which is using an approach that is not supported by Microsoft. Bummer. The various DR vendors didn’t think about this in the architecture design, the "hack" they decided on which seemed technically appealing did not help them in the sale.

To the financial service client this was like a show stopper and immediately decided against its previous DR vendor selection. In the past several consulting engagements we have helped ISVs architecture their solution that avoid these kinds of pitfalls.

The next time your thinking of building an architecture are you thinking of how the architecture can empower your sales team with the strategic "battle card" to help win the deal? Is your architecture strategic?