I’m proud to say my old company pulled a two out of three and wonthe SC Magazine best endpoint solution of 2008 award again at RSA. They werealso finalists in three other product categories, products all of which I canbeamingly say I had a hand in creating. What’s different about the SC Mag awardsfrom many others is these awards are voted on by the readers, both users andfollowers of what’s happening in the market. While others have suffered the percentages of the startup business, othersmarch on to live another day.
The NAC market has been a tough slog, one of those markets that’s experienceda great deal of attention and hype. None the less, products have to provethemselves, no matter how shiny and exciting they seem to be or how big theanalysts say the market will be in five years. NAC’s not an easy problem tosolve and I’m proud the StillSecure has stuck with it to continue leading themarket against heavyweights like Cisco. Frankly, this market could be all sownup if Cisco had purchased the right product several years back. (And guess whichproduct that would be, I say tongue in check. 🙂 )
I always enjoyed the claims other startup vendors would make about "beingthere first" and owning "xx" double percentages of the market, when in fact Iwas part of creating one of the first purpose-built NAC products from the groundup before NAC was even a term. The idea came from customer experience interviewsI was doing for a completely different product idea, and up popped the customerproblem that later became a NAC product. I still remember the excitement ofsharing the idea with the team. Serendipity I say.
Net-Net, congratz to my old team on the awards and the continued marketsuccesses. The award is just one of the ways to visibly see all that hard workpay off.
One of the things I was interested to investigate at this week’s RSAconference was whether SaaS and cloud services (compute, storage, etc.) hadentered into the horizon of the security market. The answer is easy. NO. Noteven close. Security doesn’t get where the software market is headed and we needto get after it now.
There’s two perspectives to assess this from; What are security vendors doingto build products for the On Demand, SaaS and cloud computing world we arerapidly moving into? And, are security vendors moving into offerings based inthe cloud themselves? Again, with a very few exceptions this isn’t somethingthat even appears on the radar screen of RSA exhibitors.
Regarding the first question, the themes of RSA is still very much in theworld of data protection, data lose prevention, network access control, USBstorage containment, and infatuation with the latest 10 gigabit doodad appliancebox. Maybe its too early for security in the cloud to be the issue of the day -security in the virtualized world isn’t even a topic for conversation. At leasta few smart people like The Hoff are playing virtualization MythBuster, keeping ushonest about what challenges and interesting problems need to be solved asvirtualization continues its march into data centers, storage and applications.
How about those offering their security wares via the cloud? Clearly Qualyssuffered the arrows of being an early SaaS security vendor but crazy frenchman Philippe Courtotis still riding high knowing the SaaS market is doing well within other segmentsof IT and security will eventually get there. But they are still pretty much a lone SaaS delivered security player.Another company doing SaaS delivered security products is Alertlogic, providing logmanagement, analysis, and compliance software On Demand. I spent some time withAlertlogic CTO Misha Govshteyn, someone who has been through the transition toSaaS and learned the lessons needed to scale a multi-tenant product. (Misha’s asmart guy, btw. You sooooo need to start blogging dude!)
I think Misha’s approach also shows some insight into where we’ll see SaaSenter into security – in the mid-enterprise and SME markets. Those are buyerswho don’t necessarily have access to full time security, storage or otherspecialized resources. They also are more accepting and can get over theperceived privacy concerns that surface when considering an On Demand service,especially private companies who don’t fall under SOX compliance. I stillrecall selling against Qualys and pushing the issue of your vulnerability databeing stored in the cloud – many saw the advantages and convenience from an OnDemand offering, and for yet many others it was a no-op. But mid-enterprise andSME’s adoption of On Demand software solutions could show us this is wheresecurity will make it’s first SaaS market beachhead.
As security professionals, we can’t wait for the market and vendors to catchup. We need to be creating the security dialog and debates about virtualization, on demand and cloudbased services. While Microsoft may be trumpeting the call of End-To-End Trust,trying to get the other elephants to tap dance with them, we’ve got to working ahead of the curve onthe tough problems, vocalizing the security needs while services are being created and moving intothe cloud, not after. I’m glad that Hoff, Misha and others are thinking ahead of thecurve.
I was talking with a friend and fellow musician JasonMendelson last week and the topic of software delivery came up during ourconversation. Jason knows that I have a lot of experience leading product teamsto bring software products to market. I’ve learned a ton about shipping productsand if there’s a mistake you could make, well, I’ve probably made it at one timeor another, and sometimes more than once.
When it comes to shipping software, delivering software releases on time isone of those seemingly elusive concepts that most everyone desires butfrequently don’t achieve. (I actually believe delivering on time is a learnedbehavior, but that’s for another blog post.) Quality can also be an elusivegoal, especially for startups who may not have a lot of experience workingtogether as a team, or are under huge pressures to deliver releases. Dialing inon the winning customer experience and product feature mix is another passion ofmine that’s vital to creating great products. I could blab on about all thesesubjects but a philosophy of mine about creating software caught Jason’s ear;"Love developers, and trust QA".
These days I’m frequently a coach or mentor to someone who is leading aproduct development effort, sometimes for the very first time. Frequently they’vecome up through the developer ranks with a lot great experience that sets themup for new opportunities leading product development efforts. I always try to helpthem understand a key lesson I’ve learned; while I love software developers and theinnovative work they do, I trust most what QA software testers tell me about thequality and completeness of a software release. I’ve advised more than onedevelopment manager that even though you may not always like what QA has to say(you may even dread hearing it), you need to hear it straight — they’re lookingout for your best interest.
Software developers, engineers, artists, or whatever job title you chose tocall them, are a loveable, creative, quirky, smart bunch of people who have totry and envision how best to build software that embodies the vision and needsof the business. They are a great group of people and I love hanging around themand being part of the team. Sometimes product developers get great directionand it seems more often than not a lot is left up to their interpretation whencreating a new product. Hopefully someone is giving them great input about thetarget user personas, product requirements, user interface design and help withkey decisions about the product architecture and which options help the businessmost achieve its goals.
But inevitably, releasing software products can become a grind. What’s afterthis release? Another release. And after that, another release, etc., etc. It’shard work and developers are frequently in a situation where they have to be asproductive as possible, inevitably making decisions that could make or break theproduct’s quality, feature set and success in the market. Developers have a lotof competing needs to balance and are often asked to make decisions without thetime or input that might help make that decision the best one. That’s where thedevelopment leader, manager and/or product manager comes in, btw, making surethe development team grasps the impact of various options and decisions, andalso that business leaders understand consequences of certain demands whichcould impact the product or the business. But that’s why I love developers –with all these things to consider, the best plow through and get the rightthings done to create great products.
It’s also why asking a developer questions like; Is it done? Is ittested? Does it work? Is the quality better? Did we find all the problems?Is this going to satisfy what our customers asked from us? Is it ready to shipto a customer? I could think of a million questions that while I’ve askeddevelopers, I know I may not have gotten a completely accurate picture based ontheir answer. In many ways developers are too close to the problem, head deepinto creating the solution we need. One developer is likely only working on oneportion of the software release, and more work is required to integrate and getall the elements of the full release working together. That’s why everyone knowsthat to get quality software you shouldn’t rely just on developersthemselves testing their own code. That’s also why I trust developers, but Itrust QA engineers more when it comes to understanding the true state of asoftware release.
QA guys (guys and gals) tend to think very differently. Their job isn’t tocreate stuff, it’s to break it — anyway they can. Because if they don’t find aproblem, that means a customer will. And some people just have a real knack forit. The best are also very detail oriented, don’t assume anything and watch tomake sure nothing gets by them. The best QA engineers are also very good abouttracking results, creating thorough test plans which get a lot of scrutiny byeveryone including the developers, automate testing, and understand the value ofmetrics and how this can raise the learning and skill of the entire team atreleasing quality software on time.
QA engineers are also the first point in the process where someone isactually trying to use the software. Functional testing doesn’t always drivethis out, but scenario or use case based testing can make a really bigdifference. Using your own products in your lab or by your IT staff can also bea great way to get real usage feedback, in addition to customer experiencetesting of course. Testers also have great suggestions about the product. Theycatch nonsensical error messages, product inconsistencies, or encounter areas ofthe product that are hard to use. Most importantly, QA engineers know they arethe last in line to judge the release, and take their responsibility veryseriously when it comes time to say whether they think the release is ready ornot. QA engineers aren’t just critiques, they want to ship the product too. Theyjust don’t want to be embarrassed, taking it personally when bugs or qualityissues escape the testing process and are found by customers.
I also believe the effectiveness of any QA team or department is a directreflection on their leadership, including the visibility, importance and voicegiven them in the product development process. One of the things I’ve learned todo as a development manager, VP engineering or CTO is to hold my own weeklymeetings with the QA team. Development managers are welcome if they like too.This is our time to talk about release testing, QA processes, metrics, testplans, lab needs, improvements, suggestions, issues escalated from support, and– most importantly — give QA a voice directly to the top of the organizationto say whatever needs to be said, good news or bad.
I hope this explains some of my learnings around the philosophy, lovedevelopers, and trust QA. The fact of the matter is that I love them bothfor what they bring to product development, and I trust them both too. But Irely on their skills, experiences and judgment differently, and at differenttimes, bringing the best strengths of both to release great software products.
We have a number of job openings at my SaaS application performance management software company, Absolute Performance Inc.
The following positions are open:
Send your information and inquiries to firstname.lastname@example.org. (And let them know you read about it on my blog.)