The ITKO Blog: Service Virtualization and Application Lifecycle Optimization - CA Technologies

How Soon are BPM and SOA Merging?

I just joined in another fast forum on eBizQ with a good question posed by uber-SOA blogger Joe McKendrick:

"There has always been a huge cultural divide between the business folks, who felt that they own BPM, versus the IT folks, who own the architecture or the technology architecture, which would be SOA. So do you think BPM and SOA are going to merge, and if so, how soon?"

Judging by the rapid-fire responses alone, I can tell this strikes a nerve with lots of the experts. I can certainly understand the concern about yet more redefinition and lumping together of terms that aren't really related. However, I don't see this confusion as a problem in practice as much as others might.

In our experience the most successful SOA implementations are being driven at a high level by a BPM process, even if we aren't talking about directly connecting a process engine with a SOA registry for instance. It isn't going to happen overnight, but the SOA implementations without business process orientation will die out and be replaced by business-process driven SOA, which the business can justify budgetary considerations for.

Anyway, yet another good conversation and I invite you to take a look.

Virtualizing Over-Utilized Systems: Part 3 - Common Bottlenecks

This is the third post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this installment, we will break off one of the big 3 challenges of Over-Utilization: the "Common Bottleneck" that constrains multiple teams attempting to develop, test and integrate enterprise software. Conventional virtualization can break under the strain of attempting to eliminate these bottlenecks, as they are often too large or too complex to be replicated on a given VM.

[Nifty picture I took in Tierra del Fuego, Argentina - constant 50mph west wind]
Well-respected enterprise application design patterns are actually causing software development lifecycle bottlenecks where numerous teams rely on a key system or technology.  These systems become new constraints to development and testing, and push the original goal of time and cost savings further out of reach. Here's the key points where we find Common Bottlenecks:

Design of Core Services – In some Enterprise IT organizations, a few key services are so fundamental that they are used in a majority of projects.  From the standpoint of re-use this is exactly what we were looking for, but while designing, testing, and running our applications, these core services create dependencies which slow teams down, because unlimited access for software teams is often considered too risky.

Examples of core services include:

o        Customer/Account – An example of one of the most commonly created core services, so there is a single place to get customer records.

o        Billing – Customers don’t want to receive multiple bills from the same vendor, so this is also a common core service to create.

o        ERP System – Especially for internal purposes (HR, Financials, etc.) companies adopt a single platform and require everyone to integrate.

Customer Example:

A large North American Telco had issues in replicating their core SAP system across a myriad of environments.  Only 3 of 7 non-production environments have an SAP instance they can use. Also the training system does not have a copy of SAP, so they cannot train their Customer Service Reps on applications that integrate with SAP until they are rolled into production. The result is that bugs are not found until it is too late to repair them and still deliver projects on time.

Data Warehouse – Numerous services depend upon the same set of data, especially for account information. In order to make data available for development purposes, this data usually comes from a production “refresh” as needed, and is put into pre-production.

• Data setup & teardown – Managing relevant, stable and secure data in the environment can become a huge drain on team productivity, sometimes consuming 60% or more of testing time.
  
• Data volatility - When data is treated as community resource for multiple development and test teams, other teams can pollute the test data (for instance deleting a key user required for your regression test suite).
• Secure data - In addition, live data must be suitably scrubbed or “desensitized” to protect unauthorized tester access to account information, which is a time-consuming process.

Cloud Services – Saving money by using external service vendors on a pay-per-use basis is great, but not when they get in the way of being able to do testing and development. This means we have another team we need to coordinate with from a data standpoint (test accounts, etc.) and potentially we are charged a usage fee when calling on these services.

Incremental fees are fine if they are a part of a revenue-generating customer activity in the live application, but they are a problem when they become a development cost to the business. For instance, how can we avoid skyrocketing fees for load tests that include a cloud service, or analyze negative ramifications if the cloud service doesn’t meet their SLA?

Customer Example: Insurance in the Cloud

A regional insurance company needed to be cautious about how they run their performance tests for adding new auto insurance customers. Among other things, the new client application performs a credit check and runs an automobile history report.  During one of their routine load tests against the new app, they sent actual requests for automobile history reports to a third party, resulted in a $15,000 access charge. After this unexpected charge they simply chose not to test any third-party service calls until they reach production.

Next installment: Limited Capacity and Other Inefficiencies

 

Virtualizing Over-Utilized Systems: Part 2 - Under vs. Over Defined

Here's an introduction to the concept of "Over-Utilization" in terms of Virtualization of software and services. This and 4 more posts in this series will cover concepts detailed in a recent whitepaper by Ken Ahrens and Jason English, "The Next Frontier for Virtualization: Over-Utilized Systems", downloadable on iTKO's site.

Are we Virtualizing the Path of Least Resistance?

Hardware virtualization technology is now par for the course in enterprise IT infrastructures. Enterprises can realize rapid cost savings through the use of hardware virtualization to reduce server proliferation, consolidate desktop environments, and run numerous apps with a smaller combined hardware footprint. The key value espoused by leading virtualization vendors (such as VMware, Microsoft, Citrix, etc.) is making better use of “under-utilized” servers that do not require dedicated system resources.

But what are we supposed to do about the kinds of systems that are not good candidates for hardware virtualization?  What about the critical over-utilized applications that create bottlenecks among teams that need access throughout the software development and testing lifecycle?  Hardware virtualization has a much less compelling value proposition in this scenario. 

A strategy to apply in this case is the use of Service Virtualization (SV) to reduce multiple team dependencies on over-utilized systems, allowing them to work in parallel. Let's take a look at the utilization patterns encountered in enterprise IT environments, and which type of Virtualization (Hardware virtualization, Service virtualization, or a combination of both) should be applied to receive the greatest value.

Defining Utilization Patterns

For simplicity, we’ll just categorize enterprise systems into one of 3 categories of utilization and figure out what this means from the standpoint of virtualization:

• Under-Utilized systems have low CPU/memory/disk usage, or otherwise there is significant capacity on the system to run additional applications.
  
  
• Over-Utilized systems may have high CPU/memory/disk usage (for instance a transaction mainframe or multi-terabyte system of record), or perhaps they are services outside of the control of the Enterprise, with usage limitations or per-use costs (such as third-party services, cloud computing, SAAS, etc.).
  
  
• Properly Utilized systems, which are working optimally, and can be left alone.

Causes of Under-Utilized Systems:

• Infrequently Used – Low usage does not necessarily equate with low business value (as a rarely used service could process very expensive orders), but it does usually mean that the system could get by with less processing power during those hours when it is not used.
• Excess Capacity – For teams that didn’t have the time or resources to do significant capacity planning tests, many architects hedge on the safe side of providing too much capacity rather than too little.  At some enterprises this creates a capacity glut of servers and bandwidth.
• More Efficient Software – Let's give developers and testers some credit, they can build very robust software, or perhaps optimize the software performance and use of system resources over time, to get their services to run very efficiently.
  

In many of the above cases of under-utilization, conventional Hardware Virtualization approaches have proven successful in eliminating excess capacity by consolidating servers and applications. Performance testing and benchmarking can help identify good targets for hardware virtualization, but do these under-utilized systems represent the greatest cost and risk to IT?

Causes of Over-Utilized Systems:

Why would systems end up over-utilized and unable to handle ongoing transactions, particularly in supporting software test and delivery teams?

• Common Bottlenecks – Literally this means that many teams depend upon access to the same constrained system or service.  Usually this is due to a design decision early on, but in shared environments, the usage pattern is hard to predict when a service is called upon by many customers, and other teams’ services in unplanned ways.
• Limited Capacity – More likely for services that have been in production for some time, it’s not hard to imagine that new technology teams get hardware upgrades, while older technology gets left in the dust. Or the production environment may be re-built, but pre-production servers needed by development and testing may not get the same upgrade due to budget constraints.
• Inefficient or Unscalable – Unfortunately, technologies and platforms may not provide the scalability initially advertised.

While we hope that responsible architecture, integration and deployment strategies will result in proper system utilization, it typically doesn’t work out that way in today’s heterogeneous, distributed application environments. There are simply too many variations in how the systems are connected and used, and too many components in the environment that aren’t under one team’s control.

Next post in this series: Outlining the Challenges created by Over-Utilization of key systems.

Virtualizing Over-Utilized Systems: Part 1 - A new concept

One of our really savvy Architects Ken Ahrens recently had an Aha! moment while visiting a financial institution. The customer was asking how our definition of virtualization was different than the more commonly known types of hardware and desktop virtualization already happening in most IT shops.

That's when it hit him: You are already familiar with virtualizing under-utilized systems -- servers and specific desktop OS configurations that don't need as much dedicated hardware and capacity as expected. That's certainly useful for trimming some IT costs.

But what about the over-utilized systems -- those critical and costly applications, services and mainframes that are just too big, or too remote to be replicated on a VM? The over-utilized systems represent a lot of cost, and big constraints for our ability to deliver and test software. Surely there must be a way to virtualize these too?

Well after a lot more analysis on this topic with Ken, we have a new iTKO whitepaper, "The Next Frontier for Virtualization: Over-Utilized Systems," that addresses how companies can identify and start to virtualize these over-utilized systems.

We'll be posting some additional notes and excerpts from the paper explaining the concept here in the future as well.

HP to Resell LISA Virtualize - The News

iTKO and HP recently signed an agreement which created a significant piece of news: "iTKO's LISA Virtualize Software to Be Resold by HP to Reduce Testing Costs and Accelerate Time to Market for Modern Applications"

There is a lot of value to capture here. In every major enterprise IT shop we go into, we find that there are a growing number of constraints to testing created by what the industry is calling "modern apps" -- highly distributed, componentized, loosely coupled applications that no longer reside within a company's four walls. Call it SOA, SaaS, Cloud, pull in BPM, legacy migration, etc. and you have a recipe for quality chaos.

Many of the systems we need for software development are supporting live transactions, contain critical customer data, are inaccessible to the team, and perhaps even charge significant fees for each access. IT shops can literally spend 40-60% of their development time trying to configure test beds, code "test responders" or stubs of needed services, and massaging data into and out of the system before and after each functional and performance test. Faced with these constraints, companies simply do not test as early or often as they should, and quality and performance suffers.

We are familiar with virtualizing servers and desktop apps, but what about the above highly constrained pieces that make up a modern app? These systems are resistant to hardware virtualization, but they can definitely be virtualized behaviorally with LISA, so now HP test and development team members can get access to them on their terms.

This functionality is complementary, but very different from the well-known practice of hardware-based virtualization, in that it is not imaging a hard drive or desktop OS as a VM. Instead it is an automated software-based solution to virtualize the behavior of downstream dependent systems, services, data and components that may not be under a team's control. There are huge benefits to be gained in terms of faster delivery cycles, fewer production errors, and much lower cost and effort of managing test environments, coding stubs and managing test data.

It's a fact that there are more performance and functional testers with HP's testing software installed than any enterprise solution on the planet. And every one of them could stand to benefit from having robust test environments that are readily available to work with. We think this is great news for the software lifecycle when the world's largest technology companies are working to solve some of the largest problems out there.

Stay tuned for more news about this partnership here.

Recent coverage of the announcement (in progress):

• Dana Gardner in ZDnet: HP Partners with iTKO on LISA Services Testing Suite for SOA, BPM
• Virtualization Journal: We particularly liked an article from Maureen O'Gara: "HP's Got a New Girlfriend Called LISA"
• Vance McCarthy in IDevNews: "HP To Sell iTKO LISA for Virtualized SOA, Apps Testing"
• eBizQ "iTKO's Virtualize Software to be Resold by HP"
• StickyMinds.com News
• Official iTKO release on BusinessWire.

How the Recession Affects CIO Budgets

Interesting article in a recent Forbes magazine. In "IT After the Recession," Ed Sperling interviews Gartner's Mark McDonald about research conducted with a sample of corporate CIOs about the economic impact of the global downturn on their budgets. Not surprisingly, 90% of the answers did say they had reduced budgets this year.

The report points out a couple interesting trends that call for virtualization on a greater scale in my opinion. The first is in the management of server environments, an area that is only becoming more constrained. The survey notes that budgetary cuts are focused on reducing third-party and contractor support, or renegotiating support contracts.

That is a good sign compared to knee-jerk layoffs to meet budget goals, but it still will call for a lot more automation and reduction of costs wherever they are available. Hardware virtualization will remain a top priority for CIOs, given the need to "do more with less" with every technology asset, as well as the ballooning amount of storage and processor power required to handle complex workflows.

Second, in the article McDonald points out a discontinuous trend that calls for more innovation: "There traditionally was a relationship between transaction volume and revenues. As revenues grew, so did transaction volume. Starting about four-and-a-half months ago, CIOs began reporting that relationship is broken. Transactions continue to grow even though revenues are flat to down. In banking, for example, balance inquiries are one of the fastest-growing transaction types. It doesn't generate any revenue, but it does generate a lot of work."

That is a stunning report, and one that we have seen corroborated in banking/insurance, travel, defense and other industries - more transactions no longer means more revenue. Today, both customers and business partners expect 24/7 any where, real time data from the enterprise -- in fact a companies' ability to provide good real-time data such as order status, tracking, pricing, balance, etc. are key differentiators in customers' minds.

The same also applies to development and testing transaction volumes -- non-revenue generating  transaction fees, bandwidth, and data setup while working to build functionality, can increase much faster than the revenue the business functionality supports. In these cases, Service Virtualization is a valid approach, since you have systems that are either unavailable or not under the teams' control for Hardware Virtualization.

We hope as the CIOs start to employ these leaner practices during the downturn, they will come out stronger in the years to come.

Definitions of the Cloud Abound

We have been writing quite a bit here about how the public and business sector are defining the cloud. Here is another useful look at the cloud and how it can be positioned in the range of IT options. Ruben S. Montero provides a quadrant for sorting things out.

The two dimensions he espouses are local vs remote (where are resources located?) and physical vs. virtual (where are resources provisioned?). It is nice to see the options fit in the classic 2 x 2 table. It is also useful to clarify that the cloud is not simply remote provisioning, despite what some providers are claiming. Ruben uses his table to show the movement connected with the three major resource provisioning options (other than your own chip-and-mortar data center) employed today.

As Gartner's Lydia Leong recently wrote, "If you worry about hardware, it's not cloud, even if it is remote." As they added, "...if it's not on-demand, seamless, and nigh-instant, it's not cloud." 

Classic IT outsourcing involves a movement from on-site to remote systems, but stays within the physical world of data centers. Cloud outsourcing goes all the way across the grid to move from local and physical to remote and virtual. The hybrid cloud moves from local virtual to remote virtual. Each represents different challenges and opportunities.

One fulcrum for tipping off any given Cloud approach is that of authority and governance. By looking at the way the business or market wants to pay for the solution, and defines and manage service levels, you get a pretty good picture of whether or not a Cloud model is needed (or just virtual hardware/grid is needed) and which type of cloud would make a better target depending on security, authority and control factors (Private vs. Public). Of course, these distinctions will continue to abound.