- Enterprise IT, General, Observations, Technology
- No Comments
Solving the Dark Data Puzzle
In this era of Big Data where more than 90% of the world’s stored information was created in the past 2 years, there is a challenge that has emerged which we see very frequently. The problem is “Dark Data” which is data and information that is segregated or hidden within an organization accessible by only a few people.
First, let’s address why Dark Data is a problem at all. There are countless examples through history where one person or team makes a discovery but a completely different person or team creates a useful application…some that come to mind are ether (for medical anesthesia) and Teflon (for nonstick cooking ware). With all the data accumulated in research and development today there are even more opportunities for applications resulting from solving the Dark Data puzzle.
At ExtensionEngine, a lot of our work involves solving the Dark Data problem. For example, we recently completed a project for a large property and casualty insurance company where they had data spread across nearly 30 different regional offices and we were able to aggregate that information into a single data warehouse and then make it accessible throughout their organization, including from executive management to their field sales reps on iPads, and many others in between. Another Dark Data solution we built and manage is for Harvard Business School professor Noam Wasserman’s research of entrepreneurial organizations and the founders who launch them. Wasserman’s research was, for many years, “Dark Data” but then through a collaboration (CompStudy) with industry players including Ernst & Young, WilmerHale and Park Square, an executive search firm, we were able to create an application providing compensation benchmarking data for entrepreneurial executives.
Solving the Dark Data puzzle requires addressing the following issues:
- Creating a central data repository. Often times data is spread out across systems and formats. Bringing it all together with a single ontology is key.
- Managing access. One of the main legacy reasons for Dark Data is fear of it falling in to the wrong hands. Designing a process and system to manage and secure access to the data is a top priority.
- Cleaning data. Even the best systems will have data quality issues and making it easy and quick to ensure dirty data doesn’t get into the system and being able to clean or expunge dirty data that does get in is a must.
- Automatic publishing. Ultimately, the key to solving the Dark Data problem is creating a way to automatically publish the right data in an informative fashion to the right people. Often this means publishing using interactive charts and graphs.
- Enterprise IT, General, Observations, Technology
- 23 Comments
Lorem Ipsum is Evil
Lorem ipsum, that place holder text that you often see in website and other graphic design, has been around since the sixteenth century by some accounts, but became popular in the 60s when Madison Avenue and the golden age of advertising took off. Its use today in web design, however, is corrupting to the point that it’s become evil.
Do you think Apple uses lorem ipsum?
I can’t tell you the number of websites I’ve seen designed with lorem ipsum (some of those designed by yours truly). Funny enough, I’ve even seen a few websites or products go live with some of that lorem ipsum placeholder text still there! The idea that somehow I need to make a good looking website and then figure out what to say is absurd! I think a lot of people do this because they (1) don’t know how to do graphic design and (2) they don’t know how to program but they do know how to write (or at least they think they do). So many folks outsource #1 and #2 and put in lorem ipsum as filler until they themselves can come back after they are done and write the real copy.
So by the time a website creator figures out what they want to say, they already have pretty designs, beautiful buttons, cool interactive charts with nifty forms that all tell half a story that is certainly not aligned. The end result is either a confusing user experience or a lot of wasted time and money spent fixing it.
I suspect the advent of lorem ipsum was for technical reasons. Before the age of Photoshop, designers would have to actually draw things so it made sense to put in filler text while the actual copy was being worked out. But today there is no need for that.
So here’s my advice to those planning to build a website. Start with your message. Then write a story in words and surround that with whatever the lorem ipsum equivalent of graphics and images is. Once you’ve nailed your branding, messaging and story to the point where you know exactly the experience you want, only then do you commission expert designers and programmers to manifest your vision.
The last point I will make on this topic is don’t assume you personally know how to write well. Most of us don’t know how to do that. There are really talented writers/branding folks out there who for short money can help you craft a killer story. In fact, folks who write copy are way cheaper than graphic design folks because the buyers of these services value the latter more. Think of writers as the equivalent of OBP in the world of Moneyball.
- Enterprise IT, General, Industry, Observations, Technology
- No Comments
10 Tips on Selecting an Outsourced Development Partner
For more than 15 years I’ve been on both sides of the table of selecting vendors for outsourced software development. Most of that time I’ve been on the “buy-side” hiring companies, but for the past few years I’ve been on the “sell-side” here at ExtensionEngine…in total I’ve seen hundreds of projects worth tens of millions of dollars during which I’ve made pretty much every mistake you can imagine. Based on that, here is my list of ”how to” tips that hopefully will help you avoid many of my pitfalls and achieve great results for yourself. If I were tasked with selecting an outsourced development partner, I would:
(10) Define the project. The first step in outsourcing is to define the project or initiative (which I’ll call “projects” here). The project definition should start with an answer to, “what business metric are you attempting to improve, and how?” followed by more mundane descriptions of scope, schedule, budget, etc. The more detail you can provide, the better. Writing a full RFP is the ideal, but an outline will often suffice. Here is the checklist we use when initially trying to understand the requirements for a project, which gives you an idea of what an outline might look like.
(9) Create the right cohort. Not every job is a great fit for even the “best” vendor. I always get a laugh when someone calls in to ExtensionEngine and says they’re sending out a RFP for a project to “their neighbor’s kid,” ExtensionEngine and IBM. Instead, what you want to do is create a cohort that matches your project on at least two dimensions: (a) size and (b) service offerings.
(a) Size. To grossly generalize, there are three sizes of projects: small (<$100K), medium ($100K to $1M) and large (>$1M) and similarly there are three sizes of development vendors: “tall” (<100 employees), “grande” (100-1,000 employees) and “venti” (>1,000 employees). If you have a small project, any type of vendor can do it, but realistically a “venti” vendor has too much overhead to do it practically–generally speaking you should focus on mostly “tall” and maybe one or two “grande” vendors in your cohort. If you have a medium project, every type of vendor is going to claim you’re in their sweet spot. That said, you should focus your cohort on “grande” vendors with one or two in the other categories so you have a full spectrum of opportunities. Lastly, if you have a large project, you should rule out “tall” vendors and focus on “venti” with one or two “grande”.
(b) Service Offerings. Outsourced development partners have a wide range of service offerings–you want to make sure there is a match between your needs and the cohort of vendors. Are you looking for engineering resources only that will be managed by your internal team (a service known in the biz as “staff aug”) or are you also looking for business strategy, user experience, graphics/design, dB/architecture, QA, customer support, engineering maintenance, advertising, etc.? Make sure vendors you’ll be looking at offer what you need. This matters most for the smaller vendors who, due to limited resources and specialization do not necessarily have the full breadth of offerings.
Based on the above, you’ll want to create a list of 5-10 vendors that match the general criteria of skills and interest. Once you have your cohort, you can run them though the paces (including the rest of this list) and ultimately select one.
(8) Don’t ask “where” ask “why”? Almost every client of mine asks “where” our technical resources are located, but only the savvy ask “why”? Location has a few tactical implications (e.g. time zone) and every country has its stereotype, but what really matters is the strategic basis of the location. You want to know how the location decision affects the quality of service, competitive advantage, rate of growth, profitability, etc. for the vendor. For example, with ExtensionEngine, our technical resources are primarily located in Split (population 500,000), the second largest city in Croatia. One of our co-founders is originally from Split and after living and working in the US, he recognized the opportunity. By locating our R&D center in Split, we have the largest independent development firm in the city, providing access to world class talent. Located on the Adriatic coast, Split is a beautiful place to live and enjoys a 3-to-1 cost advantage over the US. And with Croatia joining the EU in 2013, we bring stability in terms of currency, intellectual property rights and with respect to international travel. We’re not competing (yet) with the likes of Google, IBM, Infosys or hot startups which means outstanding talent and low turnover (<5%). All of this provides a competitive edge the benefits of which inure to our clients. So bottom line, ask “why” the vendor’s resources are where ever they are.
(7) Probe relevant experience. I often get asked, “does ExtensionEngine have expertise in Java [or .NET or PHP or Ruby or some other language]?” and I often joke that this is a little bit like asking your auto mechanic whether they use Craftsman or SnapOn tools. Understanding basic capabilities is important, but what you really want to know, is do they have current, relevant experience. The first cut at understanding experience is to dive into industry expertise, but even within that, there are many specialties. For example, “financial services” is really broad so if you have a “mobile banking” project you want to dig deeper. Sure any shop worth their salt can get up to speed quickly, but I would weight heavily the vendor that has current relevant experience [obviously you need to dig into any competitive issues].
(6) Meet the team. Everyone knows that when hiring a lawyer, it doesn’t matter whose name is on the door of the office so much as who is the partner working on your account (or the associate, for that matter). The same goes for selecting an outsourced development partner. The people that you’re dealing with on the sales process are going to be convincing (that’s why they got that job), but what really matters is who is going to be on your implementation team. Most vendors won’t be able to tell you the entire team (if any) prior to signing a contract, but some will be able to tell you the “engagement manager” (especially the small and medium sized vendors) who have less bureaucratic staffing processes. I would go through the entire vetting process (again) with the specific engagement team leader…it’s one thing for a firm to have specific industry experience, for example, but it only really matters if your team has it. Also, you want to get a measure of their personality…it’s the same sort of process you would go through for a direct hire. You want to make sure they fit your culture as well as bring the “right stuff.”
(5) Understand their methodology. For web and mobile applications, almost every vendor will profess some sort of agile development methodology, but in practice I have seen many (especially the large) firms simply call their old waterfall process “agile”…essentially putting lipstick on a pig. You should probe the vendors on how they manage sprints in terms of people, technology and process. Ask for samples of burn down charts and velocity reports to see what sort of rigor they employ.
(4) Push them on the approach to your project. During the vetting process, I’d push the candidate vendors to provide very detailed proposals for how they would approach your project. Attack their technical recommendations and see how they respond. Do they have conviction or are they “yes men”? You’ll learn a lot during this process. Some vendors will provide valuable insight and others will be going through the motions. How they respond should factor in somewhat in your ultimate decision.
(3) Leverage intangibles. When negotiating, particularly with the small- and mid-sized firms, you can use “intangibles” to help lower price and align long term incentives. By intangibles, I mean things like offering to do a case study or be a client reference. You can offer to participate in one of the vendors webinars or even to make introductions to peers at other organizations, helping with sales leads. Not only will these kinds of “free” offerings help you win concessions in the contract negotiations, they will also ingratiate you with the vendor and ensure that they keep you happy long term (would you upset a client that is a prominent case study and customer reference?). I often see clients “hold their referencibility” until some future date thinking that the vendor will work hard to earn it, but my experience is to give it out early and often to get the most out of it.
(2) Check References. And I don’t mean ask the potential vendor for 3 client references. Asking a vendor for references is going through the motions of checking references. That is actually a waste of time. You should reach out to clients that the vendor listed and get blind references. Don’t underestimate the value of LinkedIN in this process. If you don’t already have a “business” account, you’ll need to upgrade (costs a very reasonable $250). Then you can search for people who work at the listed clients and reach out to them using INmail. Messages cost $10 or so each to send, but it’s well worth the time and expense to get some real feedback on the vendor. Depending upon how much time you have, I would also reach out to former employees of the vendor (an easy advanced search on LinkedIN) and get their unvarnished feedback…you’d be surprised what a former employee would tell you! The other thing I would do, is to take the feedback from reference checking, particularly the not-so-good stuff and talk with the vendor about it directly. How do they respond? Are they defensive or are they thoughtful?
(1) Walk before running. Lastly, when hiring employees, years of experience have taught me to, “hire slow and fire fast.” The same advice rings true for vendors as well. It’s good to be always on the hunt for a talented development partner and it is often possible to bring them into a project gradually. You should plan, if you can, on having a ramp up period during which time you can see how the relationship is going with a vendor. Also, by messaging to the vendor that you are easing your way into the relationship and that there is more business to come if they perform, then you’ll get their full attention and, hopefully, the best results.
So that’s it. That’s my 10 tips for selecting an outsourced development partner. What do you think…are there other tips you’d like to share? If so, comment here and I’d love to discuss.
- General
- No Comments
Information is the Interface
I had the fortune of attending one of Edward Tufte’s one-day seminars in Boston last week. His seminars have become something of a pilgrimage for the data-minded, and whether or not you agree with everything he preaches, there is no questioning the influence he’s had on the science and art that has come to be known as Data Visualization. Tufte has got his presentation down to a science, and even works in some great one-liners (only the software and drug businesses call their customers “users,” and in both cases those users are really only there for one thing – the content).
The course was a full day event, and while not all of it was salient to UI/UX design, he did spend a fair amount of time highlighting some design heuristics that I think apply to what we at ExtensionEngine do for every project.
1. Information is the Interface. When designing for either web or mobile, often the easiest thing to do is to layer on lots of pretty graphics and animations, even if that means you end up “burying the lead” for the user. Especially in cases where you have lots of good data or information to present, design should be the enabler, not the end goal. Tufte cited the fact that corporate websites and presentations often have data broken up across 10 different pages or 10 different slides, making it a chore to consume all of that data at once and make the comparisons our brains want to make. A good counterexample is the sports section – millions of people can look at a table on ESPN.com that might have 10 columns and 30 rows, and not feel overwhelmed. Let the information itself be the interface, and let your users process the data on their own terms.
2. Pick your battles. When everything on a page is emphasized, then effectively nothing is; you’ve just increased the noise level. When you’re designing a homepage, if you highlight and put nice graphics around every page element, it will be difficult for the users to know what they’re supposed to read first, or how they’re supposed to follow your call to action. Instead, draw the users’ eyes to your tagline and the sign-up button. If they really want to get to your Management Background page, they’ll get there on their own.
3. 1+1=3. Two pieces of data means you have one piece of data, a second piece of data, AND the relationship or the space between the two. One of biggest ongoing UI challenges is presenting complex information in an easily digestible manner. When attempting to do so, it’s important to keep in mind not just the individual data points on which you’re reporting, but the relationship between them as well. So in practice, if you’re presenting data on heart disease, and you put the “patient age” and “rate of heart disease” columns next to each other, be aware of the effect that will have on the conclusions your users may draw.
4. Look to maps as the shining example of effective design. Maps are one of the first user interfaces, and are probably the most widely recognized. And generally speaking, maps have got it right. A map of the world can convey thousands of pieces of data, but it’s also easy for any one “user” to find the one piece of data that is most relevant to him. When you look at a map, you know that the lines drawn on it demarcate the boundaries between countries; words with the biggest font represent countries, smaller fonts stand for cities; rivers are blue and mountains are brown (and the little italicizes number is the height; a simple legend tells us how far one map-inch really is.
5. Don’t go bragging about your big swinging terabytes just yet. Designing for “big data” is a real challenge. Doing the same for “lots of data” can be easy – make sure you know the difference. If you’ve taken ten million measurements, it might seem like you have a lot of data, but if you’re just capturing the same variable over and over, you really just have one piece of data. If you’re trying to solve a bank robbery, two cameras trained on exactly the same place won’t give you 2x the number of observations. You need multivariate data – two cameras trained at different angles, plus a sound recording, plus a log of bank activity over the last week, plus some fingerprints – now you’re getting closer to “big data.”
- Enterprise IT, General, Technology
- No Comments
Project vs. Product Management
These two words sound similar and many people even use them interchangeably, however they are quite distinct. In the world of software and IT, every project however big or small requires both product and project management. For the very small projects, however, the same person will typically perform both roles and they often take a small percentage of the overall time invested in that project. But for larger projects these can become full time roles in and of themselves. If misunderstood, a project can become a huge failure, but if understood and executed well, you can achieve a wild success.
But first, some definitions:
Project Management. Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of a specific project. Think of it as keeping the “trains on time.”
Product Management. Product management is the discipline of planning, forecasting and marketing of a product at all stages of the product lifecycle. Think of this as planning the “design of the train, train routes, schedules, ticket pricing, etc.”
You can see from the above definitions, these are very different disciplines.
The Project Manager is primarily interested in and focused on:
- Staffing
- Scope
- Schedule
- Budget
- Quality
- Risk
- KYC – Know Your Customer
- Product features / benefits
- Competing products/services
- Pricing
- Sales / distribution
As you can see, the Product Manager is the subject matter expert across multiple functions (marketing, sales, engineering, finance, etc.). Success is predicated on having a great product that “wow’s” the customer that is appropriately priced and efficiently distributed.
Great Product Managers are seasoned veterans. They have industry-specific knowledge and a broad portfolio beyond engineering. They obsess about the customer experience and are keen to monetize their product optimally.
Great Project Managers are skilled in the science of development and have unmatched attention to detail. They know that good news
travels fast and bad news travels faster. They are expert communicators and they know that the devil is in the detail.
At ExtensionEngine, we pride ourselves on recruiting not only just great engineers and quality assurance professionals, but also outstanding Project and Product Managers.
- Enterprise IT, General, Technology
- No Comments
Open APIs: Time to Press Ahead, with Caution
Open APIs are all the rage now. Businesses are scrambling to put one together as quickly as they can. In fact, research firm Gartner predicts that 75% of the Fortune 1000 firms will have a public API by 2014. Such are the perceived benefits of APIs, or application programming interfaces, in an increasingly inter-connected world of technology in which websites and apps want to talk to one another, and computing becomes ever more pervasive.
In strict business terms, many APIs are simply necessary to outsource and deliver a variety of collaborative services. Sites and businesses as diverse as, for example, Facebook and Amazon have embraced and profited from open APIs. Of course, there is much more to the open APIs in Web 2.0, but there are enough pitfalls, too, in this rush to get one out the door and rake in the millions.
So you have lightning in a bottle and want to share it with the rest of the world. What should you do?
APIs hold exponential power and fit into our worldview of pervasive computing. But good APIs are notoriously difficult to deliver. This is not because programmers don’t know what needs to be done, but rather most APIs fall short because resource starved teams are focused on building the core product and are just trying to check the API box. However it’s not clear a bad API is better than not building one at all. To make the best impression on development partners, API developers need to aim a bit higher than exposing some function calls. Here are a few ground rules to get you started.
#1. Keep it simple. Do whatever it takes to make it easy for developers to implement. There are other rules but whenever in doubt, go back to this one. This is the one that matters most. Would you want to use an API that’s convoluted in its implementation?
#2. Get the big picture. The real trick to a good API is to focus on the complete “developer experience,” rather than focus solely on functions and data. That means surrounding the function calls with sample code, tutorials, forums, blogs, API Explorers, etc., is more important that getting the calls out. Better to have a small library that make’s it super easy to implement than a large library that’s cryptic and has little support.
#3. Think ahead. Just like any product, the initial release of an API is not the end game. An API is a partnership interface that will need to work over time. The function calls are only a minor piece. So, consider such things as access management (e.g. what if I forget my developer key), performance, versioning and metrics when building your API.
#4. Model APIs. If you’re thinking of creating or improving an API it’s a good idea to check some glowing examples out there. I can think of Twilio, GitHub, Twitter and Google Maps. All have solid offerings and serve as model APIs.
#5. REST + JSON + HTTP. Unless you have a sound reason to use SOAP (e.g., enterprise WSDL requirements), go with REST, which is simpler and near universal. Developers will know what to expect. For responses, you can use XML, which is structured and flexible, or JSON, which is simpler to use in a browser. But if you stick by Rule #1, it’s got to be JSON.
Also use native HTTP. It has REST built in. So instead of using a URL like:
POST /myapp/object/update/{id}
You would instead use:
PUT /myapp/object/{id}
Where POST is used for creation and PUT is for updates. Your code on the backend should know the difference between a POST and a PUT. In addition you can leverage Accept and Content-Type fields to manage versions, request and response types, and multi-language parameters.
#6. Use Standard HTTP Response Codes. This is easy. If the API throws an error don’t return 200 and explain the error in the response body. Just use HTTP standard responses. They can be found here.
#7. Allow Paginated Results. Another easy one. Allow developers to paginate the results. You just need to handle start and limit. Bonus functionality would be providing the URL for previous and next or numbered page increments in your response.
#8. Return Related URLs in Error Response. Since you can return anything in your response how about the URL for the help page associated with an error or function. While not needed in the normal course of application development, it comes in handy when there’s an error.
So, even if you recognize the issues cited above, or go over a more comprehensive API Checklist, you may not have the time or bandwidth to ensure robust management, security and reporting. In that case, you should check out the growing list of API Management (APIM) providers such as Apigee, Mashery, Layer7, 3Scale and Mashape. You could outsource some or all of the API services. Some of the services they offer include:
- Authorization and Management. An APIM provider can manage onboarding of new users, key management, partner filtering, etc.
- API Explorer. Allows developers to enter parameters on a web page and view API responses right on web page. Very cool.
- Documentation. Automated and interactive API documentation. For instance Mashery’s I/O Docs lets a user see the actual response associated with a function right in the documents.
- Security and Load Management. Are you prepared for a DOS attack? API management firms can get robust defense systems up and running quickly. You should pay attention to the provider’s implementation model. Some providers require API users to make calls directly to the provider instead of you. That may make changing providers difficult down the road. Others serve as “Connectors” where API users still connect to your API, but all traffic is routed through the API management provider before it gets to your backend systems.
- Reporting and Analytics. Know how many users are on the system? What’s the growth rate of calls to a particular feature? API management firms can provide a rich reporting suite out of the box.
Some might say that building a robust API is not for the faint of heart, but it’s really not that daunting if you tread carefully. Besides, in today’s world, not developing one could be a bigger risk!
Finally, I would like to include a checklist of best practices for designing, launching and maintaining an open API:
API Checklist
- Access
- Developer registration and key management
- Application registration and key management
- Authentication and permissioning
- Partner filtering
- Security
- Traffic control
- Rate limits
- Encryption logging
- Getting Started and Documentation
- Reason to use, benefits
- Getting started guide
- Tutorials
- Sample code
- Reference documents
- Blog
- Forum
- FAQs
- Pricing
- Terms and conditions
- Performance
- Concurrency
- Spikes
- Reliability
- SLAs
- Availability reporting
- Error tracking
- Over Time
- Versioning
- Communicating your roadmap
- API Metrics
- Bonus Points
- API Explorer
- End-user on-boarding
The list can be daunting but keep in mind that not all of this needs to implemented up front and there are a number of API management firms that can bridge the gap until you’re ready to build this yourself.
- General
- No Comments
Do You Really Know What Your Users Want? Time for Some ‘Discovery’
The Internet has profoundly changed our perceptions about a number of things, not least the concept of time. But has it sufficiently changed businesses’ perceptions of its consumers?
Take a simple thing as a website’s look and feel, and consider what it evokes in your users.
People, obviously, have different expectations. Still, most of us think we can gauge user expectations to some measure…the proverbial ‘focus group of one.’ But what we may not recognize is the dynamic nature of these expectations, and the rapidity with which they change over time. Consequently, it is critical that businesses recognize this fundamental dynamic and do so in, shall we say, Internet time.
One of my favorite anecdotes to bring home this point concerns a client of ours. The client offers products and services in the student / educational space and is probably more vulnerable than others because a large proportion of its users are so-called “digital natives” whose online behavior changes faster than most. When we began our “Discovery” process, the company was solidly skeptical about the need to spend money and time on a UX upgrade.
But you would be surprised how quickly the client changed their mind — based on some end-user feedback. Here is the gist of what that student said in a videotaped focus group of the company’s then website:
“It looks dated, old and stuffy…I fear the content might be old as well.”
Such a perception — even if it weren’t true — could be a deathblow to any company. Our client recognized that the perception was real, even if it wasn’t true that its content was not updated. To its credit, it was instantly persuaded, admitting that it hadn’t realized how much impact the look and the feel of a website has on the end user.
What is striking in that user feedback is the intuitive connection users make between a site’s look-and-feel and its content. In the Internet era, old wine in a new bottle is, perhaps, better than old wine in old bottle. Of course, the link between design and content is not the only finding that impacts users. Let me share a few other bits of user feedback on our client’s website that are quite remarkable for what it tells us about user expectations.
“Classy elegant streamlined logo but the rest of it looks like back end search. Definitely be more attractive as a web app.”
“Would like to choose sources to search.”
“I wish I could drag and re-order saved content/searches.”
“If there was a way to work with a team that would be helpful. Like Google Apps’ ability to share.”
The key thing to understand is this:
Users “interact” with any site, and its contents in myriad ways. What’s more, this process itself rapidly changes with technology.
Take, for example, the simple process of search, which has undergone dramatic changes even within the universe of Google. Different users interact differently with different search engines, or when using search features on websites. As is evident from the reactions above, users come to expect many other features seen in other sites. Consequently, businesses need to stay tuned with their users, periodically assess their changing needs and nimbly deliver on their expectations as they evolve.
Our “Discovery” process is geared to do just that and more. In this phase, we gather key information and data, and assess user experience/interface in order to formulate a sound strategy that will, among other things, provide a personalized web experience to users, extend the brand, increase market share, evaluate expansion opportunities and reposition the company to support future growth plans.
Once this preliminary evaluation is completed, extensionEngine’s team will outline a strategy that best fits the client’s need before collaborating in defining the scope of the project, its schedule and budget for development. We believe this will ensure that you will serve new wine in new bottles but at the very least be able to serve old wine in new bottle.
- General
- 1 Comment
Not Your Father’s IBM!
Legendary investor Warren Buffett’s $10.7 billion investment in IBM Corp. (NYSE: IBM) has taken the tech world, as much as Wall Street, by surprise. What is one to make of an investor, arguably the world’s most famous, who never placed a pretty penny on tech stocks, not even during the Internet boom, now making his largest quarterly commitment of cash in 15 years on a single technology company?
In the hullabaloo about Berkshire Hathaway’s huge investment in IBM, many may have missed the fact that Buffett also placed a smaller bet on Intel ($232 million), too.
Buffett’s fabled investment strategy has been built on a few principles that he believes will always remain inviolable. With regard to tech stocks, it was encapsulated in his annual letter to shareholders amid an Internet-led tech boom in 1998: “Technology is just something we don’t understand, so we don’t invest in it.”
Clearly, that has changed. When announcing his huge investment, Buffett told CNBC: IBM “fits all my principles…it’s something we expect to own indefinitely.”
So, if Buffett has not really tweaked any of his stringent investment principles, we would have to believe that IBM has dramatically transformed itself to fulfill Berkshire Hathaway’s valued standards.
What really has happened at IBM?
Oldtimers will barely recognize Big Blue today. It has shed nearly all of its hardware business – only 1.6% of its revenues come from sale of servers and computers. After a strategic shift that started over a decade ago under Lou Gerstner Jr., IBM is today a software and technology and business consulting services behemoth.
Two things are crucial here.
One, IBM’s financials have vastly improved on account of far higher margins on software and services, and extraordinary execution. So much so, some analysts are calling IBM a “classic Buffett stock.”
Two, in its strategic transformation, the 100-year-old company is looking like a perpetual business machine that is never likely to go out of fashion or business, no matter what new technology or computer might emerge in the future.
Of the two, it is the latter that finally swung Buffett. Remember he is an investor who likes candy, paint, insurance and finance – things that everybody loves or needs, no matter the circumstance. Buffett likes things that seem perpetual, which is why he then holds stocks of these companies indefinitely.
“I don’t know any large company that has been so specific about what they want to do,” said Buffett. “I felt that IBM had a very good business.”
It is clear that Buffett, finally, believes IT services will be a bedrock of business, and that no business can be run without quality computers and software. In this realm, IBM is supreme with its innovative focus on business solutions, a strategy that Wharton marketing professor George S. Day says “is sound and hard to copy.”
Even though IBM’s transformation may have finally endeared it to Buffett, the fabled investor’s final embrace of technology still is a recognition that IT firms play a crucial role in powering business and will likely do so for the foreseeable future.
And that is a view that we at extensionEngine share with Mr. Buffett.
- Enterprise IT, Technology
- No Comments
Are You Ready for the Post-Flash World?
Flash for mobile is dead. Can Flash for desktops be far behind?
That is the big question facing hundreds of thousands of websites after Adobe, maker of the most popular technology for web video and other interactive multimedia features, said earlier this month it would no longer support Flash on mobile browsers, ceding to the newer, feature-rich HTML5 technology that works – and performs better – on most mobile devices.
For years, Flash has enjoyed a monopoly that is comparable to Microsoft in the past and Google now. Just consider the following, advanced by Adobe itself but citing independent companies such as Forrester, Alexa and ComScore:

- 85% of the top 100 websites used Flash;
- 75% of web video is played on Flash players;
- 98% of PCs connected to the Internet have Flash players;
- 98% of enterprises use Flash to deliver videos;
- 70% of games are delivered using Flash
- Developer community of 3 million
Even though Flash remains near ubiquitous on PCs, web developers such as Robert Accettura give the technology a life of no more than 24-36 months. Some others such as Robert Reinhardt, founder of VideoRx.com, believe the transition to HTML5 technologies will be “slow” but “inevitable,” with the latter the operative word.
If history is any guide, technology change typically occurs more rapidly than we ever realize. In about 18 months since Apple’s Steve Jobs mounted the first serious opposition to Flash’s monopoly – refusing to include the technology in Apple’s iPad or iPhone – HTML5 has soared in popularity and emerged as a consensus technology by biggies such as Microsoft and Google. Just look at the figures below:
- 34% of the 100 most popular websites used HTML5 in the quarter ended September, according to the blog binvisions.com.
- By 2016, 2.1 billion devices will have HTML5 support, according to ABI Research Data.
- Dice.com, the tech job site, has found that resume searches for HTML5 expertise more than doubled between the first and the third quarters.
If anything, HTML5 adoption will likely accelerate, ironically because of Adobe’s abandoning Flash for mobiles.
Given the situation, what are companies and IT heads to do?
As many have pointed out, the current period is one of transition in which web developers will have to work with multiple formats. Some believe HTML5 still lacks some features such as full-screen rendering that is so exciting on a desktop or laptop, or streaming out-of-the-box. Still, many will want to progressively convert from Flash to HTML5 in order to deliver their content. Also, companies can, and should, decide when and how to manage this transition, and when to dive headlong into HTML5. These are tricky decisions critical to the enterprise but those that nevertheless need to be taken at the right time.





