AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Have you read our latest blog post?

Print

Please Be Quiet

Are you allowing your product or service to fail because someone else doesn't understand what it takes for you to succeed?

I’ve noticed lately that more companies are putting up signs in hallways and cube farms requesting that people avoid having conversations in these areas. While having a nice quiet work environment makes sense to me as a developer, doesn’t this completely void having people work beside each other? The ad hoc/hallway/water cooler/coffe machine conversations or ones overheard when cube mates are chatting about a new feature are one of the primary benefits of having people work in small open environments.

I haven’t done any sort of scientific study but it seems that these sort of “please be quiet” signs are more prevalent at larger companies. These are the same ones that are trying to mimic the small startup with agile development processes or open work spaces to compete in a fast moving SaaS marketplace. Imitating the actions without understanding the purpose or allowing old school corporate policies to overrule are surefire ways to tank the initiative.

A parallel to the “please be quiet” sign is allowing corporate IT to dictate the architecture of the SaaS offering based on a corporate standard that works for the ERP system. Running Oracle ERP on a 16-way system might be the vendor recommended, preferred approach but for scaling a SaaS offering this is a quick way to run up the costs and ensure lower availability. We often use the analogy of goldfish and thoroughbreds for comparing small, cheap 1U servers with large, expensive multi-processor boxes with lots of memory. The goldfish (small, cheap servers) are inexpensive to purchase and replaceable while the thoroughbred (large servers) are expensive to purchase/maintain and cause big impacts when they go down.

The take away to all of this is that if your part of a corporate initiative to run an internal startup or deliver a Software as a Service from inside a larger organization, don’t allow corporate policies to prevent your success. The differences in approaches, architectures, organizations, and offices have a purpose and should not be discounted as non-critical to the success of your initiative.

Author:

Comments RSS TrackBack 2 comments

  • Curtis Deptuck

    in August 3rd, 2010 @ 20:03

    While I agree with you about the commoditization of hardware, I would somewhat disagree about the scale up approach to heavily commercialized RDBMS platforms like SQL or oracle.

    On these platforms, from a licensing perspective one is almost penalized for scaling out and not up (ie I can change out 4 core procs for 6 or 8 core with no change to overall licensing on SQL or reduced costs on oracle). The introduction of multiple server complexity also convolutes many of the out of the box features like simple failovers.

  • Fish

    in August 5th, 2010 @ 09:05

    Hi Curtis,
    Thanks for the comment. I agree that if you have a processor-based (not core-based) license then moving from a box with dual cores to quad cores is possibly cost effective. However, given the limit how many cores you can grow into, you are likely to quickly outgrow this approach if you are rapidly growing. Additionally, the more cores the greater the hardware cost which has to be factored into the equation.

    BTW, Oracle has prevented this practice by charging a core factor for its processor licensing model:

    From Oracle Tech price list: http://www.oracle.com/corporate/pricing/technology-price-list.pdf

    “Processor: shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third party users. The number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table which can be accessed at http://oracle.com/contracts. All cores on all multicore chips for each licensed program are to be aggregated before multiplying by the appropriate core processor licensing factor and all fractions of a number are to be rounded up to the next whole number.”