The Xuropean The Xuropa Online Community Blog

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.

Posted under Features, Xuropa, business, industry, marketing

In the previous posts in this series we covered some definitions of cloud computing; drivers of the transition to cloud computing by electronic design tools; and a potential roadmap for how this transition could look over time for the EDA tool flow.

In this post we conclude the series with a discussion of different approaches to Cloud Computing.

Remote Access and Cloud Computing Approaches

Cloud Computing could be thought of in different ways, but as with the adoption of most new technologies it will be gradual and in different forms.

Tool Access Models

Beyond the completely locally hosted scenario, there are three basic remote access and SaaS models available today.

VNC (Virtual Network Computing)

This scenario is built upon technology and tools that have been commercially for a few years now. It takes quite a bit of maintenance and support on its own and is not extremely user friendly on its own. However, many electronic design firms are using this for different phases of technology adoption. Engineers also typically use VNC to access tools that are internally hosted.

This is not “Software as a Service”. It an ad hoc technology that provides remote access in a bare knuckle fashion. Software needs to be installed on the server and the client to set up the environment. Connections are set up from the command line and not very user friendly.

EDA SaaS 1.0

As has been productized within a Xuropa Online Lab™, this is an infrastructure that provides systematic, secure remote access to an EDA tool without any installation, setup or teardown by the user. The tool is available on demand and provides for an ideal environment within which to carry out many of the tool adoption phases above.

SaaS and Tool Adoption Process

Also, a Xuropa Online Lab can be extended to provide a design environment allowing the user to upload and download design files. This last model can be adapted to provide SaaS remote access to the EDA tool and would be ideally suited to perform evaluations and even utility of some tools under the right use-model.

For existing EDA tools, this is the shortest, most secure and economical way to place your product in the cloud to provide global access to your market.

The hardware supporting this environment could be a dedicated server or a server farm running virtualization software to maximize resource utility and lower costs. The hardware could be an internal or leased server farm with VMWare or Parallels software. There are other commercial providers of Cloud Computing, the most widely quoted is Amazon with their EC2 (Elastic Compute Cloud).

Above and beyond the Xuropa Online Lab, Xuropa provides services to extend this product to accommodate different use- and business-models. Please inquire for details: sales@xuropa.com.

EDA SaaS 2.0

Using similar hardware configurations as described with SaaS 1.0, this architecture requires the replacement of an existing user interface with a web-based user interface. Alternatively, a new company wishing to broaden the reach of their core tool engine would begin by building a web interface and make it scalable and accessible globally from the start.

There are two early examples of this within electronic design today. Think Silicon provides IPGenius™ as a web service to generate IP cores from different configurations. PDTi™ provides a web-based tool called SpectaReg that is a web enabled collaborative development environment for addressable register interfaces within an SoC. In the past 3 or 4 years this space has become crowded with competing commercial solutions or internally developed frameworks. A SaaS approach is a great way to compete on business model and support model.

[You might want to have a paragraph of the issues/costs of maintaining two versions, one a “regular old” EDA version and a second SaaS version of the tool. And perhaps how Xuropa knows and can offer services to reduce that cost. Just a thought!]

The business model will also migrate from a per-seat time-license model that the user has little control over to a cost-per-“X”, model where “X” can be a number of different parameters. For example, X could be the number of bugs found, the number of cores integrated, the number of regressions run, the length of time the tool was used, the number of designs created, the number of micro-watts saved, etc. ie. the model could be a simpler time/user-based model, but it could also be more tightly tide to the value a particular tool delivers. And the real power of this model is that these metrics can be measured.

Not only can more creative business models be created, but they will make more sense and be more easily and naturally support by both vendor and user.

If there wasn’t such inertia within the existing EDA business models the business model could be a driver that trends gradually towards change, but then experience a significant “tipping point” as a major player changes the rules of the game.

Whether your company is looking to move an existing tool to the web, or is developing a tool for a SaaS model from scratch, it is important that you focus your resources on your core value proposition – your tool’s engine. Xuropa SaaS Design Services is the ideal strategic partner to collaborate with. Leverage our web and EDA expertise and the Xuropa Infrastructure to realize your SaaS vision. Contact us for more information sales@xuropa.com.

Conclusion

We’re at the beginning of a trend, but without a doubt it is a trend. There are 4 key drivers to the development of the use of Cloud Computing and the adoption of SaaS as a business model, and gradually these drivers will align for different products and different companies.

While the drivers do not align for some companies and products just yet, the electronic design industry is primed for a change of this magnitude. Business pressures due to macro-economic “re-adjustments” could be the catalyst for the trend. Also, for those start-up EDA companies that either cannot get funding or are not able to obtain their Series B or C, moving to a SaaS model could be the only way to penetrate accounts, global markets, lower the cost of sales and out maneuver their competition. It might even be a way to get VC’s interested in EDA again…maybe.

SaaS also offers opportunities to semiconductor vendors. It is a way for them to reduce their total cost of ownership and increase their flexibility. Not all of their CAD department is tightly coupled with their value proposition. In much the same way as having a fab no longer became essential to a semiconductor’s success, an internal CAD department could go the same way through SaaS and Cloud Computing.

Finally, there are many benefits to SaaS and a Cloud Computing model for the end user.  They always have access to the latest revision of the tool without the pain of installation and transition.  They also have an environment that is architected to operate in a distributed and collaborative fashion across specializations and teams.  This will remove a lot of the friction and inefficiencies within geographically distributed companies.  And the business will be a pay-as-you-use or a results/value-delivery model, which should result in a higher return-on-investmet.

If you’re considering making the move, drop us a line and let’s discuss. sales@xuropa.com or register within the community and send me an email from my Xuropa Professional Profile – Search for James Colgan within the Community area.

Posted under Features, Xuropa, business, industry, marketing

Cloud Computing Adoption Roadmap for Electronic Design

In previous posts in this series we covered some basic definitions and the basic drivers to adoption of cloud computing by the electronic design industry.

In this post we discuss a different vector along which to view cloud computing adoption and a potential roadmap of tool type transition.

A Different Vector of Adoption of SaaS Model

There is another vector of transition that is worth exploring. Even if some EDA tools do not lend themselves to moving directly to the cloud, there are phases of the adoption process that are.

Considering the adoption process, there are four main steps: demonstration, training, evaluation, and use.

Technology Adoption Process

Demonstrating a tool via the web is already available using services such as Xuropa’s Online Labs. These integrated environments can also be used for training purposes. But this is only the beginning.

As each phase of the technology adoption process moves to the cloud, a positive psychological and behavioral effect will occur on the subsequent phase. Ie. for some tools, the user will question, “if I can get training for a tool online, why can’t I evaluate your next alpha release online too”. The value proposition will be convenience and time saved. There will be no installation required, less technical support and no conflicts with existing environments when the alpha release is used. Also, as bugs are fixed in the alpha release they are immediately reflected out to the user. This improves their experience and increases their potential of adopting the new revision of the tool when it goes to general release.

Again, the transition is not black and white. Some tools, some users, some situations lend themselves to a move to the cloud. However, as we move forward, each point in the process will undergo a “tipping point” and the transition will occur.

Transition of the Flow

As has been alluded to previously, a fundamental premise for this paper is that the transition will be gradual and it will depend on many components. Not least of which will be the architecture, use-model and implementation of the tool to make the transition.

Below is a much simplified abstraction of the semiconductor and software development flow. Considering the 4 Drivers described previously, it would be easier to note those pieces that would be slower to transition to the cloud.

Electronic Design Tool Flow

Hardware/Software co-design and co-verification has tool and methodology related technical challenges that could slow a transition. But the process of system development and the fact that the two teams holding the disciplines are often separated geographically would lend itself to a remote SaaS model. This could be valuable for at least the early stages of the product development project. It would resolve issues around versioning and facilitate collaboration between the disciplines.

Analog Mixed-Signal could well be a slow mover as simulation runs can take days and present a quality of service challenge. Top-level chip simulation could also be slow in adoption for the same reason.

Synthesis will be slow to move over due to the sheer massive amount of data involved. And test would be a challenge as the actual chip is needed.

However, all other parts of the flow should be possible to transition to SaaS, including emulation and test.

EDA Tool Adoption Curve

In the next post in this series we’ll look at different approaches in the transition to cloud computing and SaaS for electronic design.

Posted under Features, Xuropa, business, industry, marketing

The Drivers of Cloud Computing Adoption

The previous post in this series laid out some basic definitions and a premise of where the EDA industry is with respect to the adoption of Cloud Computing and SaaS.

As with any move to a new technology, there are drivers towards adoption and points of inertia slowing down the transition.

Outside of trust, the number one objection that I hear to Cloud Computing is performance.  And indeed, this is a key inhibitor to many parts of the EDA flow. But not all.

Cloud Computing Adoption Drivers

Above is the start of a model that could help us understand if there is indeed a path towards Cloud Computing and what the environment would have to look like to get us there.

“Trust” has not been called out separately. In reality, “Trust” is a nebulous combination of all of the above factors and is individual to the specific potential user. The added mystery ingredient being, “who else is using it?”. (Consider the psychology around the use of credit cards on the web in the mid-90’s or the adoption of an IP core.) The other aspect that could be added is “Robustness”. Maybe that driver is significant enough to have its own representation, but for now I’m considering it within “Performance”.

Business Model

This is where it really all starts. If vendors and users were perfectly happy with the current business model within EDA this conversation would never likely arise. However, as has been brought into stark relief recently, the business model could well be the largest challenge that the EDA industry faces today. Above and beyond moving to the next process node.

This can be broken down to two aspects:

1. Revenue generation
2. Cost of sales

Though large EDA vendors have revenue streams to protect, they are constantly pressured to reduce costs. Even with a focus on just the top “10” or “20” semiconductor vendors, there are design centers spread all over the world that need technical support and training. To put an AE on a plane or ship out lap tops for training is expensive. Also, Webex-like tools have limitations that impact the usefulness of online tutorials and training. Especially across time-zones.  Users need to have access to the tools themselves - not just be shown them.

The change in business model for a large EDA vendor would be a significant inhibitor to moving to a cloud computing SaaS model. However, as mentioned later, the move beyond EDA to become a “development infrastructure” provider could be an attractive way to look at the problem differently and stimulate growth.

Alternatively, this could be a business model to support infrastructure partners, such as design and verification service companies. By providing their tools as a SaaS (is this “TaaS” – Tools-as-a-Service?) to these partners would encourage proliferation into the service provider’s clients and also lower the overall costs to the partner directly.

Smaller companies have both the cost and the revenue generation challenges. They cannot afford to put in place a large sales team to penetrate a global market. And they’re also open to trying new business models as a means to differentiate and compete.

For medium to small EDA vendors the benefits are clearer. The SaaS model not only enables a smaller company to compete with the large vendors on a new front, it enables them to overcome sales resource limitations. By providing their products via the web instead of directly, a small EDA vendor can now serve the global market without building an expensive sales team.

The bottom line - a requirement to improve ROI, regardless of size.

Cost

I wonder what the percentage utility of the servers in the data centers of large semiconductor vendors is? I would bet that it’s pretty bursty over time and on average fairly low. (Anyone got any data?)  If they’ve employed virtualization, utility would have increased significantly, but it’s still a burdensome cost.

Building and maintaining sophisticated server farms is an expensive proposition. Importantly, across the industry it represents gross duplication of investment that does not lend itself to a semiconductor vendors core value proposition. This makes it a prime target for outsourcing to a specialized outfit that can amortize overall costs across multiple customers. Thus reducing the total cost of ownership to individual semiconductor vendors.

An additional benefit to moving EDA flows and their accompanying hardware into the cloud is the conversion of a capital expenditure into an operational one. Acquisition of a service is more streamlined, cheaper and flexible. This would be extremely attractive to start-ups and provide a cost effective method for EDA companies to support them.

Of course, challenges exist for an EDA company to offer their tools via the cloud and to take on additional costs. However, this is an opportunity to differentiate and provide more value to their customers. To move from a tool provider to a “development infrastructure” provider.

One more benefit would be the potential to reduce product development costs. Moving product deployment to a SaaS model would mean that all users are using the latest revision of a tool all at the same time. Upgrade control would be in the hands of the vendor. This would reduce the cost of tool maintenance that would increase the overall efficiency of the industry.

In essence, the movement of costs and the overall opportunity to reduce them provide opportunities and benefits to both EDA and semiconductor vendors alike.

Performance

Performance requirements can drive a tool to or from the cloud depending on the use model and the application itself.

Tool Use Model

Tools that are used continuously with tight iterations may need to stay “local” for a while depending upon their resource requirements. “Bursty” use-models (eg. regression testing) and developments that are stretched geographically would lend themselves to a transition to the cloud.

Some EDA tools are extremely resource intensive. In the past processor, memory and hard-disk requirements would have presented a significant challenge. However, there are infrastructure services available that could accommodate many tools out there.

The challenge that would slow down some applications making the move is bandwidth and latency. For example, interacting with 3D representations of a stacked die would be annoyingly slow when compared to a local application.

However, performing design verification should be straight forward and in our opinion is an application area ripe for transfer to the cloud.

Many engineers are already using VNC to connect to remote servers hosting tools. Many tools are operated in batch mode from scripts and after set up and test are not actively interacted with by the engineer. These types of use-models do lend themselves to transfer to the cloud. Compute intensive applications however, will keep some tools local.

A significant aspect of performance is continuity of service. Service guarantees built into license agreements will be needed to move cloud computing beyond the early adopter phase.

So, depending on the tool, this driver can go either way right now.

Security

This is likely the biggest hurdle to the adoption of cloud computing wholesale. The transition to the cloud will be largely dictated by the degree of actual and perceived exposure and the associated cost-benefit.

Releasing fundamental intellectual property outside of a semiconductor vendor’s “walls” will take the building of tremendous trust and the accompanying legal and technical infrastructure to support it. However, I know of large semiconductor vendors that are already allowing IP onto their supplier’s servers. In particular in the verification domain. It won’t be the whole chip, but it will be individual cores or small “tiles” (sub-systems).

The transition will continue over time and at different rates, but this obstacle is not insurmountable.

So, in summary, there are four main drivers that either accelerate or slow the transition of tools to the cloud. It is because it is not clear-cut and that there are opportunities to compete, reduce costs and create efficiencies that the transition has not only started, but it will continue.

In the next post we will discuss a different way to look at the adoption of cloud computing and SaaS by EDA vendors.  A potential cloud computing adoption roadmap for electronic design.

Posted under Features, Xuropa, business, industry, marketing

Cloud Computing and SaaS (Software-as-a-Service) have been at the heart of the vision of the Xuropa Platform from the very beginning…on the proverbial napkin back in May, 2007. It’s current incarnation is captured with our Online Lab facility, and our development progress is metered by the adoption rate of key concepts by the electronic design industry.

This first post in a series of 4 was spurred by Daya Nadamuni’s article in EETimes.com and many conversations with a huge proponent of Cloud Computing and SaaS for EDA, Harry Gries (aka The ASIC Guy). I thought it was time that I took a crack at articulating how I see this technology evolution and it’s application and adoption within the electronic design industry.

Definitions

As with any “next big thing”, the definition of Cloud Computing will evolve over time as it’s better understood and the software industry moves the ball forward. However, it’s important to note what Cloud Computing is not. As we saw within EDA and the stretching and pirating of the definition of “ESL” in the early days, it’s important to have a common understanding.

Wikipedia offers a pretty good and comprehensive description and definition of Cloud Computing.

I’ve paraphrased points here for convenience.

What it is not:

- Grid Computing: “The application of several computers to a single problem at the same time.”

- Utility Computing: “The packaging of computing resources, such as computation and storage, as a metered service similar to a traditional public utility.”

- Autonomic Computing: “computer systems capable of self-management, to overcome the rapidly growing complexity of computing systems management, and to reduce the barrier that complexity poses to further growth”

It’s a little tricky, because as is noted in the Wikipedia entry, “many cloud computing deployments are today powered by grids, have autonomic characteristics and are billed like utilities, but cloud computing can be seen as a natural next step from the grid-utility model.”

Cloud Computing Components

I’m a huge fan of models like the OSI Seven Layer Model, and the Wikipedia editors of the Cloud Computing entry have taken a shot at capturing a hierarchy of its components. I’m not sure I completely agree with this model yet, but it’s a good start.

Cloud Computing Stack

Client: self explanatory. The combined device and browser system.

Services: These are support services intended to be used by Applications. Eg. Google Maps and PayPal.

Application: Software applications that are accessed via the web and leverage cloud infrastructure. Peer-to-peer (Skype); web-based application (Facebook, Xuropa (networking, news, and other applications) ); SaaS (SalesForce, Xuropa (Online Suite, Booth, and Kiosk); software+services (Microsoft Online Services)

Platform: A software application delivery environment. A key differentiator between a Platform and an Application is the degree of openness. In the case of Facebook Apps, the API is open and is written to by third parties who then have their application delivered to users within the Facebook environment. In the case of a Xuropa Online Lab it does not make sense to create an API for software vendors to write their tools to. And so we took the “API” down to the logical level – the Operating System.

Storage: Remote storage that is made accessible via the web and charged as a utility. Pay as you go/use. Eg. Amazon S3 (Simple Storage Service)

Infrastructure: Essentially the hardware resources and utilities to manage and make upper layers of the stack available via the web. Eg. Amazon EC2 (Elastic Compute Cloud).

Another example may be illustrative:

A database accessible via the web can be presented in three different ways to users.

• Raw database that is accessible via the web: Application
• Database with a UI (eg. Salesforce): Application
• Database with a macro API that can be written to and the resultant applet/macro/widget hosted and accessed by other users of the database: Platform

Adoption By Electronic Design: Where are we?

As can been seen from reviewing the above model, aspects of Cloud Computing are being used by the electronic design industry today: webex, Skype, salesforce.com, etc. But these are support services in the context of the EDA industry.

The rest of this series discusses the use of Cloud Computing and SaaS at the heart of the EDA business: delivery and monetization of electronic design software applications via the web.

99% of people in the industry to whom I mention Cloud Computing state with great conviction that it will never happen - “it’s been tried before”. And if they’re anticipating a step-function adoption that will stretch across the entire flow and be able to serve mainstream semiconductor vendors from the start, then they’re probably right. But that’s never the way things happen.

[“All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.” -- Arthur Schopenhauer]

A common theme that recurs across these conversations is “trust”. And as with any new dislocating technology, this is a major hurdle to mainstream adoption.

So, regardless of all the buzz out there, this is where I think we are today:

Cloud Computing Technology Adoption Curve

So far, not very far.

The next post in this series will address The Drivers of Cloud Computing Adoption.  What industry components make cloud computing and SaaS attractive, and what would potentially slow adoption down.

Part three of the series presents a potential roadmap of cloud computing adoption for electronic design.

Posted under Features, Xuropa, business, industry, marketing

There are nearly 800 companies entered into the Xuropa Company Wiki now!

EDA, IP, Semiconductor, Software and Systems companies are represented.  The entire supply chain!

The wiki entry for each company includes a logo, description, contact information, and many more pieces of useful information.  But there are some entries that need “help”. Sign in and you can edit the information for your company.

1. From iXuropa, click on the green “TradeShow” icon
2. Click on the “Company Wiki” tab
3. Find your company using the alpha directory
4. Click on the “Edit” link and fill in the information
5. Click “Submit Company” and you’re done

If your company is not in the directory, add it yourself by clicking the “Add your company” link at the top of the Company Wiki directory.

Xuropa members are browsing the directory all the time, so ensure your company information is accurate and current.  It’s free and a great way to promote your company to a focused electronic design community.

Posted under Features, Xuropa, marketing

One of the biggest problems for electronic design tool vendors is how to quickly and easily get tools in front of engineers.

For all of the new products out there, engineers want to:

• Get a quick demonstration
• Review some technical material
• Dive in and try out the tool (not on their own workstation!)
• Get some technical training
• Get quick answers to technical questions from engineers or other users

All on their own time, without installing anything or leaving their desk.

Well, now it is possible.  All from the same online location.  A Xuropa Online Lab provides a controlled and secure online environment within which visitors have access to your products with only a browser.  No downloads, no installations and no configuration.

Watch the video to learn more and contact us at (exhibit)[at](xuropa)[dot](com), (with no brackets).

Posted under Features, Xuropa, marketing

We just published a “how to” video describing the use and benefits of the Specialization and Skills features of the Professional Profile section of the Xuropa Community Platform.

It was a new tool to me and the process was very efficient with no real gottcha’s.  So I thought I’d share the process.

1. The tool: Camtasia.
- Extremely intuitive to use.  I only had to refer to the help menu twice to research particular functions, but everything else was straight forward.
- There are some more things that I could learn how to do, but I was off to the races almost immediately.
- Use a headset and microphone.

2. Duration: 3 minutes
- I got this pointer from Tom Kozas of Tuscany.  They do some pretty slick video demonstrations and it’s always better to learn from others than discover mistakes “new-to-you”.

3. Process: Fast Iterations
- Know up front the particular feature you want to emphasize.  Remember that you’ve only got 3 minutes, so you need to focus.
- Without writing a script, capture a “sketch” video with your voice over.  Tom recommended writing a story-board and a script up front.  But if you’re comfortable with the tool and are familiar with demonstrations, I found that this was a quicker way to get started and to iterate to something that works.  Don’t worry about the “ums” and “ars”.
- Play back the recording to make sure you captured the right flow and appropriate pace.  (And check you’re around 3 minutes.)
- Type up the transcript of what you said during the recording.
- Clean up and edit the transcript keeping the same flow and pace.
- Play the captured video and re-record the audio as you read off the edited transcript.  Using a headset, keep the old audio playing at a very low volume so that it can give you an audio cue for when to start and stop speaking.  This may take a bit of practice so as not to be distracted from what you’re saying.
- Clean up the transitions in the video stream using Camtasia.
- Play back and edit accordingly.
- Publish and you’re done.

I published the video to Youtube so that I can embed it into my blog.  It’s also within the Visitor Center of the Xuropa Community for members to reference.  It’s a little hard to say how long it took me as I was multi-tasking as well, so I would say about 2 hours all in all to create the video.

Here’s the result.

Posted under Features, industry, marketing

The realities of the new economy are upon us.  Finance pundits are no longer debating if the “R word” is an appropriate descriptor, but when it actually started.

In bringing the electronic design industry together, the Xuropa Platform was envisioned to address a number of issues.  The most timely one is costs.  How do you reduce costs using Xuropa?

Reduce Travel Budgets: Use Xuropa Online Labs

Electronic design tools are extremely complex and sophisticated pieces of software.  Educating potential users of your tools can take time and several costly trips (long gone are the days when all of your users were in Silicon Valley).  The process looks something like this:

1. Introductory presentation
2. In-depth technical presentation
3. Demonstration
4. Demonstration to a larger team
5. Training
6. Installation and evaluation
7. Probably more training to a larger team

Sometimes these steps iterate through the same design team.  Alternatively the wider audience to be brought in is at a different location requiring a different on-site visit.

To keep things simple, let’s say everything went smoothly and only 4 different visits were needed.  There are two employees (applications engineer and a business person at minimum) over 4 trips lasting five nights each.  (You’d want to make it a week long trip and meet with other potential users.)  We’ll use flights from San Francisco to Frankfurt as representative and not include any intra-European flights to keep it simple.

Looking at an economy class trip (I used Kayak and took almost the cheapest of everything) including hotel room, flights, rental car, minimum per diem and the cost of your two employees’ time.  The cost to the company is $32,815.  (Nearly a third of this cost is direct expenses, the rest is hidden in salary broken down to an hourly rate.  There were no executives on this trip by the way.)

These costs quickly get out of control once we consider how disaggregated our industry now is.  For example, a single SoC design team can have locations on three different continents and all need to be brought into the decision making process and be trained.

Hidden Costs and Challenges

Unfortunately it’s not always even this simple though.  There’s the opportunity cost of these trips.  Choosing between which users to see and also choosing between the support of existing users and bringing in new ones.  These are tough decisions, especially for small to medium-sized companies.  Unfortunately, the impacts of these decisions are not seen until well after the fact.

The Solution: Xuropa Online Labs

At some point your team will get on a plane and meet with users.  It has to happen.  However, the objectives of the Xuropa Online Labs are to ensure the following:

• Only absolutely necessary trips are made and you have data to decide which
• Your users are as educated as possible before you step on a plane
• Your team is focused on the right users at the right time
• Your team is leveraged across multiple teams from their desk - not spending most of their productive time in the air or in hotel rooms

How to Use Xuropa Online Labs

A Xuropa Online Lab provides an interactive environment where users and applications engineers can collaborate and communicate to accelerate the early stages of the education process.

• Online presentations, flash demonstrations, videos and technical collateral
• Online interactive demonstration
• Online interactive training
• Online self-driven training
• Online self-driven pre-evaluation
• On-site installation and training for evaluation

All of the online education work is using your tool in a secure environment.  The user does not make any downloads, there’s no configuration and no setup required.  It’s ready to go when they are.

Crucially, a key aspect of the process is to provide all of this within the same controlled and secure environment that is easily managed and maintained.

Conclusion

The Xuropa Online Lab enables your application engineering team to support and educate in parallel multiple new prospective users independent of geography or time zone.

A key aspect of the process is the ability of new users to learn about your technology on their own time independent of your applications engineers.

And crucially, this is how a Xuropa Online Lab can reduce those 4 trips down to one very productive one with a high probability of success.  Xuropa saves you money and saves you time.

Posted under Features, business

As we traverse the web, the number of times we have to input a user-name and password is getting annoying.  We agree.

For this and many other reasons, we developed the Xuropa Platform from scratch.  Well, almost…we did build upon the LAMP infrastructure (Linux, Apache, MySQL and PHP), but all of the features and functions that you use within the environment are developed internally.

This departure from the fashionable “throw-it-together and throw-it-out-there” Web 2.0 strategy enabled us to provide internal Single-Sign-on (SSO) capability.  For example, you can go from browsing the member community to checking out a development tool in an Online Lab seamlessly.  If we’d thrown together the platform using a collection of templates and “frameworks” this would not have been possible.

So, we’ve solved this issue.  However there’s a bigger problem out there - Cross-Platform SSO.

There are a few projects underway to resolve this, and the better known one is OpenID. As they state, “OpenID is an open, decentralized, free framework for user-centric digital identity.”

We’re investigating how to build this into the Xuropa Platform.  Interestingly enough though, some of the major platforms aren’t on-board with this yet.  LinkedIn and Facebook being two of them.  Anyway, we’ll get there and I’ll let you know when it’s up and running.

In the meantime, here are some features that we put into the Xuropa Platform to make your time on the web more efficient:

• Aggregation of nearly 50 news & blog feeds from all over the electronic design industry
• Import of LinkedIn profiles
• Import of LinkedIn contacts
• Import of contacts via csv file
• Company directory “wiki-lite”
• Product directory “wiki-lite”

Thanks to Jonathan David for raising this as an important topic.

Posted under Features, Xuropa