I got a chance to take in a fair bit of the ALM EXPO this year and some good talks that were still accessible. In the opening keynote, however, I was surprised at how the panelists responded to one of the questions pertinent to this month's journal. The question was: Does size matter for application lifecycle management (ALM)? The answers tended to center around level of implementation and complexity of the application:  Are the teams operating globally?  Are they small enough for verbal communication? 

The implication seemed to be that ALM was not as important for very small organizations as for larger ones, or at least that a less full implementation was acceptable. At first glance, this seems to make sense - more people to manage, more files to manage, etc. And there is no question that ALM is necessary for large teams.

Let's put the question in perspective, though. Say that you're a small firm and you have to produce and deliver a product that can compete with those from larger firms. Your product has to be not only as good of a product offered by your competitors, but a better product. Also, you don't have the same amount of staff to draw from to get it done.

Which parts of the ALM function can you afford to skip? Which parts can you afford to do manually? Which parts can the larger competitors afford to do manually? None. None. Some. As a small business, you still have to compete on level terms. Whereas your large competitors can throw manpower at enforcing process, and can put manual processes in place if they don't have their tools quite right, you don't have such spare resources. A small business relies much more on strong tools, good processes and automation simply because it can't afford not to.

So yes, size does matter for ALM, but it's the smaller companies that need the more complete solutions. They still need to track requirements, customer requests, backlogs, builds, source code, test suites, documentation, problems, etc. They still need disaster recovery, backups, integration, etc. And then they need zero administration, strong pre-defined processes, higher levels of automation, and, of course, very high reliability. Who can afford the staff to deal with administration, process customization, lower levels of automation, or down time? Perhaps the larger firms, but definitely not the small ones.

So ALM is critical for small teams. On top of that, add another 20 team members to a small team and you've got a fair bit of change that you must adapt to - so your ALM solution better allow you to adapt. For a large team, 20 new members is hardly a blip, and if the ALM solution doesn't adapt, just throw some manual labor at it. Growth is another reason small teams need ALM.
Why?
Why did the panelists suggest that perhaps some ALM functions were less critical for small business? This is a key question and it tells us a lot about our industry - where it is.

The answer comes down to one of CM Generations. Most CM solutions today are mid to late 2nd generation solutions, with some elements of 3rd generation capabilities. These solutions tend to come along with significant millstones:

• Heavy infrastructure
• Lots of administration
• Costly customization, in-house or contracted
• Significant data mining expertise
• High license costs
• Significant glue/glue maintenance for non-monolithic solutions

The list goes on. Are they better than simple source code solutions? Definitely. Are they worth the extra costs? Definitely. Would I recommend them? Well, not so definitely. Why? Because 3G and 4G CM solutions don't impose the same big-IT requirements.  There are no millstones around the project neck.

So if you're familiar with 2G systems, but not as familiar with later generation systems, you understand that small teams simply don't have the resources to implement full ALM solutions. They can't afford the administration, license and infrastructure costs, expertise for customization, glue, and data mining. I would have to believe that that was the perspective of our panelists. And they're right.

But if you're more familiar with 3G and 4G systems, 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
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. Today, though, as with 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 indispensable.

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, he 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 1980s.

I've been fortunate enough to use 3G and 4G solutions for well over a decade, and to recommend them. 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). Don't make the mistake of fixating on a specific feature, when you need an end-to-end solution.

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, tut 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 them. Why? Why would they impose a lesser solution?

It's the same argument. If you have a 2G solution, you've put a lot of resources into it. You know how much it costs. You buy out a small firm with a different solution. There's no way you're going to absorb your 2G costs again - so you mandate conformance. In other cases, I've seen a move from 2G to open source solutions which were less capable but perhaps less costly. Again, when a 3G solution appears in a small firm that's bought out, the open source solution is imposed.

So my recommendation is not any different for larger firms: by all means implement full ALM solutions, but look beyond 2G solutions. Same wording, small team or large team - but small teams simply can't make up the difference with additional resources, so it's more critical for them to heed this advice.

Let's Get Specific
Why is a 3G or 4G solution so much easier for a small team? After all, in a small team you typically don't need many of the 3G features:

• Multiple site operation
• Fancy reporting
• High performance
• Extensive customization capability
• Electronic approvals

These might be nice to have as you grow your team, but I'm not going to move to a 3G solution to get that set of features when I'm a small team. There are other 3G features that are critical:

• Low acquisition and operating costs
• Easy to install (and evaluate)
• Very low administration
• End-to-end ALM
• Good out-of-the-box process
• Easy to load in product data
• Reliable
• Easy to use / low training level
• Mature CM functionality
• Low-effort automation capability
• Easy to customize
• Easy traceability navigation

Look at these features:  lower costs, less effort, mature process, and productivity. In a small business, or a small team with a small budget.  These aren't just nice-to-have features, they're life savers. They allow you to do the same as larger teams, but without a major investment in dollars or time. If you run, or have run a small team, wouldn't you agree?

Some of you, I'm sure, are still not convinced. If so, I'll wager you haven't yet ventured into a real 3G solution:  a small-IT, big-value ALM suite. The pace of CM/ALM advances probably doesn't suggest that you have to look at technology that often, but perhaps the time is now, especially if you're running a small project, or even a big project with a small team.

So the next generation of CM and ALM processes and tools change the game for small teams. It's no longer a question of what parts of the ALM process we cut out or ignore. Instead, it's how can I compete against a Goliath competitor.