This month I thought I'd write an article from a vendor's perspective. As vendors, what do we need to do to help the CM/ALM industry move forward? Now this in itself is a loaded question because forward assumes a starting point and the industry is not at a common starting point. There are mostly second generation solutions out there, with many vendors trying to build 3rd generation functionality onto them.
There's a problem there. Elon Musk may have said it best after the splashdown of his Dragon capsule this month, when he said that [b]when you assume existing technologies, you assume their cost structures as well.[/b] Trying to build the next generation space access vehicle from components of the Space Shuttle (i.e. STS) may save some costs in some parts of the development, but overall, the solution will be relegated to the cost structure of STS. The Falcon/Dragon technology of SpaceX started with a few key principles which has allowed SpaceX to set themselves apart from the others:
- Build what we need internally (keep control of our destiny)
- Use common technology across the subsystems and products
- Perform extensive testing, with heavy automation
- Create the ability to react quickly to problems
- Keep administration and overhead low.
- Re-use components where possible - that is, re-use of the rocket/capsule for a second launch.
Elon, diplomatically, also said that the NASA-Commercial partnership works. They've proven it. That's true. It does work. But only with the right commercial partners, as we're sure to see in the future. NASA, to their credit, recognizes that, not only do they have a lot to teach SpaceX, but they have a lot to learn from SpaceX. Except for a launch escape system (which the shuttle does not have), the Falcon/Dragon is very close to having the ability to support manned flight - at a small fraction of the cost of any previous US Manned Space Program.
So how does this apply to ALM? Well, from a vendor perspective, it's not easy to just throw everything away and start over again. That doesn't mean we can't offer more and more functionality and capability. But it does mean that without a fresh start, what we produce is constrained, in cost structure and architecture.
Let's look at the past to a few examples.
In the 1990 time frame, Atria took the experience of the Apollo DSEE version control model, and applied it to a new product, called ClearCase. Had Atria attempted to build out from Apollo DSEE, they would have carved out a nice little niche market rather than taking the market by storm. ClearCase has been dramatically successful, though its 20-year architecture is showing signs of constraint. Still, a little polish here, some new infrastructure there, and a nice product evolves in 2010 (RTC). Is it a full 3rd generation CM/ALM product? Yes and no. Lots of 3G capability from the end-user experience, lots of 2G from the back end. But that's because it is somewhat constrained.
In the mid-90s, Perforce started from scratch with a product. Very successful again. Why? Again primarily because they were unconstrained in their approach. They were able to say "we don't want the admin headaches that other tools show" and "we can't have the performance issues characteristic of the leading vendors". With those goals in mind, they successfully created their CM product.
In the '70s and '80s, yours truly produced some very capable 2G CM/ALM tools for Nortel (then Bell-Northern Research), and Mitel, both large Ottawa telecomm companies. When an attempt in 1989 to acquire the Mitel ALM technology failed, Neuma started to create a new product from scratch. However, like Elon Musk did at SpaceX, Neuma looked at the full industry requirements for ALM and decided, not to build a CM tool or an ALM tool, as had been done at BNR and Mitel, but instead to build an architecture that could endure. As a result of this, Neuma moved forward, with some mistakes, but at the turn of the century, came out with