Greenfield thinking: improving storage in the ’90s

Back in 1998, as a small/midsize company, Clarify found itself in one of those situations.  Clarify was a CRM software vendor, and we were battling with Siebel and Vantive for supremacy.  As a software shop, one of the big metrics was quality.  Lowering quality can improve time-to-market, but increases the burden on the backend with the Customer Support organization, and ultimately the trust of your customer.

One of the largest challenges in software engineering is build times.  Long build times, which were endemic for a complex waterfall design shop back in the ’90s, had a very peculiar effect.  If an engineer knew it would take 6 hours to compile, he/she would make changes to many parts of the code to get them into the build compile.  BUT when the compile threw errors, digesting the results could be difficult, with so many changed variables.

So, around 1998, I looked into a shared storage design.  The approach had a lot of caching, and spoke to the servers at the filesystem level.  We didn’t have have a lot of time to change paradigms into SAN, nor the money or expertise.  After a serious bake-off, I chose NetApp:  we found that our compile times would drop to under 30 minutes with the amount of cache and number of spindles we were going to use.

And, in one of those moments that forges the opinion of a young IT guy, I went to speak to the CEO — an amazing guy named Tony Zingale.  Tony was aggressive, loyal, and passionate about his customers.  But I was nervous. I was going to ask him to do something he wouldn’t want to.  I brought the proposal to him.  Because he is sharp, he immediately hit me with the feared question: one of our best customers was EMC, couldn’t they do this?   (NetApp, on the other hand, was not a customer, instead choosing software from our competitor, Vantive.)  I agreed in principle that it indeed made the most sense for us to buy from EMC, all things being equal.

A hard choice that changes the game

But I laid out the scenario — things weren’t equal.  At that moment in time, NetApp had a little “secret sauce.”  And that secret sauce would change the characteristics of our engineering compiles – and *that* would encourage new behaviors.  People naturally change their behaviors to embrace opportunity.

However, in our case, since compile times would drop to 30 minutes, engineers would submit changes in smaller batches, and product quality would improve.  Clarify would have better product, one that scaled better in the marketplace, and could improve our overall speed of development.

Tony immediately decided that a better product would support our customers and agreed  — despite the challenges of the politics that I laid at his doorstep.  (I always admired that decision.  It would create conflict for many CEOs, but Tony always has had a clear view to long-term customer success and value).

We laid down the path and in that small way, IT contributed to to the overall goals of the organization – building a world-class product.

Today’s chances for order-of-magnitude changes

It appears to me that another such jump is possible today.  I recently looked at Violin Memory (I have zero relationship with them, for the record), and it seems they have figured out SSD in an architecturally appealing way — they eschewed the traditional analog algos used for spinning disk and focused on 0s and 1s.  We used SSD for some servers when I was at CIBC, but it was expensive and a one-off.  Violin Memory seems to have realized a built-for-SSD architecture would be useful and has lept past most of the storage vendors trying to retrofit their original investments (an eventual losing strategy, IMHO).

The changes in the storage market got me thinking about what we’re trying to do here at Framehawk.

In many ways, Framehawk has the same type of premise in remoting protocols that Violin Memory has in storage.  When a greenfield approach is taken using new techniques, the result can change the way people work – and that’s when the fun begins.

(Ironically, Framehawk is looking to solve the problems of mobile access to enterprise applications by making the same kind of move, but in the opposite direction.  We’re changing the approach of remoting technologies from digital to focusing on analog, since humans — the users of the mobile user interfaces — have an affinity to analog).

In any case, congrats to Violin Memory for kicking off a second storage renaissance.  I expect most enterprises will be reclaiming rack space, and giving themselves a chance to transform their business processes – a 10x factor of improvement can provide room for a lot of change in nearly any marketplace.

How IT should respond, however, varies a lot from organization to organization.  What would be helpful would be some tips to help wade through the numerous suggestions.

One place I’ve heard a few good pieces of BYOD advice recently has been on Twitter tweetchats.  There are a few good tweetchats that happen pretty regularly focused on mobility, the consumerization of IT, and their impact on the enterprise that have produced some great snippets of advice.

Practical BYOD project advice

One of them – #mobilebiz, run by Brian Katz (@bmkatz) and Benjamin Robbins (@PaladorBenjamin) – recently asked for advice that participants would give organizations starting a BYOD program.  Here are a few of the answers I thought were particularly useful.  So much so, that I’d call this “7 things you should absolutely remember when launching a BYOD program that’s right for your particular organization.”  Sure there are other things you’ll need to think about, too, but I thought these were especially on point.  I’ve noted the Twitter handles of the people supplying the comments to give credit where credit it due (current avatar photos included below for good measure):

“Talk to users! Find out what people want and need. It’s for them after all.” (@mark_lorion)  Too many people forget this out of the gate.  I (@jayfry3) piled on in agreement with this one: “Yep, talk to users involved in BYOD. Critical. Learn needs, but also set expectations on org’s sec reqs.”  This can be through surveys or even 1:1 interviews.  How you get the user feedback should be tuned for your org.  But regardless of how, do it.

“Start with users who are pretty savvy & self-sufficient in the first place. Add mainstream 2nd.” (@Framehawk)  This was our contribution:  begin with a subset of users who are up for a little disruption and bleeding-edge activity.  If IT partners with them, you’re likely to be more successful, and also pick up some other out-of-the-box ideas.  Add the masses to your BYOD program once you’ve tried it out with constituents helping you build toward success.  Those masses can be rather demanding (and definitely need more support hours), so make sure you’ve got a bit of practice before opening the floodgates.

“Start with policy first and remember it’s about protecting your data while enabling your users.” (@bmkatz)  Brian’s suggestion is about making sure you know what you’re doing before diving in.  Set up the goals – and restrictions – of your BYOD program at the outset.  If you don’t, you’ll have trouble delivering and difficulty explaining/justifying what you’re doing and why.  Security and user enablement, as he mentions, are huge drivers.   You also may have other drivers that are equally important, but write it all down so there’s no confusion.  Brian has some other useful thoughts on BYOD on his blog.

“Build a cross-functional leadership team. Focus on what biz processes you want to mobilize. Engage users shortly thereafter.” (@bbelding)  Brett’s tip is similar to some of the ones above, but adds the idea that there needs to be a benefit across your entire organization for a BYOD program to work – and you need to get all of the constituents to have a stake in the game.  Like Brian, Brett suggests figuring out specifically what you are trying to accomplish before getting going.  And that first step has to be with actual users.

“Partner w/your business to build acceptable use policies that have support/buy-in at all levels.” (@jtyrus)  Especially users, added Brian Katz in a follow-up tweet.  If Brett was talking about engaging people across various silos, Jody’s comment is about making sure different folks up and down the organization are involved — upper execs and entry-level folks, too.

“Mobile strategy should reflect biz goals through the lens of user input.” (@Bitzer_Walt)  Walt crystalized some of the other comments – make sure that your particular BYOD program is directly in line with what your business wants and needs.  If it’s not, you have to spend the time to rethink IT’s approach.  And, yes, users.  Have you noticed a definite theme here about including users?  Just checking.

“Don’t force a policy if it is not a good fit. Weigh your employee’s perspectives with utmost consideration.” (@_MassiveImpact)  This last comment can be seen as having two sides.  First, this supports Walt’s comment about having your program reflect your business goals.  However, the flip side is also true.  Force-fitting a BYOD program that users find unhelpful or contrary to what they’d want to do on a daily basis is going to result in failure.  Do your best to design a program that meets what IT thinks are the business goals while making users happy.  However, if it turns out that users are not happy, listen.  And do something about it.

So if you’ve been looking for advice for kicking off a BYOD program, there you go.  Consider it a place to start.  Also, none of the folks I quoted above qualify as “shy” on Twitter, so definitely ping them there if you want to extend the conversation on a particular subject.

Some other tweet chats that you might want to check out covering similar areas are #mobilebizchat and #CITEchat.  I’ve also seen an occasional use of #BYODchat, #COITchat, and #byod4biz.  #Cloudviews occasionally plays host to BYOD and mobile-related chats as well.

If you have other BYOD suggestions that aren’t covered here, feel free to use the comments section to chime in.  Or join the regular #mobilebiz tweetchat every Thursday at 1 p.m. Eastern.  Watch ahead of time for the topic du jour and occasional time shifts (like today’s).

If you’re interested in more background on the implications and impacts of BYOD, you can download this BYOD eGuide we sponsored in conjunction with Computerworld.

But as you leave the data center, you leave the land of computers and you start re-entering civilization.  And out in the fresh air, you are likely to run into real humans.

Humans like nuance, they like to “feel.”  They like to “like.”  What does that mean?  It means people are not precise. It means that humans don’t care about 0s and 1s.  They care about what they like, regardless of what the data says.  And often that is not quantifiable.

A couple examples:  digital phones are not as good as analog.  What, you say?  But digital is better!  Digital (AKA 0s and 1s) is more efficient and more precise!  But it doesn’t sound as good.  It lacks the “human” quality.  How many times do you hear someone say “you sound robotic”?   And audiophiles will always prefer a spinning vinyl record over a transcoded mp3.  Why?  At the end of the day, the brain interprets waveforms and images as curves, not 0s and 1s.

Why does this matter?  In the remoting protocol industry, most of the protocols are based on algorithms and graphics language.  Images are drawn and rendered on the user devices.  This perfection is compounded by the network being keen to guarantee delivery of the packets (the Internet was built for reliability, not performance).

Framehawk’s position is fundamentally different.  We focus on “representing” an image on a remote device. Representing is not perfect recreation.  It’s about representing the original in a way that makes sense to the person.  A real person.  Our protocol is built to value the things that people value: linearity, visual pop, clean images — and most importantly, no distractions.  Watching the screen resolve, clicking-and-waiting, slow-fast-slow (the Slinky Effect!) are all things that the human subconscious registers and finds distracting.

Framehawk is about relevant, not right.  Computers are about getting things precisely right — and hoping you find it relevant.  We think we’re coming in on the correct side of this argument.  The key is to remember who is consuming your service.  If you are computer-facing, stay digital.  But if you are human-facing (and our platform for letting users access corporate applications over tablets definitely qualifies), you need to consider how to be good at operating analog.

Red Herring does this each year:  they research the most notable private companies and put them through the ringer (in the nicest of ways) to find the ones they want to highlight at their annual event.  The criteria they use to evaluate start-ups range across a variety of areas, including the candidate company’s addressable market size, its intellectual property and patents, its backing, its revenues, management’s expertise, and proof of concepts.  And after that…then they start the due diligence. (I’m only slightly kidding.)

This year’s Red Herring 100 North America event features many well-known names from the venture community with topics like “Is There a Secret to Getting Funded?,” “Managing Growth,” and “Exit Strategies.”

The IT companies nominated are in some of the hottest areas of interest and are in markets witnessing some of the biggest innovation right now.  It’s no surprise that the list includes companies aimed at cloud computing, mobile, software, and security – to name only a few.

We’re proud to have been selected.  We believe this is to be another indication that solutions like ours — helping enterprises figure out mobility for their application portfolio – are of critical importance.  And are where the action is.

But there is a subtlety about this network ubiquity that I should have expected, but didn’t clue into until I looked at the underlying spectrum data (Framehawk leverages its own QoS system, giving us insights into some interesting communication patterns).  While bandwidth is largely disappearing as an issue for access over mobile networks, “loss” — due to RF interference patterns — is appearing as a large and difficult variable to deal with.

Why is this surprising?  Well, for most of our IT careers, we dealt with wireline networks.  Wireline’s biggest enemy was congestion.  The further you got away from the core, the more likely you would run through a chokepoint.  On TCP, loss converts to (and results in) latency and latency swings.  Which effectively reduces throughput - which many people interpret as “bandwidth restriction.”  A few years ago, 2-4% packet loss on a far-flung WAN could occur, even with a decent OLA.  I was consulting at a health insurance brandname in 2009 where there was congestion to the tune of an added 40ms in their metro area, and they weren’t even aware of it!

What about now?  Today, packet loss numbers have improved to under 1%.  We’re not in “bandwidth Kansas” anymore, that’s for sure.  But today’s wireless networks are a different animal.  The wireless space is polluted with noise, ranging from microwaves to mobile devices to other wireless access points.  In a demo the other day, a VC was commenting that they regularly see 30% loss in their office WiFi, due to interference.  To visualize what this looks like, I included a telling image (above) from the EtherealMind website.  Quite boggling!  I also see some amazing technology coming from ThinkRF for some advanced approaches to spectrum analysis, and hear they have great things coming for real-time management.  Also insightful reading is this blog by Peter Grace which includes some images of WiFi interference in a Wall Street building (one included below).

So, whether the issue is the need for more bandwidth or more perceived bandwidth or I-want-my-own-Internet-access or “gee, I seem to have connection issues, perhaps I need another network gadget thing on this side of the floor,” more and more wireless access points are being installed, increasing the problem.  In my office, there are over 30 access points competing for spectrum around us.

What is the impact?  Well, in general, for accessing corporate client/server applications, it means more spinning wheels and waiting.  In the remote protocol space, for our competitors who have tuned themselves for 250ms and 1% loss (corporate WAN and office VDI targets), it means that leaving the well-managed corporate network and using mobile networks for application access will be painful.  For Framehawk?  I think we’ll help customers handle this situation just fine.  We’re architected to handle crazy amounts of loss and still let you do productive work — handling 10 to 20% loss is not a stretch at all.

Will we all glow at night 30 years from now from the radiation from all the network use?  Who knows.  But I can say that the most important metrics for networks over the next 10-15 years will be talking about loss handling rather than bandwidth.  Strap in!!  I see “lossy” storm clouds gathering outside…

The write-up highlights four core things for an enterprise’s client computing initiatives:  productivity, cost reduction, risk mitigation, and user flexibility.

Says Gartner, “the current technologies available to IT organizations can fall short in addressing these often-competing objectives.”  The Cool Vendor report named Bromium, Framehawk, Numecent, and revisited Wanova, which was acquired by VMware in 2012. All of the 2013 cool vendors in this space “increased focus on managing the assets the enterprise truly cares about — applications and data — rather than the entire device and OS.

“This theme,” writes Gartner, “has swept through the enterprise mobility space over the past two years, and is now taking hold more broadly in enterprise client computing.”

This last point rings especially true from our perspective here at Framehawk.  Our focus is on application mobilization, rather than trying to provide device-specific mobile security or management. We think the currently required trade-offs between mobile security, performance, and user experience are unacceptable as employees demand to use tablets as part of their normal work day.

If you’ve been following us for a while, you know our backgrounds from NASA and large financial service organizations have both played large roles in shaping the Framehawk Platform.

A quick recap of the tenets of our solution:  nothing – no data or application code — goes on the device.  You shouldn’t rewrite the applications you’re already using in order to enable mobile access.  You should be able to use new cross-platform technologies like HTML5 to build your new mobile-first applications.  And touch interfaces should be intuitive – and automatic.

It’s great to have folks like Gartner add us to their lists.  I’d even call it kind of, well, cool.

If you want some basics about the Framehawk solution, start here or download our “Strategic Application Mobilization” white paper.

The Gartner Cool Vendor paper referred to in this post is the following (and requires a Gartner subscription to view):

Gartner, “Cool Vendors in Client Computing, 2013,” Terrence Cosgrove, Nathan Hill, Federica Troni, Mark A. Margevicius, Phillip Redman, and Neil MacDonald, May 3, 2013.

Gartner Cool Vendor Disclaimer:

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

The Cool Vendor logo was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request here.

But in this case, it was a Windows 8 laptop with a touchscreen — and they actually executed something with that tap!

I used to yell, “Hands off the keyboard!”

Now I guess I have to yell, “Hands off the screen!”

Times are a-changing.  New behaviors will abound.  Between my screen, my pen, and my mouse, I am still finding my rhythm on how to work efficiently…and as apps become more touch friendly, I expect we all will continue to adjust.

And provide a few chuckles along the way.

Not so long ago, I sat in on a number of behind-closed-doors customer conversations.  The IT infrastructure folks were talking through their approach, strategy, concerns, and plans going forward for enterprise mobility.  They were dealing with employees wanting to bring their own devices.  They were struggling with IT’s role in a BYOD world.  They were figuring out how to mobilize applications while dealing with application functionality, authentication, and data residency issues.

In short, all the topics that we often cover here on the blog, they were dealing with daily.  I scribbled down a few comments that I thought were particularly well-stated or pertinent.  You won’t see any names here, but that probably doesn’t matter:  based on other discussions we’ve had with customers, these things could have been said by any number of organizations.

Anyway, I thought there was some good commentary here worth sharing.  Note that the “we” in all of these quotations is the perspective of an IT guy whose responsibility it is to help make application mobilization happen in their org.

On the topic of BYOD:  “We must be positioning ourselves to handle whatever walks through the door.  We will get the Microsoft work done when Microsoft makes a compelling consumer device to make employees to want to buy those.”

On the phrase that will scare any IT guy thinking about application mobilization: “The board of directors will be your beta testers.”  In fact, in several customer discussions, I know for a fact that this isn’t hyperbole, but pretty close to the truth.

What they’ve heard employees say in response to IT’s often-draconian MDM enforcement on employee devices:  “Thanks for turning my iPhone into a BlackBerry.”

What IT wish they could say to the employees that are working with about their often-thankless role as the mobile security enforcers:  “Everything evil about IT are the things that the lawyers made us do.”

On the different usage model that tablets cause, compared to desktop PCs:  “In a VDI world, churn will kill you.”  Churn refers to set-up of remote access, followed very quickly by tearing down that same set-up.  The session duration we’ve seen from tablets is measured in single-digit minutes, usually.

On the sweet spot in enterprises – where they need help with application mobilization:  “The play is where people have spent tons of money on custom business logic and now there’s a proliferation of devices that need to support those applications.”

On how employees are going to judge mobilized enterprise applications:  “This thing is going to live or die on a great user experience. When it works well, it’s magic.”

On the big picture, including IT’s role going forward, given everything that mobile is enabling:  “Where are we going to go with IT? We just don’t know. But that’s OK. We’re just not going to know.”

These are just a few comments, but they give you a snapshot of the kinds of things we hear people saying as they are weighing their enterprise mobility options.

To me, these sound like folks in the middle of giving some serious thought to some serious transitions, a little excited and a little worried, as they sort through a bunch of unknowns.  As it should be.  If you’re in the middle of a project of this sort yourself, some of them just might sound familiar.

If you’ve heard any particularly pithy or telling quotes about the move to mobility inside an enterprise, feel free to leave them in the comments section so others can read them, smile, and chuckle knowingly.

Even in a world that included WebOS, Android, Windows, Symbian, and iOS, for a long time all I heard about was iOS Objective-C development.  In 2011, I had one bank VP tell me that he expected to spend all of their money on iOS — even though that would risk having to duplicate the work on another platform sometime in the future — because that was a “safe” strategy that would not get him fired.

Roll forward a few years, and wonderful tools are showing up that can handle layout and UI on many platforms — the text options on HTML5, the node.JS platform, the canvas-aware libraries are all flooding into the “next big thing” for UX and UI developers, who no longer need to be tied to one platform.

The only thing worse than not working on the “hot thing” is working on a 3rd-generation-old hot thing, on a stifling single platform.

There is a lot of evidence that younger-generation developers are quite interested in Android, and even the Windows platform (Blackberry QNX, anyone?  Or Ubuntu?).  Why?  Because today there are places where innovation can happen quicker and more iteratively than on iOS.  With millions of eyes glued to Xbox Live screens anyway, platforms like Windows are enticing developers to do-what-you-know and innovate where the payback is direct and palpable.

If you are a developer, would you use tools that let you constantly change and evolve as an artist?  Or would you stay in a stodgy environment due to legacy fanboi blindness?

I am not seeing people hate or run away from iOS (recent stock woes from Apple aside).  But I do see people running towards a future where mobile-first applications are easier to build and easier to deploy, manage, and maintain broadly across the device community.

This is a future in which iOS is included, but not exclusive.

And that is good for everyone.