Q: Why Silicon Valley ?
A: Statistics show that up to 90% of the products developed in-house, for internal or external customers, fail. Facebook is an example on why they moved to Palo Alto from Boston. Silicon Valley has an intelligent risk taking and daring ability to shape the future via investments. There is no such a place anywhere else
Q: Do you improve the success rate?
A: Yes. The product must be usable, valuable and feasible. The product must be “wanted” The product discovery process must pass companies hurdles and inertia. We make sure to collect the goals and wishes of all parties involved. As outsiders, we can do things the company's employees can't and they are the most creative ones, We subtly replace traditional push marketing with inbound marketing. We develop solution and product presentations
Q: What you specifically do?
A: We pay attention to the product portfolio and to the people who make them. We create events, like blogs, webinars, interviews until we identify the ideal customer persona. We can recommend the minimal set of features that meet the goals. We can help write what readers want to read and startle them
Q: How do you charge for your services?
A: We charge consulting fees and when possible, a contingency fee on results which can be in the form of equity.
Q: What do you think is the most important criteria to find ideal customers?
A: Empathy: The type of work we do leads to extraordinary results, these will not happen unless there is a chemistry with our customers. Great customers breed good consultants. Great customers think differently, out the box and have brilliant ideas. They are our teachers
Q: Do you use social media?
A: We use blogging - one of the most essential marketing tool and we translate hard-to-understand into easy-to-understand. We can help write what readers want to read with pleasure These are two different languages. We use virtually all social media tools to create clout and discover thoughts
Wednesday, May 19, 2010
Monday, May 03, 2010
Grid Computing Software. To build a grid (SGE, LSF, Condor, etc) , a master and scheduler worked hand in had. Jobs and logins did not go straight to a server, but to the master, which had the exact picture of what every server was doing. The software will aim at keeping 100% busy all servers. As a result, a job that took 10 days at 10% utilizations, could run in one day at 100% utilization, leaving the network free to do more work for the rest of 9 days. The productivity can increase up to 10 times.
Grids are nice and dandy, but the whole concept of a grid was that it can not have enough resources for everyone. If I am the only user in a 100 node grid, the master will allocate all servers to me. Maybe I don't need 100 nodes to run my work, still, the dilligent aomeone stupid master, is trying to keep busy the servers 100%. I will use 100 nodes, when in reality I needed 20 to satisfy my level of service, wasting electricity for another 80 nodes. But when more users came in, I was given 50 nodes, then 25 nodes then a super-duper job with top priority comes in and I am thrown out altogether. I must wait until resources are available, because important jobs are defined in Heaven by management - no matter if I think I am more important- the Heavens never took me into account). Therefore grids are NOT guaranteeing the level of service, as there are not enough resources for everyone. They are often annoying, have a built it dictatorship, designed to create unhappiness in those not so well connected at the top.
Now clouds. Here the users of the grid are greatly alleviated. First, they want to use the cloud only when they need it. If is is once a month, be it. If it is 24 hours a day each day, be it. In that case determine a service level and the customers pays ONLY FOR THE TIME USING THE GRID. Contracts per year are hosting, not clouds. The customers also want to know if the they pay $100, for 1 hour with a specific service (PAM Car Crash, for example, or Intuit Sw), they got the same quality of service constantly. Here no user is thrown out or loosing resources to another user, like in a grid. The grid must bring in elastically resources (some call them cloud bursting, but many other techniques can be employed), to maintain the service levels promised by contract. Note that here the blind predicament, the raison d'etre (the existential reason), of 100% utilization, might not apply. If a corporate user wants an advanced reservation for two days, whether they use the allocation or not, as long as they pay hefty for privilege, be it. Here money talks. Do I have funds for my projects? Yes, no problem, I pay and I demand service for what I pay. No big dog will decided how important I am. Money talks. In a cloud maximum utilization goal is replaced by maximum return on investment (ROI).
There was a thread in cloud computing Google group on whether clouds could be free. They could be free, if their daddy or mommy or their employer pays for the them. Other wise, by definition as you see above. BTW, the IT is not free and never was free. Enterprises paid hefty money, adding to the cost to make an employee productive. IT cost much more than the chair, the desk, the rent of teh cubicle, but no one know for sure how much each user costs. In the cloud, one ALWAYS knows how much each employee costs if if the service would have been outsourced to RackSpace or AWS, etc. - if we use their price lists and we create some invoices never sent to the employee, but to the management.This is called 360º Billing. About how to make IT profitable, see here
At the beginning, a 10-node-network users had to call the sysadmin to know where to login and submit jobs. Everyone working in Sun a decade ago, everyone working in EDA a decade ago, knows, if you forgot the name of the server to log in, you could not get in the network. You had to call the sysadmin. This was called the telephone load balancing. The result was many people overloading say 1 server, with 9 servers doing nothing & no one knew that they exist or if they are available to them. A job taking 10 days in reality used 10% of the total available resources per day
- ► 2016 (29)
- ► 2015 (42)
- ► 2014 (84)
- ► 2013 (65)
- ► 2012 (63)
- ► 2011 (30)
- ▼ May (2)
- ► 2009 (10)
- ► 2008 (9)
- ► 2007 (11)