Posts Tagged ‘PaaS

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

19
Feb
09

Lincoln Murphy: Platforms and Bet-Your-Business Decisions

Lincoln Murphy: Platforms and Bet-Your-Business Decisions

I’m sure there will be hundreds of posts regarding the demise of Coghead, but I felt compelled to share this one from Lincoln Murphy of Sixteen Ventures because it focuses on the bigger picture of placing bets on companies and platforms that could ultimately sink you if you bet wrong.  For many of the reasons Lincoln touches on, Delivered Innovation made the shift from Coghead to Force.com by salesforce.com late last year, and we have been thrilled with the both the platform and the great team behind it.

18
Feb
09

Coghead shuts its doors

As a charter Coghead solution provider, it was a shock when we heard about the company’s failure to secure late round funding in November.  While we have known this day was coming for a while, there was still some sadness when we received the email with the subject “Coghead service termination notification” this evening.  Coghead was a visionary technology with a great team behind it, and we enjoyed working with everyone.  Hopefully folks land on their feet and we can work together again soon.

R.I.P. Coghead:

Dear Valued Coghead Customer:

On behalf of the entire Coghead team, I would like to thank you for your
past business. We have taken pride in offering you our state-of-the-art
Platform-as-a-Service to support your development of software applications.
Regretfully, due to the impact of economic challenges, Coghead has
discontinued its operations.

Effective immediately, the Coghead service and the license agreement to
which customers agreed when they registered for the service are terminated.
However, existing customers will be able to access and use their
applications and data through my.coghead.com *until April 30, 2009 on an
unsupported, “as is” basis without any representations or warranties
(express or implied) or indemnity from Coghead or any other party. To use
the service during this period, customers must go to
http://my.coghead.com/api/util/serviceterms.jsp and accept the specified
terms of use listed. Effective immediately, all access and use of the
applications and data available through my.coghead.com shall be pursuant to
the terms listed at http://www.coghead.com/serviceterms.html.*

Customers should download their data that is available through
my.coghead.com before 3:00 p.m. Pacific time on April 30th. However,
Customers should not attempt to copy, modify, reproduce or reverse engineer
any portion of the software that is part of, or used in the delivery of, the
service. Customers will not be charged for their use of the service through
April 30th. In light of the foregoing, we strongly recommend that customers
limit their work on existing projects and refrain from initiating new
projects and application rollouts.

*Basic support inquiries can be submitted to support@coghead.com until 3:00
p.m. Pacific time on April 30, 2009.*

Thank you again for your past business and support.

Coghead

Coghead customers interested in migrating their Coghead apps to the Force.com platform can take advantage of emergency migration services by Delivered Innovation.