Mark Lewis's blog

The Three C’s of Productivity

I think most would say that the way to sustainable productivity is to work “smarter” not “harder.” Here is a quick rule of “Three C’s” that I use to help my own productivity.

As I work each day, I try to categorize what I am doing in to one of three things:

• Creation
• Coordination
• Consumption

Creation is just that, it is building things. From writing code to developing a business plan or making a sales call, creation is anything where you actively working to make progress. Needless to say, everyone should try to maximize creation time.

Coordination time is any time spent coordinating efforts across the team. Good coordination is very important in terms of being effective but there is such a thing as “too much of a good thing.” When teams are coordinating they are not creating so care should be taking to find coordination methodologies that minimize the time required.

The key to working smarter is minimizing consumption. Consumption is any time spent on an activity where there is minimal to no value-add. A great example of consumption is unneeded EMAIL. When you spend 10 minutes deleting emails that are irrelevant to you that is a pure waste of time: consumption.  I actively manage myself off all distribution lists that are not important. If the team waits 15 minutes for me to join a meeting, that unproductivity is consumption (of the team) so I try to be on time and I expect that from other team members.

Leaders should be especially careful about generating consumption in their organizations.  Many years ago, I calculated that one email sent to our (large) organization cost the company $10,000 even if everyone just opened it and glanced through it. Needless to say I used to insure large distribution lists could not be used unless the communication was truly necessary and relevant across the audience.

A few simple things like setting an expectation that everyone be on time to meetings or asking team members to focus emails to just the people involved can have a huge impact on productivity. In this era of so much data “noise” hitting us each day, it is important to be aware that team effectiveness will not come from more time at work but from more time spent doing important things.

Choosing Simple and Good or Complex and Best - Conclusion

(Continued from Part 1) http://www.starshiplewis.com/blog/2015/03/choosing-simple-and-good-or-complex-and-best.html

High-level summary from Part 1: With IT decisions today there are many options.  Some claim Swiss army knife functionality, others do one or a few things very well.  What’s the best way to evaluate these technologies for your modern data center?  Rule 1 – simple and converged, maybe. Rule 2 – don’t use a variable cost model.

Rule 3: It is OK to do both.

I have both an iPhone and a fancy Canon 22 megapixel camera. I probably take ten times more pictures with the iPhone (because it is convenient), but there are still times when I want the best possible picture and will sacrifice convenience for specialized function.

Converged platforms are never going to be able to cover 100% of use cases and there will always be needs for specialized solutions, but it is often better to still use converged platforms where possible and also use specialized products. 

The compelling reasons to look at converged products are simplicity, convenience, and cost. I believe that, within IT, converged solutions are about to take center-stage just as smartphones did five years ago.  Convergence comes in many forms; there are cloud-based SaaS solutions that provide “convergence” by aggregating customers onto a single platform and solutions that integrate server, network, and storage infrastructure.

With our company, Formation Data Systems, our focus is converging data storage resources like flash, disk, and even cloud storage into a single virtual environment that can be used to meet all types of application data storage needs. In this way, a common set of physical resources can be shared to deliver block, file, and object formats with varying performance and reliability metrics. 

While it is fun to own every specialty product, in the end things like cost, and practicality usually win.

 

Choosing Simple and Good or Complex and Best

Owning and using technology is very much like deciding what tools to have in your garage. There are people that will choose to buy the 64-piece wrench set in standard and metric sizes and others that will simply buy one crescent wrench and call it good. Technology has the same choices. You can buy many individual things to meet needs or look to converged technology platforms as an alternative approach.

There is no universal right answer but I believe there is a very specific decision process that should be used when evaluating different solutions. It comes down to three rules.

Rule 1:  Assume you will use the simplest, most cost efficient “converged” solution and then see if there are any use cases where it WILL NOT work.

Converged solutions will tend to be “good” at everything and “great” at nothing. In each individual case, there will likely be specialty products that would come out on top.  The reason to not buy a specialty solution is generally that they are more costly and complex when you have to have ten different ones (like ten wrenches vs. one).

The best example is your smartphone. In this case, most of us choose to carry one device with us and use it as a phone, camera, GPS, music/video player, and browser. There are definitely better single-function devices in every category yet most of us still prefer the convenience, cost-effectiveness, and simplicity of a single device.

Rule 2: Don’t use a variable cost model. 

Let’s say you already own a digital camera and are looking for a new phone. Should you buy a smartphone even though you don’t need that camera? In most cases, the answer is yes because it will offer you an overall improvement for minimal incremental cost. While not strictly essential, it will easily pay for itself over time.

If you use a strict variable cost model, you wind up never innovating and only buying the next point product to meet a single need. 

Next week I’ll post Rule 3 and my conclusion.  Making these decisions are at the top of the list for many IT professionals this year.  Hopefully this will give you some good perspective.

It’s Time for Enterprise Storage to Switch Technology Foundations

Thirty years ago the technology world moved in two distinct architectural directions for resiliency; enterprise computing and networking/internet proceeded toward a loosely coupled resiliency model whereas storage focused on a tightly coupled model.

Both were viable options and, at the time, the directional choices were logical. Today, however, enterprise storage has become the weak link in modern IT largely because these architectural tenants have not been challenged. In fact, the storage attributes that drove the use of tightly coupled architectures no longer exist and I believe that enterprise storage should move to a loosely coupled foundation.

For those not familiar with tight and loose coupling let me provide real-world examples. Tightly coupled systems are used when simple forms of replication or redundancy are not practical or are too expensive. Airplanes are a good example of tightly coupled systems. If you are flying at 30,000 feet and something breaks you can’t simply switch planes; you really, really want to keep that plane flying. Systems must work together in very coordinated ways and yet still be resilient to failures. Planes use sophisticated software and systems and rely on meticulous maintenance to achieve their reliability. This is all clearly necessary but it does not come cheap.

For automobile travel we have loosely coupled systems. Our cars have many single points of failure and if we want “resiliency” we buy a second car, or rent one, etc. to deal with issues.  It may seem expensive but having two cars is very economical vs. trying to create a single car that NEVER breaks down.

Building tightly coupled systems may be hard but it’s very often necessary. In the case of storage, the implementation and use of RAID technology drove the requirement for tight coupling. RAID provided cost optimization for the highest-cost element at the time (storage) by creating tightly coupled groups of disk drives in conjunction with sophisticated resiliency algorithms to protect data against device failure and minimize storage consumption. This solution also required sophisticated redundant controllers, shared memory busses and things like mirrored cache. Most importantly, it required expensive and complex software that necessitated extensive testing to verify even minor changes.

This architectural choice made lots of sense in 1985 when 1 GB of storage cost $100,000 and storage capacity made up the bulk of system cost. Today, with storage approaching $0.01/GB the situation is quite different. Today, raw storage is no longer the largest cost of “storing” data. In fact, it can almost be considered free.

While the price of storage is going to zero, the overall cost of building traditional enterprise storage systems continues to climb due to the rising complexity of the software and continued need to develop customized hardware.  A foundational change in needed to put storage back in line with modern IT.

The transition to loose coupling for storage is well underway in many modern technology companies. For these companies it was actually more economical to hire teams, design, and build their own custom storage software platform vs. purchasing off-the-shelf arrays! These solutions generally use commodity hardware and simple replication for data protection and resilience. Our new company, Formation, will be the first storage company to bring this technology to the commercial market.

The benefits for loose coupling are numerous.  Loosely coupled systems are easier to engineer, can have more features, and can generally use more commodity components. Given the price of storage today, they can also be far more economical even though they typically replicate data rather than use RAID for data protection. For very low cost (deep archive) solutions, a technology called erasure coding can be used to further reduce storage cost while still maintaining loose coupling.

One concern I often get from enterprise IT leaders is that they “need the availability and reliability of an enterprise array.”  This is where things really get interesting because, done right, a loosely coupled system can not only be faster and more flexible but it can also be far more robust and reliable.  I will save the math for another blog but suffice it to say that loose coupling wins in reliability. Hands down.

Just about every storage player is declaring that they are “software defined” or that they use “commodity hardware” as even classic arrays mostly use x86 architectures these days. The real key to transformational features, reliability, and scale at dramatically lower costs is in the fundamental architecture.

I often get asked about Formation’s motto “Demand Incompatibility” as it appears to defy logic for “good business.” At Formation we understand that achieving breakthrough results means making foundational changes. One of these specific changes is moving to a loosely coupled system model.  The simple fact is that transformational results nearly always require disruptive change.

 

 

Death by 1000 Acquisitions

We all know and understand the “death by 1000 cuts” metaphor; Andy (our COO) recently coined a new and more modern metaphor, “death by 1000 acquisitions.”  Making the wrong acquisitions is more risky and potentially more deadly when companies are dealing with disruptive market transitions.  Leading of existing technology companies should pay careful attention to not make this mistake.

I was recently chatting with a corp dev executive from a large tech company and he was telling me that his CEO tasked him to find low-cost (small) acquisitions that would leverage their current products and fill existing gaps. Under most scenarios, this sounds like a reasonable plan but, in the face of a disruptive force, it could be a very poor strategy.

Essentially the incremental/leverage strategy works well for evolution (incremental change) but not for revolution (disruptive change). If your technology space is plodding along and not undergoing a disruptive phase then the evolutionary strategy is sound. On the other hand, within disruptive technology cycles, incremental additions that seek to pseudo-modernize legacy products are probably worse than doing nothing at all. 

An analogy here might be the print vs. digital media. The revolution of digital media is upon us and yet some players have sought out incremental evolution (of print media) as the solution to this disruptive change. Arguably, this only prolongs their decline and makes it even less likely that the existing company will find a way to thrive in the next era.

This is one of the reasons that unlikely players tend to dominate new categories.  Given the cash and technology capabilities across companies like IBM, HP, EMC and Cisco it is surprising that “a bookseller,” Amazon, now clearly leads the market in public cloud computing technology.  This disruption has been visible for many years so this is not an issue of execution, it comes down to strategy.

When faced with disruption, I believe companies need to have a revolutionary acquisition strategy that seeks out the best new technology to win “the next fight.” Preferring something cheap and looking for legacy compatibility (vs. disruptive capability) will only lead to a Death by 1000 Acquisitions….

The Four Key Attributes of a Startup CEO

I recently gave a speech on innovation. Prepping for these events is interesting in itself in that it forces me to take a plethora of insights and beliefs and try to quantify them into a cogent set of lessons, rules, beliefs and the like.

In looking at the “process” of innovation I consolidated the critical elements of a startup CEO down to four: Fight, Focus, Talent and Culture.

Fight requires the CEO to have a total sense of urgency, the courage to make very tough decisions and the overall desire to win. The fight in the CEO is contagious to the team. The most inspiring commentary on this point can be found in Ben Horowitz’s book: The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers.

Focus is the ability to drive incredible efficiency from your team by being intensely focused on just a few things. I think too many startups believe “focus” requires a niche product strategy. I do not agree. Most of the largest tech companies today would not exist if they had a niche strategy. Focus is about having a clear, ordered and concise plan for success.

Talent is important in any organization and critical in a startup. A CEO must drive an agenda that allocates the right amount effort to attracting the best talent. Thankfully, the most talented people are usually driven by the chance to work on hard problems and work with great people.  Only organizations with great talent can scale.

Culture is, I believe, the most important element of all. The most important thing a CEO can do is to build a team that has a shared passion for the mission. Passion is infectious and unifying.  In my view, passion trumps everything.

 

The Road to Hybrid-Clouds

Last week I attended the AWS event in Las Vegas and the buzz around Amazon reminded me of the excitement and interest VMware events generated 10 years ago. Even though I’ve been in this industry a long time I never get tired of seeing the continued technological advancement in IT.

There was, as you would expect, a lot of discussion around hybrid-clouds. AWS has seen strong growth from its initial customer base of startups and point deployments. Now, they clearly have set their sights on bigger fish; serving more of the mainstream enterprise market.

There is one big problem, however; the hybrid-cloud as it exists today is a myth.

Thus far, the tools and technologies to facilitate hybrid-clouds have been focused on one thing - migration. When viewed from a vendor perspective this is quite logical. The primary goal of any cloud operator is to acquire new workloads; facilitating bi-directional flow of information and applications is not in their best interest.

In some ways, Hybrid clouds mirror today’s wireless carriers. Each carrier provides tools and incentives to IMPORT customers but they offer nothing for EXPORTING data or workloads. Additionally, no tools exist to dynamically choose a wireless provider on a case-by-case basis.

Today, if a business wants to move applications to the public cloud they will find many tools to help. However, if the same business wants to create a flexible operational construct that provides the ability to dynamically operate across public and private environments much more work is needed.

One of the key requirements for a business to create a “genuine” hybrid-cloud is the deployment of a common data model and data access layer across both private and public cloud environments. This is necessary to provide data consistency in both form and content and to enable businesses to build a consistent and effective data governance model.  Additionally, the data access layer must provide full virtualization across storage resources in both clouds not to mention to effectively manage data protection, performance, and data placement.

Hybrid-Cloud is a very innovative potential concept. But hybrid-cloud will not make it to prime time (and thus to the mainstream enterprise) without tools and technology that let a business seamlessly operate and manage applications across multiple environments. The lack of a foundational converged data access layer is an example of a key gap that must be filled.

What we have today are multiple clouds with varying degrees of compatibility and a number of migration tools to move applications and data from one cloud to another.  The next step is to build the technology that enables seamless operations across clouds.

Open Letter to Open Stack

Dear OpenStack,

Two years ago, when Formation was at its’ inception, you were all the rage. Everyone in tech was buzzing about you. And nearly every venture capitalist I spoke with wanted to know two things:

 -       Would Formation support/ work with you?

 -       Why would VCs fund Formation since you (and open source in general) have next-gen storage “covered?”

I was blown away by the presumed “fait accompli.” I couldn’t fathom how you moved the storage paradigm from the likes of EMC to “free downloads” so quickly. But even still, we at Formation forged ahead, found investors and built our product (including OpenStack support and integration.)

Given what I had heard from the venture and analyst communities I was shocked when I experienced the reality of the solution(s) firsthand. Prior to the launch of our Alpha program earlier this year, we had yet to work with your software but we were all aware of the surveys showing strong planned adoption. So when we integrated with OpenStack at two alpha customers we were shocked to discover that you were even less ready for prime time then we were!

This seemed insane as the media told us you were on the verge of mass adoption. Could it be true that hype eclipsed reality? In a word; yup.

I received further validation when I attended an IT conference. CIO’s were asked about their strategies. Turns out, interest in you actually declined year over year.  That is not a good sign for “the next big thing.”

So, what happened here? Here are my thoughts (and some coaching).

You have too many cooks in the proverbial kitchen:  Most leaders today believe that small teams drive innovation. Small teams with great leaders can have incredible outcomes. I believe that teams of 8 -10 (Jeff Bezos calls this the “two pizza rule”) are ideal. Therefore, I found it incredibly disappointing when I researched the OpensStack.org site and found that your BOD alone comprises 24 people. The “technical committee” is 13 people!  Sounds more like Congress than a cool new software product.

You have too many variants: Successful open source projects usually start as a single distribution. Over time some fragmenting occurs based on natural evolutions. Simply put…you’ve fragmented…too early…and too often.

Who is your leader?: Every project needs a leader. I am still looking for the “Linus Torvalds” of OpenStack.  Even the US Government, with a congress that is hardly effective, still has a President.

You should focus on engineering – not marketing: The evolution of successful open source projects is grounded on the “pull factor” vs. the “push factor.” Individuals, teams, and companies create cool things and other developers jump in. I believe that companies (fearful of AWS on one side and VMware on the other) used marketing to enhance your promise as a ready-to-go alternative for clouds.  In my opinion, you ought to try under promising and over delivering.

You’re trying to be everything: You have SW modules that, in theory, could eliminate every commercial technology vendor in the market. Are you sure you’re being honest with yourself? Wouldn’t it be better to focus on being a great framework, or orchestration, etc. and not try to be all things cloud?

Where exactly is your focus? Legacy or emerging apps?: Again, it is hard to determine if you’re trying to embrace legacy or present a new alternative? I think you will find that trying to do both is impossible.

The interest that you have generated demonstrates that you’ve uncovered a real need in cloud based computing. But you may want to rethink your approach in order to achieve success and adoption. Don’t get me wrong. I’m a huge fan of your overall objectives but I also believe you should consider strategic changes in order to actually attain the mass-market adoption you seem to be already famous for.

Respectfully submitted…

Mark Lewis

 

 

 

 

Failure

In telling the story of Formation to some folks in the media last week, I was reminded by long-time storage veterans (thanks Joe Kovar – see article here ) that I have had two previous attempts to create a more ubiquitous data virtualization layer. The results were… well… not great. OK, miserable failure might be more appropriate. The first was a product called VersaStor which started at Compaq and then migrated to HP. My second attempt was a product called Invista while I was at EMC.

Third time a charm? I am heartened by the Henry Ford quote that “Failure is simply the opportunity to begin again, this time more intelligently.”

I did learn many things from these “failures” but four lessons stand out.

1. To innovate you must look forward not backward.

The design focus of both previous products was towards accommodating existing (legacy) storage arrays and not on building the best forward-looking solution. Bad.

2. It is nearly impossible to create transformational technology inside of a company that will be financially impacted (negatively) by the disruption.

I am sure that most of you get this but if you don’t give the Innovator’s Dilemma by Clayton Christensen a shot.

3. Building a large team is not the way to go.

Small teams are key to innovation success, even on “large” projects.

4. Everyone involved needs to believe!

I can’t emphasize this enough. If you want to do something disruptive then everyone from the engineers to the CEO (and especially the CEO) must “believe.” If the project must succeed then it will. If it is a “pet project” or an “alternative” then it will most certainly fail.

While there certainly are many other learning’s, both organizational and technical, these four stand out as the most significant.

And they are embodied in our third beginning. And I believe this time is definitely a charm.

 

Stealth Mode

One of my favorite terms for startups is “stealth mode.” It is just so mysterious to say, “we are in stealth mode right now…” It is essentially a way for us geeks to add intrigue and mystery to technology.  The basic process for stealth mode seems to be: 1) put up a web site and 2) put on the site that you are in stealth mode and can’t say anything. It makes me wonder, if I really wanted something to be secret, why put up the web site in the first place?  The answer is simple; it’s just no fun to have a secret when no one knows you have it.

I am reminded of the movie line “the first rule of Fight Club is we don’t talk about Fight Club.” In the era of so much clutter and information overload, withholding information can create more interest than providing it. Just look at the lengths that people go to try to figure out what Apple is doing next.

The time has come for my current company, Formation Data Systems, to exit our “stealth mode” phase. We never were really that “stealth” in the first place; we have been speaking with lots of analysts, potential customers and advisors all throughout our development process. Still, until today, we actually never disclosed the level of investment in the company or the fact that we have been in Alpha testing with customers for several months and the fact will deliver Beta software by the end of the year. 

We are super-excited about the potential but, alas, as we are not Apple, we are not going to get notoriety though silence.