CM: THE NEXT GENERATION of Small Team ALM

you realize that they are not "BIG-IT" solutions. There is no heavy infrastructure required, very little administration, lower solution costs, very little glue and customization costs.  And the systems are easy to use, across roles, so there's less training and less expertise required to use them.  You get a lot more for a lot less.  So, in this light, the answer to the question becomes: Small teams can't afford NOT to implement full ALM solutions.  Give me a 2G solution, or even a 2.5G solution, and the same cannot be said.

What a Difference a Generation Can Make
Wow - what a switch a generation or two can make!  It's like computers - most companies could not afford 1st or 2nd generation computers, let alone the costs to run, maintain and program them.  But today, as for the past couple of decades, companies can't afford not to have 3rd or 4th generation computers.  When 1G cell phones appeared - who had them?  Big cars owned by big executives (remember they were tied to the car back then).  2G cell phones certainly widened the market, but 3G and 4G (smart phone) solutions make them indispensible.

So the fact that a generation or two makes a huge difference is not really a surprise.  What is a surprise is that 2G solutions continue to dominate the market.  Why?  There are a number of reasons, and I'll put forth a few of them.

  1. Almost all solutions require multiple repositories or storage mechanisms (across all ALM functions).  That makes seamless integration difficult at best, and increases administration significantly.
  2. Many, though not all, existing 2G solutions were built on top of large infrastructure: RDBMS systems, heavy duty VOB architecture, glue-intensive tool cohesion.  It's not easy to remove large infrastructure as a solution goes forward.
  3. 2G solutions were mostly built to have particular features that shone, and market was built upon these.  The architecture of the point features were great, but in terms of evolving into a full ALM solution, well, the architecture just wasn't there.
  4. A great deal of CM/ALM revenue comes from consulting.  There's a vested interest in having heavy infrastructure.  Don't make a solution too easy to customize and you generate plenty of customization revenue.  I'm not saying solutions were designed with this in mind, but the revenues certainly didn't encourage change.

On top of that, 3G and 4G architectures are not easy to design.  How do you get more out of less?  Of course, that's really just the natural progression of technology.  But database technology has been largely stuck at where it was in the '80s.

I've been fortunate enough to use 3G and 4G solutions for well over a decade, and to recommend them.  And the key is to start with an architecture that will support the weight of ALM, and then to go beyond that. 2G infrastructure simply cannot evolve into 3G architecture without very significant re-architecting.  Don't start with a 2G solution and wait for the provider to evolve it into 3G and 4G solutions, unless you're sure that the underlying architecture was designed for the future (and if it was, the solution should have evolved by now).  And don't make the mistake of fixating on a specific feature, when you need an end-to-end solution.

So the real advice to small teams is:  by all means implement full ALM solutions, look beyond 2G solutions.  I've seen startups go bankrupt trying to implement full 2G ALM solutions.  But I've seen them prosper with 3G solutions.  In some cases, they're absorbed by larger companies which then impose the corporate 2G solution on

About the author

Joe Farah's picture
Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com