Archive for the 'Platform as a Service' Category

31
Dec
09

2009: The Year Cloud Computing Reached The Tipping Point

By most accounts, 2009 was a bad year.  For some, an awful year.  But for cloud computing, 2009 will be looked back on as the year the movement reached the tipping point.  I don’t necessarily want to run through a year-end wrap-up, but I do want to take some lessons learned from 2009 and apply them to what I believe we’ll see in the year ahead.

The Question Without an Answer

What exactly is “Cloud Computing?”  The term will probably never be fully fleshed out in terms of a common definition, and at the end of the day that’s fine with me. Yes, we need to put structure around the term and the industry, but as we noted earlier in the year with a post about cloud maturity models, we run the risk of painting ourselves into a corner if we try too hard to make things fit neatly into buckets that we can easily classify and categorize. Taxonomy will be key to understanding and adopting cloud computing, but I’ve become convinced that in order to truly embrace the cloud, we must…

Embrace the Abstract

I had the opportunity to speak at Interop Las Vegas this year with Rick Nucci of Boomi and R. “Ray” Wang of Forrester Research, and when I made the statement that “cloud computing is the technical manifestation of Service Oriented Architecture,” I realized that I had found the unifying principle of cloud-based solution design; unifying both in the sense that the promise of SOA finally has the technology behind it to transform it from philosophy to practical design pattern, as well as in the sense that the term “cloud computing” itself was being co-opted in much the same way that traditional software vendors co-opted the entire concept of Service Oriented Architecture to sell middleware throughout the decade.

Cloud computing may mean many things to many people, but in the end its full potential can only be realized if we stop trying to think of it in terms of the “known known” and embrace the the “known unknown.”  More importantly, when we think about the cloud and applying SOA design principles, we cannot continuously innovate and drive value if we are traversing connections inward to rationalize patterns and explain the abstract with the known; we must restructure our patterns and embrace the abstract in an attempt to forge new connections by moving outward beyond our comfort zones. The next generation of system design is less about creating code, and more about assembling services – innovation through extending value in what already exists rather than inventing new sources of value.  In terms of practical application, this means moving up the stack and…

Learning to Describe Rather Than Prescribe

An interesting pattern that I observed throughout 2009 is the continuing tendency to try and reinvent the wheel despite the fact that not only has the wheel already been invented, but it’s right in front of our eyes and meets our needs 99 times out of 100.  I saw this over and over with Salesforce CRM and Force.com projects; the value of using Platform-as-a-Service is that someone else (or more accurately, thousands of other people) has already thought about just about everything you could possibly need in a data model, user interface, and business rules.  And not only have they published just about everything you could possibly want in an easily configurable platform, they host it and manage all of the operational details such as backups, upgrades, and security. Yet time and again I encountered teams that thought that their way of doing things was better, and would go down the path of trying to build Salesforce on Salesforce before realizing that the same outcomes could have been achieved by spending a little more time upfront optimizing business processes and making minor configuration changes than going down the path of creating complex custom workflows, classes, and user interfaces to achieve the same end.

Some case studies are extreme, such as the support manager that duplicated Contacts across multiple accounts and assigned multiple portal logins to customers – in one extreme case 101 times – rather than setting up sharing rules properly; I don’t have to tell you what a data quality nightmare that ended up being.  In other cases, it’s simply a matter of building rather than reusing what’s already there, resulting in hard-coding of attributes and logic that should be dynamic and extensible.

What I’ve come to realize is that there is a conceptual barrier that we need to overcome when it comes to metadata and other abstracted entities; because multitenancy architecture and SOA are reaching such a pervasive state, we must shift our thinking to describe what already exists rather than trying to recreate it.  Entities exist once and in perpetuity – for example, there is only one of you in the entire world and you cannot be recreated on demand – thus our ability to provide context necessarily requires us to describe the entity in a manner that provides value to the application; the ability to describe entities with deep domain knowledge and create relationships to other entities that enrich the value of the data set will become an important competitive differentiator.

This will take time and a great deal of trial-and-error until we get it right, but in the end it is the only way to leverage the tremendous potential of core cloud computing architecture patterns; our entire concept of producing and consuming services has to change, which leads me to the conclusion that…

SaaS is Dead…Long Live SaaS

Granted, the title of this blog predicates from the acronym for Software-as-a-Service, but as cloud services mature and the traditional technology stack gets blown up and reassembled, the entire concept of “software” shifts from the self-contained, monolithic packaged application to that of a delivery framework. Software was invented to make hardware useful; hardware is abstracted in the cloud and we no longer write code down to the kernel level – we assemble, configure, and code to the layer of abstraction of the specific cloud platform.  The term “software” will gradually fade from our lexicon.

This was the philosophy that drove the Java language and multi-platform virtual machine concept, and will continue to evolve with next generation rich Internet application frameworks such as Adobe Flex / AIR.  What we will see moving forward is the continuing shift from desktop software that interacts with the cloud, to ubiquitous frameworks that consume data and logic services from the cloud and leverage the processing capacity of the local machine to enhance the user experience.

2009 and its economic and sociopolitical malaise are now behind us, and by all accounts 2010 will be the year of the cloud. While the technology and the terminology of the cloud have permeated the mainstream, it will take significant shifts in thought processes and design patterns before the cloud can be fully leveraged.  Here’s to a great New Year and the hopes that the likes of Microsoft and other relics will accelerate their fade into obscurity and stop trying to steer the cloud discussion back into a box.  Until next time, here are some…

Other 2009 Wrap-ups and 2010 Predictions

Jeff Kaplan: Key Challenges Facing Cloud Computing in 2010 and Beyond
Phil Wainewright: Tips from 2009 for a prosperous 2010
Dave Barry’s year in review: 2009 (Humorous, non-cloud related)

30
Aug
09

Force.com and its Implications for Technology Service Delivery Models

How Force.com enables an analyst-driven approach to development projects

Michael W. Topalovich, CTO
Delivered Innovation

For years, the rallying cry for the CIO has been to align IT with “The Business.”  This presupposes that there is a wall between IT and other functions and processes within an organization, which of course we know to be the case. While nearly every business function that lives in its own silo has challenges integrating with other functions within the organization, IT has been particularly challenged because of the technology-centric reality of its world; while other functions may not necessarily have a direct impact on the value chain, IT is often viewed as being completely disconnected from it in many organizations.

Technology vendors have long targeted the CIO with messaging that implies an understanding of ITs alignment pain, and they have offered myriad remedies for closing the gap between IT and the underlying business processes that create value in an organization. Everything from enterprise applications to network management tools have promised to lead beleagured CIOs to the Shangri-La of “IT-Business-Alignment.”  Ironically, the technology with the most promise for bridging the IT-business divide has been right here under our noses, but only a relative handful of visionary organizations have embraced it to drive business value.

Continue reading ‘Force.com and its Implications for Technology Service Delivery Models’

07
Aug
09

How Force.com Changes System & Software Testing Processes

It’s evident by this point that cloud computing technologies such as Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) have changed the way applications are developed.  The interesting thing that we are finding with our customer engagements is that the rapid and iterative nature of designing and developing apps on Force.com has created an entirely new set of challenges with how the apps are tested prior to deployment to production environments.  The ability to demonstrate application features and functionality to project stakeholders in near-real time is more of a double-edged sword than most people realize; on the one hand, being able to show progress and continuously incorporate feedback has fundamentally changed the concept of application development and delivery.  On the other hand, if expectations are not managed properly, the ability to visually represent system designs and demonstrate prototypes in such a rapid timeframe could potentially trivialize the importance of testing, code refactoring and optimization, and change management.

Continue reading ‘How Force.com Changes System & Software Testing Processes’

20
May
09

Excerpts from discussion with Jon Sapir on the impact Force.com has on IT service delivery

I tend to have very spirited philosophical discussions with Jon Sapir from Power in the Cloud / SilverTree Systems, and as much as he tries to get me to blog about some of this stuff, I tend to put it off indefinitely.  Just came across this thread and thought there were some important thoughts to build off of:

The old / traditional approach had a lot more players involved…I always envision enterprise IT as two funnels connected at the most narrow point, with one funnel being IT and the other being “the business.”  On the IT side, the fat part of the funnel is web programmers, platform programmers, DBA’s, etc.; the connection to the business side is the program manager, who takes specs from the business program manager and hands it off to a lead architect, who then disseminates pieces to platform / application / database architects, who then give specs to the relevant coders, who are then checked by a parallel QA organization that is segmented similarly by function.  On the business side, the program manager is connected with a business process architect who assembles requirements from lead business analysts representing the business functions involved with the system, who then fan out to all of the end users of the specific functions / departments to gather feature / function / interface requirements / feedback.  And scattered throughout is about a dozen project managers, each running their own project schedule for their piece of the world.

Force.com disconnects the business users from the stack, eliminating the direct involvement of IT and changing IT’s role to one of data / process governance + management.  In some organizations IT may still provide the programmer, but in many cases the business architect will directly design the system, and the analysts will configure the system to the specific needs of their constituents.

The future piece further abstracts the business from IT, pushing governance to the periphery of the business where it is managed by analysts and designed by the business architect to overlay horizontal, end-to-end processes rather than a vertical / function-driven organizational structure.  IT may provide technical services, but the internal IT organization, for all intents and purposes, is just one of many service providers that the business provisions IT services from.  In the most likely scenario, IT manages the connectivity to the cloud, data/information security policies and overall governance, and potentially manages the service delivery / financial relationships with cloud providers.

Does this sound like a reasonable description of most enterprise service delivery processes?  Is management and governance the role that IT will take on?  Will IT simply become a service provisioned directly by business process owners?  Does SaaS / PaaS / cloud computing really make such a significant impact on organizational and business process structure?  For every answer we come up with, there are about five new questions.

18
May
09

Interop Panel Discussion Preview: Honeymoon and Divorce: Changing SaaS Providers

Interop is here, and based on the preparatory discussions that I’ve had with fellow panelists on the ‘Honeymoon and Divorce: Changing SaaS Providers‘ session, I am excited about the topics we will be covering and the insight that Jerry Smith (Symphony Services), Rick Nucci (Boomi), and R “Ray” Wang (Forrester) will be bringing to the table.  I will be approaching the topic of migrating both data and SaaS code / logic from PaaS providers with a service-oriented mindset, giving real world examples of migrating applications from the now-defunct Coghead platform to the Force.com platform by salesforce.com.  Delivered Innovation migrated both customer apps and our own strategic marketing suite of applications to Force.com over a period of several months with great success.  I am confident that the panel will provide a great deal of value to attendees, as the topic of SaaS / PaaS “lock-in” is becoming more relevant with the proliferation of cloud computing services.

Please stop by if you are attending Interop.  We’re scheduled to present at 4:00PM on Tuesday, May 19 in “Breakers L” at the Mandalay Bay conference center.  I will also be attending CloudCamp this evening, let’s talk about ‘The Cloud’ over beers.

Michael Topalovich / blog @ deliveredinnovation.com

16
Mar
09

Jonathan Sapir: Situational Application Platforms Threaten Smug Programmers

Jonathan Sapir: Situational Application Platforms Threaten Smug Programmers

Jonathan takes a somewhat provocative approach to pointing out that cloud computing and situational applications are rendering “traditional” programmers obsolete at an increasing rate.  Derrick Harris at GigaOm lays out a similar scenario for those on the IT infrastructure side of the house as cloud computing pervades mainstream Corporate America.  Both of these posts remind me of something that I had written early last year, “Platform as a Service and the Implications for IT,”  just prior to transforming our business to focus on SaaS design and strategy.

There are compelling arguments on both sides that innovative technologies either create jobs or eliminate them, but I don’t think the discussion is that cut and dried.  What’s inevitable is that cloud computing will certainly change jobs, and I think the bigger point here is that if you are an IT professional, if you have not learned by now that you have to continuously stay on top of new technology and business innovations to maintain your place in the pecking order, you will inevitably be left behind.  Sure you can sit back and hope that Black Swan events such as Y2K will come out of nowhere and suddenly make your 20-year-old programming skills a hot commodity, but the more prudent approach is to evolve with the times and stay relevant.  Cloud computing is here, so those hoping it would just go away are in for a rude awakening.

28
Feb
09

Don Sears: SaaS Startup Failure Leads to Blog Banter

Don Sears: SaaS Startup Failure Leads to Blog Banter

Don provides insightful analysis into the Coghead post mortem that I wrote last week.  He touches on the issues that I had to think about prior to writing that piece, which has generated an astounding amount of traffic.  His point about the decision to put all of Delivered Innovation’s eggs in the Coghead basket is a good one, and thankfully we didn’t wait too long to mitigate that risk by forging a relationship with salesforce.com.  Takeaway – social media creates some interesting lines that you have to think about before you cross them, although hopefully Don realizes that this wasn’t a customer we were talking about here and the nearly 50 other posts on this blog are related to SaaS / PaaS advocacy and trying to forge the right path moving forward for our customers and peers, so the analogy he presents was somewhat fallacious.  Beyond that, I appreciate the feedback.

Michael Topalovich

28
Feb
09

Coghead Roundup: A Collection of Analysis

The death of Coghead triggered a flood of analysis – just about everyone had an opinion on the event, myself included.  After the initial wave of shock and disbelief, a steady stream of insightful post-mortem analysis began to make its way to my NewsGator account.  Now that we have had almost ten days to come to terms with both the events that led to Coghead’s demise as well as the implications on SaaS and PaaS moving forward, I wanted to take this opportunity to present posts that highlight some of the key issues that emerged from the Coghead discussion: Lack of PaaS standards and interoperability (exacerbated by the uncertainty of long-term vendor stability), and PaaS evaluation and selection criteria confusion (including the immaturity of monetization strategies & pricing models).

PaaS Standards and Interoperability Analysis

PaaS Evaluation and Selection Criteria Analysis

Michael Topalovich
Founder and CTO
Delivered Innovation

21
Feb
09

Clarification from Coghead CEO Paul McNamara: Update to Post Mortem

I appreciate Paul McNamara, CEO of Coghead, reaching out to provide clarification regarding the events that ultimately led to Coghead seeking a buyer for its intellectual property assets.

In the Coghead Post Mortem entry, I wrote that while addressing a group of Coghead partners Paul stated that the company had commitments from existing investors to at least get through 2009.  This was a true statement at the time.  In early December, Coghead investor American Capital shut down their venture arm, which was a critical blow to Coghead.  When I questioned Paul about this because of the short period of time between his statements to partners and the announcement by American Capital, he told me that he had no foreknowledge of the closure when he made the statements about Coghead’s funding situation.

To be fair, the partner meeting was held several weeks prior to the rapid deterioration of the capital markets, and while the communication from Coghead regarding their situation was poor, it would be irresponsible for me to imply that they could have foreseen the rapid fallout in the venture and equity environments and predicted such a Black Swan event.  I will amend the Post Mortem analysis to reflect this, and once again I thank Paul for taking the time to reach out and provide clarification.

Michael Topalovich
Founder and CTO
Delivered Innovation

20
Feb
09

Coghead Post Mortem: A Partner’s Perspective

The death of Coghead generated a lot more news than I had expected; perhaps the relative silence in the press about the company cutting most of its staff nearly three months ago after failing to secure late round funding implied that few people really cared about the outcome of Coghead.  But the media attention since Coghead announced that it was fading away, from the Wall Street Journal to TechCrunch, has been significant…so obviously people did care.

The great irony for me in writing this post is that I had actually sat down to write it yesterday.  As a charter partner and ardent evangelist of the Coghead platform, I was tired of sitting back and waiting for the other shoe to fall after  having not received any “official” communication from the company since December 21.  A few partners had read between the lines and moved their apps to new platforms, but I kept receiving phone calls and emails week after week asking the same question: “Do you know anything?”  The fact is that I did know something…I knew a lot of things, in fact.  But I kept them to myself because I had a good relationship with the Coghead folks and was quietly rooting for them to pull out of the nosedive and find a miracle outcome.  Yesterday at 6:30PM, I decided that the miracle wasn’t coming, and that I was going to start strongly recommending that folks start thinking about porting their apps.  The silence from Coghead was deafening, and they were stringing too many people along.

It turns out my gut feeling was fairly prescient: a quick scan of my Inbox uncovered a message – sent just 7 minutes earlier at 6:23PM – with the ominous title, “Coghead service termination notification.”

I first came across Coghead in mid-2007.  After having connected with a former Siebel Systems colleague over beers one night, we came away with the idea of turning a piece of intellectual property (what eventually became the Marketing Lucidity Lead Model) into a SaaS application.  I thought it was a fun and challenging project, and because I can’t say no to fun and challenging projects I started working on The Lead Model.  It’s important to note here that the extent of my programming experience was writing BASIC math games for the Commodore 64 for my second grade class, and a couple of programming logic and Java classes in college.  I was not a coder.  Yet I took it upon myself to write The Lead Model in Java and attempt to publish it on a Tomcat server that I threw together over a weekend.  It was OK, but it would never work commercially.  So I started down the path of exploring this relatively new concept that salesforce.com was calling Platform-as-a-Service, or “PaaS.”  The Lead Model got half built in Zoho Creator before I realized that it just wasn’t going to handle the complex logic requirements; I started tinkering with DabbleDB before I realized that the nearly 400 mathematical functions would have to be built in the most unorthodox fashion; Force.com was just emerging and didn’t support the dynamic references in the data model at that time.  So The Lead Model just wasn’t happening…until we happened to stumble across a blog posting extolling the virtues of Coghead.

Coghead was love at first sight.  It did everything I needed it to and more…and it was easy.

Thus began what would be an intense, albeit extremely short lived, relationship with Coghead.  After six months of using the platform, I decided to become a Coghead partner and completely abandon the next-generation IT service delivery consulting practice that I had started in 2006.  The Mikan Group became Delivered Innovation, and we were all about Coghead…all Coghead, all the time.  We released Marketing Lucidity Lead Model in late April of 2008 in conjuntion with the Web 2.0 Expo in San Francisco, and had a full head of steam built up.  But the honeymoon didn’t last long, and by July we were noticing fatal flaws with Coghead the platform and Coghead the company.  Just as the country is quickly realizing that putting the collective hope of the nation on the shoulders of an unproven politician isn’t such a great idea, I quickly realized that putting all of my eggs in one basket – while never a great idea in any circumstance – was a shortsighted strategy.

I loved Coghead.  I believed in the technology and the team behind it.  I was Coghead’s biggest cheerleader outside of those collecting Coghead paychecks.  You couldn’t talk to me for a period of nearly 6 months without hearing at least something about Coghead.  Coghead, Coghead, Coghead.  I built a company around Coghead, investing nearly 4,500 hours of my time and personally going 6-figures into debt bootstrapping the operation.  I hired a small army of interns with a seed investment, and I set out to conquer the world with Coghead.  Unfortunately, by early summer it became painfully clear that things just weren’t going to work out.  By the end of summer it was clear that Coghead was entering a death spiral.  By Christmas it was circling the drain.  In hindsight it was an incredibly short period of time, but in my mind it felt like 10 years.

Delivered Innovation is still kicking, and today we are a salesforce.com partner, and we have ported our flagship application to the Force.com platform.  A second application, Marketing Budget Management, is nearing completion and will be submitted for certification on the AppExchange by the end of March.  But we’re in this position because we saw the writing on the wall with Coghead; many others didn’t, and in some cases I blame folks for holding out for an outcome that just wasn’t probable, and in other cases I blame Coghead for stringing partners along for the past few months.  In any case, there are extremely important and valuable lessons to be learned from the collapse of Coghead, and my intention is to capture these lessons thoroughly and objectively.  What follows is an analysis of events and observations related to the shutdown of the Coghead platform, from the perspective of a fiercely dedicated partner that obviously backed the wrong horse.

  1. It’s the economy, stupid. [This analysis has been amended to reflect the content of a conversation with Coghead CEO Paul McNamara on February 21]  When I first received the anonymous email announcing Coghead’s shutdown on April 30 blaming the economy for the shutdown, I cried foul because of statements that were made to a select group of Coghead partners at an October meeting at the company’s HQ in Redwood City.  CEO Paul McNamara had indicated that Coghead had commitments from investors to provide enough capital to last through 2009 at a minimum.  Not two months later we were hearing that the company was searching for a buyer.  The connection that I failed to make at the time of this post mortem was that American Capital, an existing Coghead investor, shuttered their venture wing in early December, which contributed to a series of events that left Coghead searching for other sources of capital or a possible sale of the company to a bigger fish that could ride out the Nuclear Winter.  Paul would not have had foreknowledge of this event at the time he addressed us at the Coghead partner meeting.
  2. A blurred line between development tool and platform. The Coghead development interface was a sight to behold.  It was beautiful.  You could visually develop applications by dragging form input “widgets” onto a canvas; the widgets in turn propagated the data model, and the visual representation of the form that you saw as a developer was the same interface that was presented to the application user.  Application logic was designed in the same drag and drop manner; common branching and looping operations were represented visually by widgets, and conditions were entered directly into a graphical overlay using dropdown menus and buttons.  The platform that delivered these rapidly developed applications was anything but beautiful; in early July, Coghead experienced a number of lengthy outages that nearly led Delivered Innovation to abandon the platform completely.  The outages followed a major platform upgrade, and it had become apparent that Coghead was sacrificing platform stability for features and functions.  After enough partners complained, that practice was changed and there was more focus made on stabilizing the platform and slowing down the pace of upgrades.  Platform performance was always an issue for me as well, and one of the most frustrating aspects of the Coghead infrastructure was that performance varied from node to node; I could literally execute the same process simultaneously from two separate accounts in two different browsers, and one process would complete in less than five seconds while the other would time out after two minutes.  The lesson learned is that if you offer best in class development tools, make that your focus; if you also want to be in the PaaS business, make sure the platform is on par with the development tools…if it’s not, get out of that business and leave it to someone more capable.
  3. He said, she said. Coghead’s messaging was schizophrenic.  To their credit, they finally realized this, but long after we had lost many deals as partners because our customers had completely unrealistic expectations of what was involved in developing Coghead applications.  If you believed what Coghead told you on their website, the development tools were so intuitive that you could just dive right in and build apps in a matter of hours; while this may have been the case for a single-form data entry tool, we were getting requests for proposals for highly complex “run the business” apps that admittedly could be turned around much faster than if we were building the underlying infrastructure from the ground up instead of a leveraging a rapid application development tool, but by no means were these trivial projects.  I have been responsible for the delivery of literally hundreds of  IT projects throughout the course of my career, and I know what’s involved in turning around IT services.  I encountered customers with such completely unrealistic expectations of the costs involved in application development that in one extreme case I quoted a dollar amount that was below cost just to get the business, and the customer was “shocked” by the cost…when I pressed, he was expecting something “in the $500 – $600 range.”  This was an application with 10-12 forms, each one with a series of business rules that were triggered based on a number of conditions specified at the field level.  $500 – $600 for a custom app to run an entire business is not realistic, but somehow this was the impression that the customer was given based on Coghead’s “it’s so easy” messaging.  I finally called the customer to get to the bottom of his expectations, and I was told that he had seen a slide in a Coghead webinar that stated that a partner had built an app for $100 on Coghead after having spent tens of thousands of dollars developing it on .NET.  I was floored.  I remember the exact slide, and I know the partner that was profiled fairly well; what Coghead failed to mention is that the gentleman that built this app is exceptionally intelligent and driven, and spent nearly a month of his own time dedicated to building the app.  To somehow imply that the app only cost $100 ignores the opportunity cost of the developer’s time; if his time was only worth about $0.50 an hour, then that figure might have been accurate.  But his time was worth far more than $0.50 an hour, and that slide ended up costing me countless hours of my own time producing proposals for customers that had similarly skewed expectations based on how easy they though Coghead made the development process based on what they read on the website.
  4. Who is our customer? Coghead’s inability to find a successful monetization strategy is not unique; what is perplexing is the way partners were brought in to help drive adoption and revenue, only to be left high and dry in the end.  Coghead marketed to individual developers and ‘Solution Providers’, but never really knew which one to focus on.  And even within the partner ecosystem, it was unclear what Coghead’s idea of an ideal partner looked like…was it a consultant that could bring 20-30 customers onto the platform to use an application specific to an area of domain expertise?  Sure!  Was it a SaaS provider selling application subscriptions to potentially large swaths of customers?  OK!  Was it a development shop building custom situational applications for customers that were savvy enough to specify use of the Coghead platform?  We’ll take them, too!  It’s one thing to be opportunistic, which is perfectly reasonable for an early-stage company.  It’s another thing to have no cohesive marketing strategy at all.  I won’t even go into the pricing issues.
  5. Whatever happened with the Coghead Gallery? This was supposed to be the greatest thing since sliced bread, and it went nowhere.  There was going to be this AppExchange-busting marketplace of partner-developed applications, and again the strategy was all over the place.  When the idea was first introduced, the Gallery was sold to partners as the centerpiece of the Coghead experience; within a couple of months the Gallery was being downplayed and the executive that was brought in to spearhead the effort mysteriously disappeared (which became a recurring theme that accelerated in frequency as time progressed).
  6. The case of the mysterious disappearing employees. Coghead had its share of communication issues, which could reasonably be blamed on being a young company.  But when key contacts that I spent many hours on the phone with just stopped returning emails and phone calls, or would be conspicuously missing from developer and partner meetings, red flags went up.  Obviously not every departure at a company warrants an email blast, but the way Coghead handled transitions was nothing less than suspicious.  People move on, it’s a fact of life; but when the event is concealed from those close to the company to the point of conspiracy, what are we supposed to think?  It’s not like I’m not going to notice when the person assigned to me as an executive sponsor disappears off the face of the planet, or the marketing person that coordinates an event that I fly 1,800 miles to attend isn’t even present at the event.
  7. Don’t volunteer your customers and partners to do your QA. To Coghead’s credit, they did eventually introduce the VIP environment so that partners could conduct application testing on a new platform version prior to production release, but it was long after I had given up on them.  I was finding so many bugs after platform releases that I finally asked bluntly, “Do you even test this stuff before you release it?”  I hate saying things like that because Coghead had so many great folks that I enjoyed working closely with, but after spending so much time getting issues fixed following system upgrades, I stopped giving the benefit of the doubt and started expressing my frustrations.  I will be the first one to admit that a percentage of issues with the platform were because of my own ignorance, but the pattern of instability far eclipsed the stupid user issues.
  8. Make Money With Coghead. There never really was much hope of achieving what the now-infamous webinars promised.  I’ll take as much blame for this as anyone, but I thought that my assumptions regarding the underlying business processes of the partner program would be reasonable enough to justify taking the risk in trying to make money with Coghead.  Provisioning new applications and accounts was a tedious manual process, and the “Hey, we’ll bill your customers for you, take our cut, and pass the rest on to you” promise was supplanted by a hastily thrown together Pay Pal solution that created significant costs for the partner and never actually worked.
  9. You hang me out to dry. It all ended like the title of a Cold War Kids song…partners were strung along for months after Coghead failed to secure financing a few weeks before Christmas.  On December 6 we received an upbeat and slightly detailed message from founder Greg Olsen regarding Coghead’s status.  CEO Paul McNamara had been rumored to have been let go during the mass layoffs that followed the failure to secure funding, and hearing from Greg directly all but confirmed that (until the conspicuously absent Mr. McNamara resurfaces earlier today in the From line of a follow-on message about the Coghead shutdown sporting the title of “Chairman” – that apparently was enough to fool TechCrunch into thinking he was still actively involved with the company despite what I was told by a number of ex-employees).  This is followed by a December 21 email that contains the highly cryptic message from Greg that stated, “I wanted to give you a quick update on our progress.  I am unable to yet discuss details, but we’ve made substantial progress  toward a positive resolution of our recent financing challenges.  I anticipate that we will be able to announce something next month.”  That was the last email blast from Coghead until the shutdown notice that went out Wednesday – nearly two months later.  Many of us knew about SAP’s involvement, and the thought (hope) was that SAP would keep Coghead alive, but alas they decided that it would be better to just dump the hundreds of developers and partners using the system rather than keep it alive.  So is life.  The least Coghead could have done was be more upfront about their struggles; I had seen the writing on the wall long before the funding catastrophe and had shifted the direction of Delivered Innovation to focus on SaaS applications developed and delivered on the Force.com platform, but as I’ve seen over the past 24 hours, there are a lot of people that were caught completely offguard by this, and that is unacceptable.

It is sad to see Coghead go.  It was such an innovative concept.  In the end, execution could not keep up with vision, and financial challenges cut Coghead’s promising life short long before it had a chance to be the game changer it was destined to be.  There were many talented people at Coghead, and we hope they land somewhere that can put their talent to use.  I hope that this assessment of key issues that I observed with Coghead will prove to be of value to others in our industry as we lead SaaS, PaaS, and other important cloud computing technologies towards maturity and widespread adoption.  It is too important for this movement to fail, and to succeed will require near-flawless execution moving forward.

Michael Topalovich
Founder and CTO
Delivered Innovation