The costs of fat-client PCs on all enterprise desktops continue to rise. A report by the Organization for Economic Cooperation and Development, declassified in March and released this week as a background document for a ministerial meeting in Seoul on June 17, estimates that fully a quarter of the PCs in the United States alone are currently carrying some kind of malware infection -- with attendant consequences that range from lost productivity to lost reputations.

This is not speculation or fear-mongering: there are actual incidents, the subjects of reliable reports and sometimes criminal indictments, across the spectrum of malware effects. One result is that growing paranoia surrounds anything other than a plain-vanilla, out-of-the-box software configuration on even something as locked-down as an iPhone -- let alone something as open-ended and generally capable as a PC.

Defensive tools like anti-virus software don't solve the entire problem: a plaintive analysis from India observes that "Often virus being caught means the source 'exe' is removed/quarantined but what about the associated damage that the virus leaves behind such as numerous registry entries, startup entries, the additional dll's/inf files which don't just sit there twiddling their thumbs but quickly become a pain in the wrong place..." When fat-client PCs get corrective surgery, the convalescence may be more painful and take even longer than the cure.

Restoring the full configuration of a typical PC, with all of its installed applications and their preference settings and their patches as well as all of the user's resident data, is a process that can take hours -- unless an organization invests in considerable, entirely unproductive infrastructure and staff to maintain machine-state imaging and restoration services. That support must be available to both on-site and remote personnel 24x7, or it won't be there at the time that the need is most critical. That's not a scalable solution.

What does make sense is to put more functions in the cloud, where multi-tenant systems spread the costs of configuration -- and where business process governance can be held to the highest professional standards at affordable cost.

As much as I appreciate the elegance of PaaS, the crucial question for entrepreneurial developers is whether something like Force.com actually represents a compelling opportunity to

• deliver capability to customers
• at an attractive price
• with a satisfactory return to the developer

Now that the blogstorm from Dreamforce Europe has somewhat calmed, I'd therefore like to shine the spotlight on perhaps the single most important commentary coming out of that event: Phil Wainewright's May 13 blog post, "CODA2Go and the economics of PaaS", in which he narrates a conversation with CEO Jeremy Roche of UK-based CODA plc -- whose CODA 2go, built entirely on Force.com, provides broad-spectrum financials in a package that Roche expects to "do for finance what salesforce.com has done for CRM."

Wainewright's conversation with Roche established two key points:

• CODA saved a huge amount of time and development effort by using someone else's infrastructure and API foundation to deliver its on-demand product
• CODA's recurring costs were comparable to what it would have cost to deliver the same things with CODA-owned infrastructure, but the Force.com approach combined far lower up-front investment with much more rapid time to market

When these key issues are demonstrably addressed, and when the package of Development as a Service is giving developers a complete solution to their needs for capability and productivity, it seems as if it's clearly time for PaaS to be the model of first resort for new projects.

The language we speak shapes the way we think, according to anthropologists Edward Sapir and Benjamin Whorf. It's certainly been my experience that learning new programming languages gives me new ways to think about a problem, and not merely new notations for expressing the same old solutions -- and this is more than just mental recreation, but really a growing imperative for dealing with new development challenges, in the view of Ted Neward as expressed at TheServerSide Java Symposium in Las Vegas this week.

As reported by eWEEK's Darryl Taft, "challenges that Neward said stretch the capacity of current programming languages and tools include application security, object security, pure object model drawbacks, distribution and services, user enablement and user interface expression." You'll pardon me if I note that writing applications with high security, readiness for service incorporation and delivery, and readily enabling users and expressing user interfaces is absolutely the stock in trade of Apex Code and Force.com.

When I hear the question, as I often do, "Why should I learn a new language to use the Force.com platform?", it's always been my inclination to answer, "New languages solve new problems." Ted Neward, moreover, said in Las Vegas this week that "there are a number of challenges coming up that we can't solve with our current set of languages and tools" -- so my question is, why not learn a language that does solve those problems, not in theory, but in practice with immediate deliverability at enterprise scale? That's what Apex Code represents to me.

Call it the displacement of Moore's-Law progress in raw hardware capability, and a shift to a Sapir-Whorf sensibility to the need for better ways to talk -- and therefore to think -- about the things we need to do.

If you are looking for ideas to combine the declarative, point and click tools along with the programmatic power of Apex code, take a look at this sample solution to implement dynamic approval routing including better delegated approver support.

The sample solution shows how custom objects, apex classes and triggers and approval processes come together to build a dynamic, data-driven approach to approval process automation. Use the apex code snippet listed in the sample solution  to handle scenarios where you want to send the request to a delegated approver when the main approver is on vacation.

The Apex code included in the App Exchange package serves as a good example to highlight some important best practices when writing apex code:

• Test Driven Development - Make tests an integral part of your application and strive for 100% code coverage.
• Code for bulk triggers - Effective usage of Set and Map data structures to code for bulk triggers and ensure that you are within the governor limits.

The concept of "hybrid vigor" deserves more respect than it's been getting of late from enterprise application vendors. The "h" word ought to be reserved for combinations that reinforce strengths, rather than those that compound weaknesses -- but some tech providers blithely assert that choice is an unmixed blessing, making a claim that often falls apart under careful scrutiny.

There are substantial costs to any effort to deliver application function in both on-premise and service-mode configurations. In the real world, all costs are ultimately borne by the customer, and the costs of so-called hybrid application product lines are no exception.

The baggage of a legacy code base that's optimized for on-premise delivery is no advantage -- quite the reverse -- to any effort to match the efficiency and the pace of innovation seen in Software as a Service. Hybrid offerings lead to product line fragmentation, enterprise portfolio incoherence, and old-fashioned market segmentation that serves vendors' interests rather than customers'.

I’ve written a white paper entitled “Hybrids and Hidden Costs” that details these dynamics; I've also restated the case in a 3-minute video. I welcome your comments on either of those offerings.

There has been a lot of buzz in the Force.com community about Visualforce ever since this new feature was introduced at Dreamforce in 2007.  Many developers were excited about the presentation capabilities of Visualforce Pages, which allowed them to leverage the powerful functionality built into standard Force.com applications in virtually any user interface scheme they could imagine.

But the technology behind Visualforce includes more than just a flexible way to present pages.  The ability to control the way that any page interacts with Force.com objects is, in my humble opinion, even more exciting than the interface flexibility presented by Pages.

A small proof of this flexibility is offered up in a series of articles describing how to implement dependent picklists in a more flexible manner.  What will look, to your end user, like a standard set of declarative dependent picklists is actually implemented with a handful of Visualforce code.  However, the values for those picklists, as well as the dependent relationship, come from two related objects, which means you can add values, and specify dependencies, without going into the Force.com Builder.  You can also store additional data attributes for each picklist value.

The first part of the article, located here, introduces the general problem to be solved.  This part will give you links to Part 2, which explores the code needed for the picklists themselves, and Part 3, which shows how to use these picklists with Visualforce Pages to control the display of information based on the picklists.

Check out these articles for some practical examples showing off the logical power of Visualforce!

Developers face huge numbers of contenders for a place among their technical tools. The investment of time, and the bet that a developer places on the success of a platform by building code that depends on that platform, make developers' choices among the most significant leading indicators of future platform mind share.

That's why I encourage you to review the slate of finalists for Product of the Year at Developer.com: a list that includes, not incidentally, the Force.com platform in the category of Web Service Development Tool or Add-in. Voting closes at the end of this week, on December 21: we'd be honored (in every sense of that term) to have your support.

If you are here, you have hopefully heard about the Force.com platform, the world’s leading on-demand development and deployment environment. The Force.com platform brings all the advantages of the on-demand environment to your own custom applications – no infrastructure costs or maintenance, rapid and universal deployment, and a rich development environment.

Two new white papers will help you to understand the Force.com platform and one of its newest, and coolest, aspects. The Force.com white paper introduces you to the basics of the platform, including its architecture and main components. The second white paper is focuses on one of those component, Visualforce, which dramatically enlarges the flexibility of the platform in terms of user interface and data access logic.

You can gain the power of the Force.com platform, and the place to start is with these two papers.

As the academic year got under way in September, I noted the growing momentum of on-demand alternatives to on-premise IT at major universities. A more recent story now looks at several questions about that trend that have clear parallels in the workplace:

• Does it make financial sense to keep spending resources on aging proprietary software when it’s available on the Web?
• Do colleges’ services still offer advantages over those reflexively preferred by students?
• In offloading a primary function of the campus information technology infrastructure, what role would remain for administrators who previously oversaw e-mail services?

No, it does not make sense to throw more money at old software now, when you can clearly see that the situation several years from now will be just like today's -- only more so. The relative costs of centralized computing (trending down) and always-on connectivity (ditto) aren't a swinging pendulum: they're a tectonic shift.

No, in-house services designed and developed over the last few decades almost certainly do not offer key advantages over the services that students already know how to use when they arrive, especially if we define advantages from the viewpoint of the user rather than the technologist. The same is true for new employees entering the enterprise: the company should gain maximum benefit from skills that a new hire already has.

Administrators who previously oversaw e-mail services should not be mourning the loss of an opportunity to polish utterly undifferentiated skills. As Sun Microsystems' Scott McNealy has famously said of commodity markets, "the only thing you can add to a banana is a bruise"; in one version of that remark, he then added, "the longer you have that banana in your possession, the more likely you are to bruise it, and certainly the more expensive that banana is going to become." Owning systems that don't do anything special is a more expensive way to do something no better than other options. Administrators should be adding real value to commodity platforms -- whether in the groves of academe, or on the battlefields of commerce.

I had a chance to visit with customers and prospective platform users in Melbourne and Sydney last month, and closed out a fully-packed agenda with a video interview done by the on-line developer community site Builder AU.

Our conversation lasted a good deal longer than the optimal length for a Web video clip, so they've broken my comments into two sections of five to seven minutes each: one discussing the big picture of Force.com, the other diving in more depth into the developer experience of using Apex Code. I wish I could drop by and do a brown-bag session along these lines at more of our customer sites, but perhaps you have some colleagues who might like to click and watch on their next caffeine/carbohydrate break. Enjoy.

I met last Thursday evening with the salesforce.com user group in Seattle, where I got to know several staff members from Tableau Software Inc.: a maker of visual data analysis and reporting tools that link with salesforce.com and other enterprise data repositories. The coincidence was notable, in that I'd just been speaking earlier that day with several local CIOs about the role of on-demand platforms in easing the adoption of business analytics.

I had noted at that earlier meeting the upcoming 20th anniversary of Peter Drucker's coinage, "The Knowledge-Based Organization": a phrase that he used in his 1989 book, The New Realities. We're already past the 20th anniversary, moreover, of Tom Peters's "Systems" prescriptions in his 1987 book, Thriving on Chaos: specifically, his admonition to "Decentralize information, authority, and strategic planning." So, given that these ideas are old enough to vote, why do they still seem so challenging to put into practice?

I see four key barriers to the idea of "analytics everywhere":

• Complex legacy IT portfolios make the mere integration of data an overwhelming task
• Cumbersome and brittle integrations relegate end users to the role of information consumer
• The path of least resistance leads to over-emphasis on complex measures based on historical data
• Superficial "webtop" thin-client redesign attacks the form, not the substance, of these problems

These issues, it seems to me, are directly addressed by the strengths of the on-demand model. Network-based architecture of on-demand solutions makes for affordable (and strategic) integration of data sources and tools. Rapid deployment of on-demand solutions builds momentum and achieves user engagement during the critical early stages of adoption.  Deep-dyed security and privilege management in on-demand delivery suits the growing diversity of roles for enterprise analytics users, both inside and outside the organization.

It's 'way past time to do something with all the analytic power that companies like Tableau can offer. When I look at the on-demand platform, I see a foundation for building smarter organizations.

As I recently mentioned in another post, we had about 150 IT thought leaders join salesforce.com strategists for an On-Demand Executive Summit program at this year's Dreamforce. One striking comment during those summit sessions came from Jeff Hunter, Director of Global Talent Technologies at gaming powerhouse Electronic Arts, who said: "Our epiphany came when we realized it was harder to get our next employee than to get our next customer. Talent attraction is a matter of being a selling organization."

Attracting and retaining IT talent is a daunting cost, not just in money but even more so in the time and attention span of key IT leaders in the organization. Your technology choices may greatly help or hinder that effort, but that's not a benefit or cost that's likely to have high visibility during the process of adopting a particular technology portfolio.

The same things that make the friction-free marketplace an enterprise opportunity are also factors that make this a challenging time to find and keep good people. I actually made much the same point in an eWEEK article several years ago:

A crucial market is the one for good employees. The employment relationship has begun to approach an almost theoretical level of pure competition. Employees with e-mail and Internet access need not leave their desks to research opportunities in other organizations—or even to engage in part-time employment as consultants (or, for that matter, as industrial spies), while continuing to draw full-time paychecks.

Employers shouldn't fool themselves by looking at only the one-way flow of salaries and benefits from company to worker, with labor coming back in return. An employee is not merely a supplier of services and knowledge but is also investing in a career and making a daily purchase of life experience—paying for both with the invaluable coin of time. Every employer must therefore re-recruit its workers on an almost continuous basis, making the work environment not merely tolerable but clearly superior to readily discoverable alternatives.

When you try to attract a developer who has skills that are in demand, look at the job you're offering as it appears through that developer's eyes. Imagine that developer as a Formula 1 race driver who's being asked to distill his own fuel, or as a building architect being told that a job includes forging his own steel beams. That's the image that comes to mind when I think of skilled, costly IT talent continually repeating the construction of non-value-adding elements of an enterprise IT application and infrastructure portfolio.

IT professionals see uncertain personal prospects, creating intense pressure to maintain their technical proficiency and update their skills. Companies that don't use their IT talent in career-developing ways will find critical positions hard to fill, delaying the execution of key projects.

Farther up the IT organization chart, an IBM survey conducted this summer found that CIOs shouldn't wait to be asked for the strategic input that it's critical for them to provide.

All of these are reasons to appreciate the leverage that's offered by the rich component library, the intrinsically breakage-resistant architecture, and the infrastructure overhead reductions of the Force.com platform. These are outstanding technologies, worthy of admiration as existence proofs of ideas that have been offered as ideals for decades -- but what makes them truly interesting is that their business benefits are relevant and substantial.

The post-Dreamforce momentum is still building for Force.com. ChannelWeb reports "a blitz of new software and services offerings" on the salesforce.com platform -- in accounting, human resources, college applicant management, and a surprising variety of other domains.

Not least among the targets of Force.com partners is the cobbler's-children world of IT systems integration and project management. Evan Campbell of Rally Software appeared with me at a Dreamforce session on enhancing enterprise governance, both in business and in technical project management: the video of our session is already on line along with many other Dreamforce session videos.

What makes a platform, in large part, is availability of a pool of adequately skilled people: it's therefore notable that Bluewolf has announced its plans to open a Force.com training center in New York City. Access to a developer community, including the people who build the platform, is another key concern for startup ventures: I'd therefore like to share an Australian IT report on salesforce.com's plans to expand its San Mateo startup incubator program into the Asia-Pacific region in addition to previously announced plans for an incubator site in Europe.

Tell us what it takes to make a platform compelling for you.

Among programmers, the label of "religious issue" has a well established meaning: it connotes a "third rail" subject that's better avoided than confronted. This hazard came to mind when I heard one of our senior product managers assert, "We adhere to MVC religiously," in a conversation about our Visualforce technology to be generally unveiled on Monday at our Dreamforce conference.

MVC, or Model/View/Controller, has been described as an architecture with elements of

• model: an entity representing data or activity
• view: visualization of the state of the model
• controller: a facility for changing the state of the model

What MVC does for a development organization, my colleague observed, is to

• let people with user interface design skills take care of the user interface (the view)
• let people with programming skills take care of the code that manipulates the flow of user interaction and the manipulation of data (the controller)

Ephraim Schwartz at InfoWorld captures some of the customer excitement that's springing up at the idea of being able to craft a tailored user experience -- or multiple user experiences, for different users or different devices -- that all drive against a common, high-availability on-demand database with integral trust and data integration models. The benefits of separating controller and view, and the productivity gains of using libraries of high-function and well-tested components that exhibit that separation, are suggested in that piece.

As for those third-rail issues of "What's A Controller, Anyway?": Visualforce provides clear separation between concise declarative representation of look and feel on the one hand, and disciplined procedural description of behavior and interaction on the other. Given that deep-dyed discipline, I believe that using the name of Model/View/Controller contributes far more light than heat to the discussion.

If someone wants to quibble about whether Visualforce is "really MVC," my retort would have to be, "Compared to what?" This is as clean an architecture as I've seen: I know of no better option for putting designer skills and programmer skills to work on parallel paths, producing an application that's broadly deployable soon and affordably maintainable down the road.

Is a bigger announcement necessarily better? When it comes to empowering developers, I think I can make the case that putting the capstone on an already proven structure is at least as exciting as unveiling a whole new building -- whose strength and stability are yet to be shown.

That's the significance, it seems to me, of today's announcement -- which I thought, silly me, might actually be kept under wraps until next week -- of Visualforce, which decisively answers the only serious remaining objection of independent software vendors to the idea of building their product on the salesforce.com platform. Developers have told me that they can't take us seriously as a platform until they can build an application that looks original and bears their own brand. Now, they can.

There are other service-delivery announcements expected in the coming week, and some have said that the drama of unveiling an entire new product line and business model trumps the salesforce.com completion of a picture that's been gradually painted over the last several years. Drama and excitement are nice, I suppose, but seeing a series of promises made and kept -- and in many cases, more than kept -- does a lot more for me.

Do you see anything unusual about this piece from Motley Fool?

The role of salesforce.com as an out-of-the-box disruptor is now considered something in the past. The core viability of SaaS is no longer a matter for discussion: the question now is the tension between offerings that are paid for, whether SaaS or otherwise, and offerings that are ad-supported or that otherwise cut the cord with conventional revenue models.

The salesforce.com offering is now perceived as more like the software mainstream than it is different. The odd fish in the sea are now those who think they can give their product away rather than selling it.

This seems to be the money quote in the Motley Fool analysis: "I think the massive business software industry is fairly safe. After all, businesses want to pay for software that is reliable, secure, and continually improving." What's interesting is that the salesforce.com platform is now perceived as a perfectly ordinary way -- albeit, perhaps the current and future best way -- of pursuing that set of goals: it's being judged on its delivery of that value, rather than being fascinating and strange because of its delivery model.

An interesting, if subtle, tipping point.

The reason that I came to work at this company has made the crucial move from preview to product. Last night's unveiling of the Summer '07 release, including both Apex Code for programmers and Intelligent Workflow for everyone else, defines the new genre of Platform as a Service -- soon to be widely known (and badly punned on) as PaaS.

I wish I could claim that I fully grasped what PaaS would mean when I talked three years ago with Marc Benioff about his notion that general-purpose application development capability could be packaged in a cloud-based, service-structured form. At that time, though, I hadn't done enough of a deep dive into the multi-tenant, metadata-based architecture of the Salesforce Platform to understand all of the benefits that this implied. Now, it seems more than clear: it seems truly compelling.

It's crucial to understand that this means more than extending core applications with a macro- or script-like facility. It means much more than giving developers a hosted platform on which to write the brittle extensions of application code that pass for customization on many other platforms.

This is a true platform: one that enables independent developers to conceive and design and deploy both internal and customer-facing tools, on both desktop and mobile devices. The results can be every bit as capable and robust as the platform provider's own products, and in a broader range of task domains. Anyone who claims to offer a "platform" should be called on to pass that test.

I expect to see health care, manufacturing, and many other types of application being brought to market in on-demand forms. I challenge anyone with an innovative vision to run the numbers and tell me that there's any faster path to market, or any more attractive model for building a new intellectual-property-based business.

As I observed three years ago, "You didn't insist on devising your own file system when you had DOS; you didn't insist on writing your own graphics routines and user input/output routines once you had Windows; perhaps it's time to think about application development tools as getting ready to cross the same threshold." Why build your own infrastructure, or demand that your customers do it as prequel to trying out your idea?

As Marc Benioff challenged me then, I now invite you: "Don't compare us to other CRM offerings and ask if we're equally extensible; compare us to products like Filemaker and Access, and ask if we're equally capable of creating whatever application you need." When you look at today's high standards for rich user interface, anywhere accessibility, consumption and exposure of standards-based services, and enterprise-class security and scalability, that seems like a challenge that the Summer '07 release is more than ready to help developers meet.

Entrepreneur Frank McCracken of Ireland's Saaspoint Ltd. has urged his countrymen to take on the challenge and pursue the opportunity of on-demand development, telling them at today's Enterprise Ireland summit in Dublin that "We have been able to develop full-blown on-demand applications in forty days or less" -- and adding that any lesser pace of innovation means a risk of being "left behind."

McCracken hailed the "democratised and depoliticised" on-demand platform that frees innovators from the confinement of "historical customer platform decisions." I'd hasten to add that on-demand customers aren't being offered a rip-and-replace scenario: the Integration offerings on AppExchange, for example, are a list that's both rich and reputable. What McCracken accurately identifies, though, is the hybrid vigor of the on-demand ecosystem, with its ease of entry for the new and its facilities for coexistence with the old -- presenting an opportunity to outsource technical risk for the buyer and the seller alike.

Last Saturday, I made my fourth annual visit to the CalTech campus for what's become a June tradition of discussing entrepreneurial opportunities in software. The CalTech/MIT Enterprise Forum organizers have gotten used to the idea of having me keynote a session on this subject each year: it's always an occasion for meeting some interesting people and thinking about the business of turning ideas into services or products.

This year's theme was the commercial use of open-source software. If I'd had editorial input on the session announcement, I'd have asked them at least to think about saying "free and open-source" to emphasize that they aren't the same thing. Digging through my archive of past slide decks, I found my first presentation (given back in 2000) on enterprise use of open-source code, and found that my seven-year-old list (at right) of key characteristics of "openness" is still worth discussing: the "things people know that ain't so" about open-source software continue to create opportunities for revelation.

I'm clearly a fan of open-source efforts because they create more opportunities for developers to add value. Quality open-source underpinnings free up scarce IT funds from paying license fees for undifferentiating infraware. It's a matter of record that salesforce.com, unsurprisingly, uses open-source tools and technologies internally to develop and deliver its services, although the hyperlinked 2004 article in which that 2003 disclosure was mentioned made its own errors in confusing on-demand with "hosted" delivery models. (At the risk of over-simplification, if it's a customer-specific customized stack being run on a service provider's infrastructure, it's hosted; if it's a multi-tenant architecture incorporating customer-specific customizations through metadata, it's on-demand.) And we have multiple partners who've chosen to offer products that integrate with our services that they deliver under open-source terms.

It should also be clear that I'm perplexed by questions that seem to position open-source as a competitor to on-demand. It's like calling the turbine engine a competitor to the airline. There are airplanes that use turbine engines: they're faster, quieter, and more economical than airplanes that use piston engines, with technical improvements continually making turbines cost-effective in ever-smaller aircraft.  Pilot/owners can take advantage of those technical improvements when they buy and operate aircraft to go to places that no one else wants to go, or airlines can favor turbine technology when building scalable systems for service to multiple customers.

Disclosing the source code behind an on-demand offering is about as useful as giving an airline passenger a copy of the aircraft engine service manual. The whole idea is that you buy your ticket, you get to your destination, and everything else is someone else's problem. It's the on-demand provider's job to disclose and maintain APIs for service confederation, just as it's in an airline's interest to make its flight availability and fare information accessible to Expedia or Orbitz or Travelocity. It's in the on-demand provider's interest to maximize use of industry standards, just as it's in an airline's interest to minimize its own operational complexity (for example, in the way that Southwest uses only 737-family aircraft).

But  "Open Source" is an ingredient, not a product; source code availability is a feature, not a benefit.

There's something nicely closed-loop about a wealth management product that does well in the applications marketplace. Congratulations, therefore, to Dow Jones & Company for this week's win as Best New Product or Service in the Media category at the 2007 American Business Awards in New York.

The award recognized the innovation in Dow Jones Wealth Manager, a tool for mapping financial news to the interests of particular clients -- and a proof point for AppExchange, where the product launched at the end of May.

That product will be demonstrated at the Securities Industry & Financial Markets Association's (SIFMA) 27th annual Technology Management Conference & Exhibit, June 19-21, at the New York Hilton. I'll be there to take part in a workshop on the growing role of SaaS in financial services markets, and welcome any chances to meet with readers of this blog at that event.

It’s an exciting time to be an Apex developer – as always.

You may have read the news about the alliance between Google and Salesforce.  With this alliance, every Salesforce user now has a tool to work with Google AdWords. 

As a developer, you probably want to go deeper than simply using the new Salesforce functionality – you probably want to discover ways to create your own interactions with Google Data, such as synchronizing information between data in Salesforce and some of the Google Apps. 

Ron Hess has written a piece that explains how to put Salesforce Events onto a Google Calendar, as well as pointing the way to keeping the events synchronized.  Ron’s article includes a link to sample code.

The key feature that makes this integration possible is the AJAX Proxy, a portion of Salesforce SOA. The Proxy addresses the core issue of integrating information from different domains in a single page.  Even if you are not interested in working with Google data now, this article gives a clear explanation of how and why the AJAX Proxy is important.

Although you won’t be able to run the sample code in your organization until July, 2007, you can get a jump start on your Salesforce/Google interactions, as well as learning about using the AJAX Proxy, with Ron’s article.

I've waited to see what the blogosphere would say about the first Salesforce.com Developer Conference, held last week in Santa Clara. By any measure, the event itself was certainly a success, with more than 1,100 participants registered by mid-day and with breakout sessions fully packed right up to the end of the afternoon.

At least as important, though, is the buzz that spreads out of the event and into the worldwide developer community -- and by that measure, it seems as if this conference offered developers the right opportunity at the right time.

Alan Zeichick's Z Trek blog has been known to call a spade a spade where salesforce.com is concerned: Alan was unsparing, for example, in his critique of Marc Benioff's keynote at the Software 2007 conference, but he clearly found more technical meat to chew in Marc's DevCon opening session.

Alan's comments reflect the key points that I'd want to see a developer take away from our event:

• The Salesforce Platform is more than a hosted service: it combines client-side and server-side opportunities for developers to create new value
• The Salesforce Platform is more than just a pay-per-cycle compute grid: it provides a rich and polished set of services that dramatically accelerate the delivery of business-oriented applications
• The Salesforce Platform is wide open to value creation using third-party technologies like Adobe Flex, with new capabilities for consuming as well as exposing Web services to build powerful composite applications
• Engagement and support of the developer community is a crucial priority, as Microsoft has long demonstrated, and one that salesforce.com has clearly adopted as well

Jeff Kaplan on Think IT Services makes two additional points:

• "[C]orporate executives and end-users are longing for a new breed of applications...designed to reflect the business processes and workflows of a corporate environment rather than...accommodate the limitations of the IT architecture." He adds, and I agree, that this represents a strategic overlap between doing SaaS right and doing SOA right.
• SaaS leadership is at least as much a matter of creating a platform, ecosystem, and channel to the applications market as it is of creating best-in-class SaaS applications. What this means is that it takes more than enabling an application suite with Web service interfaces to transform an old-school software vendor into a SaaS contender.

For developers, though, the really cool stuff is the incredible productivity proposition of standards-based services. During rehearsals for our opening session demos on May 21, I was startled to the point of a loud "Wow!" by a demo using Apex Code and Google APIs to exchange data between a salesforce.com account and a Google spreadsheet.

Sure enough, the live audience later on gave a burst of applause to the same piece of wizardry, and John Musser highlighted this capability in his post on Programmable Web. You can see it yourself in our screencast: if you're impatient you can jump to time mark 7:13 for the Google Spreadsheets portion of that demo.

Ian Smith at Download Squad has his own wry summary of the likely impact of Salesforce SOA: "Web 2.0 grows up, gets job." Yeah, that about sums it up. I look forward to seeing Web 2.0 turn from a promising new employee into a seasoned contributor.

It was "kind of ridiculous," said Marc Benioff this afternoon at Software 2007, that salesforce.com had to build a substantial and costly infrastructure "just to host a contact manager" when the company was first getting under way. When you're the first, though, he said, you really don't have a choice -- but once that infrastructure was all built, he said, "We looked at this and said, 'Maybe there's another business model here.'"

That's how Marc introduced the entrepreneurial opportunity of the Salesforce Platform. "We want to let small companies go up against the big software vendors: there's 'way too many good ideas on our IdeaExchange for us to do them all." He introduced the team from Appirio, who went from an IdeaExchange suggestion to a product in just a few months. "We provide developers free access to our platform," he said, and quoted a number of independent developers who had found the salesforce.com platform to be a far more productive work environment than what they'd been using before.

Marc emphasized the extension of the platform opportunity beyond the well-known salesforce.com domains of sales force automation and customer relationship management. EditGrid, a general purpose spreadsheet from a Hong Kong-based team, was one of his examples. Adam Gross then joined Marc to demo a conference management application with an Adobe Flex front end. The dynamic user interface of Flex was integrated, under the hood, with the same data sources that support the salesforce.com HTML user interface.

Publishing that conference management tool to AppExchange concluded the demo, sending an unmistakable message to the entrepreneurs in the audience. "The vision," said Marc, "combines tools, technology, and a community to make you successful."

I wish that mainstream software development were more like working on a Lisp Machine or in a Smalltalk environment. Like a workshop in the physical world, either yields a satisfying sense of creating and accumulating new tools that make every job easier -- at least, in some ways -- than the one before it.

I have the same reaction, fortunately, to the experience of writing Apex Code -- whether in the salesforce.com UI, or with the Apex Toolkit for Eclipse and a fast-growing collection of other such aids. That's why I'm so looking forward to our May 21 Developer Conference in Santa Clara.

As I'll be noting this week, at the International World Wide Web Conference in Banff, the now-unbundled Salesforce Platform gives the developer a chance to build, and keep building anew: to create new function once and use it across an entire application portfolio, and to let the platform provide foundation capability, rather than requiring a developer to redefine and rebuild things again and again.

If you're anywhere near Santa Clara, there's no reason not to take advantage of the free May 21 event; in the alternative, expect to see a lot of great content from that event on ADN soon afterwards.

Technical conferences come and go, but some events change the way we think about the things that developers do. One of those turning points is three weeks away, and it won't even cost you anything to attend.

If you were at the OOPSLA conference in 1988, you may remember Mitch Kapor's keynote speech about the need for objects to graduate from modules to a marketplace. If you were at the first JavaOne in 1996, you may remember Scott McNealy's prescient mantra, "The Web is under-hyped." You'll soon have a chance to be present at another such moment: I don't know who will say what, but I know it will be said at the first Salesforce Developer Conference on May 21.

What Mitch Kapor said the industry needed is arguably what's now been built in the form of AppExchange. A developer with a great idea for adding a high-value function to a mainstream application can build it and sell it from a globally accessible storefront, where buyers can discuss it and try it and plug it into what they're already using.

What Scott McNealy had in mind for Java -- write once, run anywhere -- is far more true of on-demand applications than it is of Java applets. I've heard people at Ernst & Young, for example, say that Java Virtual Machine compatibility issues make Java most suitable for internal use on client PCs with locked-down configurations. The on-demand model greatly reduces the risks of client chaos.

With last week's release of the Salesforce Platform Edition, on-demand sheds any baggage of perception as being merely a set of extensions to one vendor's application suite. In the same way that Microsoft first wrote applications like Word, then abstracted and productized its ideas about application improvement into the open-ended Windows platform, the underlying technologies of Salesforce SFA and Salesforce PRM and the like are now available to anyone who wants to deliver function instead of selling frozen bits in a box.

In eight and a half years, Microsoft went from Word 1.0 (for DOS!) to Windows 3.1 -- and Salesforce.com, coincidentally, is now eight years old. Think about it.

Consider time, with apologies to Samuel R. Delany Jr., as a descending spiral of semi-dead technologies. In 1982, people were buying dozens and hundreds of perfectly good IBM PCs and putting coaxial-cable adapters in their motherboard slots for plug-compatible emulation of IBM 3278 terminals. You might now find it a challenge to track down one of those once-ubiquitous "Irma" cards: Attachmate, which acquired that product from original maker DCA, stopped selling them last year and refers inquiries to a dealer in "hard-to-find" equipment.

Within the professional lifetime of anyone getting started in IT today, designing and developing a new on-premise application will seem as quaint as deploying a new green-screen application would have seemed last year. The turning point is on May 21. Be there.

I hosted a CIO breakfast seminar in Huntington Beach yesterday, following a similar session in San Diego two weeks ago -- but roughly a third of my presentation deck was new material since the earlier event, because during that time we've unveiled the near-term prospect of putting Apex Content into our platform and adding Salesforce ContentExchange to our portfolio of go-to-market tools; we've added Flex Toolkit to our arsenal of development options, shortening the path for developers interested in taking advantage of Adobe's innovations.

The larger message that's sent by these announcements, and by their rapid pace, is that salesforce platform adoption doesn't compromise application strength as the price of on-demand availability. We're not aiming at the target of where developers are working now, but leading the target of where developers are going -- with capabilities like unstructured content search, and full-strength desktop experience rendering for remote applications. That's what next-generation applications must offer to meet the community's rising expectations, and that's what the salesforce platform represents.

I love it when I hear people say they're coming to market with "a light version of salesforce.com," or some other similar proposition. I say that because I welcome anything that makes more people more familiar with the convenience and capability of On Demand applications -- and because I'd rather compete against a self-described "light" version of what we do than against people's misconceptions about what we don't do.

It's also helpful to have other On Demand service providers walk around us, estimate the cost of being us, and say that they just don't aspire to that level of enterprise-class robustness. It validates our position that being an enterprise SaaS provider requires a whole lot more than exposing application function through a Web services API; it also encourages enterprise IT buyers to look at the big-picture value of the reliability of function and the world-class data protection that we provide, not only on our own behalf but also as part of what they get from our AppExchange partners.

Pickup trucks, and for that matter 18-wheelers, aren't threatened by the existence of motorcycles. The latter get better mileage and park in a smaller space, but there are jobs that they just don't do -- and all types of motor vehicle benefit from shared infrastructure, with all kinds of driver able to find a road that goes to their destination and fuel to make the trip.

The bigger the On Demand world gets, the more people will realize that there are different ways to take different trips and carry different loads within that space. In the meantime, we'll keep on trucking.

Wouldn't you like to see your name, and your product, appearing in a Mad Libs template that looked like this?

"[company], a provider of [category] solutions, announced that [product name(s)] are the latest [category] products to be certified on salesforce.com's AppExchange and are now available to be deployed on-demand at www.salesforce.com/appexchange. The AppExchange certification process includes extensive application testing by salesforce.com, as well as the submission of endorsements from customers who have used the applications."

I mean, really: doesn't that beat the heck out of having to come up with a media buying plan, hiring a sales force or staffing a call center, having to handle your own order fulfillment...etc.?

If reading that template just doesn't get you excited, read the actual story from which I abstracted it. And think about how short a path this is between having an idea and having an actual business.

Ted Nelson coined the term "intertwingled" in his uniquely double-bound book, with two titles bound back-to-back, Computer Lib/Dream Machines (originally published in 1974). It's a good word, although I'm leery of the noun form "intertwingularity" -- but feel free to set your own boundaries.

Intertwingling is alive and well in a column by InfoWorld editor-at-large Ephraim Schwartz that appeared two days ago: Schwartz combined observations on our AppSpace initiative, on our dynamic IdeaExchange tool for user-driven identification of product opportunities and improvements, and even on research from MIT concerning IT users' growing expectation that they'll get what they want -- not what a vendor finds it convenient to build, or what some product designer thinks they should like.

Schwartz makes a key point toward the end of that column, concerning the freedom to innovate -- in response to input from sources like IdeaExchange -- that comes from a multi-tenant architecture, with a minimum number of actual running instances of an environment. "With only one code set running, a vendor doesn’t have to spend a lot of time building for different operating systems and different backends. They can build once, test it once, and know that it works for everybody, everywhere," Schwartz observes in his notes from a discussion of customer involvement trends with Denis Pombriant at Beagle Research.

That confidence can be enjoyed, not just by a platform provider, but by platform partners as well -- which is why I urge the entrepreneurial developer to think of On Demand as the starting point of a plan to go to market.

"An enterprise's most important applications, increasingly, are customer-facing. That means they must be intuitive, engaging and rock-solid-reliable." That sounds like a thoroughly Web-2.0 sentiment, but I actually said it three years ago -- several months, at least, before the meme of Web 2.0 first emerged. (It's hard to be years before your time when technology cycles are measured in quarters.) This morning's announcement of salesforce.com's AppSpace is a nice existence proof of what I had in mind.

In another post this morning, I said that a major current problem with enterprise IT is that developer talent gets wasted on building the stadium instead of playing the game. AppSpace decisively attacks that problem: this new stadium will soon be open, and the playing field waiting for innovative developers to redraw it.

We're in a time when distinctive applications, creating a congenial and engaging on-line experience, are almost literally the face of the enterprise. AppSpace liberates in-house IT talent to work with business process owners to make that both a pretty and an intelligent face -- and lets salesforce.com serve as the personal trainer, making sure that the body behind that face is healthy and energetic.

For anyone who thinks that the salesforce.com platform is only about SFA and CRM, consider this a wakeup call: the rapid time-to-market of AppExchange, and the efficiencies and peak-load-handling capabilities of an On Demand infrastructure, are exactly what's needed to support a state-of-the-art on-line presence. AppSpace lays a foundation for you to build one.

You have to be careful with analogies, but a good one can be the key to achieving understanding. That's why it was well worth my time to track down this great image of designed-for-SaaS capability, versus the limits of mere Web hosting of conventional application stacks:

The vision shifted by virtue of SaaS’ ability to make data actionable. It’s the difference between mowing your lawn with a mower and cutting it one blade at a time.

So said Morris Panner, CEO of OpenAir Inc., as quoted in the data center journal Processor earlier this month. OpenAir turns out to be a salesforce.com AppExchange partner, which shouldn't surprise me -- since Panner's words paint a vivid picture of the difference between having the server-side power of Apex Code in your SaaS toolkit, and being limited to inflexible offerings or to customization schemes that rely on extensive and redundant round-tripping from the user node to the server.

I'm not trying to be overly abstract in saying "user node," rather than saying "PC" or "Web browser." Comments this week by the CTO of Fujitsu Siemens Computers, speaking at the CeBIT trade show in Germany, reinforce a point that I've been making for some time: that the growth trends in delivering information, whether for business or pleasure, are overwhelmingly in favor of delivery to devices that don't look like traditional PCs.

And even though we're proud of the well-designed, increasingly rich browser interface that we offer to our own applications, it's a fact that more than half of the transactions that salesforce.com handles come in through our services interface -- from who knows what kind of presentation or device.

That's why it's so important to have the option of putting logic on the server, and storing data in a secure location under expert care -- rather than blithely assuming that ever-faster PCs will handle the workload of user-facing applications.

There are things that the On Demand universe needs to have before it can fully sustain large enterprise life forms. One of those is an answer to the question, "What happens to data access if the network goes down?"

A pragmatic 21st-century answer would be the counter-question, "What happens to your whole business if the network goes down?" Ten years ago, if you had a one-hour loss of Internet connectivity, life still went on -- and having key data sitting on a service provider's systems, without current local copies available, might have seemed like a serious problem as you tried to get on with your work.

In the Web 2.0 environment, does anything actually important happen while people are waiting for their network to be revived? Or does every available asset get thrown at that restoration task, on an urgent basis, because being off the net means being invisible to customers and comatose to transaction partners?

Even so, I can understand the desire to have a more risk-averse answer as well. The slate of those answers is extended by yesterday's announcement from Informatica of its On Demand Data Replicator offering: a SaaS facility for rapid setup and easy administration of a link from salesforce.com-resident data to a customer's own relational database.

Whether you ever actually need it or not, a checkbox labeled "data replication" -- with a nice black checkmark in it -- is like an actual spare tire in your car trunk, instead of the Porsche 911 solution of a can of tire sealant and an on-board air compressor. The latter represents an attractive proposition of weight and volume reduction -- it will handle most punctures just fine -- but a big enough piece of scrap metal will leave you stranded, and that puts it outside the comfort zone of many drivers even if they go for decades without touching a jack or a tire iron.

In the same way, enterprise acceptance of On Demand applications may well depend on mapping out key stakeholders' comfort zones -- without trying to redraw those maps by argument or analysis -- and handling their objections so that real progress can be made.

How "thin" are so-called "thin client" offerings that are just a tiny little bit fat?

Any proprietary client that has to be downloaded to the user device is a possible point of attack, and therefore poses a certainty of certification and/or maintenance cost to the user.

Today’s example:

http://support.citrix.com/article/CTX112589

Severity: High

Description of Problem

The Citrix Presentation Server Client for Windows includes support for making ICA connections through proxy servers. An implementation flaw in this functionality may allow an attacker to execute arbitrary code in the context of the client process.

This vulnerability could potentially be exploited by any malicious Web site visited by the user. This vulnerability is likely to be exploitable in most client deployments.

This vulnerability is present in all versions of the Citrix Presentation Server Client for Windows earlier than 10.0.

What Customers Should Do

This vulnerability has been addressed in the Citrix Presentation Server Client for Windows version 10.0 and later. Citrix strongly recommends that customers upgrade their Citrix Presentation Server Client for Windows to version 10.0 and later.

This is being covered at

http://www.channelregister.co.uk/2007/03/06/citrix_security_bug/

http://www.kb.cert.org/vuls/id/798364

http://secunia.com/advisories/24350

WebEx Connect prospects, take note.

In another post, I've observed this morning that the Merrill Lynch adoption of on-demand tools is a challenge to anyone who doesn't yet see this model as the new default for critical applications. It should also serve, though, as a wakeup call for anyone who thinks that the Apex Platform is only a place to build products for CRM and closely related tasks.

The Salesforce Wealth Management Edition clearly has roots in relationship management -- but then again, these days, what customer-facing application doesn't?  Built on that foundation, though, are capabilities for meeting compliance mandates, for managing workflows, and for assembling powerful data and analytic mashups.

I was asked the other day about the general impact of software as a service (SaaS): I realized that I continually see all SaaS offerings being lumped together, as if they all were sprinkled with the same fairy dust that fixes everything we hate about IT As Usual.  I felt obligated to point out that

• SaaS may give the customer a shorter time from product selection to function availability, but that depends on the operational efficiency of the service provider
• SaaS may reduce the customer’s technical and schedule risk, but that depends on the service provider’s track record of platform uptime and software technical quality
• SaaS may reduce the customer’s exposure to high-cost, low-benefit shelfware, but that depends on the actual terms of the service contract

In short, “SaaS” only opens doors to benefits: it does not by any means guarantee them. That's why the Merill Lynch adoption announced today is more than a statement about the readiness of On Demand: it's also an important reminder that as with any other technology, implementation matters -- and the opportunity is only as strong as that implementation.

In a discussion on another thread here, I questioned some of the measures that are being taken in the name of digital rights management. I described my concerns about complex crippleware replacing the "universal machine" of the PC -- but another participant suggested that my stance was in conflict with the whole idea of Apex, since developers have to believe that their intellectual property will be protected as Apex partners.

I'm really glad that this question was asked, because it's likely that one person asking means tens of people wondering. It seems to me that putting code on an on-demand platform, and giving people access to its function but not to the code itself, is about the best thing that's ever been done to let independent developers protect their work without treating their customers as their enemies.

When a customer takes actual delivery of software, it had better be accompanied by a choir of lawyers singing a chorus of "licensed, not sold." That refrain would still be easy for the customer to forget, and tempting to overlook -- since the customer is asked to deploy the code, configure the installation, perhaps install patches down the road, and may be under pressure from users to go beyond the bounds of the license to save some money.

When the customer runs an application in on-demand mode, physical possession of the code is never granted to the customer -- so the need to chant "licensed, not sold" just doesn't come up. The only third party that could possibly access the actual code -- salesforce.com, for example -- is the one with the greatest interest in helping to protect it, and thus protecting the reputation of the multi-tenant platform that supports it.

This is very different from the way that software has long been licensed in theory, while appearing to be sold in every other respect that matters. It seems high time for this better way.

We're trying really hard not to do plain-vanilla marketing in this space -- feel free to blow us raspberries if we lapse -- but I feel a need to acknowledge the developer as investor.

You make big bets of time, the only investment you can never cash out, on acquiring skills and crafting code for the platform of your choice. Posts in this new category, The Business of Apex, will therefore focus on issues that aren't about how to write the code you want -- but about the decision to write for Apex at all. If you need to convince someone else of the rightness of your recommendation to do that, perhaps we can help.

The two questions I've gotten most often from developers since I got here are

1. Why does the world need another proprietary language?
2. Why should I take entrepreneurial risk to build an application on salesforce.com's turf?

Those are both good questions, and I wouldn't have come here if those questions didn't have persuasive answers.

1. Is Apex "proprietary"? Well, compared to what?
   
   If you wrote a Windows application in C, would the fact that C is non-proprietary make your work substantially less locked in to one vendor's platform than if you wrote the application in C#? Once you get beyond writing applications for a glass-teletype user interface, a lot of the value that you create is going to be in manipulation of an IT stack -- that is, a windowing and UI environment, a middleware layer, a database and so on -- and you're going to be making choices that tie you to key components of that stack.
   
   Whether you express those choices in a non-proprietary notation, or by means of a tool that's optimized for the stack you've chosen, is a trade-off: the former route may let you change your mind more easily at some future date, but the latter route gets you to market a whole lot more quickly.
   
   Today, time to market seems the compelling consideration -- especially, and this is key, since Apex development doesn't require making choices that might exclude you from any prospective customer's consideration. You don't have to worry about preserving your ability to run on three different databases, or umpteen different flavors of operating system. All you have to do is create value: the stuff underneath that is our problem.


2. Can we just take your work and assimilate it? Again, compared to what?
   
   If you develop an application for any other platform, and the platform's own vendor really likes it, they might acquire you -- or they might just enter the space with their own implementation of the idea. If you want to get acquired, it's not clear that it matters which big fish swallows you -- but if you want to grow your own company, AppExchange lets you compete against our offerings on a more level playing field than a startup would enjoy vis-a-vis any other platform provider.

Doing Apex development is not a matter of writing proprietary code, and not a short path to being swallowed up against your will. It's using the tool that best exploits the platform that gets you to market most quickly and most competitively, with all your effort going into what you do best.

And I hope that no one minds my using this space to say so. I'll try not to do it too often.