IT organizations often make difficult choices depending on business demands and budget constraints, but in the realm of software testing, the standard approach didn’t allow for much choice. Application developers, architects and even IT operations staff tasked with testing applications against real world conditions have often found themselves debating which could be sacrificed – cost, quality or schedule – when working to deliver new applications.

“Traditionally, you might have had the luxury of moving one or maybe two of the needles in the right direction, if you were really lucky, but being able to move all three just wasn’t an option,” says Burt Klein, senior customer advisor at ITKO, a CA Technologies company, and former Bank of America Performance and Resiliency Executive. “All three – speed to market, cost and quality – are critical for the process, but testing to accommodate all three just wasn’t possible.”

That is, until service virtualization technologies opened up a whole new world of options and helped testers stop undergoing a painstaking “Sophie’s Choice” of sorts with each application.

Service virtualization is a capability offered in technologies from a handful of vendors today that allows application testers to remove the constraints from their software development lifecycle. The technology lets architects virtualize an environment and the application parameters to avoid using sparse physical resources not readily available for testing purposes. The virtualized environment can more accurately emulate a production environment under different scenarios and enables application developers to better design their code as well as help architects plan for capacity. More important is service virtualization’s ability to let testers configure their virtual test environment to deliver applications at lower costs, with improved quality and at a faster time to market.

“Service virtualization is part of the larger market we define as lifecycle virtualization, and it is the element that really helps IT to manage the classic ‘cost, quality, schedule’ triangle,” says Theresa Lanowitz, industry analyst and founder of Voke Inc. “For years, applications would be delivered with at least one element off, whether it be over cost, late to market or lower quality. Service virtualization eliminates the constraints the test group has, lowers costs and helps to deliver better quality software.”

The market for service virtualization technologies is young, but heating up, according to Lanowitz, who says she has been tracking it since as early as 2005. CA Technologies acquired ITKO in the summer of 2011; then soon after HP started to renew interest in its own service virtualization product of the same name, HP Service Virtualization. IBM in January closed its acquisition of Green Hat, a provider of software quality and testing solutions for the cloud and other environments.  Now ITKO’s primary competition before the acquisition, niche player Parasoft and its Parasoft Virtualize, has to compete with three of the largest software vendors in the world.

The interest in the technology isn’t entirely surprising, and not just because some of the big players are starting to include it in their portfolios. With very public technology failures, think retailer Target’s Web site crashes and BlackBerry provider RIM’s network outages, IT leaders and application organizations are more aware than ever how poor software could impact their brand and ultimately hurt the business’ bottom line. In today’s environment, delivering low quality software could break a business, but traditional approaches to testing also require capital expenditure upfront and slow time to market.

“With so many catastrophic software failures in the last year, headlines are being written about software, CEOs are resigning, stocks are tumbling,” Lanowitz says. “People are realizing they need to manage that triangle better and deliver software with a level of risk that is palatable versus the unknown.”

Do you Tweet? Follow Denise Dubie on Twitter here.

Is it possible to replace a living, breathing enterprise architect with a do-it-yourself architecture kit? How about with blueprints, formulas or other design templates?

Companies have been known to take stabs at it, and not without success. The Java BluePrints series of documents in the 1990s enabled bare bones, agile teams at small start-ups to build the online economy. Today, Oracle maintains them, while Microsoft offers its own set of blueprints, the Software Factory methodology, whose concept is to apply working patterns of software architecture, development, testing and release to sets of problems that cookie-cutter development teams can solve. CA Technologies offers blue-print papers and videos in the areas of data modeling and architecture, as well as virtualization and the cloud. And other vendors also have their own approaches.

These are all useful goodies for a number of reasons. But their usefulness increases, I believe, when an enterprise architect is onboard to oversee efforts to deploy these tools to automate software architecture and design processes. What the architect brings to the picture is everything from an understanding of time to market, cost and ROI considerations, to enterprisewide skill sets and global deployment experience. And let’s not forget what enterprise architects know about security, creating flexibility for tomorrow's desktops and mobile devices, and accommodating the growing desire to be green (e.g., energy and heat efficiency, recycling and so on). This all leads me to believe that a do-it-yourself architecture strategy probably won't work for all cases, all problems and all companies.

Patterns: The Enterprise Architect's Ornaments

One important thing that do-it-yourself kits or blueprints may not always account for are architectural patterns. If an enterprise architect wore medals, they would take the form of architectural patterns he or she helped define. An architecture pattern is a schema for a software system and its overall structure, whereas a design pattern is a more detailed, specific refinement that outlines deeper relationships between components. The Open Group has been overseeing work on standards for architecture patterns as part of The Open Group Architecture Framework initiative. The Object Management Group (OMG) has also done some work here. Together, they’ve defined patterns for service-oriented architecture, event-driven architecture, model-driven architecture, resource-oriented architecture, directory services, security, transactions and the list goes on.

According to the Open Group, patterns are a way of putting the building blocks of architecture into context so that they can be reused and applied in the right ways. For instance, patterns should clearly define how and when to use the building blocks, the trade-offs involved, and other related caveats or prerequisites. For each pattern, it’s recommended that you specify at least the following:

• The problem: when to apply the pattern
• Context: preconditions for the pattern, and other assumptions (i.e., multi-core servers)
• Constraints: considerations in terms of security, cost, efficiency, performance, bandwidth, power consumption, openness, portability and so on, as well as how trade-offs are made between them
• Proposed solution: in terms of implementation and deployment
• Example: where possible, provide a real-world example of the pattern at work
• Related patterns: often patterns build on, or work in conjunction with, other patterns
• Alternatives: a single solution is rarely the only solution; list alternatives and when to choose one over the other.

Some organizations have made quite a bit of progress defining architectural patterns that apply to specific problem domains. For example, the Open Geospatial Consortium , in conjunction with the OMG, has defined patterns that actually apply to a broader set of problems. These include patterns for geo-data storage and access, generic SOA and Web services, interoperability through data standards, data-binding models and so on. Martin Fowler’s book, Analysis Patterns: Reusable Object Models, and Fowler’s site are also good resources for more information on the subject.

Software Architecture with Math

If we could use mathematics to prove the value of the architectural patterns that enterprise architects define before the coding process begins, the case for their oversight of do-it-yourself tools gets even stronger. Other engineering disciplines, after all, use math extensively during the design phase, including electrical engineering, aeronautical engineering, mechanical engineering and so on. It’s the math that gives engineers like my father the confidence that his designs will fly — literally! Beyond basic math used to calculate memory requirements, server scale and database sizes, I’m not aware of anyone using math extensively in practice to define or at least prove their enterprise architectures, though. So if you’re actually doing this, or know anyone who is, I’d love to hear about it.

But I digress. What it comes down to is this question: Even if you could always rely solely on kits and patterns to the exclusion of enterprise architects, should you always? I think not — or at least, not if you care about customer satisfaction. It takes careful consideration to craft solutions that are not only profitable, but also make our customers continually happy (which, by the way, goes a long way toward driving profits).

So I think our jobs are still safe, and that we should instead embrace patterns and measurable processes. In fact, being part of the continuing contribution to the definition of patterns and other verification processes can help ensure our long-term success.