It's almost unfortunate that early generations of Software as a Service were strongly influenced by small-and-medium business (SMB) needs for simplicity and ease of use. When that origin is combined with the limited feature set and shallow customization tools of many consumer-grade Web applications, people can easily underestimate the true capability of cloud-based applications and platforms.

When you look at the most pressing needs facing enterprise IT professionals -- to engage business units in more of their data-related tasks, to provide strong policy leadership in information security and business process governance, and to ramp up their initiatives in data analytics and search -- it's really quite clear that SaaS and PaaS are not merely capable, but ideal solutions to these needs.

• When software as a service is delivered with powerful and accessible customization tools like salesforce.com’s programmable workflows, Apex Code for custom logic and Visualforce for user interface design, the business unit takes more ownership of the application and adopts the new tools far more broadly and rapidly.
• When application usage is observable through a service provider’s dashboards and other assessment aids, there’s far better visibility into who’s using different types of data in various ways.  
• When a platform as a service makes it easy for applications to share data, conveniently but selectively, the most difficult and brittle parts of a business analytics initiative are handled with ease and flexibility, right up front.

I've made this case for the enterprise readiness of the cloud in this 4-minute video, as well as in a more complete white paper available for free download. Please tell me what you think.

IT World has put out a list of the "seven dirtiest jobs in IT": it's dated in March, but just surfaced this week on my Google News radar. The good news, they hasten to say, is that mastering the associated skill sets for any of these tasks will pretty much assure you of employment; the bad news is that you can't expect to enjoy it.

Pardon my jumping out of the box, but my question is -- why should anyone have to do them at all? I'm not saying that any of these roles could be completely killed off, but I am suggesting that the need for them should be absolutely minimized.

For example: Dirty Job No.7 is "Legacy Systems Archaeologist." I totally agree that COBOL skills are more valuable than almost anyone realizes -- after all, I'm the guy whose quotation once appeared on an IBM COBOL T-shirt, saying that "Sharks Just Keep on Swimming." I had published a comment that COBOL is like the shark, which has been at the top of its food chain since the day of the dinosaurs.

On the other hand, there's a right way and a wrong way to get continued leverage from your COBOL assets. Wrong way: find or train people to write new COBOL that revises and extends the functions of old COBOL. Right way: use any of several technologies that wrap COBOL in a Web services interface, minimizing the need for future touching of actual COBOL source code.

Dirty Job No. 6 is "Help Desk Zombie": most organizations are staffing too many help-desk slots because they're using too much on-premise technology. Andy Steggles, CIO of the Risk and Insurance Management Society, told Baseline magazine last month that using software-as-a-service has allowed him to shift his limited IT headcount away from management and support toward addressing project backlogs.

Dirty Job No. 5 is "On-Site Reboot Specialist." The less fat-client code you run, the fewer times you'll have to help a system to its feet after it collapses beneath the weight.

Dirty Job No. 4 is "Interdepartmental Peace Negotiator." The conflict between control-oriented IT departments and innovation-hungry business units is substantially defused by a multi-tenant SaaS architecture, with its combination of disciplined governance and metadata-based flexible customization.

Dirty Job No. 3 is "Enterprise Espionage Engineer" -- and I have to admit, I believe I'd actually enjoy doing white-hat social-engineering and penetration tests for clients checking out the state of their systems. What SaaS can do, though, is minimize the value of stolen user credentials and reduce the amount of data that's readily stolen from the network's edge.

Dirty Job No. 2 is "Datacenter Migration Specialist." I can understand why that would be an ever more valuable skill -- but I hardly need point out that SaaS adoption can largely void the question, "where do we build the new data center?" (and how do you find the person to do it?)

Finally, Dirty Job No. 1 is "Sludge Systems Architect" -- and there, they have me. As ever more sophisticated IT goes into the bowels of the factory and the process plant, the digital roughneck who can interface bits with atoms is going to be an in-demand synthesist. If you're looking for a job that you can do today, or do next decade on Mars or next century on a starship, this is one of your options.

But if you want to stay out of the sludge, SaaS can help you stay away from the other six slots on this list.

When in Rubyland, do as the Rubians do. It's no surprise that Microsoft got a good reception by talking up the idea of ARAX (Asynchronous Ruby and XML) at (of all places) last week's RailsConf event in Portland, Oregon.

I hear a distinct echo, though, of a preemptively hype-puncturing blog post made by Microsoft's own Dare Obasanjo more than two years ago: as he pointed out at that time, the "J" for "JavaScript" in the popular "Ajax" label (it's not an acronym, and it's not correct to render it in all caps) is not to be narrowly construed.

As Dare observed with both wisdom and wit, "The Ajax hype...has little to do with the technology and more to do with the quality of developers building apps at Google [Inc]. If Google builds their next UI without the use of XML but only JavaScript and HTML, will we be inundated with hype about the new JUDO approach (Javascript and Unspecified DOM methods) because it uses proprietary DOM extensions not in the W3C standard?"

Even more to the point, it was more than three years ago that software researcher Ian Hixie made his plea, "Could people please stop making up new names for existing technologies? Just call things by their real name! If the real name is too long (the name Ajax was apparently coined because 'HTTP+XML+HTML+XMLHttpRequest+JavaScript+CSS' was too long) then just mention the important bits. For example, instead of REST, just 'HTTP'; instead of DHTML just 'HTML and script', and instead of Ajax, 'XML and script'."

Proposing the use of Ruby rather than JavaScript, it seems to me, is like introducing a new dipping sauce for fast-food chicken: it doesn't change what's inside the coating of crumbs -- and the problem with getting all excited about ARAX versus Ajax is that it accentuates a minor difference while overlooking a shared crucial flaw.

When Microsoft's John Lam went to RailsConf to talk about his IronRuby project, he asserted that developers would gain by avoiding a mental shift between two different languages on either side of the client-server boundary. "At some point," he said, "you might have to add some JavaScript code that adds some custom functionality on the client" -- but my question is, why are we still talking about client-side code at all?

The whole point of Apex Code, in particular, is that code doesn't have to run in the variegated environments of different browsers on different fat-client stacks: the application's logic runs in the cloud, with consistency guaranteed as an inherent property of having only one execution environment.

Also open to question is just how much mindshare a language like Ruby commands...but that's another subject for another time.

One of the unsung wonders of the modern world is the Internet Archive, especially its astonishing "Wayback Machine."

I had fresh occasion to marvel at the power of this tool when I was looking for something that I thought I remembered writing, not that long ago, and in the process ran across a complimentary blog post concerning another article from (pardon the expression) way back in 2002. I wondered what I'd written that someone had liked that much.

Of course, the link to that article was no longer valid -- since the content hosting arrangements of that publication have gone through several upheavals since that time -- but I went to the Wayback Machine and simply pasted in the URL. A few seconds later, I had my choice of multiple archive snapshots that had captured the original content, even preserving the links to other contemporaneous material that the archive had also retained. I didn't even need to supply the original publication date.

That's a neat hack that never loses its charm -- and I value it all the more for my inside knowledge of how the trick gets done. It was an interesting coincidence, though, that this happened on the same day that I noted a story about Composite Software's new "Composite Discovery" appliance, a combined hardware/software package aimed at giving people faster access to more relevant information.

The following language in the product announcement especially caught my eye: "Currently, managers spend an average of two hours per day looking for information, with nearly half of the information, once found, to be useless... According to Framingham, Mass.-based industry analyst firm IDC, enterprise data is growing by a factor of ten every five years, or at a compound annual growth rate of nearly 60 percent... Further, business executives are often unable to access the information in a form that is useful to them."

I don't doubt any of these statements for a moment, but I wonder if the most powerful tool for improving the relevance of content retrieval is always going to be the human mind rather than any formal algorithm.

My all-time favorite anecdote of data mining concerns the spaceflight engineers who were researching possible landing sites for the Space Shuttle if it failed to reach orbit. The characteristics of a particular isolated island, it turned out, were documented in the records of a 19th-century ornithological expedition that noted (among other things) the merits of the island as a landmark easily seen from near-orbital altitude.

No, of course the information wasn't labeled as such, but data like the island's deposits of guano (bright white) and the sheer cliffs all around the island (size doesn't change with the tides) were highly relevant. It wasn't an algorithm, though, that yielded this information, but the associative wetware of a librarian.

Similar powers of retrieval, I suggest, are also to be found in Salesforce Content, which does all the things that users have been promised for years: associative search, freedom from folder hierarchies, automatic versioning and version/comment subscription -- a lot of good stuff that has somehow failed to find its way to user desktops despite more than a decade of heavily hyped promises.

Data mining in an appliance is seriously cool, but data mining in the cloud -- spanning both virtual space and the additional dimension of time -- is the kind of thing that will ultimately define the true value of the Web.

I observed yesterday (on our High Tech blog) that $1 accelerometers, soon to be built into any number of portable data/communication devices, are indicators of the drive toward greater diversity of interaction -- and better judgment, if I may call it that, about how our devices choose to interrupt us with things that they believe we'd like to know.

Analyst Denis Pombriant has offered another perspective today on the use of voice interaction, a useful thing in a time when we spend so much of our workday on the road. Ribbit's integration with salesforce.com actually goes beyond what people do away from their desks to integrate digital recordings of verbal requests, for example, to improve accountability and offer convenient access to transcription services following important conversations or meetings.

I'm not an unbridled fan of voice interaction, but then again I've spent most of my paid-for time for the past 20+ years at a keyboard. There are plenty of people who are much more productive in other modes, or who don't have the luxury of hours at a desk almost every day.

There's also the simple question of managing information for maximum value to a generation of workers that's inclined to multi-task: one of our in-house mobile development leaders once said to me that "The mobile user does not have time, patience, or focus," and perhaps the word "mobile" in that comment could be replaced by "modern" with equal accuracy.

One way or another, we'll do well to get away from screen-and-keyboard assumptions in the design and deployment of tomorrow's applications.

It's no news that fat-PC applications display the end result of two decades of feature creep. Cloud-based alternatives offer ease of access and lower costs of administration, but critics often focus on the cloud tools' condensed feature sets compared to mainstream desktop/laptop suites.

Clear supremacy for the cloud is now emerging, though, in the form of superior integration among cloud-based tools (e.g., salesforce.com and Google Apps) and -- probably even more important -- both cloud-based and on-premise data sources (viz. today's announcement from Informatica).

Completing the picture are the real-world examples of delivering these benefits with unheard-of speed, for example the two-week wonder of a CODA 2go integration with Google Spreadsheet using "a Visualforce-powered Google Gadget" -- as described on the CODA 2go blog as well as in Anshu Sharma's post here yesterday.

Talent, it's been said, does what it can, while genius does what it must. (The reputed source of that quotation, for whatever it's worth, is also famous for penning "It was a dark and stormy night.") To stay on topic, though, one might observe that fat-client PC applications (with undoubtedly talented development teams) have been "doing what they can": that is, adding the kinds of features that make use of abundant processing power and graphical interaction.

Cloud-based applications, in contrast, are giving users what they arguably must have, in the form of superior real-time collaboration and comprehensive tool and data integration. Sounds like genius to me.

I've often heard reference to the phrase "A Clean, Well-Lighted Place," and it always sounded like a pretty attractive image: I finally got around to looking up the origin, and found that it's the title of a moderately depressing story by Ernest Hemingway. Education never ends.

What brought the phrase to mind was a succession of stories, over the last year or so, that reinforce my desire never to build, or operate, another data center of my own.

• It's getting hard to find the people you need
• It's soon to become really difficult to design and operate high-density server installations
• It's ever more challenging to configure systems securely against ever more sophisticated threats, even though there's growing recognition that security can be an affirmative rather than a defensive component of enterprise IT strategy

Google has lately been quite candid about the qualitative changes that take place in data center administration as an operation moves to enormous scale. Google accepts hardware failure rates that many might find quite surprising, but that Google has found far more cost-effective to wrap in the abstraction of fault-tolerant software -- rather than trying to buy hardware reliability at ever-rising marginal cost.

Tomorrow's data center won't be just a bigger, faster, hotter version of what we build today. There are really good reasons why you should not try this at home -- or even at many other "homes."

If you want a clean, well-lighted place in which to run your critical business functions, it's going to have a different architecture; it's going to be optimized for a different kind of IT asset portfolio; and if you run the numbers the same way that I do, it's going to be operated for you by someone else who makes a specialty of doing it well.

Even though Apex Code has been a GA tool since last summer, it's still news to many prospective developers and even to many salesforce.com customers -- and when people first encounter the world's first language for a multi-tenant execution environment, I still get puzzled or even aggressive questions about why Yet Another Programming Language is needed. About a year ago, Peter Kastner (then at the Aberdeen Group) put that concern in canonical form with his comment that clients of his "like the idea of opening up the application to custom integration, but are perplexed over why salesforce is inventing a new scripting language when Perl, Ruby, and Javascript are already well understood by enterprise developers."

Among hard-core code cognoscenti, it's perhaps the conventional wisdom that Ruby, Perl, or some other prepended-P patois like Python or PHP  are today's "well understood" programming tools -- but "Little Tutorials" blogger Daniel Pietraru challenges that perception with his well-researched analysis of programming language success. He concludes, if I may summarize, that languages succeed when they combine familiar syntax, really good tools, and the prospect of enabling "earth shattering improvement in the life of...programmers and projects." Hello, world, meet Apex.

Viewed through Pietraru's perspective, Apex Code takes on new aspects. It's not a niche tool for a proprietary platform -- rather, it's a Java-like language  with an Eclipse-based tool ecosystem and excellent facilities for unleashing immense gains in developer productivity and enterprise project success.

It's no small thing to be a member of the C/C++/C#/Java family, syntax-wise. Pietraru estimates, from various independent metrics, that this family of languages accounts for roughly half of all programmer mindshare, while fascinating and powerful tools like Python, Ruby, Lisp/Scheme and Smalltalk have a combined share of less than 8 per cent. If someone claims to be a programmer, the odds of his or her being able to read Apex Code pretty much on sight -- and understand pretty well what the code is doing -- are considerably better than even.

It's likewise no small thing for a language and platform to be well served by Eclipse. Research released this month by Evans Data found an Eclipse-based development environment rising above respected and well-supported alternatives such as Microsoft's Visual Studio and Sun Microsystems' NetBeans. The Eclipse-based Force.com IDE is an attractive way to enter the cloud, as I discussed in a video interview (taped at our office overlooking Sydney's Darling Harbour) last autumn.

But does Apex Code pave the way to "earth shattering improvement"? Don't take my word for it: ask the developers at CODA plc about their better, faster and cheaper project delivery. Moreover, ask ZDNet blogger David Berlind about the abstraction power of Apex that led him to conclude, "staying with one of the other all purpose languages would probably have done very little to fix the lock-in problem [but] might have sacrificed some of the optimizations that empower developers to more quickly and easily harness the salesforce platform...salesforce.com ultimately made the right choice for itself as well as its customers."

Shunning Apex Code today, because of a perception that it's proprietary, would be as big a mistake as shunning Java would have been in 1996. As errors go, I'm not sure they get much bigger.

In a paper released this month as sample work from Springboard Research, I was struck by the comment that "Organizations will [likely] seek a mix of options when it comes to software hosting... Even the most vocal SaaS providers, Google and Salesforce, have tacitly acknowledged that online presence is not possible for users at all times and have begun delivering offline variants of their applications."

I felt impelled -- or even compelled -- to challenge some of the assumptions that seem to be built into this statement.

• First, I find that it's ever more irrelevant to have a computer even turned on if it has no working Internet link. At this point, about the only things I can usefully do without a live feed are simple proofreading, image editing, or condensation of a presentation or a document down to a smaller size for use in a different setting. If I'm actually generating any new work, or taking any meaningful action, I need to be on line. Music composers and pure mathematicians are likely to disagree, but they're not the mainstream market.
• Second, I find that the number of places where I'm not on line is rapidly shrinking. I recently acquired an iPod Touch, and find that one of its most useful functions is as a pocket-size full-screen Wi-Fi sniffer. I find that if I'm not particular about briefly borrowing some bit-rate from an open access point, we live in a really packetful world -- and without much effort at all, I can even be fully legitimate almost anywhere.
• Third, I feel as if it's sort of inside-out to talk about being disconnected in terms of whether you do or don't have live Net access. I feel a whole lot more disconnected when there's something I need, right now, but it's on a particular laptop or desktop hard drive and I'm not in the same room as that particular machine. I'm getting ever more conservative about keeping things on a memory stick, or on a portable hard drive, or -- best option -- somewhere in a well-secured slice of the cloud where I can use it anywhere, anytime.

Finally and most generally, it's not the problem of any single technology provider (or even any particular subset of the tech provider ecosystem) to solve the problem of staying up and running even if your public network link is intermittent. Google Gears, Adobe AIR, and any number of solutions yet to emerge are narrowing the gap between reality and full-speed always-on -- and in a standards-based community, everyone gets better together. That's the kind of connection that benefits us all.

Once again, it will be my privilege to keynote what's become the annual June session on entrepreneurial opportunities in software at the Caltech/MIT Enterprise Forum. This year's topic, Betting Your Company On An Internet Platform?, was not actually defined by me -- but I couldn't have picked a subject that gets me more interested in sharing my thoughts, and participating in the moderated panel discussion that will follow my remarks on the morning of Saturday, June 14.

If you're anywhere in the very broad Los Angeles area, I assure you that an early Saturday morning drive to Pasadena will redefine your expectations for how quickly the freeways can get you somewhere. Please join us (sorry, the event is not free, but it's cheap for full-time students) at 8 a.m. for continental breakfast outside the lecture hall.

If you know you're coming, and I can put together a group of reasonable size, an insider's tour of some of the facilities at nearby JPL is also a possibility, so please leave a comment here if you'd be interested: we'll see if it can be made to happen.

In the past six weeks, I've had some unique opportunities to meet with CIOs and developers in Los Angeles, Newport Beach, Shanghai, Sydney, Palo Alto, London, Melbourne and Sydney. No, that's not an accidental duplication, there really were two trips to Sydney in just a three-week slice from that period -- but in all those places, no matter how often I visit, I still meet people who are getting their first introduction to the possibilities of PaaS.

On a short intra-Oz hop yesterday, I found myself sitting across an airplane aisle from a principal of a salesforce.com partner company: someone whom I'd first met, and briefed on PaaS, last fall. He put the power of prompt project delivery on Force.com into very concrete terms.

"I tell my clients, 'I'll never make a proposal to you that costs more than $100,000 or takes more than 90 days,'" he said. "I tell them, 'Over the course of two years, we might do a million dollars' worth of business together, but I'll never pitch a project to you that involves your spending a million dollars on something that takes two years to deliver.' I tell them, 'In 30 days I'll bring you something that does a lot of what you need -- and then you'll get some new ideas about what you want. Over the next 30 days, I'll make those changes -- and for the last 30 days, you'll actually be using the application, and we'll just be fine-tuning.'"

He told me that new clients find this a startling change from the process they've learned to tolerate. It's quite a dramatic shift from the old approach of having an application specified, storyboarded, prototyped, and finally delivered in a disappointing version 1.0 after a discouraging delay -- to be followed by a bunch of finger-pointing as to whether the fundamental flaws are in the statement of requirements, or in their fulfillment by the development team.

It's an enormous change to have the actual users of the application tightly engaged in polishing the product in what amounts to real time, and seeing that the effort they make to clarify their needs is rewarded with prompt and effective payback.

As we put the final pieces into the architecture and the ecosystem of PaaS, I see no reason why the 90-day wonder should not become an expectation rather than a surprise.

The Tour de Force events across the globe continue to draw great attendance and interest from developers looking to build new SaaS applications. The event is yet to make its way to India but I have been traveling across India (Pune & Bangalore) meeting with partners, educating them about Force.com and Platform as a Service generally – and the response has been tremendously positive. At one of our partners in Pune, I delivered an hour long session on PaaS and Force.com – and the result was a lot of very interesting questions and interest in this paradigm shift. A similar event in Bangalore with over 100 attendees drew a similar response.

India is Ready

There was genuine appreciation about how difficult and wasteful it is to currently build, deploy and manage software applications. This is especially true for IT outsourcing firms that month after month see ISVs and IT departments of large enterprise burn time and money on infrastructure and platform, delaying and risking delivering business value to the end users.

Across Generations

India is a country of young people – over 50% of India’s population is under 25. And presenting to various audiences – I couldn’t help but wonder how many in the audience can even remember what computing without connectivity was like. The shift from client-server to SaaS comes naturally to this generation.

More interestingly, the senior executives and technology gurus – some that wrote compilers in 1980s by hand – were even more excited about this shift. The questions and discussions revolved around how to navigate this shift and understanding the new evolving SaaS ecosystems and not whether the shift is underway. 

Here is a sampling of questions:

Is There a Whitepaper on SaaS?

Yes, we do have whitepapers on SaaS and PaaS. However, whitepapers are so 90s – I encouraged our audience to learn through building and engagement with the community – blogs, online forums, how-to wiki’s, informational videos. 

What Kind of Applications Can I Build on PaaS?

Even as salesforce.com started out as a CRM company, the Force.com platform is being used by our customers and partners to build out applications that cover wide variety of solutions be it Finance and Accounting (Coda), Risk Management (Riskonnect), Life Sciences (Verticals OnDemand) and many others. Business Applications that are data and process driven is where Force.com provides the most value today

What about Security?

No one asked this question – so I thought I will mention it. This question that resulted from both genuine apprehensions and FUD created by certain vendors that did not have SaaS capabilities is increasingly becoming a non-issue. I think there are two reasons for this: First, as customers use more and more SaaS applications their experience invalidates the concerns. Second, initiatives such as trust.salesforce.com that educate and inform have re-assured the community of users, developers and investors. 

Really?

Yes, this question was asked a few times. For example, when I explained that Force.com is multi-tenant not just for our direct customers but also for all applications written by end users and partners – and that everyone is on the latest version of the software. The response is: Really? 

Salesforce.com’s success with the platform in releasing as many as 25 major releases in last 8 years – and comparing that to once in 3 to 7 years cycle for legacy software vendors also draws a: Really?

So yes, really!

The proof is in the pudding – you are welcome to get a free developer login and build an app.

The task of maintaining information security is one that combines technology, management, and even international agreements in a volatile stew of complex and dynamic challenges. The best back doors into a system are usually opened by that system’s own applications and their configuration options, used in ways that are typical but less than robust.

Most information theft or leakage is the result of either carelessness or malfeasance by people who had all the privileges they needed to come in the front door of the system. The typical IT environment paves a path of least resistance for data to go out to the edge of the network. A software-as-a-service environment actually makes it much easier to manage privileges and monitor data use in very specific ways, while actually improving users’ access to data from any networked device and ensuring that everyone sees the same information at the same time. That's why it's so vexing to find myself explaining, over and over again, that the conscientious administration of information security is far more important than the physical relocation of data to a service provider's systems.

The cost of staying abreast of security developments is probably more than ought to be borne by all but the largest corporations. Sharing that cost across tens of thousands of served organizations with millions of individual subscribers, all on the same multi-tenant platform, can be a much better way to go. That's why I’ve written a white paper on the myths and the realities of security in the multi-tenant, on-demand environment of Software as a Service and Platform as a Service. I've also summarized key points in a three-minute video: I hope you’ll find these to be useful resources in weighing security's realities against widespread misperceptions.

It's common to see "build or buy" -- or even "build, buy or rent" -- being used as a taxonomy for any number of elements of an application, from the database handling functions up to the core function libraries behind compute-intensive logic. As enterprise developers turn their focus toward global cooperation in networked partner ecosystems, the build/buy question starts to apply to entire business tasks and not just to the layers of the application stack: hence the relevance of "Salesforce to Salesforce" integration as new connective tissue for strategic applications.

What made me think about this today was a comment by "serial entrepreneur" Mitchell Ashley, CEO and Chief Strategist of Converging Network LLC, in a blog post this week that said

If you are around the Software as a Service (SaaS) industry long, you quickly figure out that moving software out of the data center and into the cloud makes partnering a critical skill for vendors. No one vendor has all the cloud-friendly solutions you need today, whereas solutions for our traditional enterprise are a-plenty. Vendors in the age of hosted applications, SaaS services and utility computing and storage are putting their partnering skills to the test...

My personal opinion is that the longevity of many SaaS vendors will be directly determined by how [effective] they are at developing a strong partner ecosystem and then working to help foster and enable that ecosystem. Frankly, startup companies tend to have a natural paranoia that they are building the next better mouse trap and everyone else with a pulse is a competitor. Startups will have to overcome this natural paranoid tendency and quickly learn to develop partner friendly products and learn...core skills to help them be good partners.

Making partner interaction almost literally a click-to-connect proposition helps pave a path of least resistance that leads in a good direction -- that is, toward a partner ecosystem directing benefits to all participants.

It's been at least eight years since microchip gurus noted the growing gap between multi-thread hardware and single-thread tasks. Vendors who've taken the lead in the drive toward hardware parallelism are now looking for ways to bring software developers into alignment with what that technology enables. There are already definite danger signs of diminishing, or even negative, returns.

Experts like AMD Senior Fellow Chuck Moore suggest that future development must move upward into the level of the API rather than the instruction set, which is certainly not news to the Force.com developer. The PaaS development community is living that future today.

Force.com developers, I suggest, are already giving the lie to anyone who says that "What we don't have yet is that combination of a new business model and a killer application that will make parallel processing the household name that the Internet has become. I'm not sure we're going to see one." The business model is PaaS, and the killer application is Development as a Service.

As William Gibson has famously said, "The future is already here - it is just unevenly distributed." Developing on Force.com gives developers more than their share, and I'm just fine with that.

I was asked this week at the Fusion 2008 conference, "who develops PaaS applications? The IT department, or the users?"

The answer, of course, is "both," with a critical bonus for PaaS: that user-developed applications in a PaaS environment can readily be brought into the IT portfolio if they prove to be successful and worthy of scale-up.

"Rogue applications," as some people call them, can't be accurately inventoried in a world of Excel and Access -- and can't be broadly deployed without unacceptable costs of either thick-client administration or migration to some other application tool set.  An article appearing today on eWEEK.com observes that this is a key IT concern, saying:

Industry observers use the term "consumerization" to describe the phenomenon whereby office workers are less likely to wait for the IT folks to equip them.

Analyst Rebecca Wettemann of software research firm Nucleus Research says her company's surveys of corporate technology users frequently turn up the question: "Why can't I do what I want without getting an OK from IT?"...

"Individual people, not IT organizations, are driving the next wave of [technology] adoption," Forrester Research said in a recent report.

Forrester refers to the movement toward user control and individual empowerment as "Technology Populism," others refer to it as "Office 2.0." Less sympathetically, consulting firm Yankee Group, in a 2007 report entitled "Zen and the Art of Rogue Employee Management," sees it as a threat for IT managers.

PaaS applications, of course, can scale from a single user to tens of thousands of users at will: valued salesforce.com partners like Kailea Networks can be part of that story, as their tools (and the disciplines that those tools enable) can help to maintain a governable IT asset portfolio despite growing decentralization of development efforts.

I've been meaning to write about a comment I saw late last year: "Program simply, but design with complexity." That phrase caught my attention: it seemed to me a good description of the Force.com platform, which is stunningly complex where you can't see it so that it can behave simply where it matters.

The developer winds up being able to think about what the application should do, not how to manipulate the technology to make that happen. Simpler technologies require more continual effort on the part of the developer to use them appropriately, or even just use them correctly.

Complexity is not the goal, but neither is it the Ground Zero of application development that programmers should flee before the inevitable explosion. Complexity is a cost, to be sure, and it should be put in the place where it costs least to have it -- in the same way that it makes sense to use electric cars if you can use a waterfall, somewhere far away, to generate the electricity and thereby avoid polluting cities' air.

In the world of Platform as a Service, complexity may become more OK -- as long as you only have to incur that complexity in one place to make its benefits available to thousands (or tens of thousands) of customers.

Sometimes, it really is nice to have a picture rather than just words to make a concept clear. A diagram on Gianpaolo Carraro's blog, accompanied by usefully brief descriptions, may come in handy in explaining to people why there's more to "Software as a Service" than merely putting the server at the other end of a wire -- instead of in your own glass house.

Out of 800 enterprise IT managers, 86 per cent have a hard time finding qualified people; 54 per cent have trouble keeping the ones they have.

Specifically,

• 36 per cent of them can't staff security specialists
• 31 per cent of them can't staff database administrators
• 26 per cent of them can't staff storage administrators

I mention those three disciplines, in particular, because they're skills that don't create much competitive advantage when done perfectly, but they represent enormous downside risks when done less well. So, why retain the burden of doing them in-house?

The numbers cited here are from an October 2007 report, "State of the Data Center," published by Symantec. Some people will use numbers like these to sell you tools that automate data center administration: I'd rather suggest that these are reasons not to have a data center at all. That's the announced goal at Sun Microsystems, where data center architect Brian Cinque has blogged on his goal of "0 SunIT Data Centers" by 2015.

People have been talking about the shift of IT cost from hardware and software to wetware since at least the 1960s.  I can't quickly find it now, but I remember seeing an article from the Harvard Business Review that was dated something like 40 years ago, warning about the cost of IT starting to rise: the cost of the human components, it concluded, would swamp any further declines in (ahem) mainframe pricing.

Well, we've gone through a few more teeth of the saw since then, with any number of hard-tech discontinuities starting us on a new downward trend of overall cost -- but every one of those downslopes has a bottom. Is this the last sawtooth cycle? Nicholas Carr's The Big Switch suggests that we're at a critical point.

And 33 per cent of those 800 IT pros say that key people are retiring: solutions available now, like SaaS and PaaS, are better than solutions yet to be defined.

I had to count twice before I believed that it's been four weeks since my previous post here. At least there's been no shortage of news for developers during that time -- while I've been visiting with CIOs in Dallas, Chicago, Atlanta and New York. We've had a lot to discuss.

Much has been written about the Tour de Force kickoff on January 17, notably Dan Farber's real-time reportage from the event. Dan captured, in particular, keynote guest Marc Andreessen's emphatic statement that programmability makes a platform.

Renee Ferguson at eWEEK also called attention to the Metadata API, announced at Tour de Force, that allows a developer to manipulate or extract the definition of an application. I remember when "programs that write programs" were considered a distinguishing feature of AI research: it's beyond cool to find this concept mainstreamed into an enterprise-oriented application environment.

Over at Intelligent Enterprise, David Linthicum has reinforced what I consider a key point about SaaS and PaaS in the enterprise: that "as a service" offerings don't represent a separate space of solutions, but rather a powerful set of tools that complement whatever's already working for an IT owner. He writes:

[T]hose who plan, work, and build their enterprise architectures today will ignore SaaS at their peril… Other systems, new and old, have to interact with SaaS-delivered systems and they are indeed part of the architecture. Many enterprise architects are in denial about this fact and ignore the use of SaaS, in essence, considering it a Web site rather than an enterprise application. Can't do that. Indeed, the use of SaaS will only expand as the years go on…

Meanwhile, Research and Markets has enumerated the elements of SaaS that make it such an important addition to the IT builder's portfolio:

Multi-tenancy, building applications using Open Source building blocks, and spreading the cost of expensive technology expertise are all reasons why SaaS provides a compelling solution, cost-wise. Another key success factor, however, is often overlooked, and this is the fact that the most successful SaaS applications are built over Service Oriented Architecture. Looking for an SOA success story? You don't have to look far. Look at Concur, Salesforce, Workday, and RightNow.

Finally, it's always interesting when non-techies notice a transforming technology purely because of its ability to transform markets. Over at Motley Fool, analysis of "who's at risk?" leads to a conclusion that traditional software models are in jeopardy:

Start with the industries that have experienced past glory. They're the ones most likely to be complacent and, in the process, be disrupted by a bold upstart. Here are my three picks for industries that will play host to the Next Big Upset:

• Software-as-a-service over installed software. SaaS, as it is known, is highly attractive for its cost advantages and lower administrative burden when compared with installed business software from the likes of SAP and Oracle. And let's be honest: Would you really want to install software if you didn't have to? The more than 35,000 customers who use salesforce.com say "no."...

Please pardon this big-gulp catch-up post, and thanks for the chance to connect with you as I begin my second year at salesforce.com.

The folks at Yankee Group have newly opined that "A future in which business applications and data can be accessed anywhere, at any time, on any device is within sight": that the prospect is "not a Buck Rogers, Star Trek, Star Wars thing," but one that is "happening...driven by need."

Obviously, salesforce.com considers the Force.com platform a major step toward that reality -- and we're inviting developers to come to San Francisco on January 17th for a free full-day event that will give our guests both the knowledge and the perspective to build on that foundation.

We'll be joined on the 17th at San Francisco's Palace Hotel by guest keynote speaker Marc Andreessen, co-founder and CTO of Ning Inc.  Marc's role as one of the originators of the modern Web browser gives him a particular perspective on the next generation of platforms: a perspective that he's shared in a widely quoted blog post, "The three kinds of platforms you meet on the Internet."

I should have called attention to Marc's "three kinds" analysis, which was posted in September, long ago -- because he provides an independent point of view on what a Web platform, properly speaking, ought to offer to developers. Boiled down to one key requirement, Marc says (and I agree) that "If you can program it, then it's a platform.  If you can't, then it's not." Without the ability to define new behaviors, rather than merely stitching together a family of behaviors that have been predefined by a provider, it's not a platform.

Marc goes far beyond that, though, with his definition of three levels of platform in which the features of a "Level 3 platform" -- a runtime environment, integrated development tools, an integrated database environment and intrinsic security, to name a few -- may sound familiar to anyone who's looked in any depth at Force.com. Building a Level 3 platform, says Marc, is "a truly intense technical and business undertaking, and not for the faint of heart... The good news is that what it makes possible is magical."

The level of expertise required to develop on such a platform, says Marc, "drops by at least 90%" compared to less capable platforms, and "the level of money they need drops to $0.  Which opens up development to a universe of people for whom developing on a Level 2 or Level 1 platform is prohibitively difficult or expensive." (The emphasis is Marc's, but I certainly don't disagree.)

Please be with us on January 17th to learn more.

Over at TechRepublic, Alex Khizhnyak has authored an appealing invitation for developers to explore third-party integration aids for salesforce.com data. Some of his points reinforce my own arguments in my white paper on integration of on-demand resources with other IT elements: for example, "clarify the goals."

I want to call particular attention to Alex's "Web 2.5" thinking about combining the strengths of the salesforce.com API with the raw storage capabilities of other on-demand services, such as Amazon.com's S3.  Also useful is his emphasis on creating a sustainable process that automates ongoing operations. That's what it takes to preserve data consistency, and thus to make the system an operational asset rather than just a neat demo.

What sums up the piece, it seemed to me, were these comments near the end:

Integration with salesforce.com may be easier than you think... With today’s data management solutions, the business user has a powerful toolset not only to manage data streams within the enterprise, but to join data with the Web, keep it safely in salesforce.com, and exchange information with partners globally.

Precisely.

David Linthicum ended 2007 with five predictions concerning service-model delivery of IT function. Some of those predictions are focused more on supply than demand, but #2 makes a key point for buyers:

Integration issues become the largest impediment to SaaS. As more companies move toward SaaS, the more they will find the need to link their new SaaS applications with their existing data. While many consider integration when selecting a SaaS solution, most don't, and end up figuring things out on the fly…not a good approach. Successful integration can only occur with a lot of planning, and linked back with an overall enterprise architecture/SOA strategy.

Developers should therefore be looking at SaaS, not as a self-contained partition within an IT portfolio, but as an element of their toolkit that they'll mix and match with other resources.

Fernando Labastida made a similar (and somewhat more affirmative) argument in his blog post last November:

Since saas CRM manages the lifeblood of the business, sales and customers, and is increasingly more user friendly and flexible, it is becoming the preferred method for companies to manage their business.

As a result, it is also becoming the de facto integration hub, or SOA enabler, for the smaller enterprise.

Needless to say, I heartily agree, and I hope that the strength and variety of integration points into salesforce.com's systems will become more recognized in 2008. For more on the subject of integration and on-demand systems, please see my white paper on the subject.

The past year has seen dramatic growth in IT vendor hype on the subject of delivering IT capability as a service. Vendors who used to pigeonhole the service model in a small and medium business segment are now trying to position their enterprise products as suitable for on-demand offering.

In the process, there’s been a lot of self-serving restatement -- or even deliberate confusion -- of the definitions of key technology elements that can represent fundamental business and technical advantages for a dedicated services provider.

Call me old-fashioned, but I believe that credibility matters: I never make a technical statement, even in a competitive situation, unless it's what I personally believe and can objectively support. I'd like to see the debate on service offerings adhere to that level of rigor.

For example, I believe that a business applications platform can be architected from the bottom up for sharing of core functions, combined with customization of individual customers’ business processes and rigorous protection of each customer’s data. It's not the only way to deliver IT as a service, but I believe it's the best way, and I’ve written a white paper entitled “Why Multi-Tenancy Matters” that I believe makes that case.

I've also summarized my argument in a 2½-minute video: one way or the other, I hope you'll give that case a hearing before you let others define the terms of your future options.

Our developer lounge at this fall's Dreamforce conference played host to some key partners, including both Google and Adobe, in the process of bringing the platform capability of Force.com to the developer community. I'd like to conclude (at least for now) our series of video interviews from that conference with the inside story of what Force.com represents and how developers may want to approach the opportunity it provides.

My guest for this conversation was Chris Fry, Senior Director of Platform Development, who shared his views on the general capability of salesforce.com's rapidly expanding and evolving on-demand platform -- in particular, the new approach to Web-facing application design that's enabled by Visualforce.

As I've previously noted, this year's Dreamforce conference saw some of the most interesting gurus of the web-facing world visiting the well-attended Developer Lounge. I'd like to share the conversation I had there with James Ward of Adobe, concerning the opportunities to amplify Force.com's platform services with the front-end interactive power of Adobe's Flex.

I've previously commented on the growing momentum of Flex, even among influential coding mentors like Bruce Eckel who have major investments in other tool sets. Since then, we've seen further substantial investment of salesforce.com resources in making Flex an attractive complement/component for VisualForce.

If you have about 3½ minutes, we have a video segment from that Dreamforce interview that examines the opportunity to combine top-flight tools and sharpen your on-demand edge. I hope you find it worth your time.

After doing this kind of thing for a while, you might think you know a bit about the relevant data types in your applications. I suggest, however, that there are at least two things that a developer needs to reconsider from time to time about what one might know that ain't so:

• the nature of security threats and the need for every application to withstand them
• the nature of data and the need for every application to make good use of new data types and sources

What brings these thoughts about data to mind is John Murrell's commentary today on the expanding universe as viewed through Google Maps. He reminded me of an early (very early) Saturday morning a few weeks ago, when my 17-year-old son was about to leave the house at 3 a.m. to catch a ride to Mexico to build a house for a family there. His team would be meeting at a shopping mall near San Diego, and he was wondering if there would be a place to grab a hot breakfast while waiting for the rest of the group to assemble: Google Maps allowed me to drive, virtually speaking, up to the meeting point and look around to spot a fast-food restaurant where I knew he'd find a hot meal at a pre-dawn hour.

At no point, before I had this capability, did it ever reach even my wish list of things that I thought the Web should someday do. If anything, the Star Trek captain's command "On screen" -- allowing remote surveillance of any corner, it would seem, of the galaxy -- always seemed like one of the most disbelief-suspending demands placed on fans of that genre. Yet, in a limited but quite useful sense, here it is.

My larger point is that data types change, over time, as new data sources and appropriate data channels emerge. When mere on-off switching of a radio signal was the frontier of long-distance communication, Morse Code was a crucial protocol -- and one that I'm not sorry to have programmed my brain to demodulate. But times change -- and the level of investment in past capability is not a good measure of its future value. What matters is what people want to be able to do tomorrow.

Research has shown that when your brain knows what to do with something, it sees it in a different way than when it sees something that it doesn't know how to use. Work on that. What you see as irrelevant eye candy or cumbersome content, someone else may see as a way to deliver function that users will find compellingly attractive.

When people ask me what salesforce.com does, my first impulse is to say that we're the world's premier enabler of innovation. More pragmatically, I usually say something more concrete, along the lines of "We deliver business information tools as a subscription service on the Internet" -- but the former, higher-level mission statement is always on my mind.

It therefore caught my eye when that same verb of enablement appeared in the newly released report, "Strategic decision making for technology policy," produced by the United Kingdom's advisory Council for Science and Technology. Following a rigorous and useful description of process and examination of critical efforts during the next five years, the report also identified four "platform or enabling technologies" including high-bandwidth communication and pervasive (or "ubiquitous") systems.

Thinking about bandwidth and ubiquity, I'm reminded of what I've often told my three sons about the two sure things in tomorrow's economy:

1. People will spend as much as they can afford (or more) to be entertained
2. My baby-boomer generation will demand that everyone spend whatever it takes to keep them feeling under thirty

Put those two trends together, and you have a world in which people consume bandwidth for the fun of it until they're too infirm to have fun any more -- after which, medical science will consume at least as much bandwidth on the remote in-home monitoring and supervision that will be the only affordable means of scalable elder-care. And all that bandwidth will be carrying the nouns and verbs of data and code.

Developers should keep this big picture in mind. It's not about the semicolons, it's about what the user wants to do.

At Dreamforce 2007 this September, I had some unique opportunities to speak with key tech gurus for many strategic players of the Web-facing world in the Dreamforce Developer Lounge.

One of those conversations was with developer advocates for Google, which is moving into enterprise applications with recent deals like an adoption of Google Apps by systems integrator Capgemini -- following the September announcement of Capgemini's plans to develop a services practice for Google's offering.

We have a video segment from that Dreamforce interview that makes some important points about understanding the developer opportunities and perspectives that will lead to on-demand success. Enjoy.

I've only seen a few episodes of The Big Bang Theory on cross-country airline flights, so I can't say for sure whether "Pseudo-Random Number Generator" is a phrase that's ever appeared in one of its scripts. It does seem like the kind of thing a screenplay writer would use as archetypal nerd-speak, but I don't think I've even heard it on Numb3rs. (With these two shows added to its CSI franchise, is CBS committed to owning the whole nerd TV audience? Then again, does that audience actually include anyone, any more, who is not a member of my own nuclear family? Sorry, I digress.)

What brings the eye-glazing "PRNG" term to the top of my stack is this month's claim that the PRNG in Windows may be seriously flawed: vulnerable to "severe and efficient" attacks that don't need Administrator access to determine a substantial chunk of the generator's present and future state.

I've often used the security of "secret-in-public" protocols, such as the Diffie-Hellman key exchange, to calm the fears of people who believe that doing things over the wire is inherently dangerous. I continue to believe that the risks of "roll your own" IT are generally larger than most people realize, compared to the practical level of risk involved in what are mostly theoretical Net vulnerabilities. This new report is a useful reminder, though, that one can execute the form of security while failing to provide the substance. A key exchange using a poor random generator is a card game with a marked deck.

This is just one example of a more general point about security, or any other aspect of meeting IT performance metrics. Conformance with a standard or protocol is merely a starting point: competence, determined by often-costly scrutiny, is at least as crucial. In particular, the difference between a product and a service includes the difference between building something that makes security possible, and operating something in a way that makes security real.

People sometimes compare IT to the nervous system of the organization, but I found myself thinking the other day that it's more like the circulatory system. Sitting in an awkward position can make your leg go to sleep, but that's just a transitory numbness or tingle: move your leg, and it will come back to life after a minute or two of discomfort. Cutting off the blood supply to your leg will make it die, just as lack of key information can lead to a gangrenous loss of a key customer or partner: that's not something that will fix itself.

What triggered this grisly image was an article about new understanding of the limits of blood transfusion. "Everyone knows" that the function of blood is simple: deliver oxygen to body tissues, and remove waste products like carbon dioxide. What's now becoming clear, though, is that stored blood loses a key ingredient -- nitric oxide -- that has an important role in dilating arteries and capillaries so that blood cells can get to where the rest of their payload is needed.

Perhaps it's a sign that I've been in this business too long, but this seemed like a perfect metaphor of many poorly conceived IT initiatives. They're loaded with the "oxygen" of good data, but they're lacking in the nitric oxide of effective deployment and well-designed usability. You keep hanging bags of nice red cells on the rack, and sticking needles into every exposed point that you can find, but the patient dies anyway. In fact, the attention consumed by badly designed systems can make them worse than useless, just as the nitric oxide scavenging effects of old blood can make death rates with a blood transfusion actually higher than death rates without.

Without measured adoption, and rapid response to any areas where users appear to lack understanding, any software initiative is likely to yield a disappointing result. Of all the advantages of on-demand delivery, the ease of precisely measuring what people are using may be the most under-recognized. Plan to take advantage of these tools in your next on-demand deployment.

How cool is this?

Champaign, Illinois--October 24, 2007--Wolfram Research and Stephen Wolfram today announced that 20-year-old Alex Smith of Birmingham, UK has won the US $25,000 Wolfram 2,3 Turing Machine Research Prize.

In his 2002 book A New Kind of Science, Stephen Wolfram hypothesized that a particular abstract Turing machine might be the simplest system of its type capable of acting as a universal computer.

In May 2007, the Wolfram 2,3 Turing Machine Research Prize was established to be awarded to the first person or group to prove either that Wolfram's Turing machine is universal, or that it is not.

Alex Smith was able to demonstrate--with a 40-page proof--that Wolfram's Turing machine is in fact universal.

This result ends a half-century quest to find the simplest universal Turing machine.

Please also see Stephen's personal comments on this development. I love it when abstraction predicts reality -- and Turing's legacy deserves this reminder of just how right he was about so many things.

We were pleased to have almost 150 IT thought leaders attend the On-Demand Executive Summit sessions at this year's Dreamforce, and to offer the participants in that group their own on-line community portal for discussion of those events.  I wanted to share here some of the reactions I had to speakers who took part in that summit program.

Robert Bennett, President and CEO of San Francisco's Family Service Agency, spoke to the group about his agency's use of salesforce.com technology to provide what Bennett has called "access at our fingertips to demographic, outcome and productivity reports across all services and programs, giving us visibility into the effectiveness of our client programs and the ability to set and track metric-based benchmarks for client progress."

During Bennett's remarks to the summit, he said, "Three years ago, 50% of our labor went into data entry -- and once in the 'chart,' it was dead. There was nothing we could do with it. The Force.com platform, in the long run, could link all of the city's agencies in a rich program of information sharing."

We subsequently heard from San Francisco's mayor, the Honorable Gavin Newsom, who amplified on that vision. "Every client goes through your database: we know where they've been in the system, we actually know how many homeless we have and we have real information as to who's achieving what outcomes. It's changing our approach in a fundamental way," the mayor said.

These comments brought to mind something I wrote five years ago in eWEEK:

Nothing kills a relationship more quickly than the feeling that the enterprise isn't really dealing with the customer, the employee or the supply chain partner as a whole—that every interaction takes place in a separate space, without awareness of the interlocking opportunities and needs reflected in other interactions at other times and among other activities.

Conversely, the enterprise that identifies and addresses such needs will give its customers a compelling case to favor that enterprise with profitable one-stop shopping, instead of needing to fight for every separate piece of the business of even the frequent buyer.

I hear a call to action: to ask ourselves, what are we actually able to do that adds business value using all that data we spend so much time and money to acquire and store?