Cutting corners on testing turns SOA into DOA
December 27, 2011 Comments Off on Cutting corners on testing turns SOA into DOA
At WiseClouds, we help enterprises in many industries design, develop, test, and deploy Service Oriented Architectures (SOA). Over the years, we’ve observed a number of common traits among those SOA initiatives that have failed to live up to expectations. I’ll be describing these characteristics in a series of upcoming posts. For now, I want to highlight the dangers of trying to cut corners on SOA testing.
What do I mean by “cutting corners on testing”?
- Unrealistic schedules: QA is a chronic victim of improbable, overly optimistic timetables.
- Short staffing: In an era of tight budgets, QA professionals are the first people to get tossed overboard.
- No load testing: It’s amazing, but many organizations will go into production without ever subjecting their services to even basic load testing.
- No tooling: Many enterprises still run their tests by hand.
- No training: Educational budgets have been slashed, and this is directly reflected in the poor quality of delivered software that plagues so many organizations.
It’s important to remember that testing services is fundamentally different than testing traditional applications. For GUI-based applications, user interaction is fairly constrained, but anyone can send anything to a service. This means that testing (of business logic, data, exception handling, and security) must be much more rigorous for a service. Furthermore, services are often composed into larger applications, which further complicates testing.
With SOA, services play a much more vital role than any given siloed application. This means that a single service failure can severely disrupt operations. Even if all services are running normally, poor Service Level Agreement compliance can jeopardize the whole SOA initiative.
So if you’re trying to deploy a SOA-based architecture, recognize that testing services will be a larger and more complex effort than you’ve ever experienced before. And plan (and budget) accordingly!
Use encryption and the cloud to shield your data at the border
December 21, 2011 Comments Off on Use encryption and the cloud to shield your data at the border
When you pass through customs (U.S. or elsewhere), your data is more vulnerable than ever before thanks to modern data forensics tools paired with raw computing power. Whether you want to protect your personal or business data, check out this informative guide from the Electronic Frontier Foundation about how to defend your privacy at the border.
Our lives are on our laptops – family photos, medical documents, banking information, details about what websites we visit, and so much more. Thanks to protections enshrined in the U.S. Constitution, the government generally can’t snoop through your laptop for no reason. But those privacy protections don’t safeguard travelers at the U.S. border, where the U.S. government can take an electronic device, search through all the files, and keep it for a while for further scrutiny – without any suspicion of wrongdoing whatsoever.
Banks poking around your Facebook account? Yet another example of the danger of combining Big Data with Social Networking
December 19, 2011 § 2 Comments
I suppose that if something can be done, it will:
Banks have been curious about using social media to gauge risk for at least a year, said Matt Thomson, VP of platform at Klout, which calculates “influence” based on a user’s social media activity. Determining creditworthiness is not a core product of Klout’s, he said, but banks have approached the startup to ask about it. He wouldn’t name names. “It’s really like the who’s who of banking,” he said.
All the more reason to carefully consider what you share, what you say, and who you connect with. Assume that if it’s out there, everyone will eventually have access to it.
Don’t proof-of-concept past the close
December 18, 2011 Comments Off on Don’t proof-of-concept past the close
“Don’t sell past the close” is a time-tested chestnut of sales wisdom. It refers to the reasonable recommendation that once you’ve attained agreement from your prospect that they’d like to buy, it’s time to stop selling – even if you have other good stuff to tell them about your product or service. Instead, the moment has arrived for them to “sign on the line that is dotted”.
As someone who has led sales engineering teams for many years, I’m here to tell you that this guideline makes sense when it comes to the proof-of-concept (POC), too. Unfortunately, I’ve seen many situations where this rule gets violated, and the outcome is usually unpleasant for everyone involved.
For example, several years ago I was assisting on a grueling POC. The client had given us a series of seemingly insurmountable challenges to overcome. But with the help of engineering, lots of caffeine, ruined weekends, and lost sleep we managed to successfully complete the POC. All that remained was the client presentation, which went off without a hitch, much to the apparent delight of our prospect.
At this point, all that was necessary was to ask for the order. But that didn’t take place. Instead, the sales rep asked if the prospect would like to see anything else from the POC. The prospect answered ‘No’. The question was asked again – not once, not twice, but three times. On the third re-try, our prospect mentioned that perhaps his European colleagues – who previously had nothing to do with the buying decision – might enjoy seeing what we had done. In fact, they might even have some ideas of their own. Imagine what happened next.
To help you avoid unhappy endings like these, in a future post I’ll offer some humble suggestions about smoothly transitioning from the POC to the sale.
If you’d like to learn more about technical sales and sales engineering, click here.
Winning sales engineer trait #1: A competitive spirit
December 12, 2011 § 2 Comments
I’ve spent many years working as a sales engineer (SE) and then later leading sales engineering teams. Throughout my career, I’ve observed seven personality traits that separate the run-of-the-mill SE from the superstar. Since SEs are the great unsung heroes of the sales process, you definitely want to staff the best-of-the-best for this critical position. In this installment, I discuss why the most effective SEs possess an unyielding but properly targeted competitive spirit.
In a crowded market, the technical sales process is cutthroat: every deal is a brawl. Even though sales commission is typically only a small percentage of their overall compensation, the ideal SE takes a deep, personal interest in winning. This translates into a willingness to do whatever it takes to demonstrate the technical superiority of your offering. This might mean late nights configuring your solution or answering RFPs under tight deadline pressure. It also likely includes providing ad-hoc training to potential users and impressing executives of the need to choose your technology.
Unfortunately, I’ve encountered many SEs that are either too relaxed (“Why should I knock myself out? The product sells itself!”) or too competitive with their peers (“Why does that sales rep make twice what I do when I did all the hard technical stuff to win the deal?”). Incidentally, as an SE manager I found it easier to motivate the tranquil folks to step it up a bit than to get the SEs with commission envy to focus on their jobs.
Want to read more about technical sales and sales engineering? Click here.
Technical marketing mistake #3: Cramming too much information into a single piece
December 10, 2011 § 1 Comment
At Think88, we enjoy helping our customers overcome all sorts of technical marketing challenges. In the first post of this series, I summarized some of the most common oversights that we encounter. In today’s installment, I explain why it’s so easy to fall into the trap of overstuffing your marketing collateral.
First, it’s important to realize that there is no single culprit for this predicament. Instead, there are at least five reasons why we see excessively large content:
- Messaging issues. If your narrative is unclear, your collateral will reflect this unfortunate state of affairs: it may take 15 pages to say what could normally be conveyed in five. On top of that, it’s not uncommon to run across bloated pieces that somehow manage to contradict themselves!
- Budgets. Money is always tight, and there may not be funds available to create a complete collection of well-designed, focused pieces. In response, many companies have tried forcing a single document to cover all the bases. For example, I frequently come across technically oriented whitepapers that must somehow incorporate high-level customer success stories aimed at executives.
- No marketing roadmap. I discussed this common problem in an earlier post. In short, not having an overall plan inevitably leads to reactive, poorly conceived content. And badly planned materials tend to be oversized.
- Tight schedules. In today’s world of overstretched marketing teams trying to produce content to help drive sales, it can be alluring to merge two or more disparate pieces in order to hit aggressive deadlines.
- Lack of a methodology. Each piece of technical marketing collateral should be the end result of a logical, well-defined set of procedures. Failing to follow a consistent approach almost always results in content that’s double or even triple the size of what was specified. In fact, I’ve even seen White papers that were originally sized at six pages balloon to nearly 30 pages!
Regardless of the specific cause, the end result is inflated, poorly conceived material that wastes time and money. What’s worse is that these investments fail to pay off and win you new business.
The 7 habits of highly effective sales engineers
December 8, 2011 § 9 Comments
Selling complex technology frequently relies on the efforts of the technical pre-sales team. Surprisingly, given the importance of this role, it seems that every company has a different name for these professionals. Some of the most common titles include:
- Sales engineers
- Systems consultants
- Sales support analysts
- Systems engineers
I’ve been a sales engineer, and I’ve led my share of sales engineering organizations. Based on many years of experience, I’ve found that there are very few people out there who possess the special blend of talents necessary to flourish in this challenging but potentially lucrative job. Here’s a list of those traits along with links to posts about each one:
Many sales engineers spend a considerable amount of time working on proof of concept (POC) tasks. If you’d like to learn more about this aspect of the job, be sure to check out some of my other blog entries.
If you’re curious about other technical sales and sales engineering subjects, click here.
Using the Amazon cloud for Dev/Test in 5 easy steps
December 6, 2011 Comments Off on Using the Amazon cloud for Dev/Test in 5 easy steps
Recently, I explained why the software development and testing process (Dev/Test) is a fantastic use case for cloud computing. At first glance, getting started might be a bit daunting, but it’s really quite simple.
- Determine whether you want to use the cloud for development, testing, or both. If you’re building an Internet-based solution (with or without a user interface), the cloud is particularly adept at letting you quickly set up distributed load tests. These tests – which can be provisioned globally – provide much more accurate metrics about the true response times that your users will experience than if you tried to run load tests from a single location, usually within your firewall!
- Identify the cloud that you want to use. I’ll describe the major cloud computing platforms in a series of upcoming posts. For now, the Amazon cloud – specifically Elastic Compute Cloud – is a great place to start, especially for Dev/Test.
- Assuming you’ve chosen Amazon, set up a single instance of a virtual machine either on your computer, or select from one of the hundreds of pre-configured Amazon Machine Images. On the other hand, if you’ve created your own virtual machine you can then upload it to Amazon.
- Once you’ve set up your base virtual machine and it’s running on Amazon, add all of the ancillary software and technology necessary to complete your Dev/Test environment. These can include:
- Software development tools
- Database engines
- Application servers
- Web servers
- Security software
- When your virtual machine is fully and properly staged, you can easily clone it as many times as you need.
Going forward, if your Dev/Test cloud experience is positive, consider implementing specialized software that automates many of the manual steps that were necessary to create the cloud-based environment. I’ll describe this specialized software in a future posting.
Technical marketing mistake #2: Failing to consider ROI
December 4, 2011 § 3 Comments
At the start of this series, I listed some of the most common technical marketing oversights that we see at Think88. In this installment, I describe why it’s so important to consider return-on-investment before developing any marketing collateral.
In far too many companies, leaders and rank-and-file alike are convinced that the sales department exists to bring in money, and the marketing department exists to gleefully spend it. This perception is a gross oversimplification, and is largely unwarranted in most cases. However, there are certain situations where this observation is justified. Marketing collateral is one of those scenarios, but there’s plenty of blame to go around:
- Vocal salespeople who clamor for something – anything! to give to their prospects.
- Marketing executives eager to satisfy these demands.
Both sales and marketing are far too reactive in these cases. This is very unfortunate, because creating this collateral can be expensive, time-consuming, and starve other (often more qualified) initiatives of necessary resources.
Instead of making knee-jerk investments in new collateral, it’s much wiser to first subject any potential materials to a rigorous ROI assessment. Of course, ROI should also be a factor in the marketing content roadmap that I described in an earlier post. I’ve found that the most effective marketing collateral is produced after analyzing weak points in the sales cycle, and then creating materials to plug those gaps. Frankly, there is no substitute for ‘riding along’ with salespeople, or experiencing the sales cycle as a prospect would. With proper research, it should be possible to quantify – or at least estimate – the financial impact of any marketing collateral investment.
What does one of these ROI calculations look like? I’ll provide a real-world example in a future posting.
Are you at risk from escalating cloud storage costs?
December 2, 2011 Comments Off on Are you at risk from escalating cloud storage costs?
The damage wrought by the recent Thai floods has caused a significant run-up in disk drive prices. I described this situation in an earlier post.
While these increases have primarily been confined to the consumer marketplace, there’s a good chance that they will soon hit business users, too. Even though some of these wrecked factories are coming back online (or being moved to other locations), rising energy costs, soaring demand, and a shrinking number of disk drive suppliers can only exacerbate the impact of these potential price increases. Unfortunately, storage price increases will be counter to the trend – largely driven by Amazon – of steadily decreasing costs for commoditized storage.
Naturally, cloud is a voracious consumer of data, so just about every cloud solution may be impacted. But businesses are particularly at risk in two key cloud scenarios:
1. Big Data. More data than ever is being captured, managed, and analyzed. The cloud has been a natural fit in this situation: in a preponderance of cases, it’s more cost-effective and efficient than building internal infrastructure. An entire ecosystem is growing around cloud-based Big Data, with cloud-based integration and analytics just two examples of these new storage-hungry applications.
2. Cloud-based backup. In the past few years, enterprises have been adopting cloud-connected storage in lieu of onsite backup. There are many compelling reasons for this transition, such as strong vendor SLAs, economies of scale, and reduced labor costs. If you’re curious about this topic, take a look at the paper for i365 we wrote at Think88 .
Both of these scenarios consume enormous amounts of storage, and are highly sensitive to sudden, dramatic increases in storage costs such as we may experience.
Whether price increases are sudden or gradual, what should you do? I’ll explore that topic in an upcoming posting.
rdschneider 