Case Study

Categories

Cloud Computing Security

In response to a cloud computing question I posted to an online forum discussion a concern was raised about security.  Here is the unedited response in full:

“I think cloud computing is extreamly dangerous. There are enough problems with viruses now. IF people were able to exploite holes in componants use din cloud modules or even write systems with back doors in would anyone be sure thyey have a sucure or safe system?”

As I noted in previous posts, security is indeed one of the key drivers of the adoption of cloud computing.  And trust will be a crucial ingredient in the “crossing of the chasm” of this technology and use model.

There is always mistrust of new technologies.  (Did you know that in the very early days of the motor car some scientists believed that passengers would suffocate at speeds over 20 mph?)  Some mistrust is well placed and drives innovative counter measures.  Others will need greater familiarity with the technology and leaders to follow.

To address the first aspect of the posters concern though - viruses and their contagion.

For a virus to be communicated three things need to occur.

  1. Placement of the virus at the source.
  2. Inadvertent download of the virus by the user.
  3. Execution of the virus on the local machine.

There are three parties one could imagine placing the virus within the remote hosted application in the cloud: the cloud computing host company, the vendor of the hosted software, and users of the hosted software.  For a cloud computing company to go to all of the time and expense in developing sophisticated cloud computing platforms such as Xuropa’s Online Labs just to spread a virus is nonsensical.  Like-wise, for the owner of the electronic design software to place a virus within the Online Lab they are using does not make any sense whatsoever.  The last suspect, other users, could have the motive, but they will not have the means.

Consider the use model of a Cloud Computing-based EDA tool in the context of a Xuropa Online Lab as an example.  Every time the remote tool is accessed through a lab session, the environment is provisioned fresh and new from an image that is created by the tool vendor and Xuropa engineers for the Online Lab.  This image is inaccessible to a user.

While the session is active, only users that are explicitly invited into the lab session can have access to the work being carried out by the person who initiated the session.  There is no way for someone to sneak in via a “backdoor”.

If the user was malicious and did upload a virus to the Online Lab they would be very disappointed.  After every lab session has ended all data is erased, all processes on the lab are terminated and a thorough clean of the remote environment is carried out.

The Online Labs hosted on the Xuropa Platform today are even more secure in that they do not provide any upload or download capabilities by design.  No code is executed locally.  This talks to the gradual progression to the cloud of a previous post.  There are great benefits to be gained by leveraging cloud computing without leaping straight into design and development.  Training, demonstrations, workshops, pre-evaluation, and technical support to name just a few.

Which brings me to a follow up observation: mailing of CD’s for evaluation.

Today I opened the EDA Tech Forum magazine and it contained a CD from a nameless EDA vendor.  At the bottom of the CD is written “Every effort has been made to ensure that this disk is virus-free. “XYZ Company” is not responsible for any disruption, damage and/or loss to your data or system that may occur while using this CD.  As with all software we recommend running a virus scanner before use.”

I’m sure that this CD is fine.  The probability of it containing a virus is very, very low.  However, the reason why the lawyers of XYZ Company told their marketing department to include that disclaimer is because of control.  More specifically, it is because of the lack of control.  Once that CD leaves the door of the vendor they don’t know where it could go and through how many hands it will pass.  It is highly unlikely that they burned the CD themselves either.  They will have used a service provider that stamps out CD’s with the label by the hundreds at low cost.  Again, another point of loss of control that keeps the lawyers up at night.

However, with a Xuropa Online Lab you not only have complete control over the environment and who uses it, you also don’t have to go to the wasted expense of sending out hundreds and thousands of CD’s to people that have no interest in the product at all.  (Not a very green approach either.)

So in summary, the cloud is extremely secure.  It is in everybody’s best interest to make it even more secure.  For those malcontents with too much time on their hands life will actually get more limited with a move to the cloud.

You can reduce your overall marketing costs, decrease your “carbon footprint”, and let your lawyers sleep easier by moving to the cloud.

Keep control and keep lawyer fees to a minimum - not a bad thought going into the new year.

Click here to register for the Xuropa Online Electronic Design Community

Posted under Features, Xuropa, business, industry, marketing

This post was written by James Colgan on December 24, 2008

Tags: , , , , , , ,


 

How to build to last (or at least grow for a good while)

One of the advantages of the software-as-a-service SaaS (or even a more broad Web 2.0) business model is that the starting costs could be relatively low and even with a few (good) engineers it’s possible to reach a revenue-generation point in a short amount of time.  However, what do you do so you are able to profitably grow after you hit the first-revenue point?
As part of my consulting and advisory work, I have been involved in several SaaS companies this year.  Two of these companies helped me understand what kind of approach it takes to build a company for the long haul.  One of them: by not doing as they did; and the other one: by trying to do what they did.  Note that both companies were based on brilliant ideas.
Earlier this year I worked with a local internet advertising company which shall remain nameless (the protect the innocent).  Let’s just call the company “J”.  J was a very based on a very clever idea to use a mobile platform and integrate it with the internet to enable local merchants for advertising (to local markets).  I was consulting with them as their chief operating officer and as part of that I repositioned the company as a SaaS company and got them to a fund-able state (in a very un-funding market!)
J’s CEO was the one who had come up with the idea.  She was an early employee of an early internet company (i.e. mid 1990’s), but altogether she wasn’t internet technology-savvy.   So, she decided to contract out software developers to build the technology.  The company was still getting formed, so she had decided that the employees (contractors and others) will all work remotely from home office, library, Starbucks, etc. - after all, that’s one of the benefits of starting an internet company.  Due to her management style, she wanted to be the broker for all information sharing.  In addition, “to cut costs” we never got together early in the process to define terminology, hand-offs, procedures, etc. - and decided to instead do it on the fly when we needed it.
None of the above prevented us from moving forward, creating a product, marketing it, selling it, etc.
But ….
1.  Since we had contracted out all of our software development, every time (literally) we needed a product feature enhancement or a new capability added, we had to decide and approve first the cost of estimating the development cost, and then the cost of actually performing the development.  Even a small feature update or bug fix caused a decision point.  We spent more time deciding on minor iterations than actually performing the iterations.  The team spending time on these decisions was at not expense (we were all “paid for”) but the software development was an expense.  In more cases than none we decided to postpone the bug fix or the feature update, in order to save on expenses.
Making minor (and even major) iteration on product capability is a critical part of product formation in a high technology company, and we were handicapped by not being able to nimbly address them.
2. During the early days of startups, what is really important (and cannot be replaced) is the free and open brainstorming.  In their early days companies brainstorm on everything:  product, business model, personnel, financing, selling points, everything …. down to the color and the location of an item on the website.  Some of these decisions are more or less critical to business, and some are not, but even the ones that are not critical to the growth of business might be a key emotional enabler for personnel issues - at every brainstorming session there are emotional stakeholders.
Not having a common work place, we either had these brainstorming sessions on email or on the phone, which a) are extremely ineffective, and b) do not meet the emotional needs of the stakeholders.  I can’t believe how much money we didn’t save by not meeting face to face everyday for a good number of hours.
3.  When we did meet, we spent a fair number of minutes making sure we’re all talking about the same thing.  One example: We once had a conference call to decide what needs to happen on our “landing page”.  This conference call included people from the Los Gatos, Saratoga, Santa Clara, Sunnyvale, Campbell, as well as somewhere in Pennsylvania.  For 20 minutes at the beginning of the meeting the discussion was going around circles.  It suddenly became obvious to me that the term “landing page” had different meaning to different attendees.  So once I suggested to first define the term, everyone agreed (in relief) but we spent the next 40 minutes discussing the definition itself.  That meeting did not achieve what it was meant to achieve.  This is only one example, but a telling one!
Then ….
A couple of months later, I started my advisory role at Xuropa.  Xuropa had been in business for about 9 months.  They were almost at the product release point.  But they had done things differently (than J).
1. Xuropa’s founders included a technologist (software developer) - a very capable one.  The original seed technology was not contracted out.  This had two major benefits:  1) the code base was not a hack done by several short-termed developers and it was constructed by one single team and “all parts of the software were talking together”; 2) The cost was already incurred, so each enhancement was not a new “expense” and hence not subject to an ROI discussion.  As a result,  when I suggested an update or feature enhancement, it was done quickly — sometimes in a matter of minutes: the developers were involved from the first day so they knew exactly what and where needed to be changed - they would just make the change if they agree with it.
2. Xuropa had an office space - nothing luxurious but very functional.  Many might argue with its necessity, especially with the costs involved and in such an early stage.  Xuropa took a very interesting approach.  They started with an office space to get the company started and to a solid and stable point, and only then they decided to become “remote” to minimize the costs.  They had realized that the brainstorm time together in the early days is critical and worth far more than any savings they would make by not having an office space to collate everyone.
3.  From what I understand, Xuropa’s founders spend a good part of their first 6 months defining terminology and processes.  This made the company extremely efficient in meeting times and other exchanges.  Emails became shorter and shorter without losing any of their specificity and content.  Conference calls and meetings were efficient.  A few weeks ago, I had a blog post on doing better rather than just doing more.  A lot of companies advocate over-communicating to make sure things move forward without a glitch.  I prefer communicating better rather than just more, and if the terminology and processes are defined in advanced, it’s very easy to just communicate better.
###
I’m not hoping to rewrite the book “Built to Last”.  Nevertheless, a few observations, just this year, made me realize that there’s always the tendency to think penny wise and pound foolish.  If one is building his company for the long haul, he needs to resist the urge.

Posted under Xuropa, business, career, industry

This post was written by Michael Sanie on December 22, 2008

Tags: , , , ,


 

Losing Your Way Through Adwords

So far we’ve been able to keep the Xuropa Platform an ad-free zone.  We provide value to our clients by enabling them to build engaging communities around their products.  They lower marketing and support costs, and are able to build and nurture relationships globally without having to get on a plane or attend an expensive trade show.  That’s how we aim to support our business and we’d like to keep it that way.

There’s another reason we’d like to keep ads off the platform - real estate.  One of the hardest aspects of building a platform of this degree of sophistication is the user interface and use model design.  We have lots of ideas for cool features and functions, but it’s always…”where do we put it?” and “how are people going to use it?”

However, when push-comes-to-shove and ads are your only source of revenue, other than a sense of “yikes!”, I can understand the compromises in design and usability that have to be made.  But, when the reader of your blog has to scroll down past three columns of ads to get to your post you’ve lost your way.

Lost Your Way I

Lost Your Way I

When your ad is threaded within your post in such a way that the title of the post actually looks like it is “Ads by Google”, you’ve lost your way.

Lost II

Lost Your Way II

When I was at the EDA Bloggers Birds-of-a-Feature meeting at ICCAD last month it was great when Rick Munden stated that he had taken all ads off his blog.  When I asked him “why?” he pointed at Sean Murphy (the organizer of the meeting), who came back with the perfect analogy.  “Why advertise cup holders when you’re selling a Cadillac?”

Sean’s absolutely spot-on.  Most of the bloggers that I see out there are doing it on the side as a marketing promotional tool for their day-job.  More often as not it appears to be consulting or contracting work - the Cadillac!

Unless you think that advertising can be a driving revenue stream for your business, don’t do it.  It can cheapen either the perception of your core product or the message within your post advertising your core product.

If the additional revenue stream can be a significant contributor to your business model, then please do yourself and your readers a favor.  Position your ads without compromising the readability of your post or the usability of your blog.

Less is definitely more in this case.

Click here to register for the Xuropa Online Electronic Design Community

Posted under business, marketing

This post was written by James Colgan on December 19, 2008

Tags:


 
« Previous Entries

Search