Development Clouds: Delivering Peace Between Developers and Testing

Cloud computing is happening in a big way.  No wonder: infrastructure-as-a-service, resource elasticity, and user self-service promises huge, visible, and fast returns.

The needs of software development and testing  for scalable, flexible, compute-intensive IT infrastructure makes it an incredible candidate  for the benefits of cloud computing. Whether it is vast clusters for testing, dozens of machines to run ALM tools, or the requests for “just one more box,” development and test teams are always asking for something , it is always changing, and time is of the essence.

Join us as Theresa Lanowitz, the founder of analyst firm voke, discusses the utilization of cloud resources for test and development.  Theresa will share research showing how this approach can lead to lower costs, more productivity, and more predictability..  Joining Theresa will be Anders Wallgren, CTO of Electric Cloud, who  will show how task and workflow automation, resource management, and tool integrations allow test and development  teams to effectively use a  cloud infrastructure.

Attendees of the event will receive the voke Market Mover Array^TM Report: Testing Platforms with detailed analysis on Electric Cloud.

About the Presenters:

Theresa Lanowitz,
voke, inc.

Theresa Lanowitz, Founder of voke, inc. is recognized worldwide as a strategic thinker and market influencer in application life cycle, virtualization, cloud computing and convergence markets. 

With over 25 years of experience, Theresa has been associated with some of the most breakthrough technology and products of their time.

Theresa founded the analyst firm voke in 2006. Since its founding, voke has delivered thought-provoking research focused on innovation. From 1999 through 2006, Theresa was a research analyst with Gartner. During her tenure with Gartner, Theresa pioneered the application quality ecosystem, championed the application security space, and consistently identified new and emerging companies to watch. As the lead industry analyst for billion dollar plus enterprise software companies such as Mercury, Compuware, and a host of others, Theresa developed marketing and launch strategies, corporate and product messaging, and identified partnering and acquisition opportunities. Theresa has been a trusted advisor to some of the largest software companies in the industry.  Her marketing and positioning expertise has been invaluable in the successful launches of major enterprise software initiatives, products, and services. At Gartner, Theresa was the founder, creator and chairperson of the highly successful Application Development conference.

About the Sponsor:

Electric Cloud is the leading provider of solutions that automate, accelerate and analyze software build-test-deploy processes to optimize both physical and virtual IT environments. The company's award-winning products help development organizations to speed time to market, boost developer productivity, and improve software quality.

Electric Cloud
676 W. Maude Avenue,
Sunnyvale, CA 94085
Tel: 408.419.4300
Fax: 408.419.4399
www.electric-cloud.com

Video Transcript

Hi.

 Good morning, good afternoon or good evening, depending on from where you are joining us today, and thank you for holding on while we got this event started. Welcome to the CM Crossroads webcast series broadcast- development clouds, delivering peace between developers and testing. This Webcast is brought to you by Team Crossroads and is sponsored by Electric Cloud.

I'm Francesca Matteu and I'll be your moderator for today's event. In a few moments, Theresa Lanowitz and Martin Van Ryswyk will join us to discuss Development Cloud and delivering that piece between developers and testing. But first, a few housekeeping session. We will address audience questions at the conclusion of the webcast during the Q ; A period.

If we're unable to get to all of your questions during the presentation, someone will follow up via email. And to ask a question, simply use the live chat window located to the right of the screen under the tab chat. You can also undock the chat box from the screen using the pop out button at the bottom right corner of the chat box, that way it doesn't get hidden behind the slides.

If you would like to share your thoughts about today's presentation, please use the FaceBook tab located to the right of the screen, log into your account and you will have the ability to share your experience with your friends. You can also share your experience through Twitter. Click on the Twitter tab to the right of screen and join the conversation.

Your Tweets will show up in the Twitter role to the right. Now make sure to use the hash tag #C;CLC thats C#C;CLC. If you would like a copy of the presentation materials for today's session, you will find a button to download a copy of today's on the links tab at the right of the webcast window.

A recording of the entire live broadcast including Q;A, will be available within 24 hours at the same location, so you can come back again or recommend it to a friend. And finally, if you ever need to get a closer look at any of the slides during the presentation, just hover your mouse over the video player and click the full button to expand to full screen.

So with that, let me introduce our speakers who are joining us today - Theresa Lanowitz. She's the founder of Voke Incorporated and is recognized world wide as a strategic thinker and market influence in the application life cycles, virtualization, cloud competing and convergence markets. With over 25 years of experience, Theresa has been associated with some of the most breakthrough technology and products of her time.

Martin Van Rsywyk is the V.P. of engineering of Electric Cloud. Now prior to joining Electric Cloud, Martin was a senior director at EMC Corporation where he managed a number of software development teams. Prior to EMC he was the V.P. of engineering at Luminate, a privately held software company that pioneered the develop delivery of systems management software as a service which was then acquired by EMC in 2001.

Mark also has held management and technical roles at Title Software and he brings 18 years of experience in building commercial enterprise software to Electric Cloud. And with that introduction, I'd like to pass the mike back to our speakers. The floor is yours, Theresa. Thanks very much Francesca and thank you everybody for joining us today to hear about Development Clouds delivering peace between development and testing.

Before I take you to the big review about how you can actually deliver peace your development organization and your testing organization, I want to set a little bit of a context for how important developers are and how important the testing organization actually is to the overall delivery of software within your organization.

How really vital they are to the line of business. So think of software as the fundamental building block of business and technology is really no longer just an enabler. It's really business critical. You know we used to say all the time technology just enables business, it is now business critical.

And business and the IT organization. The line of business as well as that IT organization consisting of the development organization, the QA organization, the OPS organization, they have to take a long term strategic view of technology together. They can't do this in isolation, they have to work together, hand in hand to figure out what the business is really going to need from the technology side to move it forward.

And technology is now part of the brand promise and that's a big, big issue and that's why developers and testers are so important in order to deliver that quality experience to the end user. And so improved time to market with a high degree of customer satisfaction is something that every organization wants to achieve.

And in doing so, you really want to be able to shatter those shadows between development, testing, and operations and that's really critical in delivering software that satisfies the customer as well as delivering peace between the development organization and the testing organization. So in this presentation, we'll take a look at market trends and the pressures that every organization utilization faces, regardless of the vertical market that you play in.

We'll take a look at how to effectively utilize Cloud resources to bring peace between developers and testers and we'll take a look at our recent market research from Voke that shows the benefits of Cloud utilization for developers and testers and conclude with a summary. So let's start by taking a look at some of the current market trends with respect to Cloud usage,and development and testing.

So if you take a look at this chart. This is just the time line going from 2005 up to 2015. Obviously the things that had happened prior to where we are now, we know for certain, but moving on to 2015, we're making some best guess predictions as an analyst firm. And if you think about the global economic crisis of 2009, what that really did was it forced away, it really forced a change in the way we seek out and adopt new technology.

And the new technology that we adopt now has to have some economic advantage to us. We always want to know what our return on investment is going to be. How quickly are we going to see that return on investment. And you think about it, the Cloud and virtualization are absolutely perfect examples of the economy driving technology.

Those technologies deliver a fast return on investment, a visible return on investment. You can really track the benefits you're getting between, from implementing these new types of technology and through Cloud technology we now have competing platforms that are more economically beneficial and more economically sustainable.

However we still to make sure that of the tools that the developers and testers really need are available on the Cloud platform that they might be using. So as we advance over the next several years, we can expect to see Cloud and virtualization platforms really delivering more and more value with each passing year with each passing month to the developers and the testers that are actually using them.

They are going to make the developers and the testers more efficient and the Cloud and virtualization technologies will really enable developers and testers to deliver more strategic value to the organization. And if you think about it, we've really only begun to scratch the surface on what we can actually do with cloud and virtualization.

So we're about to see the best of cloud and virtualization in the coming years. So if we think about some of the trends, complexity is a trend we hear all the time. We hear everybody talk about complexity. And complexity is here to stay, it's not going to go away. We have so many different platforms that we have to deliver for.

We have to deliver for mobile platforms. We have to deliver for The Cloud, we have to deliver in a virtualized environment. So from a business point of view, we have a lot of platforms that we have to be able to maintain. From a technology point of view, really what ought to be... what our customers are expecting is really zero tolerance for errors.

We have this software that we have to deliver, software is ubiquitous it's always on, we're always connected and people want a seamless experience with their software. And that's what developers and testers are really tasked with delivering, that good positive experience for the end user, for the customer with zero tolerance for errors.

And the reason there's zero tolerance for errors is because software is your business. So regardless of your vertical market, regardless of where people might be using your software, you have to deliver a good positive experience to them. We're no longer sitting in the days of an isolated PC, where you're sitting at your desk, and the only people using that application might be the people who can come up and use the app, that might be sitting very close to you.

Software's ubiquitous, it's always on and we're always connected and one thing that we're seeing because of the zero tolerance for errors and software really being the business is that software and the brand, the software that you deliver and the brand of your organization are inextricably linked.

And because they're inextricably linked, your CEO has to be able to communicate to the share holders, customers, board of directors, media, as to what happened with your software if you do in fact, have a software failure. They're not going to come back to the testers, to the developers, to the QA organization, to the security officer and say hey, what happened?

It's up to the CEO to really to be able to communicate what's going on. because that is the brand of the company. That's how powerful software is. Now if we take a look at business trends that we're seeing in the broader market, every organization is dealing with global economic constraints. That's just reality and the proverbial "do more with less" is now the norm.

This is what we work under, everybody has to do more with less. But in order to really perform and deliver value to the line of business in a "do more with less" environment, we have to be able to act in a more strategic way. We have to be able to work in a more strategic fashion and by being more strategic we can deliver more business value andspend less time on tactical activities.

So if we think about how we can actually use technology to help us be more strategic, versus doing things in a manual way or not using automation in some way or just allowing these bottlenecks that we live with within our own organizations organizations to perpetuate. We are doing more tactical activities.

We want to reverse that and do more strategic activities. So, realize that each and every organization, regardless of vertical market, is now a software company. Software runs your business and as part of the brand promise. And remember that software is a valued and strategic piece of your organization and it contains a lot of intellectual property.

This is how powerful software is today. Software and the brand is Sony example that has been in the news for the past several months. This is a high profile security issue and it's associated with Sony. And this is how important software is. It's a glaring security failure. But at the core it is a software issue.

 And the CEO of Sony has been under fire. Fund managers were saying the CEO should resign. They're not going back and saying, "Hmm. You know, they didn't do the proper testing for security" or "They didn't do the proper things to make sure that they had a good platform for security." They're saying the CEO is responsible for this and so the CEO had to be able to communicate with the shareholders, the board of directors, customers, the media and so on.

So the moral of this story is, make sure that your applications are ready for the demands of a modern and a consumerised world. Make sure all of the stakeholders within your organization are aware of the risks when you actually deploy an application or a piece of software. And make sure that your developers and testers are given everything they need to deliver the best possible application to the line of business.

Eliminate those types of tactical activities that developers and tester have to deal with and enable them to be more strategic by delivering better quality tools and a better environment for them to work in. And enable your developers and testers to be more strategic and spend more time doing and less time waiting.

You want your developers and testers to be active. You don't want them to have to wait, you want them to be able to do. So from a technology perspective, we're really in a transformational period where - we live in an environment, as I said before, that's always on, and it's always connected. And as a result of this, our applications really have to be able to work in this on-demand world from wherever we may be demanding the applications to be used, and from whatever type of device we want to use those applications on.

 And the line of business is demanding more from its applications, and that means that the developers and testers are the ones that have to deliver upon that demand. So, developers and testers are going to have to deliver faster time to market - meaning higher customer satisfaction. How are they going to get this increased productivity and cost savings?

Well, if you take a look at the market that we're in right now - the technology market - there are some really great solutions in the technology market today that compliment tools and suites that you may already have within your organization. But what these new pieces of technology do, is they really help solve some of the classic problems that we've lived with within our organization.

They help solve some of those problems that we talked about. They help developers and testers be able to spend more time doing and less time waiting. So take a look at these new technologies that are in the market that enable your developers and your testers to solve some of these classic problems that have been just classic software problems for years and years.

And another thing that these new and innovative types of software technologies do, is they deliver a very visible and a very fast return on investment. And that's what developers and testers really want, is something that's going to be able to show give them a quick ROI, and something that they're going to be able to use to deliver higher satisfaction to the line of business, to the customer.

So now that we have taken a look at market trends, let's take a look at how utilizing cloud resources by developers and testers will deliver business value and it will bring peace between the development and testing organizations. I know that's really sort of the setup that we put here. So let's take a look at how that peace can actually be achieved.

So, we are an analyst firm, Voke is an analyst firm. And what we're doing is, we're predicting that virtualization and developer cloud technology will really be the hub of the modern application life cycle. And the ability for a technology such as developer clouds and virtualization to deliver a quick return on investment, lower capital expenditures, shatter silos, increase communication and collaboration, and enable more strategic work.

That's a significant piece of technology. And if you can give developers and testers the environment they need for as long they need it, with the tools that they need, your developers and testers are really going to be able to deliver far more satisfaction to the end user, to the customer of that software you are expected to deliver.

So enable your developers and testers to be able to lower capital expenditure, a big economic benefit in a quick return on investment, a big business benefit. Shatter silos, a big benefit between the organization to increase sort of the morale within the organization and make it an interesting and exciting environment to work in and deliver the software.

So this type, the virtual lab, technology and developer clouds are going to be the hub of the modern application life cycle. And that's one of our big predictions moving forward. And we are starting to see that come to fruition with the advent of a lot of developer clouds in usage within IT organizations today.

So, we said that we can bring peace between developers and the testing organization. And while doing so, we can really overcome some of these age old productivity barriers. I talked about the fact that some of these newer technologies we have in the market now. They really give you a big, big benefit in solving some of these classic problems that we haven't been able to solve before.

And the phrase, "it works on my machine." Every developer has used that, every tester has heard that. And if we could really eradicate the phrase "it works on my machine," that's going to deliver true peace between developers and testers. So ideally, to deliver that peace between developers and testers, we want to eliminate that phrase, "it works on my machine".

So if you use a developer cloud, the developer cloud gives testers an environment as close to production as possible in which to test. So using that developer cloud, you give your tester an environment as close to production as possible. And developers, by being able to use that developer cloud as well can have that same environment that is as close to production as possible to review the defects that the test organization is identifying.

And so if you realize that the common language between developers and testers is really the defect, then you can really start to achieve that peace and give developers and testers the same environment to test and identify those defects in. So look at that common language of the defect, and once the defect can be identified and then reproduced by the developer, and either remediated or deferred, you have really achieved peace and harmony between developers and testers.

They are working in an environment as close to production as possible to test. They're identifying the defect, the developer is using that same environment through a developer cloud, and it is much easier to reproduce the defect and then either remediate it or defer it until a later time.

So if you can eliminate the physical environment that is almost impossible to maintain, and give developers and testers the environment they need when and where they need it, it'll go a long way in speeding time to market, reducing capital expenditures and delivering a high customer satisfaction, as well as eliminating that phrase "it works on my machine".

And if we eliminate that phrase "it works on my machine", we have achieved peace between developers and testers. So that's how we can and overcome one of the age old barriers to productivity. Eliminate the phrase "It works on my machine," give developers and testers an environment as close to production as possible.

So the second age old productivity barrier that we deal with quite frequently is the wait time. And I take this from personal experience. I work in a number of software companies and while the developers were waiting for an environment to be deployed or testers were waiting for a lab to be set up or deployed, they will go out and play Ultimate Frisbee because they were waiting for so long.

It wasn't as though they were waiting for 5 minutes or so. They were waiting for hours. which may lead to a very interrupt-driven life. But the big phrase you often hear is, "We are waiting for our dead and test environments to be deployed."

And so, how can we really eradicate this issue of waiting? We want to get rid of this wait time. So we don't want our developers and testers to be in a perpetual state of wait. We don't want them to have to wait to have their environment authorised or deployed. So through the use of developer clouds and virtualization developers and testers can provision what they need.

That means they can take the environment they need, they can take the tools they need, they can take the combination of tools that they might need to develop or to test. So they can take what they need, they can take it when they need it, for as long as they need it, and put it into the proper configuration.

So that means that the tool configuration is there for the developers. They have the right development IDE. They have the right requirements solution. They have the right change configuration management solution. The testers have the right test environment that has the right testing tools. They can self provision and get these environments up and running.

So they don't have to wait for a lab to be maintained. The developers don't have to keep requisitioning new equipment, and keep all that equipment locked up in their offices somewhere and not give it up because they never know when they're going to need it again.

So, eliminating that wait time. Eliminating that wait barrier is a big, big thing to do in overcoming some of these productivity barriers. And the third big age old productivity barrier is... you hear this phrase all the time: the build is broken again. What are we going to do while the build is broken?

We are gonna wait. So, so looking at this... the build is broken again. Couple this with the wait, you know, we are waiting for our environments to be deployed. Those two big productivity barriers, when they hit your developers and your testers, your productivity of developers and testers plummets to almost nothing, because they are waiting.

They are not waiting for the environment to be deployed, their build is broken. So the solution to the broken build problem is pretty easy. Just spin up a developer cloud with a continuous integration solution to automate build and eliminate broken build issues. So if you can do that, you are going to again deliver peace and harmony between that developer and tester organization .

And our research shows that organizations that use continuous integration rarely if ever, cite broken build is one of their top software challenges. Once they implement a continuous build solution, the issue of broken build really goes away. And what they also say... our research shows that once people implement a continuous integration solution, productivity increase is tremendous.

We have seen productivity increase by as much as fifteen times once a continuous integration solution has been implemented. So, if you can overcome these top three barriers of, "it works on my machine", " we are waiting for our build", "we are waiting for our environments to be deployed" and "the build is broken".... if you can really overcome those, and eliminate all of that wait time, and eliminate those drains on productivity between your dev organization and your test organization, your customers are ultimately going to be very, very happy.

Because you'll deliver far more business value through the software that you are creating, testing and delivering. And by overcoming these barriers, be it works on my machine, my build is broken, I have to wait for my environment to be deployed. You're going to be able to deliver upon the proverbial "do more with less." But, you're going to have far better results.

So realize that the "do more with less" is really the norm. If you can overcome that and deliver better results through developer clouds, through using a continuous integration strategy, your customers are going to be much, much happier and the line of business is ultimately going to be much happier So let's take a look at some of Volk's research data to support developer clouds and advances in the testing market as well. So this research results that I'm showing you, this research was published in April of 2010, and the participants who participated in this survey were from very geographies and from varied company sizes.

And we asked survey participants what the biggest benefits were from developer clouds and virtualized environments. And the greatest benefits of a developer cloud to the surveyed participants were: a faster time to market; 51 per cent of them said they were able to have a faster time to market because they eliminated all of the tactical work.

They eliminated the wait time, they eliminated the provisioning of physical machines. They eliminated the idea of having a broken build because they had the tools they needed in the environment they wanted.

They also said that a consistent production-like environment was a big benefit to them. And this was a big benefit for testers specifically because they were able to work in a production-like environment and show the developers, give the developers a way to reproduce and recreate that defect in an environment as close to production as possible.

And the third biggest thing they got was a reduction in capital expenditures. And this is a big, economic benefit. So having a faster time to market, a consistent production-like environment, and a reduction in capital expenditures were the top three benefits that people saw from using a developer cloud.

But survey participants also told us there was something that was immeasurable: they had a better working relationship within their organization. Developers and testers worked better together, they worked better with the line of business, there was more of a higher level of morale within the organization.

So because people weren't waiting, because productivity wasn't plummeting, because builds weren't always broken, because there wasn't that phrase "it works on my machine" you had a better environment in which to work. And so these types of technologies really help organizations have better morale within the organization as well.

And this next piece of data - we specifically asked about testing productivity. Productivity improvements were characterized as increased test coverage, reduced provisioning time, improvement in the average time to market and decrease test time. And so if you think about it, the value proposition of what a developer cloud and a virtual environment can actually deliver is really defined by the reduction of physical environments, the immediate access to the needed environment when and where you need it through self provisioning, and the reduction of tactical work.

And all of these things really give you an increase in much needed strategic work. And this is a benefit to any type of organization. So use of developer clouds and virtual environments really help to facilitate the breaking of bottlenecks, which enable any organization to do more with less. While delivering on those customer demands that are not going away and the customer expectations that are not going away and we're reducing cost.

So what happens is this really equates to a win for every constituent in the life cycle. The line of business, the development organization, the test organization, the operations organization organization. Everybody gets a win from this because we have this quick return on investment. So based on our market research, we're making three big predictions about virtual labs and Developer Clouds.

The first prediction is that virtual labs and Developer Clouds will really be the hub of the modern application life cycle and we are seeing this really come to fruition as more and more organizations take on the use of Developer Clouds and virtual environments. What we are seeing is that organizations are moving from very all types of environments in both activities that they work on as well as the way budgets are actually handled.

So we're seeing silos be shattered and the development and the testing organization because the silos are shattered, their able to deliver higher quality software much faster to the line of business, to their end user customer. The second prediction that we're making is that Developer Cloud technology is really a major disruptor in breaking bottlenecks and really enabling developers and testers to get what they need, when they need it, and enable them to be more strategic.

And the third prediction we're making around this is that all industry sectors will benefit greatly from the quick return on investment that you can get from a developer cloud. So what we have here is the Vogue 2010 market array chart for testing platforms. And I wanted to put this in here today just because our host today, Electric Cloud, is positioned in this Vogue market research development chart focused on testing platforms.

And what we look at here is how organizations, how technology vendors are progressing with respect to technology and innovation and also with the marketing capabilities. So unless a cloud is ranked as a pivotal vendor in a testing platform, because of its unique approach to testing. And testing couples with delivering peace between that dev and test organization that you can get through a developer cloud.

In some of the advancement was seen in testing specifically from electric cloud, is that you can achieve greater levels of automation through the solution. You can leverage continuous integration and build verification testing to eliminate broken builds which in turn gives you higher quality software to production, to that line of business that is, is expecting and demanding that high quality software.

You can also leverage test scripts or harnesses across multiple platforms or devices to deliver as much test automation as possible. This is one of the things that will tell us all the time is that they're not fully automated or they're not automated as much as they would like to be. By using the electric cloud solution you can leverage those test scripts and deliver more automation across multiple platforms.

You can also automate the disparate test scripts in multiple tools, or multiple harnesses. And one of the other things that the Electric Cloud solution does, is it really enables complete visibility and reporting of assets across the build test deploy process. And I would encourage you to check out voking.com and listen to our complimentary webcast series on testing platforms.

So let's recap our discussion. We're living in a new world of constant connectivity. We're always on. We're always connected .We want to be able to use our applications and have a good positive seamless experience from any device regardless of where we are. And the software that we develop, test and deliver must be of high quality and to enable higher quality software developers and testers have to be more productive, they have to be able to deliver in a more strategic fashion and they have to be able to move beyond some of the artificial barriers and bottlenecks that have been set up in the organization.

Developer clouds deliver greater productivity for both developers and testers, and the greater productivity yields higher satisfaction from the customer. And embracing new and innovative technology such as developer clouds, you'll see a quick and visible return on investment. And it will help you eliminate those common age old barriers to productivity such as, it works on my machine I'm waiting for a build, I'm waiting for my environment to be deployed or the build is broken.

Those are the 3 biggest drains on productivity for developers and testers. And you can overcome these common barriers by embracing developer clouds and giving developers and testers what they need, when and where they need it. So let's take a look at some next steps. We invite you to come to vokein.com.

Listen to our complimentary webcast series on testing platforms and virtual lab management, and also we're conducting a survey on Agile; Whether or not you use it, whether or not you like it. So we invite you to come to vokein.com, take our survey, listen to our complimentary webcast on testing platforms and virtual lab management and check out our research.

Thanks very much and I will now turn it over to Martin Van Ryswyk from Electric Cloud.

Thank you, Theresa. It's always a pleasure to hear your comments on these issues. You speak to a lot of customers, a lot of vendors... and live in the analyst community and I always learn something listening to you so thank you. My name is Martin. I'm here from Electric Cloud just to tell you a little about our solutions and how they address some of the problems that Theresa just talked about.

And I'd like also apologize for our late start. I want to try to pick up the pace a little here to still get you guys out as close to the promised time as possible.

As Theresa mentioned, what we see in our customer base, what we see from the prospects and customers we talked to is, this is the head-nod-slide. Everybody goes, "Yeah, of course, development process is complex. Tell me something I don't know. I live in this world. I have lots of platforms perhaps, with tools to deal with, or geographic teams.

I've got infrastructure issues, and this has been this way for some time. The software development, particularly any kind of a project that gets more than 4, 5, 6 developers on it, starts to become and all the hand offs and you start adding QA and infrastructure to support that. It's gets very complex.

And what we also see is is just getting worse. Agile computing is something, I think, a fantastic movement. We used it internally at electric clouds to do Agile software development processes. It has helped us deliver better software with better quality faster. We love it, and I think the industry has embraced it.

When we do in-person seminars, we usually ask people to raise their hand, are you doing Agile, or have you thought about doing Agile? Maybe two years ago, we'd get a couple of tire kickers. Yes, we're thinking about Agile. We've read about it. Today when we do those sort of in-person things and ask the question, it's hundred percent yes.

We're doing some kind of Agile in our environment. It has really won the race for methodology. So, that's doesn't come free. Agile comes with many more iterations. Things have to happen faster. What used to be complex is now just more complex you have to get a team trained on this process, and everybody is doing things more often and I'm off to each other more often.

At the same the infrastructure layer, as Theresa also was just talking, is going through a big transformation. We've definitely experienced the world of, you know, I lived through open systems, was the big new thing, and then you went to virtualization and that also is just everywhere because the economy of scale and the money you save by doing virtualization is just too big to ignore.

And that is now evolving to what people are calling cloud computing. And in your own data center, that would be a private cloud, and we're experimenting with a public cloud. And so now, everything I had working before everything I was trying to keep strung together as I try to do it more often in my new agile way.

It's just getting more complicated because now I have to change out the infrastructure underneath. So, this is what we hear from all our customers. And there are our complexities that don't have to do with the infrastructure. That is the processes is also getting more complicated not just because of Agile but because of just what your software stacks and using components and hand offs and evolutions of testing tools and testing suites.

There are more just parts to the workflow that everyone has to go through. And now you are trying to crank that more often with Agile, and some of our customers, this happens to be a work-flow diagram that one of our customers gave us. This what we do, can you help us automate it? And the reason we want you to help us automate it is because we do it by hand.

It's slow. There's no visibility about what's going on. We don't know what stage at this we are really in. Someone from a remote office, unless they're on email, or chat, or some sort of wiki we set up has really no clue where we are in the process of something that if it was done automatically, should take minutes, and is taking days and hours.

Theresa talked about it works on my machine. And waiting for builds, and broken builds. And these are all problems we hear from customers and what they tell us is it because of these evolution that we're trying to do so much that it's just not working for us any more. And so, specifically around cloud computing there are many challenges in software development.

But to kind of focus a little bit specifically on the infrastructure and how it meets the developer and QA teams need. There's this very clear difference of what the two worlds want and need. Developer thinks about or development, and I included the QA teams in that, and production and deployment.

The folks who are writing the software care really about process. They want to be able to do things automatically. They want to say do a build of this release in the sandbox as Theresa was talking about. Giving me a sandbox with real production tools so that I can try this out, so I don't get blamed before it worked on my machine and I wanted it to be that branch on that platform form with this test set.

Maybe it's a smaller test set, what we call maybe a smoke test environment. That Q.A. has provided just to make sure it's not completely dead on arrival build. That's the way they think, they think in terms of "What I'm trying to accomplish with my software".

The folks providing the infrastructure layer are thinking "Well I want to be able to quickly let you spin up a box or a set of boxes, some networking, some storage, some infrastructure and some bms. I can make it very quick and easy for you to do that". But that still leaves the top group trying to push all those buttons, even if they've been given great new self service tools, they still have to push the buttons and string everything together.

And so this has created this bit of a gap as people try to evolve in this new world. I'd like to use these new cloud computing environments. I'd love to have unlimited resources and use it whenever I want it, but I don't want to have to know really that much about without it. So, from an R;D side it's, I'm still getting productivity and quality and all these other problems because I'm still spending a lot of time trying to connect to this infrastructure layer.

And the operations folks are saying "Well, I've got this great new this cloud-like or virtualization layer that should make it a lot easier for everybody to do their jobs. Why aren't people using it? And if they're using it, I don't get the benefits of scale, and the cost savings aren't what we thought they would be, and I'm not getting resource innovation.

Why aren't people using this? And we've ran into many situations like this with customers. Some of them who even had a fiat from above you will put in a cloud computing environment before they even knew what they wanted to do with it. And so what What electric cloud solutions do is, they help bridge this gap between the two.

They do that by bringing work-flow automation in, so I can have a workflow that is automated. That is exactly what that means. So I want to check out source codes. I want to do a CI build. I want to monitor a source code repository. I want to do automated testing. I want to automate deploy. They have a customer who wants to test their feature web app in as close to production capability as possible.

And so they use workflow to first build it, then test it, then spin up an environment that has the exact web application server version, and patches and configuration that they're going to use in production. And really the only difference is a little bit in scale and some I.P. addresses automatically push the application to that environment, and then do some system testing on it, automated systems testing, and some load testing, and some security testing, and all that happens at three in the morning while everybody's asleep and you get all the data back.

And that's that automation of that work-flow.

Being able to manage that workload so when you have suddenly this environment and you want a hundred, a thousand, ten thousand developers to be able to share in this environment, plus the testing teams, and the Q.A.'s, and the one-offs, and everything else. Now you have a workload that has to be managed.

You have to queueing. You have to alerts when things go wrong. You need to have emails to tell people that things are done, because of happening automatically. You need something that's managing this workload for you automatically. And you need something that's aware of the tools, no one two of our customers, one, actually of the customer uses the same tool.

We have many customers who have multiple products, multiple divisions that have different tool changes even between their products. But definitely no two customers are the same. What tools they. Some use open source source control. Some are using ClearCase.You having different defect tracking systems, different load balancing, so we're using a lot of open sourced Java tools and coverage from Clover, and Clover, and things like that.

Other people are using systems like clockwork to do static analysis, and they need something that can know about those environments, stitch the process together in the work-flow and have these integrations out of the box.

They need to be able to see everything that is going. What is actually happening in this environment, what did happen. I want as an operations person to be able to see what's happening right now. As a manager, or director or VP you want to look at my whole portfolio of products and how well is the product going.

As a VP of engineering myself, I love getting status that says we're on time. I like it even better when I see that the software is compiling, and built, and passing tests, and I can go play with it, and other people can come play with it. That gives me more confidence than someone just saying, "Yeah, I think I'm gonna make my schedule." I wanna see where the rubber meets the road, and that's the kind of analysis and reporting you can get when you see that your builds are succeeding, that's great.

They're passing tests, that's even better, and that it's working through the whole automated workflow and a human workflow that might even have manual intervention steps and I can see that from a high level dashboard. And of course all of this. If I'm going to start doing things in a more centralized fashion, in a cloud fashion, I need scale and security.

I need to have everything SSL. I need to have the ability to store passwords and secrets you control who can use them, and who can't. I need to be able to say certain sets of people are able to launch things, but they can't change them or see some of the secrets that are needed. For instance, I might need to log into a tool with a certain password.

I want someone to be able to invoke that process exactly how I wrote it, without modifying the process and I need the process to automatically give the password. But I don't want the person to know the password. So can a high level security like that...we have banks and other financial institutions and government agencies where this is very important and we've spent a lot of time and effort working through that to make sure we pass all those audits.

So, this is all kind of the abilities, the scalability, security, things like that you need to do in a centralized fashion. I'm going to skip ahead a little. This is a small subset of tools that we integrate with. We have hundreds out of the box integrations. This is just to kind of show where they land, and on the development process side between Dev, QA, Release, Ops all of the tools I talked about before.

On the infrastructure side, we have integrations to that part. That's why we're really the glue between these two pieces integrating with operating systems, virtualization, cloud, and being able to control spin up and use, consume, assign these resources to tasks. Now let me give an example. We have an automated bill at Electric Cloud that we use to test our plug-ins.

Some of our plug-ins are source control plug-ins. When we do those tests, we want to make sure that we have actually tested it against a real repository for elliptic perforce, for example. So when our build runs, it starts up a VM, a virtual machine to our cloud infrastructure that has that virtualization vendor software installed on it and configured with a test repository in a known configuration.

So I know exactly the change list that was the last one that was checked in. Then we build our software. We make another VM where we push our software refer to that machine and we silently install it and configure it. So we now have a working version of our software, a working version of the tool we want to integrate and then we kick off some automated tests.

Can I really check in, can I check out, can I get the data I need? What if I get a new version of a tool, are all the api's still compatible, do they all still work, do we get the information back we expected of a new error things like that. At the end of the build those machines are shut down and go away.

So we've integrated at the top with tools and at the bottom with the infrastructure layer to pull it all together so that this end to end sandbox was used to get some really good testing, and when it's done I can feel confident that yes that new version of software still works. Yes,our changes that we might have made in our software didn't break it, everything still works.

So this is having automated tests as well as automated tool integrations and automating from a CI point of view. We're a big believer that CI does not work if you don't have automated tests in there. It's great to say compiled. It's great to say compiled on one platform. But in realityOur customers are saying "My developers have a Windows or Linux platform they are developing on".

But when we ship we might ship on many platforms, many versions of those platforms, with many different service pacts. Many different combinations of things. Maybe foreign language versions of the operating systems and we need to test that whole matrix. The developer couldn't possibly just by saying it worked on my machine have known that it would work on everything.

And the CI or automated end to end process needs to have tests on all those environments. Big matrix problem. I'm sure many of you run into.When you put all this together, at Electrical Cloud we like to call it a "Development cloud", it is basically a very purpose specific implementation of a private cloud or public cloud that is for the software development organizations and it knows something about what they want.

I said earlier if I'm a developer I want to say I want to do this build on this brand with these parameters. That's my input that I get with this development cloud from electric cloud and it worries about marshaling all the resources tools and cloud infrastructure to get done what we want to get done.

So that is a very quick peek at electric cloud and what we do I just want to repeat that if you believe those problems that Theresa mentioned which we also hear all the time that you have heard developers say it works on my machine and yet it broke. I worked, you saw my bio, I worked at EMC, we had some very big software projects.

I was running 700 developers all over the world and we hit this exact problem. We had Japanese, Linux, or excuse me Japanese Windows failing in the field and when we traced it back the developer said, "Well, I tested it", well U.S. Windows that it was tested on. That wasn't good enough the automated testing wasn't catching and the people did not have enough time.

The, the, the human testers who were concentrating on new features and new, complicated things that have been put in the product and didn't have the scope, even though we had literally hundreds of them, to go through and do all the regression testing because regression testing is a huge matrix and it should be automated.

It should just be something that happens. Well if the human testers think about the complicated problems that only humans can think about, wow, we have this new feature, how are people going to use it? What might people do that I don't expect?

Just regression testing the "data in data out" is what it was before the same as it is now it should be automated. If you believe that waiting around is a problem the other thing that I didn't talk too much about, is when we're in this cloud environment we have the great ability to do things in parallel.

So now I can spin off, I have five developers each wanting to do one of these kind of test builds in the sand box that we were talking about to make sure that it works. Five can do it once, cause you've now provided a very flexible infrastructure with Electric Cloud and the infrastructure cloud layer underneath it to allow that to happen.

If one of those end-to-end workflows also could use some parallelization you can do that too. For instance, in our for bills, we first do the compile and then we start running unit tests at the same time we're building our installer. Because the unit tests don't work off the installer. They work right off of the source, or the compiled modules and the source code, so, for scripts.

So even though the unit test might fail and we might want to abort the whole procedure, we're willing to start building the installer all ready in parallel because it saves us an hour in the end-to-end time.

Now we have great facilities that if something is detected has gone wrong like a unit test fails you can make a decision. Abort the whole thing. Quit building the installer, quit building everything, send an email. Or keep plowing forward and when we're done we've saved them hours. And there's all sorts of little opportunities like that to do things in parallel, even with with inline work flow that can save you a ton of time.

And by doing all this as part of a rigorous process of everyone doing these types of end-to-end tests before they check into source code, you start to eliminate that broken build problem. We have two products in Electric Cloud. I've been talking a lot about end to end workflow, that's our electric commander product.

We also have a product electric accelerator. It accelerates the build part of the workflow the, I'm in the compilation phase, can get huge acceleration by doing massive parallelization in a cloud of that phase, but your commander is kinda core screen parallelization and end to end workflow and orchestration of this whole process.

Both products built from the beginning on top of a course set of fundamental beliefs we have at Electric Cloud that you should be using elastic resources that it should be enterprise scale, that data is important. That is, critical to have a single system of record, so you're not trying tie together, well this defect, what build was that fixed in, and what source code lines did that change, and where did that end up, and did that go to QA, and is that it's somewhere where I can play with it.

All of those questions should just be in the system, someone can just go click, click, click and find it rather than having to phone tree around or emailer , or I Am around to find it out. Phone tree, I'm showing an H here. And all of this should be reliable as heck, fault tolerant, secure and easy to use and be completely customizable, because one thing we know is our customer's environments are all different.

And with our solutions you can build new integrations if we don't have it, alter integrations if you're using a little different kind of a tool. If you have a custom tool that we never would have heard of and you want to build integration to it you can do that. If you want to change the UI within our product, you can do that....very customizable.

And working on top of all sorts of public and private cloud infrastructures. And I should say virtualization is the core to every public, excuse me, every cloud infrastructure I have seen. To me, Cloud is a management extension of virtualization that's bringing in more networking and more disc control.

So that you have the whole package all in one nice bundle, easy to use self service environment. So we see the, the spenders down all having a play. The VM ware, if your just using ESX, in a way is a cloud. It just doesn't have some for the fancier cloud management things that are coming out with EM ware now, it's provides that on top their basic effects package in a private cloud environment you can get those same benefits, you don't have to go to Amazon for big public cloud things although there's definitely benefits for that too.

particularly in testing. Okay, we'll skip the slide on all of our customers, the point here is all sorts of software companies use this from all sort of verticals and there's a good reason, it really helps them out. Here is our contact information, would love to have you guys give us call and tell us what your problems are before we tell you what our solution is and let our folks listen to your problems and tell you if we have something for you or not and more often than not we can help you out.

So please give that a try and with that I am going to conclude my remarks and through it back over to Francheska for questions and answers awesome, thank you so much Martin. Thank you also, for that great presentation Theresa and Martin. Now it's time to take questions from our audience and we've got about less than 10 minutes.

But I do want to remind the audience... if you want to ask Theresa or Martin questions, please type them into the chat box located just to the right of the screen. With that I'm going to jump right into it and Martin, the first question is for you. Do the developers and QA analysts use the same clouds in this environment that you've talked about?

Yeah, the answer is a good engineering answer, it depends. You certainly can. The great thing about clouds is most of the cloud management software and this is what makes it better than just pure virtualization and added things like making mini clouds or boundaries around it, being able to set limits about who can use how much... so you can can say look I have one big cloud infrastructure but I'm going to carve it up and development is allowed to get 100 boxes and QA's allowed to get 100 boxes and if development really needs more and QA has more, we can kind of move the bar a little.

But, for the most part you get the benefit when everybody is in the same, same boat.

Okay, great and Theresa, this next question's for you. Have less practices recommendations been developed for the SCM cloud process or processes? Yes, I think that is one of the things that we are going to see evolve over time. As I said in my presentation, we are really at the beginning of what a cloud can actually do for us and how all the tools that we've come to know and rely upon, in our physical environment, how they actually work.

I think we're still sort of figuring those things out and we're hearing a lot more from tools vendors these days about how their products are actually going to be able to work in the cloud and for the cloud. And you have to be able to delineate you know. Are you doing SCM in the cloud or are you doing SCM for the cloud.

Are you doing testing in the cloud or are you doing testing for the cloud. So I don't think we have a definitive answer on it yet or definitive best practices yet. I think that is one of the things that is still evolving. You know, with any cloud that you are going to use, whether it be public or private....you know Mark had brought up some really good ideas about how you actually sort of structure it and engineer it.But in whatever type of cloud you're using whether it be public or private.

Make sure you understand what the service level agreements are going to be, make sure you understand what the types of latency might be between what you're working on somebody else might be working on. Make sure you understand what the, what the procedures and the process are for disaster recovery and make sure you understand sort of what the promises are, what the service level agreements are for up time on that particular cloud as well.

So a lot of things that we dealt with on the network, dealing with on the cloud because the cloud is the basis of virtualization and also the cloud and we're still seeing best practices and services evolve.

Ok, all right and the next question, Theresa is for you as well. This person writes, I love it. You've convinced me that developers will benefit from the cloud usage. What about other areas such as QA and operations?

Ya, absolutely. I think that the cloud is something that is pervasive it's going to be for this it is the platform that we're are going to be delivering on in the future. So as I mentioned in my presentation, developers absolutely can get great benefit sent from the cloud. Quality assurance organization, being able to get more code coverage, being able to test more platforms, great, great use for a cloud for a test organization.The operations organization, being able to have that infrastructure that they know and understand and can manage and modify on an as needed basis for the type of environment that the application needs to be shipped in.

Great uses for all components, Deb QA and ops. And even beyond Deb QA and ops, you know, we're seeing a lot of organizations today. Any group really, really likes using a cloud. Or my sales and marketing organization really likes using a cloud for specific things. So the cloud is something so flexible that it's going to be used by every type of organization within an enterprise.

That way, ops, sales marketing training and so on.

Martin, how can developers share files between internal storage cloud storage and can access both?

OK, that's a good question. One of, that's one of the major features of both of our products actually. We have patents on moving data around. One of the features of the electric commander product is being able to set up what we call work spaces which is where files are going to be stored and those are definitely shared between clouds, between machines and clouds and between the cloud and the physical world.

And it's based on you know, just common network storage, NFS, Sands, thing like that and we just propped up some things in our environment where we have a VM ware V cloud director, cloud running and it's accessing data that is being shared with VM's running on people's laptops so it's just using network storage to use this all between.

All right. So we have time for a couple more questions. The next one is for both of you guys I believe. Yes. Does, this question reads, does my engineering or development organization has to be large in numbers to take advantage of developer.

Ms. Martin, maybe I'll take that one on first. The answer to know. Maybe at a certain point in history the answer was yes but prices have come down on hardware on virtualization. If you have five physical boxes from, let's say, Dell, and you get some pretty beefy ones that cost you two to three thousand dollars, couple of cores, a bunch of memory, and you put some network storage on it.

You have the capability to run fifty or so virtual machines in and out and maybe even at the same time depending on what you're doing. We run a lot of VM's on one box. And so the cost to doing that is actually cheaper for my smaller organization, we have about 40 in engineering and electric cloud, than it would have been to buy the physical machines.

It was actually more cost effective, so that's just on the physical side, and then the cost savings they get from all the profit savings from doing things twice to have things done automatically has allowed me to put out more product to the market than my competitors so I'd say there's no lower bound on size.

Because you're probably going to pay the money for something anyway; just do it efficiently instead.

Yeah and I completely agree with Martin. You know, the economy is driving innovation and what we're also seeing is the democratization because of what the economics are actually delivering to us because the cost has been reduced so much. And when we go off and talk to clients and when we do surveys, we get a pretty good demographic response from organizations of all size, you know, and it used to be just the large, you know, maybe Fortune 100 company who would be able to take on a new technology and really experiment with it and deliver the benefits to their customers.

But with something like the cloud, we're seeing that organizations of all sizes are embracing it and getting benefit from it, and it's able to really do more with less and that's sort of the norm and the standard that everybody is living by now is that do more with less. And by the economy driving innovation, and allowing things such as a cloud.

You can do far more with far less regardless of the size of your organization, whether you're a Fortune 100 company, or whether you're a small business type of environment where maybe there's three or four developers. So the economics of driving innovation and do more everything with less is the norm and take advantage of it.

Right. Thank you for that answer. Now we've got time for one more question and Theresa this one is for you. What I test is a system of systems. Where the cloud is a part of one of the systems. Is it possible to do a test of the system of including a cloud inside another cloud.

Absolutely. Anything is possible. Anything is possible, and that's something that, you know, that we're going in the direction of is the systems of systems because of the complexity, because of the integration. You absolutely can do a test of a system of a system of a cloud inside of a cloud. Take a look at the suite of test tools that you might be using.

Take a look at Electric has to offer with Electric commander to help do something like that. So, it's completely possible, and you have to really understand how your application is going to work, but the big thing I would add on top of that is look at performance. How is your performance actually going to work if you're doing a system of a system of a cloud inside of a cloud?

 Is that actually how your customer's going to be using it? What are the performance requirements from the line of business for that particular type of application? Performance is one of those things that as we see more and more applications deployed to the market on a cloud, performance is one of those things going to come back and it will be top of mine and top of the conversation, as well.

Okay, wonderful. Alright. So, thank you so much eats up all of our time or we have no more time left, I'm sorry, not eats up.

And at this point I just want to thank everybody for your participation and thank you again for joining us today, Theresa and Martin, and thank you to the audience.

Thank you everybody.