Friday, February 4, 2011

Avoiding Vendor Lock-Ins

Apple had one of the most successful TV commercials of 1984, reminiscent of Orwell’s novel, “1984”. In it, Apple reacted to IBM’s explosive PC success by depicting IBM as “Big Brother” and Apple as the champion of freedom-seeking consumers.

In many ways this commercial was extremely ironic, for it was IBM who (naively as it turns out) introduced its PC architecture with off-the-shelf components, making it one of the first open platforms on the market; whereas Apple was, and continues to be, a fanatical proponent of their own proprietary, closed architectures.

Now, we mustn't fault Apple for this. After all, its strategy to control its architecture and application interfaces as well as with its application marketplace has benefited it handsomely (Apple was recently credited for being the second most valuable company in the world!).

The truth is that, from its inception, the information systems industry has undergone cycles of alternating dominance between proprietary and standardized technologies. It’s practically a law of nature that, as soon as a new technology emerges, you find vendors rushing to compete by providing unique, value-add approaches that usually fail to inter-operate with other vendor platforms; thus seeking to lock you in to their particular product offerings.

This tug of war between closed and open systems has occurred at nearly every level of the computer stack, beginning with hardware designs, operating systems (MVS vs UNIX/Linux), languages (PL/1 vs C), and networking technologies (IBM’s SNA or the now-defunct DEC pushing Decnet, as examples), up to the more recent middleware, content and presentation standards.

The inclination of vendors to capture markets via their own technologies is understandable, but standardization has actually benefitted vendors by ultimately expanding the reach and penetration of potential markets. Standardization usually won out in the past but, on occasion, it failed to materialize, resulting in the loss of market opportunities. For example, a few years ago Instant messenger was poised to take over as a communications channel. However, AOL’s refusal to open its chat protocol to standards made IM interoperability both complex and impractical. While Email’s MIME standards allowed us to exchange emails regardless of the email software or ISP we happened to be using, chatting with someone with a Microsoft account from AOL was extremely difficult and usually required additional software. Instant Messaging failed to become as pervasive as email, proving that the refusal to adhere to standards can also kill a leading vendor’s hopes to profit from a given market.

Interestingly we are now entering a phase in which proprietary systems are beginning to gain an upper hand. Facebook has become a worldwide community but, in a way, it is also a gigantic walled-garden intranet—the type of environment that AOL once aspired to become. Indeed, it is disturbing to see companies now advertising their Facebook addresses rather than their Web site addresses. The kind of lock Facebook is acquiring may well be impossible to break other than through future legislation. At the very least one could expect regulations intended to protect the access and privacy of the users as well as clarification regarding ownership of intellectual property posted on these types of social sites (as of now, almost everything you post in Facebook, including your pictures, your art and your writings could be owned by them).

Apple, on the other hand, is successfully extending the concept of AppStore for all Mac applications; not only for its iPhones. If you have ever tried to place an iPhone application in its AppStore you know that the process is akin to trying to go through airport security dressed up as a mujahedin (pat downs, included!).
Microsoft is now realizing the huge opportunity it missed out on by failing to create an “MS AppStore” of its own, offering “certified” Microsoft based applications for a fee (it is now attempting to do so). In retrospect, Microsoft’s failure to monetize its brand and create a common marketplace for all Microsoft certified applications seems like a multi-billion dollar lost revenue opportunity--not that Mr. Gates is hurting, mind you. Thankfully, consumers benefitted from the breadth of MS-based product available in the open marketplace (alas, they also suffered some negative consequences in the form of viruses and sub-par products!).

From a technology perspective, IT has gradually moved up the stack in the cycle of technology commoditization. The new standardization frontier (battleground, some would call it) is at the layer dealing with presentation, application flows, and content. I have no doubt that technology will soon make those layers also amenable to standards, but the kind of lock-ins that we will face in the future will be mostly commercial. In other words, “Lock-In 2.0”. The AppStore concept is an example of the commercially based lock-in that’s sure to receive further traction in the near future. This type of lock-in has the potential to be even more fastidious if the Telecomm-sponsored proposals against Net neutrality succeed.

Other than through the unlikely case of government regulation, the only real possible escape from heightened dependence to the likes of Facebook or Twitter is the eventual emergence of open source alternatives—something akin to Wikipedia. But the most likely outcome is that the next standardization push will take place within the confines of such environments. Let’s face it; right now it’s hard to envision an “open source” alternative to Facebook that will have the reach of users and content that that space currently enjoys.

Still, there are things you can do to preserve some modicum of leverage on behalf of your company. When it comes to technology lock-in, you can be certain that using SOA is the best antidote against dependence upon a proprietary vendor platform. However, large vendors are quickly coming to realize the best chance they have of locking in a particular customer segment (i.e. You) is via the use of marketing restrictions (i.e. Commercial Lock-In). You’ll need to place the focus on how best to protect your company against this. It’s not enough to make sure your team configures the system with the right interfaces; you should also take a deep look at your vendor contracts and the state of the industry in order to ensure that the small print in your purchase agreement does not prevent you from integrating alternative vendors or forces you to surrender your intellectual property rights.

When it comes to integration with sites such as Facebook or Twitter, do so in a loosely coupled manner (don’t forget to use services!) To the extent you can, don’t get too immersed in their technology choices. Build your business logic, content and data sets outside their specific development frameworks and hook to them via simple APIs (application programming interfaces) only . Finally, advise your marketing team to please advertise the company’s Web address and not its Facebook address! You can always place the Facebook, Yahoo or Twitter addresses as links within your web site.

Friday, January 7, 2011

Considerations on Experience and Expertise

If you are going to build a star team capable of delivering SOA systems, you will need to ensure the right mix of skills and experience. Just as in a good gourmet recipe, you will need to gather the proper ingredients and bake them together just right to achieve the desired outcome.

In addition to the more karmic aspects of this team formation: style, culture, motivation and focus, the element I believe to most define the likelihood of success is experience. The question that then arises is this: What, after all, is experience?

My older brother told a joke about a man showing up for a job posting. “How long have you been working in this role?” the interviewer asks. “I have never worked in this role,” the applicant answers. “Then why are you applying for the job?” The applicant pulls out the want ad he had seen in the newspaper and points to it. “Well, at the bottom of the Help Wanted Ad you wrote, ‘Useless to show up without experience.’ It just so happens that I have no experience and, according to my wife, I am quite useless.”

This story aside, experience is not something easy to define. Just as the US Supreme Court refused to define pornography, experience is something usually identified with the, “I’ll know it when I see it” mantra. For starters, let’s be candid and agree that experience is not necessarily what resumes claim it to be. The quality of the experience matters. How many times have you met someone who claims “thirty-year” experience when, in fact, what they have is the experience of one year, repeated thirty times? Also watch out for resumes claiming experience-by-proxy. You know, the “I am not a doctor, but I play one on TV” kind. You can identify these pseudo-experiential claims under resume sentences that read like this: “Worked with the team that developed XYZ” or “I was there when NASA placed a man on the moon.”

Furthermore, given that our objective is to build a team that can build and operate a world-class SOA system, experience is actually pointless if it does not lead to expertise. Herbert Simon, Nobel Laureate in Economics, and one of the pioneers in the field of Artificial Intelligence, stated that expertise was the ability to do a task at least three different ways. When I lived in New York, I knew of only one route to get to La Guardia from my home. However, a good cab driver knows the detours to take when traffic is jammed. (I know, today’s Navigation systems can help me match the capabilities of this cab driver—technology can be a substitute for experience).

Assuming good-quality experience, then it can be measured in terms of years of practice. According to some popular books on the subject (“Blink” by M. Gladwell, for instance), anyone can become an expert at anything by simply practicing and practicing and practicing. Interestingly, the point is made that the magic number of practice hours needed is about 10,000. I may agree with that estimate, but those quoting the study also refute the existence of natural talent under the “anyone can be a Mozart” argument, “if only they practice as much as Mozart did”. As someone who has practiced guitar for eons and who listens with envy to the virtuoso guitar playing of an eight year child prodigy (http://www.youtube.com/watch?v=NMnw7CcWO7E), I couldn’t disagree more. Still, if we ignore those savants as outliers for the sake of discussion, a 10,000 hour period represents a minimum of five years, assuming forty hours a week. This means that, unless you are a natural prodigy, you should expect it to take five years of practice (and in my book practice equals experience) to become an expert at something.

Experience can be quantified, but expertise is somewhat more ethereal. Back in the eighties, a class of software known as ‘Expert Systems’ made its appearance. This software was intended to replicate the knowledge of experts. The idea was to “reverse engineer” this knowledge via a series of heuristic rules that could then be made accessible to the rest of us mortals. As one of the most committed practitioners of this idea, I was actually able to experience the difficulty of this endeavor. First, to have experts explain how they arrived at their conclusions was more than difficult, if not downright impossible. Oftentimes, experts couldn’t even explain how or why they reached the conclusions they did!

Fact is, deep expertise is all about moving knowledge from the realm of the conscious to the realm of the intuitive; not unlike when learning how to drive makes us no longer think about the mechanics of driving. True knowledge is embedded knowledge; knowledge that has become part of our core mental fabric. Yes, Expert Systems can encode and replicate some basic If-Then-Else rules, but true expertise is often expressed by flashes of insight that are not so easy to explain, let alone dissect.

If you are familiar with the TV show House M.D., you know about the show’s leading character uncanny ability to diagnose a variety of obscure diseases thanks to his insights. President Lula of Brazil , who just recently stepped down after eight years as president with an 87% acceptance rating in the polls (imagine that!) was asked about his secret to governing. His reply: “Good government is simply the art of doing the obvious.” Of course, that’s easy for him to say. What is obvious to him may not be obvious to the rest of us. This is what made him by all accounts a great president. Stating the obvious is something we all try to do. And therein lies one of the main issues in accessing the services of true experts: It is practically impossible, at first, to differentiate the insightful advice of a true expert from the opinionated shallowness of a fool. A know-it-all fool can at times sound like an expert. Witness those cult leaders who frequently lead their followers astray with the decisive and resolute way in which they express their convictions.

But I digress. . .

You can weed out the shaft from the gold by becoming an expert at recognizing expertise. If someone claims experience in something ask them about it. What logic, constrains, rationale did they use in solving problems in the past. Get specific examples of their past performance. Evaluate their decision-making logic. Assess these and other thought-process aspects; and do not just focus on the number of years of claimed experience.

You should be just as careful when selecting the type of experience you wish to acquire in your team. Forming a great SOA team is not unlike forming a championship-level football team. You’ll need it all: the agile quarter back able to scramble and throw the ball far, the quick receivers, the strong offensive line and even the flimsy-looking field-goal kicker. Like a good football team you will need a variety of talents. The one resource with the Doctor House-like knack to quickly resolve system outages is not likely to be the one person who introduces innovation. The project manager with the ability to sense drifting timelines is much needed, but do not expect her to figure out the types of SOA services to write. The programmer able to draw up complex algorithmic code is a key resource, but he won’t be your go-to person to define the best quality assurance processes. Think of the natural leader who can motivate the team into action as someone priceless, but don’t expect her to excel at keeping track of the written status reports.

Mix the team with a variety of experiences. Remember, there are people who have a great deal of knowledge in very narrow areas (do make sure that the degree of specialization is not so narrow that you end up with someone who knows everything about nothing!) and those who have knowledge covering a wide range of areas, although their knowledge in each might be shallower. Try to have a reasonable mix of these two types of knowledge holders, and dismiss the ones who claim deep knowledge about everything. Those are the fools I referred to earlier.

For some key areas of expertise, it is and recommended to have some redundancy (the best football teams have a great second-string quarterback). In these instances, you will benefit from getting differing viewpoints from more than one expert and will be in a better position to reach you own conclusions to help decide courses of action. Having this kind of depth of expertise is not really feasible in all areas, but you should try at least to having it in the group responsible for overall architecture decisions. Lastly, make sure you integrate some bright, inexperienced talent in your group. In addition to helping you build your team for the future, having this type of resource will give much needed fresh perspectives. Potential experience can be as valuable as actual one!

In the complex world of SOA, uniformity is not bliss and experience morphed into expertise does matter.