Information Playground

Three Box Balancing

In June I plan on returning to New York City to cover the World Innovation Forum (WIF). I have learned much about corporate innovation theory at this conference, and I also have enjoyed the exercise of comparing what I learn to what I see at my own company (EMC).

The most impactful speaker (for me) has been Dartmouth Professor Vijay Govindarajan. Among VG's many theories, I have found his 3-box theory to be the most relevant:

This theory, in brief, advises corporations to place their resources in 3 different buckets:

1. Manage the present: Most employees operate in Box #1, incrementally delivering the "family jewels" that bring in the majority of revenue for the corporation.
2. Selectively Abandon the Past: A percentage of employees should work here, exploring how to take existing technology into different markets that solve new customer problems.
3. Create the Future: A percentage of employees should work here, anticipating new markets and new customer problems, and inventing brand new solutions with very little re-use of existing products and/or processes.

A good company will be well aware of the split between these three groups (e.g. 85-10-5, or 75-15-10).

After hearing about his theory while in New York City, I began to look for evidence that this type of approach was practiced at my own company. More specifically: how was my own organization applying resources in boxes #2 and #3? And what new products result?

Selectively Abandoning The Past

About 5 years ago some smart people inside EMC recognized the rise of the IT generalist and the need for easy-to-use, inexpensive storage devices that had the same capabilities of enterprise-class and mid-range storage systems. The decision was made to "tax" several of the organizations inside of EMC (e.g. CLARiiON, Celerra, Centera) and carve off certain individuals to focus on Box 2 activities.  This group of people were creatively combined with recently-hired employees. These two groups of people were collectively tasked to "selectively forget" the traditional markets and focus on the new IT generalist market(s). They focused on a componentization strategy that extracted enterprise class components from their embedded systems and built them as standalone reusable components. These components were then hardened and inserted into various products.

In order to satisfy the "ease-of-use" requirements for IT generalists, the "selectively forget" strategy was critical. The user interfaces of CLARiiON, Celerra, and Centera were not re-used at all. They presented the wrong approach for IT generalists. However, some of the back-end plumbing (e.g. CIMOMs and Web Servers) were re-packaged and re-used. The new user interface (built with FLEX technology) was created as a set of reusable components that were then inserted into a variety of different products.

Over the course of several years EMC positioned hundreds of employees and resources into Box #2 and delivered new products such as VNXe and Unisphere.

Create The Future

A good example of rebalancing resources into Box #3 occurred with the Atmos product. Once again, some smart people inside of EMC predicted the eventual need for highly-scalable and highly-distributed cloud storage systems. These systems needed to automatically migrate content across great geographic distances via policy decisions. Upper management went out and hired new blood from the OceanStore project and dedicated dozens of employees to specifically focus on this new market. There was very little need to reuse critical assets from internal projects.

Atmos is definitely an example of a Box #3 investment. Often times these groups can operate so far off of the beaten path that there is an aura of mystery about what they are building.

The Theory In Practice

I have found that VG's theory applies quite nicely in the real world. In fact, I have asserted that it can also play a role as an excellent time management technique for individuals, especially would-be innovators.

For internal employees that see the formation of these groups within a corporation,I believe that it is a sign of health.  It is also a win-win for employees that have the option to join one of these new groups or stay where they are (and continue to more directly impact revenue by staying in Box #1).

The strategy is not limited to high-tech companies, or to engineering organizations. I have heard horror stories about companies that stick nearly everybody in Box #1.

I'd love to hear what people are seeing at their own company.

Steve

Information Playground

Twitter: @SteveTodd

EMC Intrapreneur

Building Decision-Oriented Systems

I am a big fan of contests, and will throw my hat into the ring whenever I have something to contribute. I've done that internally as well as externally.

This week EMC announced another type of contest: the 2011 Data Hero Award.

I am following this event more closely than any contest I would enter myself. Why?

Because the contestants (and the judges!) represent a set of customers that are generating the requirements for a new category of high-tech product: decision-oriented systems.

Transactional versus Decision-Oriented

Transaction-oriented systems tend to focus on the speeds, feeds, and management interfaces that satisfy the needs of popular transactional applications. The products in this area are mature. Building these types of systems involves the use of well known techniques and technologies: caching, flash, tiering, API integration, etc.

Decision-oriented systems...

• ...must address radically different problems than their transactional counterparts,
• ...will be managed via significantly different user interfaces,
• ...will be assembled using non-traditional technologies,
• ...don't serve applications, they serve executive decision makers.

As a long-time builder of transactional systems, I'm not exactly sure how to build a system that satisfies these requirements. I need to run some deep analytics of my own in order to fully understand the new customer needs. Where am I going to get that kind of data?

Fortunately for me, the Data Hero Award is more than just a contest. It's a requirements gathering exercise for the building of decision-oriented systems.

At EMC World in May, the conference attendees will see a set of use cases that represent shining examples of big data technologies and techniques.

What they won't see, however, is the deeper superset of submissions. Nor will they see (or hear) the back-room judging conversations that will occur before the conference. Here are the judges:

• Tom Davenport, President's Distinguished Professor of Information Technology & Management, Babson College and Co-founder of the International Institute for Analytics
• Kevin Davies, Editor-in-Chief of Bio-IT World and the author of "The $1000 Genome: The Revolution in DNA Sequencing and the New Era of Personalized Medicine"
• Susan Feldman, Research Vice President, Search and Discovery Technologies, IDC
• Dr. Michael Freed, Program Director, AI Center, SRI

A Hint at What's to Come

EMC's involvement in the planning of this exercise has already unearthed some fairly significant insights in how to build decision-oriented systems:

• The important of provenance. Decision-makers will continually want to go back in time, change one variable, and re-run scenarios. This becomes a lot easier when data lineage is built into the solution. EMC has been researching this for years and the time is right to bake it into a new system.
• The need for collaboration enablement. Data sets in a decision-oriented system (especially lineage-aware data sets) must support annotation and collaboration by and between multiple parties. Collaborative metadata is irrevocably bound to the content. In some cases the metadata importance rises above the importance of the content; in nearly all cases the metadata must be immutable.
• Management GUIs are essentially implemented as navigational graphs and reports. The visualization of content on the system trumps the visualization of the system.
• The system must adjust to the political/cultural framework of the corporate decision-makers.

This last item had me shaking my head at first. Why is the political/cultural framework relevant?

When it comes down to presenting, analyzing, and reporting data to corporate decision-makers, things certainly get highly political and subjective.

If you study the expertise of some of the judges you begin to see the importance of the political and social skillset of decision makers. For example, consider the education background of local Massachusetts Professor Tom Davenport: B.A. Sociology ('76), M.A. Sociology ('79), PhD Sociology ('80).

This type of background is not often found in the traditional customer base for transactional systems!

I know that EMC World is a great time for customers to experience face-to-face drill-downs with EMC engineers. It is also true that EMC employees look forward to interacting with their existing customers.

This year, however, employees such as myself will also look forward to some face time with their future customer base: the Data Hero.

Registration can be found here.

Steve

Information Playground

Twitter: @SteveTodd

EMC Intrapreneur

 

 

Captiva Speed at JFK

I was perusing the Captiva announcement today and a quote from one of the leading archivists at JFK caught my eye:

Erica C. Boudreau, Archivist for the John F. Kennedy Presidential Library in Boston, said, “This new version of Captiva enables us to compress our scanned images using a lossless method, saving storage space and costs while maintaining high quality images for the historical documents that the JFK Library is capturing. The ability to quickly manipulate images and to process them using Captiva’s latest optical character recognition (OCR) engine produces more accurate results and saves our staff significant time.”

Several weeks ago some of my co-workers and I visited Erica's team at the JFK Library and Museum to ask some questions about their digital archive, find out what was working well, and ask what we could do better. The archive holds a massive amount of scanned documents from JFK's presidency. A key part of their ingest strategy relies on Captiva's automated ability to quickly scan documents and (a) immediately convert them to multiple image formats, and (b) perform automated optical character recognition (OCR).

The picture below highlights the steps that are taken before the multiple images are handed to the back-end content management system.

During our visit the JFK archivists were asked when they would be "finished" scanning documents. The answer, based on their current process, was measured in decades (well over a hundred years)! With only two scanners, there are only so many documents that can be pushed through the system.

Their process was greatly accelerated, however, when they upgraded their Captiva software and leveraged the ability to generate multiple image sizes on the fly. These images are then sent to the back-end system (Documentum) along with the OCR metadata. From that point on the images and meta-data can be accessed using Documentum's Digital Asset Manager. The image below shows has DAM can be leveraged to manage and display these images. These images are photographs (not scanned documents), but they highlight the benefit of a Captiva integration:

In order to learn more about how Captiva transforms scanned documents so quickly I read this benchmarking report by Wipro (registration required). The report is a fair comparison of Captiva's capabilities versus the competition. For some use cases Captiva comes out on top, and in other cases they don't. If you look at the performance comparisons, however, there is no contest. Captiva is built for speed.

When considering that over 200,000 documents have been scanned into the archive to date, performance truly counts.

Steve

Information Playground

Twitter: @SteveTodd

EMC Intrapreneur

Innovation Training

As I mentioned last year, ten of my current co-workers joined EMC in September as part of an accelerated leadership program. Several of us are mentoring them through the first twenty-seven months of their careers as they rotate between different jobs during that time.

In addition to their day-to-day job duties, they’ve been asked to propose a new product or direction for the company. This directive is the equivalent of “innovation training”. How do new employees generate new ideas while building new, relevant and impactful prototypes?

Their approach has been two-fold:

1. Get your day job done.
2. Take initiative beyond your day job.

The second step (taking initiative) is what separates innovators from the rest of the pack.

In my experience, there are three key initiatives:

1. Take the initiative to become an expert in something (this may actually overlap with your day job).
2. Take the initiative to understand customer problems, needs, and requirements.
3. Take the initiative to learn adjacent technologies.

These three initiatives are summed up in this diagram:

Seven months later, I’m seeing an increase in innovative activity for their project, all visible on EMC’s internal social media site (EMC ONE). Their activity is focused on the field of digital preservation. What initiative have they taken in these three areas?

1. They’ve deepened their knowledge of the Open Archival Information System (OAIS) standard. This specification is fairly dense. They’ve all read it, they’ve all “adopted” a section of it, and they’ve all presented their section (internally, and to customers).
2. They’ve connected with customers in two different ways. They’ve had conversations with EMC Sales and asked what pain points customers are describing while trying to build digital archives. They’ve also visited the JFK Library and quizzed the archivists about the pros and cons of their current solution.
3. They’ve begun to explore, read, download, build, run and otherwise investigate relevant adjacent technologies, some of them “open” (Fedora Commons, XAM, CASPER, RODA), some of them proprietary (Atmos, Centera, GreenPlum, xCP).

They’ve also interacted with a set of students at EMC Research Russia. These students are exploring digital preservation using XDB and XAM. 

Where is it all going to lead?  There are a lot of possibilities at this point.  When these three steps are followed in earnest, solid ideas are usually generated.

Steve

Information Playground

Twitter: @SteveTodd

EMC Intrapreneur

Wavemaker Ripples

The VMware acquisition of WaveMaker was recently announced by SpringSource.

The acquisition certainly has cloud implications. In fact,  EMC's Chief IT architect characterizes WaveMaker as "PowerBuilder for the Cloud".  If a WaveMaker framework is properly architected into a Platform-as-a-Service cloud deployment,  a very positive "ripple effect" can occur. The ripple effect I'm referring to would be a steady decline in new ShadowIT deployments. ShadowIT refers to the creation of all those mini-IT skunkwork systems dotted throughout multiple business units within a corporation.

One of the more popular studies describing the motivations and reality behind ShadowIT is the RSA confessions survey published several years ago, in which the following statement was made:

35 percent of respondents have felt the need to work around their organization's established security policies and procedures just to get their job done.

For those that are unfamiliar with WaveMaker, think of it as a CASE tool that allows a person to draw pictures instead of writing code (e.g. code is automatically generated).

The understand how WaveMaker can reduce the attractiveness of ShadowIT, consider a use case where a knowledge worker (e.g. sales account manager) wants to work with their own copy of a customer database in order to more quickly run some "what-if scenarios". They may wish to run some simple database queries that generate new tables, provide new graphs, and unlock potential new business leads.

But they don't know how to code, and they'd rather not go through the process of having IT create a script. So they find some backdoor method to dump a portion of the database into Excel, or they leverage some talent within their business unit with a reputation for "getting things done, no matter what it takes". Maybe they e-mail some of this work to their home account to get it done after hours.

The hazards of ShadowIT are obvious:

• sensitive data can be exposed
• local and federal laws can be inadvertently broken
• confidential information is weakly protected and therefore more easily at risk of theft

In addition, the corporation is unable to leverage potentially valuable new ShadowIT data, given that it is "hidden" and potentially "under somebody's desk".

WaveMaker As A Cloud Service

Instead of investing in ShadowIT, a knowledge worker, from any business unit, could draw a picture of their business logic with WaveMaker, and deploy it to a corporate cloud. 

That's the vision. Click on the image below to see a demo of how WaveMaker works:

The PaaS Dependency

This vision won't work without WaveMaker functioning as an element of a well-thought-out PaaS framework. There are two critical PaaS aspects worth mentioning:

1. Support for Application Infrastructure. Many people think of PaaS as a framework that supports multiple programming languages and techniques (e.g. Python, Ruby-on-Rails, Java). Integrating WaveMaker into this infrastructure would also provide support for non-developers. This brings even more people onto a common platform that provides the advantages of ShadowIT with less risk.
2. Support for Application Services. A good PaaS framework has a set of application services that IT  provides (e.g. grid services, security services). If WaveMaker users have access to a service registry,  they can build business logic much faster than they could using home-grown ShadowIT.

WaveMaker is a solid addition to VMware's vFabric Cloud Application Platform. To get a lower-level view of how vFabric is stitched together (and how WaveMaker might fit in), read up on technologies such as tcServer, Hyperic, RabbitMQ, ERS, and GemFire.

Steve

Information Playground

Twitter: @SteveTodd

EMC Intrapreneur

 

VDC Class Launches

Last week Chuck gave an update on the launching of EMC's latest certification course, and mentioned that there were nearly 500 people signed up to take the course.

Earlier this year I was invited to participate in the creation of the test and a beta version of the course. I got an insider's view into how it is all put together. To be honest, I didn't have that much to contribute. When you spend most of your time building the insides of a new storage system (VNXe), it's hard to keep up with the deep knowledge and field nuances required to build a virtualized data center (VDC).

Now that the VDC course (and exam) are launched, the EMC Ed Services team will turn their attention to the expert version of the EMCCA track (Cloud Architect) for both the course and the exam. I will raise my hand should they need volunteers; exam and course generation brings together the experts in VDC and cloud design, not only from EMC, but from Intel, VMware, Cisco, and other companies as well. Listening to their conversations is an education unto itself.

In my opinion the main reason to go to the course is to interact with the customers and field experts that are in attendance. Some of them are server virtualization experts, some favor the network side of things, several are storage virtualization gurus, and yet another segment have experience with virtualizing apps. The course drills deep into all of these areas (in fact it is a two-day fire hose of information).

The real crux of the class, in my opinion, starts in Module 3.

Designing For Virtualized and Cloud Environments

Virtualized data center design is an exercise in requirements gathering. The requirements (e.g. elasticity, self-service on-demand, resource pooling) are not necessarily easy to articulate.

The main role of a VDC architect, therefore, is to have a framework for gathering cloud requirements, and then translating them into an architecture and design that satisfies those requirements. The course outlines a requirements gathering framework,under the assumption that the customer is transforming from an existing data center (as opposed to a greenfield deployment).

Here is a requirements gathering framework (in a nutshell):

• Gather data
  • Inventory resources
  • Document Current state
  • Determine Key project drivers
• Perform Initial Analysis
  • Identify opportunities to consolidate
  • Draft initial VDC strategy
  • Document Priorities
  • Create Justification
• Evaluate Technology Options
  • Compute resource considerations
  • Network resource considerations
  • Storage resource considerations
  • Application resource considerations
  • Management strategy considerations
• Create Plan
  • Document Future State
  • Document Migration Plan
  • Review Design, Plan and Justification

Each of these steps has checklists and strategies on how to gather requirements and translate them into a design. They represent a starting point.

The real learning about this framework begins with the class commentary:

• "That didn't work for me, because....".
• "I use this approach when....."
• "I recommend inserting an additional step...."
• "Where is the step that takes these business silos into account...."

The curriculum, and the labs, are geared to stimulate conversation between actual and aspiring VDC architects. In fact, I would estimate that at least one full day is spent designing a VDC alongside classmates.

I recommend the course. Afterwards I was asked for my thoughts about the class, which I've included below. Also feel free to listen to the commentary from Chris and Wade.

 

For more information about signing up for the course, click here.

Steve

Information Playground

Twitter: @SteveTodd

EMC Intrapreneur