CA Community






March 2011 - Posts

Understanding Cloud Terms: Why encapsulation and abstraction are critical

Published: March 29 2011, 12:30 AM | 1 Comment(s)
by Nathaniel Rushfinn

Terms and definitions are very important to me, which is why I rely on my trustworthy friends Funk and Wagnalls. Nowhere in IT does there seem to be more confusion about terms than in cloud computing. CA Technologies, and many other organizations, have adopted the National Institute of Standards and Technology (NIST) definition of cloud computing (read this recent CSO Magazine story for the latest updates on the status - NIST just released a new document outlining cloud security and privacy guidelines, as well). While industry analysts and the many contributors to Wikipedia have done a great deal to define cloud, there are two terms that I find consistently mangled, abused and generally misunderstood-encapsulation and abstraction.

Each term is used with different meanings in math, philosophy and art. In computer science, the terms stem from object-oriented programming and are specifically defined. I believe we need to make clear definitions for their use in cloud computing.

So, what is encapsulation?

When we encapsulate something, we take that object and hide it from view. In medicine, when a foreign object is lodged in the body, like a pencil lead in your arm, it forms a cyst around the object and encapsulates it, to hide it from the immune system. In computing, we mean that we take the components of an object and wrap them up in a neat package to hide them from view - so that the user doesn't have to worry about the complexity of the individual pieces.

Computers today hide a lot of the tasks of configuring and setting up applications. In Windows 7, or on my iPad, I can easily get to the Internet by simply clicking the "Connect" button. All of the complexity of the Internet protocols TCP/IP is encapsulated.

What about abstraction?

An abstraction is a single, high-level, and simplified concept. For example, when we write a report we create an executive summary-an overview so that readers don't have to wade through all of the details. In scientific journals we actually call the executive summary of an article an abstract.

In the early 1980s, people labored painfully to connect their computers to DARPAnet. If your modem handshake was successful and your PPP (point-to-point protocol) connection was established, you configured your PAP/CHAP password correctly, and established a connection with Trumpet Winsock (Windows Sockets API), you still had to know how to use Telnet, FTP, and if you were really cool...Gopher. Mosaic had not yet been invented and the Internet and World Wide Web as we know it today didn't exist. It was just a complicated mess of interconnected networks.

Today things are much easier because of encapsulation and abstraction. All of the complex protocols needed to connect to the internet have been encapsulated into a simple process. You open your computer, click "Connect", and voila!  Thanks to abstraction, the complex interconnected set of networks is now the simple concept, the Internet.

Why are these two concepts so important for cloud computing?  

In the standard computing model, applications are dependent on a complex matrix. They require specific software platforms like Java or .NET, a type of database like Microsoft SQL, Oracle, or just a simple ODBC source. Applications may also require a certain operating system plus all the drivers necessary to run on the specific hardware platform, and some type of storage. And of course it will still need a TCP stack and all of the related networking drivers.

With cloud computing we have to use both encapsulation and abstraction; otherwise, everything gets messy fast.  Let's talk about a CA Technologies solution, an example I'm intimately familiar with.  With CA 3Tera AppLogic, we're able to hide a lot of the complexity from the user -- by encapsulating the software stack within what we call a virtual business service. In this way there is a single neat box or capsule containing everything the application needs to operate from a software and infrastructure perspective. But that's not enough.

Today, applications still need some kind of physical hardware to run on. The problem is that each application requires its own compatible hardware. Data centers have become filled with racks and racks of disparate hardware. Some believe that virtualization is the answer. While server virtualization can help to a degree (watch for my next blog on Big V, Little v), but what you really need to take this to the next level is abstraction.

Getting back to the CA 3Tera solution example: AppLogic abstracts the hardware, networks, infrastructure and storage into a single fabric. Users do not need to know about the specific resources or devices, just what application or ‘service' they wish to deploy.

It is the combination of encapsulation and abstraction that is so powerful. Together these two constructs create the foundation for cloud computing so that users can easily provision applications in the cloud.

CCL image courtesy of elanbeat - http://www.flickr.com/photos/takahiro/440438901/sizes/s/in/photostream/Just in case all this still needs more explanation, I'll throw in one more analogy for good measure.  And, since I grew up in California constantly torqueing head bolts on my Austin Mini-Cooper, I like to use car analogies to explain the world.

If CA Technologies sold cars, our mission would be to have our customers experience the power and beauty of our automobiles. We might advertise our reliability, excellent gas mileage, and luxury features. Without encapsulation, users would be overwhelmed by the complexity of myriad parts-the pistons, valves, transmission gears, wheels, and pulleys. Without abstraction, the concept of the car would be lost in the infinite details. Sales staff would overwhelm customers with extensive sales quotes for individual parts, services, and training on assembling the car and how to use it. But by encapsulating all of the complexity of the engine and drivetrain, and by abstracting all of the concepts of the car, we can just pull out of the showroom, hand the user the keys and say, "Let's motor, dude..."

Share this post:  

 

By: Nathaniel Rushfinn
Nate Rushfinn is a cloud computing expert at CA Technologies and a certified enterprise architect working under CA Technologies Public Sector CTO. With his expertise in cloud computing and his in-depth knowledge of the company’s software solutions, Nate helps federal systems integrators implement cloud...
Read More..

Pragmatic Cloud: A Tale of Two Write-Downs

Published: March 24 2011, 09:05 AM | 2 Comment(s)
by George Watt

It was the best of times, it was a cell with a view

Recently there has been a lot of discussion and debate regarding the capitalizing and amortizing of cloud-related expenses (sample posts here and here).  Through most of what I read, people are on to the key items and we may have more of a semantic difference than a difference of opinion. In a previous article I discussed how beneficial, if not how absolutely necessary, a close relationship between a private cloud provider and their Finance team is.  This debate is a great illustration of why I believe that to be the case.  So I encourage you work with your Finance team to determine the best (and legal) course of action for your circumstance.  What follows is based upon my specific experience wrestling with this issue.

A Capital Idea

When a tangible asset is purchased outright it can typically be depreciated over a reasonable period not to exceed its useful life (this was usually 3-5 years for us).  Once the asset is no longer of use to an organization it can be disposed of.  When that happens, if the asset is sold for more than its value (minus the amount it has been depreciated) a gain must be claimed.  If the entire value of the asset has not been depreciated and the asset is not sold, or if it is sold for less than its residual value, it may be possible to claim a loss on its disposal.  (Typically, we fully depreciated our assets and there was no gain or loss on their disposal.)  The rationale for this is explained through the matching principle in accounting: that a business should be able to assign expenses to the revenue for which they were incurred, recording them during the appropriate period.  (More on this in a moment.)

Capitalizing Opex?

As with capital assets the costs of non-tangible assets such as a software license may typically be written off over the period during which it will contribute to the generation of revenue, though there are some important differences.  For example, usually the operational expenses may not be written off over a period that extends beyond their (let's call it) lease period.  Though some of the articles I have read have suggested that amortization is financial jiggery-pokery ("capitalizing opex") it is not and I believe it makes a lot of sense.

For example, suppose you have a three-year contract with a specific vendor for your desktop OS, mail server, development environments, and the like,  that has a multi-million-dollar price tag (not atypical for a large enterprise).  You are billed annually on January 1st for one-third of the amount (e.g.: $2 million).  Were there no allowance for amortization you would pay the entire amount January 1st and take a major hit to your Q1 (in fact, January) expense line.  That would not be an accurate accounting of things since that license would be consumed over twelve months, contributing to revenue the entire time.  To account for that, those costs may be amortized across the period over which they contribute to the generation of revenue.  (In my experience the amortization cannot exceed the lease/usage period.)

In the end, it's no different than renting an office where someone pays by the month.  They expense each month of rent against the revenue for that month.

In contrast, imagine if this were not possible.  In a worst case everything of this nature might need to be expensed in the first month of a fiscal year (e.g: when the bills were paid).  This would make for a tremendous bottom line benefit over the final 11 months with very little expense, if the company were allowed to survive past the first month.  Were this the case, regardless of the month of acquisition it would be a much less accurate reflection of the monthly operating costs of the business. 

CCL image courtesy of Brooks Elliott - http://www.flickr.com/photos/8011986@N02/3059374021/sizes/s/in/photostream/Cash Flow and Budgeting Remain Critical

That all sounds nice and clean, though one must also be conscious of cash flow, which is a different beast.  You need the cash when the bill is due, so planning when the bills are to be paid, and when assets are acquired and expenses are incurred, is of critical importance.  You cannot spend what you do not have.  In my role as a private cloud provider I spent a lot of time every year carefully planning when money would be spent on assets and expenses.  Cash flow is critical, and we also had to ensure that we planned things so that assets arrived before our consumers needed them and that the team's work was scheduled such that they had the capacity to receive and provision new assets.

Capitalization of operating expenses and the subsequent amortization over the course of use do not remove the need for disciplined budgeting, cash flow, and deployment planning.  If anything, they become even more important.  Our fiscal year began April 1st and we started talking about our budget at a high level in August.  We prepared straw man budgets in September, made a first pass with decent detail in October (ready for Finance and stakeholder consumption), and fine tuned it and made adjustments from November through February.  All the while working very closely with our Finance team and our stakeholders.

A Tale of Two Write-Downs

So capitalization and amortization are inter-related.  Certainly with a capital expense there is something tangible that is owned, and it may have some value on its disposal; though it may not.  Operational expenses such as leases may have no value at all outside the context for which they were incurred (e.g.:  if I decide to opt out one year into a three-year rental agreement, I may not be able to sublease in order to recover value, and I may still need to pay for the entire term.)

For accountants and finance pros, there are not any stunning revelations here, though hopefully it all makes sense, particularly to the rest of us.  Though, what about the magic of capitalizing opex?  I believe that is the semantic issue I referred to at the outset.  We are really having a debate about a technical term versus something said to illustrate a point.  I would bet it's amortization.  And really, does it matter what we call it when we're trying to help one another?  (If you are a CPA and you are filing financial records, OK, it matters.)

Partner with Those Who Know

Is it always that simple?  Of course not.  That's why a partnership with your Finance team is critical.  They have all of the technical knowledge required to make the most efficient, legal, compliant decisions regarding these things. Though regulations regarding these things can be similar in different regions they can also be different, as can the limits under and over which certain assets and expenses may be treated differently, so diligence is required.

There are also many other considerations such as your company's policies, which may be far stricter than the regulations, and handling operational expenses which have a term that crosses fiscal year boundaries.  As well, care is required in crafting contracts for those assets and expenses.  It may or may not be possible for you to amortize "potential capacity" or other operational expenses; and incorrect wording in a contract may change how an asset or expense can be handled.  Imagine putting your company in a position where that $2 million expense cannot be amortized.

So work with your Finance team and they will help you to gain the maximum benefit from amortization and capitalization legally while respecting your company policies.  After all, Jeffrey Skilling has all the company he needs.

Share this post:  

 

By: George Watt
George Watt ( @GeorgeDWatt ) is VP of Strategy for the Cloud Computing organization at CA Technologies. For nearly 25 years, George has been helping customers simplify and automate their complex IT infrastructures. Prior to his current role, George founded CA Technologies Engineering Services team, which...
Read More..

More on fabric computing in the cloud

Published: March 22 2011, 07:50 PM | 2 Comment(s)
by CA Community

In my last post I covered the concept of fabric computing and why it matters in the world of cloud computing.  With a "fabric" approach towards creating a cloud application, we include the virtual compute, storage and network components inside a fully software-based model of the service. This is distinctly different from a more traditional approach, where the various resources are added and configured one by one.

In response to a comment, I also suggested that this new approach could be compared to a modern espresso machine.  Such a machine delivers a complete service (coffee!) - in an integrated fashion.  No need to worry about the temperature of the water, grinding the beans, any other steps or equipment required to make it happen.

In a cloud computing context, the fabric is integrated "out of the box," like the espresso machine. It doesn't require provisioning, managing, integrating and monitoring lots of VMs and appliances individually. Most cloud solutions approach building a cloud by automating these individual steps - typically through scripting -- but this approach has distinct drawbacks. I included a short demo of the fabric approach below, but to understand these drawbacks we will use another analogy:

The parable of the spreadsheet and the calculator

CCL image courtesy of Ivan Walsh - http://www.flickr.com/photos/ivanwalsh/5187183980/sizes/s/in/photostream/

                                     

Imagine you are an accountant and you can choose between using a spreadsheet (a fabric) or an automated (scripted) calculator.  Both a calculator and a spreadsheet have similar base functions (add, subtract, multiply, square root). On a calculator, you start with a value and you perform functions against that. If you perform the same functions every month you could put these in a script, so you can play them back automatically next time. You could even edit that script to do it slightly different. This may makes things easier, but it is not a spreadsheet. With a spreadsheet you can have several versions next to each other (you can do a "Save as"), a change in one area immediately updates the other areas (it is integrated, there is no need to rerun a script), you can send a spreadsheet to other users or to your accountant.

Have a look at the demo below to see how that applies also to a fabric cloud application (including "save as", creating multiple versions, send it to someone else to run).  But first ask yourself: when did you last see an accountant with a calculator? In fact automated calculators never really took off. Spreadsheets (fabrics) are simply the better way.

Seeing is believing: the epiphany of a demo

When I personally saw my first demo of this concept in action, it reminded me of two earlier occasions where a demo later reshaped IT as I knew it. The first was after I installed Windows 1.0 (all 12 floppies). Sure back then it was still monochrome, there were no applications and the performance was not great, but it did make me think: "Boy, if they ever get this to work, it will really change how we use desktop computers."

The second "epiphany" was my first experience with X86 virtualization. After having confiscated the biggest machine in the office with the most memory, and after quite some tinkering I saw an actual X86 machine boot inside a window (of course this was not an actual machine - it was a virtual one). After it booted, it could not do much, and running two of them brought the whole machine to a grinding halt. Yet, it did make me think: "Wow, if this ever scales, it can completely change how we handle our machines." And (admittedly somewhat to my surprise), about a decade later around 2009, X86 virtualization did actually start to scale and it developed into the billion dollar industry that is changing the way we manage our servers.

Just like Windows profoundly changed the way we use desktops and virtualization is changing the way we manage servers, this new software-based, virtual fabric approach, in my view will change the way we manage data centers. Now I was certainly not the first person to realize this. Nicholas Carr already acknowledged the power of this approach in his book "The Big Switch." In an interview with eCommerce Times, he subsequently said:

"In 3Tera's AppLogic, you can see the broad potential of virtualization to reshape how corporate IT systems are built and managed..."

How is that so? Well, my marketing colleagues here created quite an entertaining video , but the original - now vintage - 5-minute demo that shows how to define an application as an integrated fabric is also still out there (and shows the potential much better than my above ramblings).

CA 3Tera AppLogic software essentially enables you to do three things: 

1) First, you set it up on commodity x86 servers, creating a single fabric for the storage, network and compute capabilities on those servers.

2) Then, using an integrated modeling tool, you take your application or service - including all its components, such as data, networking, load balancing, security etc.-- and create a 100% software based model (using a Visio-like drawing tool - check out this InformationWeek demo from Cloud Connect to see this in action).

3) Next, you can deploy a model of the fabric, with the software allocating resources based on the model, and providing automated scaling, metering and fail over capabilities.
You can also move the service or application to another data center very simply, even to one in another country or at another provider. Or, you can copy it and provide the same service to another department or customer (nearly instantly).

For a long time, CA 3Tera AppLogic software was kind of an industry insider secret. Several analysts and writers - like Nicholas Carr - were aware of it, discussed it and listed it in their publications. But today there are many case studies and real life success stories of both small and large implementations out there. This may be a good time for you to have a closer look; if only as an interesting implementation of these new fabric computing trends and principles in action.

Share this post:  

 

By: CA Community
CA Community is the blog manager’s account used to post general updates and news items.
Read More..

Is your IT organization focused on becoming a 'Trusted Advisor'?

Published: March 21 2011, 01:20 PM | no comments
by John Meyer

Over the past year I have seen many industry announcements, articles, and case studies published documenting how a "business" is taking advantage of cloud computing to become either more agile, drive innovation or become more operationally efficient.   So what?  Well, the "so what" comes when you look closely and realize that a good number (approx. 30% based on my own unscientific review) of them don't mention IT.    They talk about how the business leaders went out and acquired what they needed from the cloud.   Simple as that, the business goes to the cloud to get the SaaS application they need.    While that doesn't imply IT wasn't involved in those efforts somehow, it does beg the question "Why isn't the business talking about how IT helped them acquire their cloud services?"   Maybe it is because IT wasn't aware of what the business needed or was doing or maybe it is because IT isn't proactively acting as their "Trusted Advisor."

In a recent survey (The Changing Role of IT and the Move to an IT Supply Chain Model) of North American and European IT executives at enterprise companies (conducted by IDG Research Services and sponsored by CA Technologies), the vast majority of respondents (96%) said IT's primary role has changed over the past 5 years.  In fact, more than one-half (53%) indicated that moving in-house services to the cloud has contributed to IT's evolution (and 71% said that cloud computing will continue to change the role of IT over the next 2 years). 

It is exactly that evolution over the next two-plus years that I believe will either make or break IT's future relationship with the business.  In order to make a successful transition to becoming a "Trusted Advisor" rather than just a server provider, IT should try to shed those functions that provide limited differentiation pushing those commoditized IT functions to a third party.    

IT today is like a vendor that has several partners who have developed products on top of their technology, and then the vendor tells its partners that it is going to incorporate those functionalities into its own product.    The basic message is: move up the stack and figure out how to innovate at a higher level or face being removed from the equation.  

In a recent conversation with several IT pros at a large industrial equipment manufacturer, they mentioned that their business counterparts were going to the cloud and buying business applications without the help of IT.   Rather than ignoring the issue or getting up in arms about that happening, they were trying to map out what they could do to become a Trusted Advisor to their business counterparts. I've put together some thoughts in a diagram below on where this role fits into the IT and service provider mix (see below).

IT needs to move up the stack and help the business innovate rather than running servers in the data center - or handling the rote, repetitive, non-strategic infrastructure-focused tasks.  Would you want to risk slowly being replaced by cloud service offerings?  Albeit, not all companies fall into this scenario right now but as the security and governance issues around cloud services slowly fade into the background, the tide is turning.   

Will IT make the transition to becoming a Trusted Advisor?   From my many conversations with IT pros recently, I believe it will.  Do you have similar experiences? What are some of your initial hurdles in becoming a Trusted Advisor to the business? We'll be tackling this topic in a future blog post and would be interested to hear your thoughts.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

Share this post:  

 

By: John Meyer
John Meyer is VP of Cloud Strategy & Evangelism at CA Technologies. John has led strategy and product management for multiple business units since he joined the company in 2003. His broad industry expertise both as a former industry analyst and seasoned IT practitioner allows him to infuse CA Technologies...
Read More..

Real math and rapid-fire ideas: Overheard at Cloud Connect 2011

Published: March 18 2011, 01:20 PM | no comments
by Jay Fry

I spent several days last week at Cloud Connect in Santa Clara and I am very glad that I did. It was great connecting with a group of the cloud computing whiz kids (and some only slightly older than that). Plus, Alistair Croll and the team proved that they can continue to put on a conference each year that feels the pulse of the market and provides the content that needs to get airtime.

Last year's event was solid; this was even better.

Here were some of highlights and things I overheard while I was at Cloud Connect:

The rapid-fire, 10-minute keynotes were great conversation starters. I think they planned it that way. And it worked. The keynotes I saw ranged from Amazon CTO Werner Vogels talking about how the lines between IaaS, PaaS, and SaaS were blurring (thanks to some William Vambenepe-inspired graphics)...to the Eventbrite speaker talking about real-world cloud operations experiences at his current company, at Digg, and Playboy...to Berkeley researcher Oriol Vinyals showing how teaching computers to play and learn complex video games like Starcraft could have great possibilities in cloud resource management and automation. (From my Cassatt experience, this kind of automation is powerful - and hard.) There were only a few sales pitches we had to sit through (Rackspace, this means you), but at least they were short. The quick, concise keynotes were a great way to stretch your mind.

Lots of math. Real math. From the Cloudonomics track to the keynote by eBay, there were some real, hard numbers presented. That's a home run for anyone interested in cloud computing. The eBay keynoter talked through the math they used to decide if and when to use internal infrastructure and if and when to use public cloud capabilities -- and what situations caused those decisions to shift. HP's Joe Weinman walked his session attendees through the logic behind his proofs of the inevitability of cloud computing, the situations where it makes mathematical sense, and the reason hybrid clouds are just a good idea. Joe's work is both thorough and practical: he describes how to use logic and economics to make cloud decisions. You can check out Joe's work here; he actively solicited people to continue to pound on his numbers and check his work. That's refreshing.

Does cost still trump everything? The one thing that Joe's sessions really got me thinking about was this: how far can you take any mathematical conclusions about when an organization should adopt cloud? Humans, after all, don't always decide things by the numbers (yes, even in IT). Funny thing is that I think it was Joe Weinman who said in his session, "There's no such thing as a rational economic decision maker." We can't look at just cost, he said. "Things are more complex than that."

Nevertheless, you have to have the numbers. It's important to have those numbers to refer to, even if we don't use them as the sole decision-making criteria. Panelist Ravi Rajagopal (from CA Technologies and a lecturer at NYU on cloud computing) said he believed that after all is said and done, customers must use cost to justify any move to the cloud. Speed, competitive differentiation, and other criteria are nice, but they take a back seat. The other panelists (James Staten from Forrester, especially) underscored the power of agility as a driver and the need to look at softer things, like opportunity costs. I personally think we'll be able to move away from a purely cost-based justification as things like the Service Measurement Index for cloud services take off.

What you get when you mix cloud and accounting. At Cloud Connect I heard a comment that made me think that there may be some interesting accounting tricks still to be learned about cloud computing. One of the big pitches for cloud is that it moves many IT expenses from being capital expenses to operational expenses. However, in one of his Cloudonomics sessions, Weinman noted that Netflix is using AWS reserved instances and amortizing the costs over time. It got picked up and discussed in a bit of depth by Reuven Cohen, Data Center Knowledge, others. An interesting concept, for sure, and one that I hope those with more of a finance background than I will delve into.

What you get when you mix cloud and lawyers. Dr. Chenxi Wang from Forrester did a surprisingly thorough overview of the global legal issues that cloud is causing and that must be addressed. (I say surprising because she was actually filling in for another analyst at the last minute.) She tossed around some interesting concepts and ideas that were new to me. In talking about cross-border data flow, she mentioned an intriguing idea that might help solve some of the legal issues: treating data centers as "data embassies" where the laws match those of the country of the source of the data, rather than the location of the physical data center.

Also, she mentioned that one of the biggest concerns about housing data in the U.S. is the Patriot Act and the risks to the control of that data. But just putting a data center in Europe doesn't guarantee that a U.S. company is free and clear. "Think the Patriot Act doesn't impact your EU data centers? Think again," said Dr. Wang. The legal precedents aren't yet clear, and are heavily impacted by how you set up your European organizations.

Having your booth next to the beer is never a bad idea. Sure, the CA 3Tera AppLogic booth was in the back corner this time around, but somebody was looking out for us when they planned the location of the liquid refreshments. Having our new service provider partner ScaleMatrix join us in our booth was a great way to immediately share real-world experiences with booth visitors from the get-go. And that freed up CA staff like our man Justin to work on his mad 3Tera demo skills on camera.

Finally, here are a few quotable quotes I scribbled down throughout the conference. I thought these were pretty good summaries of a few of the key topics:

James Staten, Forrester Research: "The power of cloud computing comes through these two words: ‘down' and ‘off.'" Concise...and true. When you turn a cloud application or service off, the billing stops. It's straightforward to expand when needed, but cloud computing has to contract as well.

Randy Bias, Cloudscaling: "Cloud is a complete re-think of the IT stack." In other words, the value of the applications are what's important, not infrastructure ownership.

Ravi Rajagopal, CA Technologies & NYU: "We need to bring rigor to change the ‘art of cloud computing' to the ‘science of cloud computing.'" And, as noted above, "You can't justify cloud without the cost making sense." At least, not yet. But we're getting there.

Joe Weinman, HP: "In most cases, hybrid clouds are cost-optimal as well as the most pragmatic." He then followed that with lots of small fonts and detailed proofs. And that's a good thing.

Werner Vogels, Amazon: "It is still Day One in cloud." Meaning, there is a lot of innovation to yet to come.

If that doesn't give you your fill of Cloud Connect info, I'd suggest a couple other really good write-ups that I read: check out what Krishnan Subramanian wrote at CloudAve and Bernard Golden's commentary at CIO.com. And start making your travel plans for next year's event.

 

This blog is cross-posted at Data Center Dialog. Do you tweet? Follow @jayfry3 on Twitter.

Share this post:  

 

By: Jay Fry
Jay Fry is vice president of marketing, Cloud Computing, at CA Technologies. He has over 20 years of experience in marketing and management for innovative enterprise software companies. Prior to CA, Jay was vice president of marketing at cloud computing start-up Cassatt and founded the marketing department...
Read More..

More Posts Next page »