• Home
  • Archive by category 'Opinion'

Archive for ‘Opinion’

Should you trust your project plan?

Should you ever trust your project plan?

Keeping your developer out of the ditch and your project on track.

- Keven M.Thibeault

Should you ever trust your project plan?  In our experience the answer is NO WAY.   You are guaranteed a surprise every time.  So let’s tackle the obvious.  Chances are your team will either overestimate or underestimate some or all of the following

  1. The time needed for requirements, design, and team reviews
  2. The level of support from business owners and users
  3. The complexity of integration with other platforms
  4. The quality of your data
  5. The effort and time needed to test
  6. The time needed to develop the code
  7. The readiness of your production systems
  8. The capabilities of your development team
  9. The strength of your vendor’s products
  10. The features your users really want or need


Planning how long it takes to build your application, (and its related cost) is incredibly challenging indeed.  The development world continues to change and we have to adapt how we plan our projects accordingly.


The enormous pace of change in development today has disrupted how software products are built and invalidated most conventional planning methods and historical comparisons.  Chances are your plan is off by a factor 50% or more in either direction.


And this is not always a bad thing by the way.  The good news is that many tasks now often take far less time to execute, including design, development, and deployment.   Our insatiable demand for technology has forever shaped how technology is supplied to us.  Market forces have shrunk and commoditized nearly every facet of application development.


Dedicated servers can now be provisioned in hours or even minutes with companies such as Rack Space, Godaddy, and Grid.  Code sharing sites with sample snippets like Sitepoint and PHPBuilder allow developers to search, cut, paste, and configure, (vs. customize), their way to staggering levels of functionality and sophistication.  Plugins and modules for CMS platforms such as Joomla, Wordpress, or Drupal number in the thousands and give you the ability to add capabilities in minutes.  And outsourcing mega-portals such as Elance, Odesk, and Guru give a project manager near instant access to designers, testers, business plan writers, and developers complete with virtual team rooms and project, task, and hourly tracking tools.


It is important to contain our enthusiasm however.  The incredible progress in these areas is not a guarantee for an easier dev process over-all, or a higher quality result, much less an end-to-end solution for development.  Inherent in this virtual development world are new risks and pressures placed upon your project manager.  You may save time but give up key controls.  A feature of your platform may rely on a module written by a unknown distant developer you have never met.  But it is most important to understand that any of these new tools and services still lack basic ingredients to your success.


The truth is that successful websites and mobile applications are still the result of imagination, ingenuity, elegant design, unique vision, solid product strategy, and effective marketing – none of which can be outsourced, downloaded, configured, or hosted.  You still need leadership, talent, and experience.  You need a team that works well together. You still need experts and gurus.  And of course you need a great project plan to pull it all together.



Make sure your project plan and tools are well organized and include the following


  1. Project Summary
  2. Project Goals
  3. Team Structure
  4. Activities
  5. Deliverables
  6. Dependencies
  7. Risks
  8. Communication Plan
  9. Tasks, Work Schedule, Milestones
  10. Testing Criteria
  11. Production Launch Criteria
  12. Is Web based or web enabled for multi user edit and access


Helpful Links


Project Management Software

Comparison of Project Management Software



Follow logicaldesigndb on Twitter

About the author

Keven M. Thibeault has been developing applications since 1990.  He now serves as principal and CEO at Logical Design Database Solutions based in Boston, Mass, and provides product strategy and expert application development services for web, mobile, tablet, and enterprise platforms targeting startups, interactive agencies, and technology clients.



10 Reasons Your Application Development Project Will Fail and How You Can Avoid Disaster

Keeping your developer out of the ditch and your project on track.
- Keven M.Thibeault

According to a 2010 survey of 200 companies, 53% of IT development projects failed or were seriously challenged. That’s a success rate of only 47% — slightly worse then current rate of divorce in the US!

Project Disaster

Are you a business owner or manager getting ready to invest in a new mobile application, website, ipad app, or other technology? Then you need to know how to improve your odds and make sure your project doesn’t fail.

You should understand the underlying causes of failure, learn how to counter these common pitfalls, and finally – take action to stack the odds back in your favor. 

There are two main roles that contribute to the health of any project. The first player is the business owner. The business owner sees the market or organizational need (problem) and has the vision for the product (solution). They use their experience and business prowess to imagine brand new products or improve current platforms.

The other major player is the developer or development team. Geeky developers by nature love to build solutions to their clients’ problems that impress each other and their clients. Developers take pride in constructing and inventing dynamic products that educate, entertain, or otherwise serve people in the real world.

On the surface, the two seem like a marriage made in heaven. One generates compelling ideas while the other brings these ideas to life. You would think that more often than not, business owner/developer relationships would go smoothly and enjoy harmonious bliss. We only wish this were true. More often than not, we see disjointed relationships, flimsy business plans, and unengaged project management affecting development efforts that otherwise should have been a huge success — on paper at least. In reality it is primarily the business owner/developer relationship that drives the success or failure of any technical project.

Those familiar with software development will recognize these common sentiments:

From the Business Owner: “The developer didn’t get my vision, my process, or understand my company’s and or consumers needs. They missed so many obvious details.”

From the Developer: “The business owner didn’t tell me everything I needed to know, so I was guessing most of the time and I was totally caught off guard when he was angry and disappointed in the end product. I’m not a mind-reader.”


When projects fail, who takes the blame? Generally the developer does. After all, it is the developer that seems to hold all the cards, right? As business owners, we typically assume:

• they have all the required expertise needed in all technologies or entities connected to the product
• they get it; they completely understand our business and our vision
• they know all our business rules and requirements and can apply good common sense to fill in the blanks when they lack necessary detail
• they are intimately familiar with our industry, our markets, our competitors, our corporate culture, our language, and our product offering
• they can accurately predict all technical risks and costs at the beginning of the project
• they can intuit the business meaning of every detail in the design, whether it is documented or not
• they can naturally work well with hurried, impatient business owners

While it is true that the more experienced the developer the better the resulting product, no developer can claim all of these qualities. This is especially true as it relates to custom development which is by definition new, innovative, and full of exciting unknowns.

So how do you keep your deadlines, budgets, and project plans safe from disaster? How do you help yourself manage common threats and risks?
You have to actively help your developer and your project succeed. It is possible to manage the pressures of limited funding and aggressive delivery dates if you are smart, flexible, reasonable, and commit to a thoughtful strategy and action plan to mitigate common development threats.
Above all you must commit to staying engaged throughout the project, constantly collaborating with your developer to avoid the common mistakes. So what are the top ten reasons your project will fail?

1. You design your application in a vacuum with little or no product strategy.

When car makers get ready to invest millions in a new model, they research the market to answer fundamental questions such as  What is selling now? What is not selling and why?  What is my competitor offering?  Who is buying their products?  How can we do better?  If we made something new, would anyone buy it, and who would we market to?  How much should we charge?  What designs are most appealing?  What are the current trends in features, prices, colors, etc. ?
Just as with billion dollar automotive investments, you too must give careful thought to your software application and its position in the market.   You will invest in development, but also need to plan to spend money and time on marketing and promotion to let the world know about it.  Very few products take off virally.  Yes it is possible to get free mention on Engadget or other powerful blogs,  but you cannot count on it.  Most sites and applications need social media advertising at the very least on Facebook, Linkedin or other sites.  Others, depending on budgets rely on cable, TV/movie product placement, celebrity endorsements, traditional media, and good PR.  To keep from failing, make sure you have a solid product strategy in place before you spend a single dime on development.

2. You give your dev team little to no background on your industry, niche, market, or company.

Any good developer is busy.  This means they have many clients building apps for consumer and business markets and cannot be an expert in everything.  So unless you are lucky enough to find a developer that knows your industry and company intimately, plan to spend time to educate them.  This means giving them your marketing materials, web resources for industry background, and several meetings to get them oriented.  You could avoid this step, but do so at your own peril.  If you don’t take the time to do this, they will be lacking in their design efforts.  They need to know your target audience and the main value you bring.  They can help you capture the biggest opportunity if they are knowledgeable in your markets.  ”But these are marketing disciplines” you say, “why should our developer care?”  They should care because as they build your product, they can quickly assess how it fits in the product market at large and add unique differentiators.  At the very least they can me sure the branding, look and feel stand out from your competition, and appeal to your target market.
For example, if you are building a dating site for outdoorsy singles, make sure you educate the developer on the lifestyle of your target audience.  Your developer then, might surprise you and suggest a new expanded design that includes a new plan for integration with premier camping, hiking, cycling, and boating sites for cross promotion.  Your site can help your users find BOTH a date AND a great place to go this weekend that appeals to both dating profiles.  Your site can co-register users while your partner sites share in increased revenues.

3. You rush through the design process

This is likely the largest source of aggravation for all sides.  We want an appealing and effective product design and know that as soon as it is finished, we can get on with the job of actually building the product.  This excitement can cause us to push the process along too quickly.  In our eagerness to get to the development phase, we shortchange ourselves.  We miss important details that our users invariably find after we launch. Ouch – how did we miss that one?! We may or may not blame the developer but it doesn’t matter at this point.   Our users have shared negative ratings, sales dip or crash, and we are faced with picking up the pieces.
To make sure you don’t miss important design details have your developer prepare screen mockups.  Don’t assume that wireframes are enough, they are not.  Wireframes are basic black and white squares, rectangle, and words with dimensions, and lack good detail.  Screen mockups are needed too.  They are usually created in Adobe Illustrator and show final end results documented with fonts, colors, sample pictures, backgrounds and the like.  These take time to build, and require investment to cover costs.  Make that investment.  If you don’t you will be setting yourself up for uncomfortable conversations later on during endless fixes and redesign.   Even if your developer is comfortable to start the project without these designs, you should insist he uses these, and you should be willing to pay for them.  As a rule, the requirements and design portion of your project should be about 30% of the total cost.  The others being 30% for development, 30% for testing, and 10% for deployment to real production environments.

4. You assume your dev team thoroughly and properly tests your product for functionality before giving you a first look

Don’t assume your developer thoroughly tested anything. They should, but they often do not.  Developers by nature are inventors.  They create.  They are stimulated by creative problem solving.  They do NOT like to test.   They do it but they do not like it. Testing is seen as mundane and anything BUT creative.  Often you will ask to see the current development version of a product in the very early stages.  In the exciting rush to build the prototype for client review, developers will cut corners on testing to meet a deadline.  Good developers will have a separate staff that does the testing.  This is huge. Go with them.
The saying, you cannot change a leopards spots applies here.  So how do you manage expectations and avoid failure?  First understand there are always hundreds of moving parts in any development project, even if there is only one person doing everything!  Just because something does not work, or does not work as expected, does not mean the developer has not given adequate effort to this feature.  They may have had a fully and correctly functioning version on a different server, but when moving it to the client server something  broke.   They may be lacking good test data.  Or just need to finish an unfinished thread of code.

In order to minimize disappointment here, it is important to document what you wish to see, before you view the prototype.  It is quite simple – give your developer testing criteria.  Just create a list of features you would like to see demonstrated first, and the results you expect in the demonstration.  For example, your list might look like this:

  • Create a new profile; user name = John_smith, password = pass1234, mobile phone number = 555-1234, profile type = “free”, upload my picture
  • Login (john_smith / pass1234) – displays welcome screen with links to “My Profile” now visible
  • Create an article to share with my friends on the site, with pictures or videos
  • Rate and comment on my friends articles, want to use five star rating, comment via text box, share on FB or twitter.

Giving simple testing criteria gives your developer the chance to knock it out of the park the first time.  All parties will be happier, and your product will get done sooner with higher quality.

5. You decide to avoid the time and cost of a stress test so you can launch sooner

Your market and investors are waiting.  The design is done.  The data is loaded.  The product looks great and performs perfectly.  So it is time to launch, right?  No way.  Not every product requires extensive load testing, but in the day of connected mobile products and consumer web applications, most really do.   Don’t skimp here.  If you expect 10,000 visitors a day when you launch, test how the servers respond when you simulate 50,000 users in two hours.   If your site allows users to upload video, and your encoding server is expecting 100 five minute videos a day, simulate 1,000 videos.   The weakest part of your platform will magically and instantly reveal itself.  You will have time to tune and adjust your platform.  You will avoid failure and avoid costly and embarrassing performance problems giving your product a real shot at a good first impression.
One of today’s most popular desktop telephone calling and video conference products which has millions of users is failing with one of their mobile products.  Users can install the mobile version on their phones, but then cannot log in!  The product works great on the desktop, but not on all mobile platforms.  They did not properly test on all supported devices, and are specifically having issues supporting users on the Android platform with some devices.  The negative feedback has been streaming in for months.  They would have been better off with nothing at this point.

6. Your dev team has no easy way to communicate progress or complications, or worse, is just bad at communication in general.

Avoid project failure and avoid costly surprises, keep engaged with your team answering design questions, and keep up to date with progress.
Just as in any relationship, the key to happiness is clear, honest, frequent communication.  Technology partnerships are no  different.  Avert failure or serious challenges by making sure your developer has good general communication skills at the start.  It is vital to interview the project manager who will be managing your product development during the sales process.  This person should be experienced and able to talk freely about the dev team and their process for client communications.
In addition, make sure your team uses a web based project management tool to track milestones, bugs, enhancement, and general communication between stakeholders, developers, and the testing team.  Most good developers do, but not all for sure.  You must know what is going on and help during any difficulties.   The alternative is to rely on an impractical and time consuming series of regular status meetings.  Meetings are important, and certainly there is nothing wrong with status meetings,  but they should not be the primary method of team communication.  With Basecamp, Bugzilla, Trak, available for free or close to free you have some very useful options.  There are many good team communication apps to employ, and if your developer is not already using one, insist that they do.

7. Your budget is not flexible

Projects can fail when owners and developers cannot accurately predict the time and cost required to build the product.  The owner can run out of available funding in the middle of a project leaving the developer with a choice to absorb the increase or not.  If no compromise can be made the relationship quickly sours and could result a stalemate where no more funding is found and no more work is being done.  The product can die on the operating table and the business relationship can devolve into a place no one wants, including threats for legal remedies.
Even with the most experienced developers, estimating projects is more an art than a science.  No developer ever bids on a project with  100% certainty they have correctly planned all hours required.   They make an educated guess based on experience and some estimating tools. So the price and the cost are always somewhat fluid.  In addition, the developer may have made concessions in the contract negotiations that leave little room for error.  With bigger projects especially, developers often cannot predict time needed to cover loosely defined requirements or integrations.  And in many cases, requirements change or grow and necessitate more development to support them.  When scope increases, be ready to add more funding to support the change.  This is common and is a contingency that should be planned for.  Keeping an eye on budgets means making decisions together with the developer on how to handle unplanned changes.

8. You choose junior level resources

The needs and resources of each business owner is different.  Many times only a fraction of an otherwise reasonable budget is available to fund product development.  In these situations the business owner has three options: 1. wait until more funding can be made available, 2. reduce the scope of the project to match funding, or 3. find junior resources at low costs to do the project.  This last option seems very appealing to many owners because by using lower cost resources, they can now seemingly afford the “five bedroom vacation home” for the mere cost of a mobile home.
It should be no surprise that common sense dictates that the result of choosing cheaper resources is higher, not lower overall costs, in the long run.  Your project is at a much greater risk of failure if you have “newbies” designing and building due to the sheer lack of real world experience.  When considering heart surgery, who would you prefer does the operation?  You want the veteran doctor who has done 1,000 procedures, NOT the new intern.  The reason is because the veteran has seen it all and knows how to handle the curveballs that inevitably come along.  The same rule applies to custom software development.  There will always be unknown challenges, and an experienced professional with a healthy business is your best friend, even if they cost a bit more.

9. You don’t take adequate time to explain your vision to your developer

It is amazing but true.  Developers often hear only the bare minimum about the product.   Business owners are by nature are driven, high energy, innovative, very busy, and lacking in patience.  When it comes time to sit down with the developer and tell the story of the product and its value in the market, they often leave out rich color and subtle detail.  They may not feel comfortable going into great detail or understand the value of the exercise to the developer.  Or they might feel it is simply not needed and therefor a waste of valuable time.  Nothing could be further from the truth.

Great products are the result of solid research, great imagination, and tight collaboration of talented professionals.  It is critical to take the time to share with the development team, the whole vision in as much detail and enthusiasm as possible.  The project is being built by real people.  If those people share the business owner’s enthusiasm and power, the product will shine.   Instead of delivering only what is asked for, they will indeed over-deliver, adding more than was ever imagined in the beginning.

10. You didn’t plan for change during the project.

Things change over time, if your project is 10-15 weeks long as most are, you will think of new ideas throughout the project.   This is okay and natural.  Make sure your developer is flexible, but also make sure you proactively plan for change.   Don’t assume your end result will mirror the original design.  IT NEVER DOES.  Also make sure you have a prototype to play with early in the project plan!  This will give you new ideas and jog your thinking.  You will come up with changes.  And it is critical to have a plan to deal with change.  If your new ideas change the scope, then change the deadline if needed and also change the budget.  Don’t get stuck in a corner with a developer who adds cost when you change the scope, and doesn’t tell you until later in the project.  Agree together on a plan for change.  All changes should be logged and priortitized.  Stick to your original plan if you want to, but if a new enhancement is needed, then you have to be willing to lengthen the project and increase the cost.  When you find that you and the developer  both missed a critical component of the product in the design process, be ready to adjust the scope.

Don’t make your developer wrong for not predicting the change, even if it seems obvious to you.  Work with them to plan if and when the change will be added to the project.   If you want to keep the budget and timing per the original plan, you can always adopt the change in a future version of your app.

Follow logicaldesigndb on Twitter

About the author

Keven M. Thibeault has been developing applications since 1990.  He now serves as principal and CEO at Logical Design Database Solutions based in Boston, Mass, and provides product strategy and expert application development services for web, mobile, tablet, and enterprise platforms targeting startups, interactive agencies, and technology clients.

1 2010 IT Project Success Survey, drdobbs.com

2 For a general definition of “failure”, consider these variables:
TIMING: TOO LATE- finished weeks or months after the project plan called for, or missed several critical deadlines during the project
COST: BLOWN BUDGET – delivered significantly over original cost estimates
QUALITY: DOA – dead on arrival, the product performed badly, did not meet most of the stakeholders needs, or had to be rescued by another team
3 the term “product” below refers to a website, a mobile website, a widget, a PC application, a tablet application, or a mobile application



More Articles Like This: “Should You Trust Your Project Plan?


Want to download your own copy?

For a limited time, you may download a FREE version of this white paper.
Just sign up with your email on this form .  You will receive a download link after you confirm your email address.


CNNTech: Apple vs. publishers: Why the tech firm already won

CNNTech  - Feb 17, 2011 By Pete Cashmore, Special to CNN

CNN) — Apple this week announced a planto levy a 30 percent fee on publishers who charge subscriptions through its App Store on the iPhone, iPad and iPod touch. The fee applies to newspapers, magazines and digital books (not to mention music and videos).

What’s more, Apple’s rules dictate that publications can’t offer these same subscriptions at a lower price outside the App Store. And in another blow to publishers, customers will have the option not to share their details — name, e-mail address and ZIP code — with the publisher.

Some publishing industry analysts are aghast at the proposal, claiming that the rate is much too steep and the terms too strict. I don’t disagree: There’s no doubt that Apple is using its dominant position in digital distribution to strong-arm publishers.

But the fact that the tech giant can propose such onerous terms without blinking points to the fact that the battle is already lost: The balance of power has permanently, irreversibly shifted from the media companies to the tech firms.

Is it possible that Google’s Android operating system and freshly announced “One Pass” subscriptions service could challenge Apple’s leadership in digital distribution?

Android is notoriously poor at persuading users to pay for apps, and the Google Checkout payments service has received a lukewarm response.

But let’s imagine that Google is one day able to exert some pricing pressure on Apple that forces the latter to negotiate friendlier terms with publishers — then we’d still have a situation in which the tech companies get to dictate pricing over the publishers, albeit with Apple taking a slightly smaller share than it might like.

Perhaps a better way to phrase this epiphany is not so much that Apple has already won but that publishers already lost — if not to Apple, then to whichever tech company dominates digital distribution in the long term. To repeat our mantra: The balance of power has permanently, irreversibly shifted from the media companies to the tech firms.

Let’s imagine some bolder moves from the publishing industry. Perhaps multiple publishers could band together in opposition, starving the App Store of content until better terms can be negotiated. Or maybe they could seek to challenge Apple on antitrust grounds. Either might prove effective in leading to slightly better terms for publishers.

But unless a media company is able to build a better tablet or a better phone or convince customers to return to paper magazines and newspapers, nothing changes the fact that the publishing industry has lost control of its most valuable asset: distribution.

It was always the printing presses and the delivery trucks, not the words themselves, that were the seat of the publishing industry’s power. The audience has moved elsewhere, and this emigration has birthed a new gatekeeper.



Can print media survive? Part II

As with any other industry, newspapers and magazines exist to make a profit.  But since people aren’t buying anymore, new approaches have to be taken.

It is the context that has changed, not the content or the demand for it.  In other words, if viable methods can be created and properly executed, established newspapers and magazine companies should be able to survive and even thrive, well into the future.

London’s Evening Standard has recently taken the bold step of going completely free and has rescued itself in the process – temporarily anyway.   Abandoning their per-issue price and turning solely to advertising for its income, new owner Russian tycoon Alexander Lebedev, rescued the company from consistent losses.  But now that the publication is seeing profits, it is probably only a short term fix in itself. With the dizzying pace of improved access to the internet via mobile devices, especially the iPad, the complete abandonment of printed news media is certainly inevitable.

One promising option is to follow in the footsteps of concepts like iTunes, where not only everything is available digitally, it is available in parts rather than as whole collections; instead of having to buy an entire album, one can purchase and download by the song.

But how would this translate exactly to the world of newspapers and magazines?  We have already shown that people are not willing to pay for quality content online – but this assumes a 1-to-1 correlation, where the publications we are used to would merely be relocated to the internet as the individual entities they are today.  This probably won’t work.

What may work however is a concept offered by Journalism Online that offers a universal payment system shared by ALL subscribing companies.  Customers would select from a list of options and pay various fees for online access to a few or all companies within the system.

Among these options would be a micro-payment  arrangement  (a la iTunes) that charges instantly for per-page view, or a broader access via monthly or annual billing – with options for full access to one, several or all of the news services available within the site.

This begs the question however: how do you get mega-monopolists like Rupert Murdoch to come on board?  Clearly the success of any such system would depend on the cooperation of many different publications that are already fighting desperately for their territory.  Someone like Murdoch who owns such a massive chunk of that territory is likely to resist such a concept more than anyone else.

But he and many others may not have that choice.  Time will tell if his experiment will work, but in this climate in which the customer is gaining more and more control over where and how they get their news, he and the rest of the drowning print news world will probably be forced to give in to this or another similar online subscription system.

Or die trying to fight it.

By Jon Simpson, Logical Design, September 27, 2010


Can print media survive? part I

Newspaper circulation continues to shrink

By Jon Simpson, Logical Design, July 13, 2010

As many print publications around the world continue to close or are just barely breathing, the hunt continues for a way to survive the global shift towards the internet for free news and information. To many this is an impossible mission, believing that no one wants to pay for an online news site when the same information is available for free in countless other places.

According to a recent Yougov survey, they are right. 83 percent are unwilling to pay for any online content but approximately 60 percent actually said they would be willing to pay for a quality newspaper – as long as it is not online.

But if this is true, why are the most respected print news publications closing down in such huge numbers? It would seem that “willing to” does not equal “going to” when there is an easier way available. Karin von Abrams, senior analyst at eMarketer says of this dilemma, “The game clearly has changed for most old business models, but we don’t yet know what the successful new ones are going to be.”

Newscorp king Rupert Murdoch finally started placing his bets on July 2nd when he took the bold first step by initializing a fee for online access to The Times and The Sunday Times newspapers in London. Arguing that “Quality journalism is not cheap, and an industry that gives away its content is simply cannibalizing its ability to produce good reporting,” Murdoch is trying to pave the way for all of his newspapers to make this shift – something the world will be watching very closely.

Making a similar point, Chicago Tribune and Los Angeles Times owner Sam Zell believes there will be a successful shift from print to pdf format via internet home delivery, saying that “there will never be a surplus of opinion…and I think the newspapers provide an opportunity to do that.”

But besides evidence provided by the recent yougov survey, there is another glaring problem here: online file sharing. Murdoch (and his son) vow to aggressively fight this problem but anyone who has been awake the last decade knows that this is largely a losing battle. What these publications need in order to survive into the internet age is a paradigm shift and some radical new approaches.

In Part II of this article, I will take a look at how the music industry’s response to the internet age may be a viable model, as well as the option of going completely free, with entirely ad-based revenues. With these and other emerging concepts there may be a remedy for the collapsing print media industry – a bridge toward a new and profitable online presence.


Strategies for Cloud Computing, Michael Jackson's Sony Website

By Charles Babcock
May 10, 2010 08:00 AM

Native Americans had no trouble believing that creatures from the spiritual world roamed at will among those of the physical. At night, these visitors became shape shifters, transforming themselves from the coyote, the bear, or the raven into a spirit form, then changing back again at daybreak.
Cloud computing is nothing if not similarly amorphous. The cloud’s hard-edged, warehouse-sized data centers accessible on the Internet, filled with seven-foot-tall racks of pizza box servers, seem concrete enough. But when an individual end user accesses a server in the cloud, the server has the ability to take on or shed processing cycles from CPUs and use more memory or less, as needed. The user’s cloud machine expands according to her needs and shrinks when peak processing is over. It may be on one side of the data center one moment and on the opposite the next. The end user hasn’t slowed down what she’s doing; the shift in servers occurs without her realizing it. In the cloud, the computer becomes a shape shifter. It’s not limited by the box it arrived in; instead, it’s elastic.
When you need a computing resource to serve you, but you don’t know how much of it you’re going to need, this special characteristic of the cloud — elasticity — will serve you well. To see this elasticity in action, take the example of Greg Taylor, senior system engineer at Sony Music Entertainment, who is responsible for the computing infrastructure that supports the Web sites of thousands of recording artists and hundreds of individual artists’ online stores. In 2009, Taylor felt that he had adequate monitoring systems and surplus capacity built into his infrastructure. At theMichaelJackson.com store, for example, he could handle the shopping transactions and record comments from 200 shoppers at a time on the store’s site.
Upon the star’s unexpected death on June 25, 2009, the site was suddenly overwhelmed with people who wanted to buy his music or simply wished to congregate with other grieving fans and leave a comment. Sony Music saw an influx of more than a million people trying to access the Michael Jackson music store over the next 24 hours. Many wanted to post comments but could not. The servers stayed up, but not everyone who wanted to find album details could be served that information, and indeed, many would-be purchasers could not buy because traffic overwhelmed what was already “a very database intensive” site.
Other surges were felt around the Internet. The Twitter broadcasting site was overwhelmed by users’ tweets and slowed to a standstill. TicketMaster in London slowed to a crawl. Yahoo! was staggered by 16.4 million site visitors in the 24 hours, compared to a previous peak of 15.1 million on Election Day.
“Our site became the water cooler for everyone wanting to remember Michael Jackson,” Taylor recalled in an interview four months later.

Sony Music’s top management told Taylor that it was not acceptable to have traffic trying to reach a company music site and have would-be customers left hanging, with no response from an overwhelmed site. With 200 individual artists’ e-commerce sites engaged in capturing both transactions and user feedback, Taylor had a large problem that couldn’t be solved in the conventional way: buy a lot more servers, more network bandwidth, and more storage, and throw the mat the problem. If he had followed this route, most of that expensive equipment would have sat unused in Sony’s own corporate data center. What’s a senior system engineer to do?
Taylor has since re-architected the Michael Jackson store, AC/DC’s online store, and other popular artists’ sites so that traffic can be split into two streams when necessary: those who are buying music (conducting transactions) and those who are just seeking information. The transactions remain on the core store site hosted on Sony’s dedicated servers, but visitors who are seeking read-only content, such as background on an artist and his albums, can be shunted off to the multitenant servers in the cloud. Many cloud customers in addition to Sony Music share those servers, keeping the costs for the music company low.
The cloud service that Taylor chose was Amazon Web Services’ Elastic Compute Cloud (EC2). In the future, Sony will build each artist’s store in tandem, with an e-commerce site and a related but separate information-serving site in EC2. When the e-commerce site starts to get overloaded, the latter can expand to meet nearly any foreseeable traffic count, thanks to the elasticity of the cloud.
SMBs are getting the analytical capabilities to drive faster decisions based on better data

BI For the Small-Medium Business
As traffic at any artist’s Web site builds up to a point where the site can’t handle more, new visitors get shunted over to the read-only cloud site, where they can at least find information and identify something that they want to buy. Under the Amazon agreement, cloud servers will scale up to handle as many as 3.5 to 5 million visitors per day, if the occasion ever arises that they need to. In a big traffic spike, a visitor might not be able to purchase an album immediately but will never go away miffed at not being served at all.

The new architecture reflects a changing world where online activities and social networking have taken on added importance. Sony management wants Taylor to be ready for the changes in customer behavior. In the past, there would have been less opportunity for the news of a pop star’s death to spread so fast or to result in such a spontaneous outpouring of grief and comment at a well-known music site. If the need arises again, Taylor is in a position to fire up 10 more servers in the cloud as soon as traffic starts to build.
Such elasticity is one of the things that distinguish cloud computing from large corporate data centers. Many data centers include a specially engineered elastic capacity reserved for a select few users, such as major customers who are trying to make purchases on a site that is already busy with browsing visitors. In some cases, more servers are engaged to handle the traffic. But it’s also possible for the information seekers to experience delays or even get booted off the site until the buyers have completed their transactions. In the cloud, however, there’s no need to turn away desired traffic. Additional “virtual machines” can be fired up quickly to handle all comers.



"The PC is a Truck" – Jobs; Forrester Predicts by 2015 1 in 4 Devices will be Tablets

by John Paczkowski, June 18, 2010, All Things Digital

Apple (AAPL) CEO Steve Jobs likes to compare the transition from desktop/laptop PCs to tablets with the transition from trucks to cars. Like trucks, which waned in popularity with the urbanization of America, so too will older PC form factors with the advent of more mobile and responsive forms of computing.

“When we were an agrarian nation, all cars were trucks, because that’s what you needed on the farm,” Jobs said at D8 last month. “But as vehicles started to be used in the urban centers, cars got more popular. Innovations like automatic transmission and power steering and things that you didn’t care about in a truck as much started to become paramount in cars….PCs are going to be like trucks. They’re still going to be around, they’re still going to have a lot of value, but they’re going to be used by one out of x people.”

Jobs stopped short of predicting just how quickly this transition will occur, but in a research report published today, Forrester (FORR) hazards a guess: By 2015, nearly one out of four computers sold in the U.S. will be a tablet. According to analyst Sarah Rotman Epps, tablets will outsell netbooks by 2012 and desktops by 2015.

“Catalyzed by the introduction of the Apple iPad, the tablet market will kick off with a modest 3.5 million units sold in the US in 2010 but will grow at a whopping 42 percent compound annual growth rate (CAGR) between now and 2015,” she writes. “Tablet growth will come at the expense of netbooks, which have a similar grab-and-go media consumption and Web browsing use case as tablets but don’t synchronize data across devices like the iPad does.”



Exoplanet Hunter Close to Finding Earth-like planets

Wired, June 15th, by Alexis Madrigal

The planet-hunting space telescope, Kepler, released its first big batch of data today.

That should be exciting, but the team held back the good stuff until February 2011, wanting to analyze and follow up on the early observations themselves. Kepler is trying to find Earth-like planets that exist at just the right distance from their home stars to retain water in liquid form.

Of the 156,000 target stars in the telescope’s field of vision, the 43 days of observations found 706 possible extrasolar planets from Earth size up to a bit bigger than Jupiter. Today, the NASA Ames Research Center crew, led by William Borucki, released data on the 306 targets they’re least excited about. Their top 400 candidates to investigate as possible Earth twins will not be announced for eight more months.

“Many of the candidates are likely to be false positives and the brighter stars, and those with the small-size candidates … are among the 400 withheld targets and are thus not among those considered here, biasing the results toward the dimmer stars and larger candidates,” Borucki wrote in an article posted to arXiv.org.

The data release plan was approved earlier this year by a special NASA advisory board, but has recently touched off controversy over its fairness and wisdom.



Don't worry, Tech Deals are Coming Back, 2010 Q1 up 55%

WSJ June 3, 2010

By Anupreeta Das

Bankers tend to be eternally hopeful. Chet Bozdog, the global head of technology investment banking at Bank of America Merrill Lynch, is among those optimists.

Bozdog expects deal-making to soon pick up in the U.S. tech sector, which has seen $33 billion worth of deals this year, according to Thomson Reuters data.

Despite the current M&A drought, it’s been a good five months for Bank of America Merrill Lynch’s tech team, which is ranked third in the tech league tables after Barclays Capital and Goldman Sachs, according to Thomson Reuters.

The low-profile group headed by Bozdog has been involved in both of the high-profile tech deals this year. They advised Hewlett-Packard on its $1.2 billion purchase of smart phone maker Palm, and sold database software company Sybase to Germany’s SAP for $5.8 billion.

Deal Journal caught up with Bozdog, a former mechanical engineer for GE, on what tech deal-making is going to look like in the coming months:

Deal Journal: What are some of the trends driving consolidation in the technology sector?

Bozdog: There are a few key trends. First, mobility is a key focus. More and more data will be consumed by mobile users, so it’s one of the largest areas of growth for technology. The second key driver is security. It’s becoming far, far more important across the board. As corporations look at outsourcing their data to the cloud, their biggest concern is the security of that data. Third, the data center. Data centers are a good area of growth and a key area of overall consolidation as tech companies look to make them more efficient and provide a more comprehensive set of products. HP-3Com and BMC Software-Blade Logic are a few transactions that took place specifically to gain technologies and products for the data center.  The overriding theme of all these trends is growth. Tech companies are looking for areas that will drive growth for their business


Ernst & Young

Global technology M&A update: 1Q10 highlights

Despite the reduction in large-dollar deals, the number of deals in 1Q10 grew to 628 (up 55% YOY and 14% sequentially) showing certain dynamics continue unabated — the blurring of sector, industry and work-life boundaries; the migration of other industries to “smart” products and services; and the mobilization of information and media.

More specifically, we saw deal growth being driven by development of a mobile “ecosystem” and by cloud computing (including SaaS), health care IT, clean energy and smart-grid initiatives — as well as by recession-weakened companies in need of partners to preserve their businesses and visions.



Our love/hate relationship with all the technology we "love"

Ever since graduating from Lego’s as an 4th grader, I have been consumed with gadgets and how they work.  My first wave of electric and electronic gadgets included the electric train, digital watch, and yes even a Merlin, the Electronic Wizard!  The Merlin was the iTouch of the day.


Apple iTouch

It had an 11 button pad that lit up and beeped to the games it supported.
(Of course you had to read the manual to learn how the games worked.)  One of the first mass-market toys based on a true microprocessor, it was supposed to improve memory and be FUN at the same time.

Parker Brothers’ Merlin is notable as one of the earliest and most popular handheld games, selling over 5 million units during its initial run, and remained popular throughout the 1980s.

The games were quite dull by today’s standards, but the Merlin blew the doors off anything else that Christmas.  My favorite toy that year played 6 games including tic-tac-toe, mindbender, music machine, and Blackjack.  Okay tic-tac-toe?. eh… not so great.  But Merlin had fabulous battery life, didn’t crash (unlike my train set), and would STILL worked if you dropped it, (unlike my Palm Pre).

Although my best gaming days are behind me, shiny new objects DO STILL esmerize this magpie.  I just bought a USB Traktor DJ controller the size of a jumbo universal remote that fits in my briefcase and replaces about 30 lbs of audio gear.  Very slick!

Traktor Kontrol X1

But WHY in an age where we are smarter and costs to build tech platforms is steadily dropping must we be FORCED to sustain a love/hate relationship with all  the technology we truly LOVE?   Hardware and software battle over ever scarcer resources.  Music is more portable now but sound quality suffers.

And rampant “built in obsolescence” means my cell phone wont even last as long as my carrier contract.  I distinctly remember reading about cell phones that would be upgradeable via software, and over the air.  So much for that “breakthrough advance”.

So here is my list of Best / Worst products and why.  Please add to the list and comment below as you see fit.

  1. Palm Pre – It’s simply a gorgeous phone.  Maybe the best phone on the market.  But the phone often slows down for no reason, the battery barely makes through a single day, and it has no protection on the edge of the touch screen.  This means if it’s in your pocket when you disrobe onto a tile floor like I did, get ready to pay $100 for an INSURANCE replacement when the screen cracks.
  2. Google Chrome – it is hands down THE fastest browser I have ever used, either PC or Mac.  It is simple and smart.  My daughter said the other day “It just knows.”  Downside:  Random websites will not function properly such as Rhapsody, Netflix, Webex, etc.  Still Chrome market share is rising (now 7%) while others are declining, so I believe this will create full compatibility over time.
  3. My Cable Company (Comcast).  All home based digital services are provided with no big complaints, if a tad pricey at $170 a month for triple play with HBO.  However, their on-demand charges are NUTS.. and have doubled in the last 18 months from $2.99 and $3.99 to $6.99 and even $8.99 for a 48 hour rental!  Considering the low cost of distribution this is soaking their customers.  I have switched instead to renting only from Itunes/AppleTV and boycott Comcast on-line.
  4. iPhone:  the coolest phone (for now) that I have seen.  I mean the interface is truly beautiful and unrivaled.  But AT&T phone service make it entirely unusable as a phone in many parts of the country, especially Manhattan where my business takes me quite often.  For the number of times my friends curse their iPhone, I will sit this one out.  Lack of support for even limited Flash combined with a strategy to avoid this pervasive UI platform is the nail in the coffin for me I am afraid.
  5. iPad.  It’s price point and service plan ($15/month for internet!? awesome) are the perfect combo, letting it compete squarely (or beat) with netbooks and readers.  But it has no USB port, until you buy the accessory, no ability to print, and most of all, no file system to store spreadsheets, documents, or presentations (and no real apps for those productivity tools either).

Falling in love with your favorite platform, device, or service will be a risky choice it seems for years to come.  In the mean time, stay happy.  We have come a long way in our journey as a tech enabled society.  We can pay bills in seconds with free online service from our banks.  And though we may hate ATM fees, we love getting our money whenever we need it.

Merlin and his kind paved the way for countless tech aids and entertainment machines.  Just think what devices we will have in 20 years time.  I wonder if they will be able to play tic-tac-toe.

© 2011 Logical Design Database Solutions All Rights Reserved