Securing the applications

IBM Rational has written a solid white paper on software security, focusing on improving code reviews. Although I rarely (very rarely) endorse a vendor white paper, this is one that’s worth reading.
Written in December 2009 by Ryan Berg, a senior security architect at IBM, the paper focuses on best practices for examining code for security flaws, and then figuring out how to remediate those flaws. The paper, called “The Path to a Secure Application,” breaks the vulnerabilities into five specific categories, each of which is examined in detail:
• Security-related functions
• Input/Output validation and encoding errors
• Error handling and logging vulnerabilities
• Insecure components
• Coding errors
For each of those vulnerability categories, Berg describes specific instances and offers a list of suspicious code behavior that might indicate problems. For example, for insecure components, he offers that you might have unsafe Java Native Interface methods, or unsupported methods. Suspicious behavior would include raw socket accesses, which could indicate possible backdoors; timer or get-time functions, which might mean triggers; or privilege changes, which might speak to unauthorized access levels within the code.
What’s nice about this paper is that – unlike many that cross my desk – Berg isn’t setting up a paper tiger. He’s not highlighting flaws so that he can say, “Oh, look, IBM sells tools to solve this problem, call us today.” While IBM Rational does offer source-code scanning tools, this white paper ain’t peddling them. Rather, Berg is offering guidelines for making a QA checklist for reviewing source code for secure vulnerabilities. Nicely done! I wish more white papers were this good, and this genuinely educational.
Z Trek Copyright (c) Alan Zeichick

The modern programmable portable sensor pack

Battery-powered. Built-in satellite-based Global Positioning System receiver. Accelerometer. Ambient light sensor. High-resolution camera. Powerful processor. Gigabytes of storage. Radios for communicating with Bluetooth devices, WiFi networks and cellular data systems. And now, even an embedded gyroscope.
The sensor and communications capabilities of today’s smartphones is astonishing. Each generation of device, whether from Apple or its competitors, crams more and more sophisticated electronics into a pocket-sized package, with the latest being the iPhone 4’s gyro.
All you need is a life-forms sensor and a probe for detecting buried dilithium deposits, and today’s smartphones would be right at home on the U.S.S. Enterprise. Oh, a tachyon emitter would be nice too.
We’ve been here before, of course. In early 2007, Sun Microsystems gave me a Sun SPOT development kit. A SPOT – Small Programmable Object Technology – was a battery-powered device equipped with a small ARM processor, short-distance radio, accelerometer, temperature and light sensors, some multi-colored LEDs and general-purpose analog and digital I/O ports, managed by an embedded Java virtual machine. I did some experiments with the SPOT and was impressed with its capabilities. Sadly, the Sun SPOT initiative faded out after its first limited production run.
General-purpose smartphones, whether based on Apple’s iOS (the new name for iPhone OS), Google’s Android or Microsoft’s Windows Phone 7, have the potential to revolutionize remote sensing. Not only is the array of built-in sensory apparatus impressive, but the ability to add more through hard-wired or Bluetooth connections takes that a set farther. I don’t know if there are third-party toolkits yet for adding analog and digital inputs to smartphones – but there should be.
Already there are kits for connecting smartphones to a car’s OBD-II to pull down a vast array of real-time onboard diagnostics. Software uses that data, plus the phone’s accelerometer, to measure acceleration and performance.
Look at a smartphone, and forget, for a moment, that it’s a phone. Think about its sophisticated electronics, processing power, radio capabilities, and sensory functionality. Imagine how it could be used for science and engineering — both in the lab and in the real world. Think about the low price, well under $1,000 (forgetting about carrier subsidies). Amazing, isn’t it?
Z Trek Copyright (c) Alan Zeichick

Is Continuous Deployment the next step forward in agile development?

Speed matters. With most agile development methodologies, the faster you can push new code out into the source-code management system, into builds and onto servers, the faster you can evaluate your progress and chart your next moves. From monthly builds came weekly builds, then daily (or nightly) builds. In some shops, those builds are used internally, with less-frequent deployments into the production environment. In other cases, the bits are actually pushed out to production servers daily.

Even the now-common daily/nightly build and deployment may not be fast enough to drive modern development, according to some proponents of ever-more-agile agile methodologies. That’s why thinkers like Kent Beck (pictured) are now advocating a move from Daily Deployment to Continuous Deployment.

Continuous Deployment is the topic of the first-ever SD Times Virtual Conference, which we’re holding on Wednesday, June 30, beginning at 1:00pm Eastern (10:00am Pacific). There’s no cost to attend this three-hour educational event, which I’ll be hosting.

Our three instructors are Kent Beck, founder and director of the Three Rivers Institute, and author of “Implementation Patterns,” “Extreme Programming Explained: Embrace Change,” and much more; Timothy Fitz, tech lead at IMVU and one of the creators of the Continuous Deployment movement; and Jez Humble, build-and-release manager at ThoughtWorks Studios, who is currently writing a book called, appropriately enough, “Continuous Deployment.”

Here’s what we’re going to cover in the virtual conference – you can stay for the whole thing, or choose the parts that seem more relevant to you:

• The potential benefits of Continuous Deployment to your organizations.
• The technology required to implement Continuous Deployment.
• How to apply Continuous Deployment to your company’s existing IT systems.
• How to apply Continuous Deployment to the software you’re creating, both Web and client-installed.
• The social challenges of applying Continuous Deployment in your organization.
• The risks of doing Continuous Deployment wrong – and how you can avoid mistakes.
• The impact of Continuous Deployment on various job functions: testers, marketers, managers, programmers and other stakeholders.
• The prerequisites to Continuous Deployment.
• Practical advice and best practices to take steps toward Continuous Deployment today.

You can learn more, see the agenda and timeline, and pre-register at http://bzmedia.com/agility/ — please join us!

Z Trek Copyright (c) Alan Zeichick

Making sense of Salesforce.com

Salesforce.com intrigues me, and that’s a positive thing. The company keeps reinventing itself, and shows the type of innovation that used to be more common in Silicon Valley.

If you thought that Salesforce was in the business of hosting customer relationship management software, you’re living in the past. CRM barely scratches the surface of where the company is today. Sure, the company describes itself as “Web-based Customer Relationship Management (CRM) Software-as-a-Service (SaaS),” but when was the last time you heard anyone talking about the company’s CRM systems?

With Salesforce today, it’s all cloud, cloud, cloud. And chocolate – Salesforce is very popular with my family, since the company’s public-relations team bundles bags of chocolate with its press-release packets. Full disclosure: It’s delicious. Also, our advertising sales team uses Salesforce’s CRM system.

Chocolate? By sending out press packets with tasty treats, Salesforce keeps demonstrating that it’s an old-fashioned company innovating with the latest technologies. Very few companies mail out printed materials to journalists any more. Everything is all email and Web pages, webcasts and blogs. Yet there’s something appealingly archaic – positively 1980s – about this corporation.

Salesforce was born in 1999, launched by former Oracle sales executive Marc Benioff. Some analysts (myself included) formed an initial impression that Benioff – a brash showman not unlike Larry Ellison –formed the startup to tactically exploit the hosted CRM market focusing on small and mid-sized customers. A decade ago, that was a niche opportunity that Oracle was far too big to serve.

Benioff would gain some traction in the CRM space, we predicted, and then sell Salesforce.com within a few years. Probably back to Oracle, but if not, to SAP, IBM or another IT-industry giant. If Oracle was the buyer, Benioff would be well positioned as Ellison’s eventual successor at Oracle’s helm.

Yes, I still predict that Oracle or another large firm will acquire Salesforce. My estimate is that it’ll happen within five years. But while the company’s CRM assets are essential because subscriber fees drive substantial revenue, the real intellectual property will be in Salesforce’s cloud technology.

The revenue is growing nicely. According to Salesforce’s fiscal first-quarter results, covering January-March 2010, the quarter’s revenue was US$376.8 million, an increase of 24% over the same period in 2009. Subscription and support revenues made up nearly all of that, coming to $351 million; the rest was professional service. While that’s paltry compared to Oracle’s first-quarter 2010 revenues of $5.1 billion, it’s nothing to sneeze.

There’s no sneezing at Salesforce’s market cap either, which was $10.74 billion in late May, with a price/earnings ratio of 134.17. By comparison, Oracle’s market cap is $112.12 billion, with a P/E of 19.96.

What’s driving the market cap? The cloud. Of course, as a hosted CRM service, Salesforce has always lived in the cloud, even before term gained widespread currency. What distinguished Salesforce years ago from other hosted software companies – and linked it to much-larger cloud pioneers like Amazon and Google – is that the company realized that its hosting infrastructure and database engine could be leveraged by its customers for running custom software. Initially, most custom software was coupled tightly to the CRM service, but increasingly, the capability has taken on a life of its own and has attracted customers beyond Salesforce’s traditional installed base.

So, while cloud service fees are only a small part of Salesforce’s current revenue stream today, it represents the leading edge of the company’s innovation and attraction. To be blunt, that’s the only reason why we cover Salesforce in SD Times – because hosted CRM isn’t an area of interest to the typical enterprise developer or ISV software engineer.

Look at what Salesforce has done with the cloud. It’s gone beyond its simple Apex and VisualForce programming languages – designed to create add-ins to the CRM system – to a richer environment, called Force.com, that’s trying to appeal to all enterprise developers. The company moved into collaboration with its new Chatter system. It created an application store, AppExchange, to let developers choose from pre-written tools and services. It supports rich Internet apps using Flash, CSS and JavaScript. Most recently, the company has partnered with VMware to host a subset of Java EE within the cloud.

Balance sheet notwithstanding. Salesforce.com is no longer about CRM. To my earlier prediction that the company will be acquired with five years, let me add two more. First, its name no longer fits. I see a name-change within the next two years. And that stock ticket, NYSE:CRM – that’s gotta go. It looks like NYSE:CLWD is available.

Z Trek Copyright (c) Alan Zeichick