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.