Published: July 24 2009, 03:51 PM | 1 Comment(s)
by Stephen Elliot

Jonathan Zittrain's Op-Ed "Lost in the Cloud" (New York Times, July 19, 2009) is absolute and on-target in relation to the legal, compliance, and security concerns of consumers and enterprises that adopt a cloud service.  In fact, CA's conversations with both end-user customers and cloud service providers validate these challenges.  They are proving difficult to solve, but require innovative answers to drive further revenue streams and accelerate adoption. 

The cloud providers that solve these challenges fastest will have a competitive advantage as they will be able to provide the highest levels of service availability, performance, and security.  Better yet, those providers that differentiate beyond price by offering innovative, best-in-class, tiered pricing models based on the level of service a customer requires will be most successful. 

To accomplish this, cloud providers must invest in scalable solutions that align their technology infrastructure and data centers to the availability, performance, and security of their services.  This approach will provide a customer-first perspective and enable providers to "bake-in" processes that reduce waste and deliver differentiation and value for customers.

Real innovation that directly correlates the underlying cloud delivery infrastructure to the value that it delivers to customers - Lean IT - is similar to the transition of the car industry from manual to automated manufacturing processes. They key is building quality into the process.  

Cloud providers have a unique opportunity to enable quality and differentiation through their delivery mechanisms (i.e., software and infrastructure).  Those that seize the opportunity will win and be rewarded with revenue growth and higher market capitalizations.     

Share this post:  Email

Share

Published: July 22 2009, 05:00 PM | 2 Comment(s)
by Stephen Elliot

In November 2008, CA announced more comprehensive solutions for management of virtualized and cloud computing environments, and a bolder vision for management of the cloud-connected enterprise. 

Unlike BMC's more limited offerings, CA's solutions span the full breadth of Enterprise IT Management-from governance to management and security.  Our vision for cloud management leverages this unique strength, and includes differentiators like control over transactions as they cross on-premises and cloud applications, and federated security.

In terms of Amazon EC2 specifically, CA demonstrated provisioning to the Amazon Cloud a year ago. We surpass BMC capabilities today with support for this popular commercial Web service through our Business-Driven Automation and Application Performance Management solutions, among others. And, we are working closely with Amazon and joint customers to extend these capabilities.

CA has an aggressive plan to build on this foundation. Our recent acquisition of cloud computing pioneer Cassatt has infused substantial expertise into the CA organization, and we expect to introduce a growing number of new cloud offerings in the near future.

Share this post:  Email

Share

Published: July 21 2009, 11:50 AM | 1 Comment(s)
by Pam Snaith

It's always the network's fault or that's how it usually seems to the network group at most organizations. The blame for business application failures needs to land somewhere and, historically, the network was a good choice. In the pioneer days of networking the network often was the problem - it seemed a miracle that information made it from one system to another - but networking has come a very long way since that time. 

Absolute dependence on the network for a vast amount of business processing has led to comprehensive management tools that let us all know when network problems are brewing. Or do they? One area that continues to plague network support organizations is configuration change management. If the router configuration changes aren't made perfectly network compatibility problems ensue. And the reason that configuration errors are so common is that there are simply so many of them. Networks teem with routers and switches that, in the normal course of business, need configuration adjustments. Furthermore, the devices are often from multiple vendors, each with its own command-line structures. The number of changes can be daunting and the variety of syntax can be overwhelming. If the configuration changes are done manually the opportunity for errors is tremendous. Just the timing issues associated with manual input - some devices will be changed before others - can expose configuration discrepancies that result in network outages. Another common problem is discrepancy between the startup and running configurations. This happens when a configuration change is made correctly but is not saved to non-volatile RAM. In the event of a device reboot, the device reverts to the old configuration and results in a network issue.

There is a solution to the configuration change dilemma. First, if configuration management is integrated into the network management fault solution you achieve correlation of network events with configuration changes and gain insight on problematical configuration changes as part of the root-cause analysis. In addition, you can also obtain a configuration audit trail of any selected network device through the history that is typically retained by network management tools. .Second, by automating configuration changes you eliminate manual errors and time delays that can cause outages, you are instantly notified of changes and you relieve your IT staff of this tedious, but important, task - moving you towards Lean IT. 

What's good for the network is also good for service assurance - closing the loop on network problems will go a long way towards keeping your services humming. For more information on the value of integrated fault and configuration management and how automation can help you, check out http://www.comnews.com/features/2008_april/0408_close.aspx.

Share this post:  Email

Share

Published: July 14 2009, 11:23 AM | 2 Comment(s)
by Ramona Copeland

I want to start off by saying that I'm not, nor have I ever been, a database administrator (DBA).  For this discussion, I feel that this is a distinct advantage, as I offer an "outsider's perspective."  So let me ask you, have you ever been watching a news story and your common sense tells you to do the exact opposite of what the person in the story did?  That's what puzzles me about database staff.

I've visited many companies in person while at CA, and have participated in even more customer meetings via phone, and I still don't get it.  Every database team I've spoken with admits to being blamed erroneously for performance issues that lie at the fault of another IT domain (apps, network or systems).  One customer even stated that out of the 1300 service tickets assigned to database, only about 30 ended up being database related.  Although this was an extremely large financial company and isn't the norm, it gives you a sense of how much time can be/is being wasted by the database teams, chasing down performance issues.  What makes this even more difficult is that there is typically a different database team managing the different databases (DB2 Linux, UNIX and Windows, Oracle, SQL Server and Sybase) within a company. 

So, here is my question.  If you were a DBA and you could wave your magic wand and no longer receive any service tickets that didn't belong to the database area, wouldn't you?  Of course you would! (That's what your common sense tells you.)  But within many companies, there are database staff who don't want to do just that.  The question that I'm still trying to answer is why?

Maybe because information is power?  I do believe that there is some of the "If you don't have visibility into my domain, I'm in control" aspect to the discussion.  But, if the database team were to become much more productive, due to no longer spinning wheels tracking down performance issues that don't actually exist in the database area, then wouldn't management view the database team as being more in control?  They would have a sense that the database team does know what is going on and displaying successful management. 

This is where I would welcome some insight from you.  Why are some database teams so reluctant to share information with the other IT domains?  Which is worse:  operations knowing for certain that there is a database related issue causing a business service to degrade, or operations thinking that database has caused 100 service related performance issues that really weren't database at all?

If the hesitation from the database team is in fact the "information is power" argument, then let me set the record straight.  I don't believe that information flow should be a one-way street.  If operations and other IT domains gain insight into overall database health, then the database area should also be the beneficiary of what is happening within those other areas too.  It becomes a two-way street.  What might be affecting the health of the databases, or could potentially affect them if the other IT domains aren't proactive in managing their own areas?

Determining which area is responsible for a disruption in service or for poor service can be challenging when applications, database, network and systems teams can't/don't successfully collaborate. The phrase "can't we all just get along?" is ringing in the back of my head. 

Share this post:  Email

Share