Monday, April 30, 2012

Fixing Software Patents, One Hack At Time



Software patents are broken and patent trolls are seriously hurting innovation. Companies are spending more money on buying patents to launch offensive strikes against other companies instead of competing by building great products. There are numerous patent horror stories I could outline where they are being used for all purposes except to innovate. In fact the software patent system as it stands today has nothing to do with innovation at all. This is the sad side of the Silicon Valley. While most people are whining about how software patent trolls are killing innovation some are trying to find creative ways to fix the problems. This is why it was refreshing to see Twitter announcing their policy on patents, Innovator's Patent Agreement, informally called IPA. As per IPA, patents can only be used in an offensive litigation if the employees who were granted the patents consent to it. I have no legal expertise to comment on how well IPA itself might hold up in a patent litigation but I am thrilled to see companies like Twitter stepping up to challenge the status quo by doing something different about it. If you're an employee you want three things: innovate, get credit for your innovation, and avoid your patents being used as an offensive tool. IPA is also likely to serve as a hiring magnet for great talent. Many other companies are likely to follow the suit. I also know of a couple of VCs that are aggressively pushing their portfolio companies to adopt IPA.

The other major challenge with software patents is the bogus patents granted based on obvious ideas. I really like the approach taken by Article One Partners to deal with such patent trolls. Article One Partners crowdsources the task of digging the prior art to identify bogus patents and subsequently forces the US patent office to invalidate them. Turns out that you don't have to be a lawyer to find prior art. Many amateurs who love to research this kind of stuff have jumped into this initiative and have managed to find prior art for many bogus patents. It's very hard to change the system but it's not too hard to find creative ways to fix parts of the system.

I would suggest going beyond the idea of crowdsourcing the task to find the prior art. We should build open tools to gather and catalog searchable prior art. If you have an idea just enter into that database and it becomes prior art. This would make it incredibly difficult for any company to patent an obvious idea since it would already be a prior art. We should create prior art instead of reactively research for it. Open source has taught us many things and it's such a vibrant community. I can't imagine the state of our industry without open source. Why can't we do the same for patents? I want to see Creative Commons of patents.

The industry should also create tools to reverse translate patents by taking all the legal language out of it to bring transparency to show for what purposes that patents are being granted for.

I would also want to see an open source like movement where a ridiculously large set of patents belong to one group - a GitHub of patents. And that group will go after anyone who attempt to impede innovation by launching an offensive strike. If you can't beat a troll then become one.

Silicon valley is a hacker community and hackers should do what they are good at, hack the system — to fix it — using creative ways.

Photo: Opensource.com

Wednesday, April 18, 2012

4 Big Data Myths - Part II



This is the second and the last part of this two-post series blog post on Big Data myths. If you haven't read the first part, check it out here.

Myth # 2: Big Data is an old wine in new bottle

I hear people say, "Oh, that Big Data, we used to call it BI." One of the main challenges with legacy BI has been that you pretty much have to know what you're looking for based on a limited set of data sources that are available to you. The so called "intelligence" is people going around gathering, cleaning, staging, and analyzing data to create pre-canned "reports and dashboards" to answer a few very specific narrow questions. By the time the question is answered its value has been diluted. These restrictions manifested from the fact that the computational power was still scarce and the industry lacked sophisticated frameworks and algorithms to actually make sense out of data. Traditional BI introduced redundancies at many levels such as staging, cubes etc. This in turn reduced the the actual data size available to analyze. On top of that there were no self-service tools to do anything meaningful with this data. IT has always been a gatekeeper and they were always resource-constrained. A lot of you can relate to this. If you asked the IT to analyze traditional clickstream data you became a laughing stroke.

What is different about Big Data is not only that there's no real need to throw away any kind of data, but the "enterprise data", which always got a VIP treatment in the old BI world while everyone else waited, has lost that elite status. In the world of Big Data, you don't know which data is valuable and which data is not until you actually look at it and do something about it. Every few years the industry reaches some sort of an inflection point. In this case, the inflection point is the combination of cheap computing — cloud as well as on-premise appliances — and emergence of several open computing data-centric software frameworks that can leverage this cheap computing.

Traditional BI is a symptom of all the hardware restrictions and legacy architecture unable to use relatively newer data frameworks such as Hadoop and plenty of others in the current landscape. Unfortunately, retrofitting existing technology stack may not be that easy if an organization truly wants to reap the benefits of Big Data. In many cases, buying some disruptive technology is nothing more than a line item in many CIOs' wish-list. I would urge them to think differently. This is not BI 2.0. This is not a BI at all as you have known it.


Myth # 1: Data scientist is a glorified data analyst

The role of a data scientist has exponentially grown in its popularity. Recently, DJ Patil, a data scientist in-residence at Greylock, was featured on Generation Flux by Fast Company. He is the kind of a guy you want on your team. I know of a quite a few companies that are unable to hire good data scientists despite of their willingness to offer above-market compensation. This is also a controversial role where people argue that a data scientist is just a glorified data analyst. This is not true. Data scientist is the human side of Big Data and it's real.

If you closely examine the skill set of people in the traditional BI ecosystem you'll recognize that they fall into two main categories: database experts and reporting experts. Either people specialize in complicated ETL processes, database schemas, vendor-specific data warehousing tools, SQL etc. or people specialize in reporting tools, working with the "business" and delivering dashboards, reports etc. This is a broad generalization, but you get the point. There are two challenges with this set-up: a) the people are hired based on vendor-specific skills such as database, reporting tools etc. b) they have a shallow mandate of getting things done with the restrictions that typically lead to silos and lack of a bigger picture.

The role of a data scientist is not to replace any existing BI people but to complement them. You could expect the data scientists to have the following skills:

  • Deep understanding of data and data sources to explore and discover the patterns at which data is being generated. 
  • Theoretical as well practical (tool) level understanding of advanced statistical algorithms and machine learning.
  • Strategically connected with the business at all the levels to understand broader as well deeper business challenges and being able to translate them into designing experiments with data.  
  • Design and instrument the environment and applications to generate and gather new data and establish an enterprise-wide data strategy since one of the promises of Big Data is to leave no data behind and not to have any silos.

I have seen some enterprises that have a few people with some of these skills but they are scattered around the company and typically lack high level visibility and an executive buy-in.

Whether data scientists should be domain experts or not is still being debated. I would strongly argue that the primary skill to look for while hiring a data scientist should be how they deal with data with great curiosity and asking a lot of whys and not what kind of data they are dealing with. In my opinion if you ask a domain expert to be a data expert, preconceived biases and assumptions — knowledge curse —  would hinder the discovery. Being naive and curious about a specific domain actually works better since they have no pre-conceived biases and they are open to look for insights in unusual places. Also, when they look at data in different domains it actually helps them to connect the dots and apply the insights gained in one domain to solve problems in a different domain.

No company would ever confess that their decisions are not based on hard facts derived from extensive data analysis and discovery. But, as I have often seen, most companies don't even know that many of their decisions could prove to be completely wrong had they have access to right data and insights. It's scary, but that's the truth. You don't know what you don't know. BI never had one human face that we all could point to. Now, in the new world of Big Data, we can. And it's called a data scientist.

Photo courtesy: Flickr

Friday, March 30, 2012

4 Big Data Myths - Part I



It was cloud then and it's Big Data now. Every time there's a new disruptive category it creates a lot of confusion. These categories are not well-defined. They just catch on. What hurts the most is the myths. This is the first part of my two-part series to debunk Big Data myths.

Myth # 4: Big Data is about big data

It's a clear misnomer. "Big Data" is a name that sticks but it's not just about big data. Defining a category just based on size of data appears to be quite primitive and rather silly. And, you could argue all day about what size of data qualifies as "big." But, the name sticks, and that counts. The insights could come from a very small dataset or a very large data set. Big Data is finally a promise not to discriminate any data, small or large.

It has been prohibitively expensive and almost technologically impossible to analyze large volumes of data. Not any more. Today, technology — commodity hardware and sophisticated software to leverage this hardware — changes the way people think about small and large data. It's a data continuum. Big Data is not just about technology, either. Technology is just an enabler. It has always been. If you think Big Data is about adopting new shiny technology, that's very limiting. Big Data is an amalgamation of a few trends - data growth of a magnitude or two, external data more valuable than internal data, and shift in computing business models. The companies mainly looked at their operational data, invested into expensive BI solutions, and treated those systems as gold. Very few in a company got very little value out of those systems.

Big Data is about redefining what data actually means to you. Examine the sources that you never cared to look at before, instrument your systems to generate the kind of data that are valuable to you and not to your software vendor. This is not about technology. This is about completely new way of doing business where data finally gets the driver's seat. The conversations about organizations' brands and their competitors' brands are happening in social media that they neither control nor have a good grasp of. At Uber, Bradly Voytek, a neuroscientist is looking at interesting ways to analyze real-time data to improve the way Uber does business. Recently, Target came under fire for using data to predict future needs of a shopper. Opportunities are in abundance.

Myth # 3: Big Data is for expert users    

The last mile of Big Data is the tools. As technology evolves the tools that allow people to interact with data have significantly improved, as well. Without these tools the data is worth nothing. The tools have evolved in all categories ranging from simple presentation charting frameworks to complex tools used for deep analysis. With rising popularity and adoption of HTML 5 and people's desire to consume data on tablets, the investment in presentation side of the tools have gone up. Popular javascript frameworks such as D3 have allowed people to do interesting things such as creating a personal annual report. Availability of a various datasets published by several public sector agencies in the US have also spurred some creative analysis by data geeks such as this interactive report that tracks money as people move to different parts of the country.

The other exciting trend has been the self-service reporting in the cloud and better abstraction tools on top of complex frameworks such as Hadoop. Without self-service tools most people will likely be cut off from the data chain even if they have access to data they want to analyze. I cannot overemphasize how important the tools are in the Big Data value chain. They make it an inclusive system where more people can participate in data discovery, exploration, and analysis. Unusual insights rarely come from experts; they invariably come from people who were always fascinated by data but analyzing data was never part of their day-to-day job. Big Data is about enabling these people to participate - all information accessible to all people.

Coming soon in the Part II: Myth # 2 and Myth # 1.

Wednesday, March 21, 2012

Learning From Elevators To Design Dynamic Systems


Elevators suck. They are not smart enough to know which floor you might want to go. They aren't designed to avoid crowding in single elevator. And they make people press buttons twice, once to call an elevator and then to let it know which floor you want to go to. This all changed during my recent trip to Brazil when I saw the newer kind of elevators.

These elevators have a common button panel outside in the lobby area of a high rise building. All people are required to enter their respective floor numbers and the machine will display a specific elevator number that they should get into. Once you enter into an elevator you don't press any numbers. In fact the elevators have no buttons at all. The elevator would highlight the floor numbers that it would stop at. That's it! I love this redesigned experience of elevators. It solves a numbers of problems. The old style elevators could not predict the demand. Now the system exactly knows how many people are waiting at what floors wanting to go where. This allows the system to optimize the elevator experience based on several variables and criteria such as speed, priority, even distribution, power conservation etc. This also means an opportunity to write interesting algorithms for these elevators.

This is how I want ALL the systems to be - smart, adaptive, and dynamic. Just like this elevator I would like to see the systems, especially the cloud and the analytics, to anticipate the needs of the end users as opposed to following their commands. The context is the key to the success of delivering what users would expect. If the systems are designed to inquire about the context — directly or indirectly, just like asking people to push buttons before they get into an elevator — they would perform more intelligently. Some location-based systems have started to explore this idea, but it's just the beginning. This also has significant impact on designing collaborative recommendation systems that could help the end users find the right signal in the ever increasing noise of social media.

The very idea of the cloud started with the mission to help users with elasticity of the commodity resources without having users to learn a different interface by giving them a unified abstraction. If you had two elevators in a lobby, you wouldn't use this. But, for a high rise with a few elevators, the opportunities are in abundance to optimize the system to use the available resources to provide the best experience to the people, the end users.

Self-configuring and self-healing dynamic systems have been a fantasy, but as the cloud becomes more mature, dynamic capabilities to anticipate the needs of an application and its users are not far fetched. Computing and storage are commodity on the cloud. I see them as resources just like elevators. Instead of people pushing buttons at the eleventh hour I would prefer the cloud take a driver's seat and becomes much smarter at anticipating and managing applications, platforms, and mixed workload. I want the cloud to take this experience to the next level by helping developers develop such adaptive and dynamic applications. I almost see it as a scale issue, at system as well as at human level. If the cloud does promise scale I expect it to go beyond the commodity computing. This is why PaaS excites me more than anything else. That's a real deal to make a difference.

Thursday, February 23, 2012

Simple Workflow Service - Amazon Adding One Enterprise Brick At Time



Yesterday, Amazon announced a new orchestration service called Simple Workflow Service. I would encourage you to read the announcement on Werner's blog where he explains the need, rationale, and architecture. The people I spoke to had mixed reactions. One set of people described this as a great idea and were excited that the developers can now focus on writing domain-specific code as opposed to writing plumbing code to orchestrate their actual code. The other set of people felt that this service creates a new cloud lock-in making it difficult for the developers to switch from one cloud to another as well as being able to interoperate at the orchestration level.

I believe this is a brilliant idea for a variety of reasons. Orchestration has always been painful. Ask the developers who have been involved in managing task execution across a cluster that required them to code for load balancing, handling exceptions, restarting hung processes, tracking progress etc. This is not a core competency the most developers have but they do end up writing such code due to lack of better alternative. The frameworks such as WS-BPEL were not designed to run in cloud-like environments and there has been no single standard REST orchestration framework out there that people could use.

From a vendor's perspective, I admire Amazon's ability to keep innovating via such services that differentiate them as a leading cloud vendor. As computing becomes more and more commodity, competing based on price alone isn't a good idea. If you're a cloud vendor you need to go above and beyond the traditional IaaS attributes even though you excel in all of them. I also see PaaS eventually bleeding into IaaS as IaaS continues to become a commodity. As far as PaaS goes, federated or otherwise, we're barely scratching the surface.

I don't see this service as a cloud lock-in but it certainly makes EC2 more attractive and sticky. I would be concerned if Amazon were to force the developers to use their SWS for orchestration. This is their version of how they think orchestration should be done and the developers can opt in if they want. And kudos to them to think beyond their cloud. The folks who worry about cloud lock-ins also talk about Amazon not following the standards. I believe that we should not create standards for the sake of creating standards. I am a believer in first showing that something works and later, if there's enough interest, figure out a way to standardize it. All these talks about standard-first even before you write that first line of code doesn't make any sense.

It's yet to be seen how this service turns out, but this is a huge step forward for getting more enterprise software customers onboard. Orchestration is one of the most chronic problems of enterprise software and with the challenges of a hybrid landscape to be able to orchestrate across on-premise and cloud-based solutions, this service is certainly a step in the right direction. Right Scale has been using a Ruby workflow Ruote for their workflow needs and now they orchestrate these workflows using SWS  to achieve fault tolerance and concurrency. As you can see, Amazon has opened up a gold mine for start-ups. The back-end execution has always been challenging. Now, there is an opportunity to write your own enterprise grade workflow engine or scheduler that runs in the cloud.

Friday, February 17, 2012

Wrong Side Of The IT Ecosystem



I find it ridiculous that people are blaming Apple for job creation in China as opposed to in the US. People are also debating how US might in-source some of these manufacturing jobs to compete with China who has sophisticated manufacturing abilities and large skilled labor force supporting these operations. They are all missing the point. This is a wrong debate.

The US lost manufacturing jobs to other countries a long time ago. I find it amusing that people expect the high-tech companies such as Apple to create manufacturing jobs in the US. If Apple were to even consider this option we would not have seen the tremendous success of Apple as a company and its products. What Apple created is an ecosystem of people and companies that are doing amazing things with their platform and their devices. It's a different kind of ecosystem and America should focus on that innovation as opposed to bringing those manufacturing jobs back.

On one side we are whining about the loss of manufacturing jobs and on the other side we have shortage of skilled IT workforce. Try hiring a good developer in the Silicon Valley and you'll understand what I mean. And yet as a nation we are behind in retraining our existing workforce, attracting students to engineering majors, and fixing our immigration policy for highly skilled foreign workers to meet the increased demand of IT-driven jobs. And, of course, while we wait, Apple is quadrupling its IT investment in India.

America should not play the manufacturing game with China or for that matter with anyone else. We are at such a loss. Let's play the game that we know we can win — technology-driven innovation. When I work with customers' on daily basis I come across so many opportunities that we are not looking at. We can use the technology, that we have built, to our advantage in the industries such as healthcare, agriculture, public sector etc. A combination of cloud and mobility could take us long way.

We're looking at the wrong side of the IT ecosystem. I don't expect the hi-tech companies to hire low-tech workers in the US. But I do expect hi-tech companies to create jobs in the US at the other end of the ecosystem via the opportunities to consume their technology and innovate in a different sector. A lot of people are missing this point. I'm talking about an ecosystem where Apple has paid out more than $4 billion to the developers. Why are we not talking about these jobs? Apple has more than $100 billion in cash, but what doesn't get much discussed is that a large part of this cash is overseas. Given the current US tax laws, Apple can't/won't bring this cash back into the US. This might make Apple acquiring or investing overseas. We do have an opportunity to reform the tax laws to deal with such a global situation (that we never encountered before) to encourage the hi-tech companies to invest into R&D in the US and not overseas.

When you look at the big picture, having a job is merely one piece of contributing to good standards of living. What about access to affordable healthcare and college education? There's a significant opportunity to apply technology built in America to innovate in these areas. We are barely scratching the surface of what's possible in healthcare as well as in education. We are living in such an antiquated and inefficient system.

Another industry that has seen less than desired technology innovation is agriculture. Take a trip down to central California to see the potential. At 2008 Olympics in China, Michael Phelps winning 8 gold medals was obviously the biggest highlight for us, but people in Watsonville were super excited because China allowed the US to export Watsonville strawberries for the Olymipcs. Recently, India relaxed the laws (that are still being challenged) to allow 100% foreign investment in the retail sector opening up the doors for Wallmarts of the world. Any guess what's the biggest challenge in retail operations in India? A non-existent cold supply chain and lack of reliable infrastructure. We take a lot of things for granted — nationwide freeways, strong governing bodies such as FDA, and size of the country. We do have an opportunity to excel in certain agriculture areas and employ a lot of Americans. We need to recognize what our real strength is and look forward as opposed to look backwards.

I am a geek and a technology enthusiast, and perhaps a little naive. But, I know for sure, we aren't pushing the technology envelope as much as we should.

Photo: Looking Towards Tomorrow

Tuesday, January 31, 2012

To RIM: Don't Change The Strategy, Change The Rules


A lot has been said and discussed about RIM's downfall: indecisive leadership, inability to innovate at fast pace, and no clear path to recovery. I don't disagree at all with the analysis and the interpretation of the situation, but I do disagree with the conclusion that many people are drawing and vehemently disagree with their advice to RIM to keep trying to regain the smartphone market share. That train has left the station and RIM doesn't have a chance to catch up, even if they do everything that they could.

But RIM may have stumbled upon something that they probably least expected. It's the BlackBerry Messaging, popularly known as BBM. We got to see the power of BBM during the London riots. During my recent trip to India, I firsthand witnessed how much of people's lives depend on BBM. These people were sad, upset, and depressed due to a RIM infrastructure outage. This is a phenomenal success. The recipe behind this success is quite simple: provide free messaging that looks likes SMS that supports groups in a network. RIM has significantly leveraged network effects; BBM got better as more and more people used it. The sale of BlackBerry in India has gone viral. The consumers buy Blackberries since their friends have it so that they can chat with them for free and perhaps do their emails. These consumers don't use any apps at all! Their needs are quite simple. These phones are also priced well - the median price is somewhat around $200 for an unlocked phone. The Indian middle class and upper middle class have no issues shelling out this money to buy a BlackBerry. I talked to quite a few people and they are moving away from Android and iPhone to BlackBerry. Yes, that's right. If RIM can manage to introduce lower end versions of BlackBerry this will further fuel the growth.

May be, just may be, there's a category between smart and non-smart phones. For a large number of people in emerging economies making a phone call and staying in touch with their friends and family via text messages and email, and not paying too much for doing that are the driving reasons to purchase a right kind of a phone.

Let's briefly look at the history of RIM. It was the device of choice for email and calendering and perhaps still is for a lot of people. RIM myopically focused on going after the enterprise customers while iPhone and Android pulled the rug underneath them. RIM initially ignored and later underestimated the disruptive nature of this innovation. What started out as a consumer market, iPhone and Android easily crossed the chasm and entered into an enterprise and started replacing BlackBerry. We all know this story. But, something happened during this era of RIM: they ended up building a massively scalable and reliable enterprise class messaging infrastructure. This is an amazing feat of technical excellence. Building BlackBerry Messaging was a logical extension of leveraging this infrastructure. What if RIM uses this as a strength and not worry about competing in the smart OS area.

It's time to pivot.

Build a robust phone that is primarily driven off by BlackBerry Messaging and double down in emerging economies. Change the rules of the game and beat Nokia at its own strategy. Even better, spin off BlackBerry into two separate businesses: one that exclusively focuses on this strength and the other that embraces innovation by OEMing either Android or Windows or both and defend the handset as well as the services market share. I don't believe BlackBerry is cut out to innovate on a new smart phone OS quick enough to beat iOS or Android or an emerging contender, Windows phone. That would mean playing by your competitors' rules. If you learn one thing from Apple, it would be not to do this.

I don't need to tell you how many cellphones the Indians own and how many of those can buy a BlackBerry. This may not be an intended move, but this social effects driven business in emerging economies such as India as well as in other developed countries could be the second act for BlackBerry. Can other vendors replicate this? May be. Not many companies in the world can do what BlackBerry does with emails and messaging in general. Group messaging on a mobile device is a killer app in itself to drive the sales of handsets. Also, this works across the carriers and the geographies, essentially allowing RIM not to be threatened by a provider. SMS GupShup in India has been an extremely popular group messaging service. It's a validation that there is significant untapped potential for RIM.

Photo courtesy: NoHoDamon