It's a different perspective being at EMC World as an engineer and seeing an announcement or showcasing of a product that you've worked on for months and years.
There were two products announcements in particular: VPLEX and Unisphere. Much has been written about their features and functionality, but what I find interesting is the way that they were built. I did not directly work as a member of either of these business units, but myself and dozens of my co-workers had a hand at contributing to both of these software efforts.
Given the number of acquisitions last decade, there are many valuable algorithms and features embedded within different products across EMC. One interesting design exercise is to analyze the architecture of each product and determine the level to which the algorithm or feature can be extracted from its native environment and turned into a reusable software component. If the component can be extracted, it is free to be reused and inserted into other products, put inside VSAs, installed on servers, etc.
At EMC World it occurred to me that VPLEX and Unisphere were two products that benefited from the reuse of components developed by other organizations, and as the years progress I'm sure that this situation will become more and more common.
I wrote in my post about VPLEX quality that the base platform for VPLEX is a reused version of LINUX that runs inside other products (like Centera). As part of this LINUX version VPLEX has the option to pick up other components like platform monitoring, upgrade, logging, etc. It's similar to a community sourcing model where a menu of features are there to be re-used or enhanced should they meet the needs of the product.
From the Unisphere perspective, a close comparison of the user interface with VPLEX's interface reveals the beginnings of a similar look and feel. There is a reusable, FLEX-based GUI toolkit which contains common screens, wizard infrastructures, and navigation frameworks. Another point of interest is that Navisphere's web server/CIMOM has been componentized. In addition to running on it's native Windows platform the same code was reused inside VPLEX to serve up GUI screens and handle CLI commands.
Past componentization efforts have enabled more cross-pollination of products, such as the embedding of a deduplication component into Celerra and the reuse of Celerra assets within CLARiiON's FLARE code base. A re-usable security component was built from RSA and is now running inside many different products.
These are examples of existing software which has been re-purposed for re-use.
New code that gets written is also designed in such a way as to fit this model. At EMC World application-aware provisioning was previewed; this logic is being designed into components that can be reused across products as well.
A longer-term vision for this type of development process is that of a library of components that can be assembled and targeted towards a particular service. While this vision is by no means an "open model", it has a lot of similarities to what I see described as a Service Component Architecture (SCA).
Building quality, re-usable components allows for faster development cycles. Iomega does this well by churning out frequent product/feature updates based on open-source components; this design pattern is starting to make its way up-market as well.
Steve
http://stevetodd.typepad.com
Twitter: @SteveTodd
EMC Intrapreneur
Comments