What is ALM? Traceability
What is ALM?
If you are a software developer, there are a whole bunch of
companies (including mine) who want to sell you stuff.
If you read any magazines, go to any conferences, or visit
any websites, there is a good chance you've seen their (our) marketing efforts.
More and more often, the term you see in those marketing
materials is "ALM". Ever wondered what that term means?
It means "Application Lifecycle Management".
Don't you feel better now that I've cleared all that up? :-)
Digression: Dead-End Acronyms
So ALM is what I call a dead-end acronym. Like all
acronyms, nobody knows what it means until you see its expanded form. But with
dead-end acronyms, people can stare all they want at the expanded form
and they still don't know what it means. There's nowhere to go. It's a
We software developers have a tendency to create dead-end
acronyms. For example, SOA means "Service Oriented Architecture", but I still
don't know what that means.
My personal theory is that dead-end acronyms get created
when somebody forces the issue. They create an acronym which didn't want to be
created. Indigo didn't really want to be WCF -- it just wanted to stay Indigo.
Dead-end acronyms. Our special gift to the world.
No, really. What is ALM?
Back to the point. What is ALM? Let's look a bit deeper.
The expanded form actually does hold a few clues:
- From the word "Application" (and from the overall context)
we know that this is about "Software Development".
- The word "Management" is fairly intuitive all by itself.
- The word "Lifecycle" tells us that we're talking about the
whole software development process. All of it.
So, we can translate "ALM" to "Managing The Whole Software
I suppose it's obvious that "MTWSDP" doesn't exactly roll
off the tongue like "ALM" does.
Worse, I'd have to say we still haven't made much progress
here. Isn't there some way out of this dead-end?
What is ALM?
Two roads diverged in a wood, and I...
Starting from this point, attempts to define ALM usually go
in one of two distinct directions.
- The Trees (focus on the details)
- List all of the activities in the whole software
development process (idea, market research, requirements, design,
architecture, implementation, testing, release, wild drunk release party,
user support, postmortem, assignment of blame, sackings, regret over
impulsive terminations, rehiring as contractors at twice the cost,
lather, rinse, repeat).
- For each activity, list one or more tools that support
that activity (requirements management, modeling, compilers, automated
testing, issue tracking, project management, dart board, help desk, time
- The Forest (look at the big-picture)
- Talk about the benefits that software managers can get
from looking at the whole lifecycle.
- Talk about the integration between the various tools in
the whole software development process.
I believe the essence of ALM lies in the big picture view,
in the real benefits that software managers get from using a truly integrated
suite of tools that give them the ability to deal with the whole software
development lifecycle. My definition of ALM proceeds from The Forest
perspective, the big picture view.
Getting more specific
So far this piece is over 500 words long and it still
doesn't say anything. It's time to get a bit more specific.
Before I go any further, let me say that this particular
article does not attempt to offer a complete definition of ALM. For now I am
going to focus on just one issue: Traceability.
Let's look at an example.
The Mystery of the PersonCompanyAssoc Table, Part 1
Joe is a technical support representative for CrummySoft,
an ISV that sells a CRM solution. He is working with a customer who says they
just upgraded from version 6.0 to 7.0 and suddenly everything became really slow.
In an effort to track down the problem, he goes to visit Sally, a program
Joe: One of my customers says version 7.0 is a lot slower
Sally: How much is "a lot"?
Joe: Loading their dashboard page went from 1 second to
around 30 seconds.
Sally: That's a lot. How many other customers are
complaining about this?
Joe: I've heard of a few. Maybe a dozen. So far.
The detective work begins. Sally opens her IDE and digs
into the problem. Looking into the DB schema, she sees something odd.
Sally: Here's something odd.
Sally: Somebody changed the SQL table schema during the 7.0
dev cycle. In 6.0 and prior, each person could be associated with exactly one
company. In fact, the People table had a column which was a foreign key into
the Companies table. Sometime during 7.0, this changed. Now we have a new
table called PersonCompanyAssoc, which allows a Person to be connected with
more than one company.
Joe: OK. So what's the problem?
Sally: The problem is that there were lots of places in the
code which assumed a Person would only be associated with one Company.
Somebody went through and tried to fix them all with a bunch of changes to
indexes, triggers and constraints. Not all of those fixes were done in a very
scalable way. Most customers will be unaffected, but I could imagine some
situations where we end up with a major slowdown.
Joe: What kinds of situations?
Sally: Well, for example, I'm guessing things would get bad
if the Locations table has lots of different entries for the same Company.
Joe: Bingo. My customer deals mostly with virtual
companies. Their database has one company which is scattered across thirty
different states and five countries in Europe.
Sally: That would do it.
Joe: So doesn't this change seem kind of stupid anyway?
Why would somebody need the ability to associate one person with multiple
Sally: I don't know, but there's probably a reason. Let's
look for more clues.
Sally brings up the version control history log to find
out who made these code changes and why.
Sally: Apparently the PersonCompanyAssoc table was added by
a developer named Tony. The checkin comment explains what he was doing, but
there's no rationale for why and no mention of the spec for this feature.
Joe: So hey, as long as we're here in the code, can you
just put it back the way it was? If this change doesn't make any sense and
it's causing performance problems, why not just undo it?
Sally: It would probably be better to understand the whole
story before we just change it back. Let's go find Tony and ask for more info.
Isn't version control enough?
Version control does give you some traceability, and that's
a good thing. But in many cases, it is not enough.
Version control will tell you about code changes. It can
answer questions like Who, What and When. But the hardest question in
traceability is Why, and version control often lacks enough information to give
a good answer. Even if the developer is supposed to give a checkin comment
which explains why a change was made, the detective work tends to get stuck
because the clues dry up.
- Why is this piece of code there?
- Which bug?
- But why was this a bug?
- Oh, the spec says it should work this way.
- But why?
- Oh, here's the rationale for that requirement. It came
from marketing research.
Very few developers write checkin comments which are good
enough to solve the really tough mysteries in software development, and they
shouldn't have to. We don't need better checkin comments. We need all the
artifacts from the whole software development process to be linked together.
The Mystery, Part 2
Sally and Joe walk across the CrummySoft campus to
building 71 where they find themselves in a seemingly endless room filled with
cubicles. The manager sitting next to the entrance at a mahogany desk with a
nameplate identifying him as Biff.
Biff: Can I help you?
Sally: We're looking for a developer named Tony. Is he
Biff: Why do you want to see him?
Sally: He made a code change and we need to ask him for
more information about it.
Biff: OK, let's see. Tony. Ah yes, he's in cubicle
Joe: 19-346-B. Where's that?
Biff: I gather that you've never been here before? Very
well. Cubicle 19-346-B. Go to aisle 19. Walk down to the 346th
cubicle. Tony should be in the one on your left.
Joe and Sally eventually reach Tony's cubicle where they
find him playing World of Warcraft.
Tony: You need somethin'?
Joe: Why did you add a PersonCompanyAssoc table during the
7.0 dev cycle?
Tony: How should I know? That was like nine months ago.
I've probably made at least two other code changes since then. I can't be
expected to remember details like that.
Sally: Do you know anyone who might know?
Tony: Ask Phil in QA. Maybe there's some info in that bug
tracking database I've seen him using.
Joe: So where do we find Phil?
Tony: Geez, have you guys never been here before or what?
Phil is in cubicle 61-842-A. That means you go down to aisle 61, turn left,
and walk down ---
Joe: Yeah, yeah, we got it. Thanks.
Sally and Joe meander their way across the cubicle field to
find Phil. Along the way, Joe pauses at the intersection of an aisle and a
row. The walls in all four directions are too far away to see. Continuing on,
they eventually reach their destination.
Sally: Phil, any idea why Tony added a PersonCompanyAssoc
table about six months ago?
Phil: Yeah, I think we did that to fix a bug.
Joe: Which bug?
Phil: How should I know?
Sally: Well could you look it up?
Phil: Fine, let's see. Oh yeah, it's bug 8675309.
Sally: Does that bug have any information about why the
change was made?
Phil: Not really, but there's a comment here by somebody on
the sales team. Did you talk to them yet?
Joe: Aha! Let's go ask the sales team!
ALM tools are often associated with very large projects and
enterprise development. This is just intuitive. The more people involved, the
more complexity to be managed.
Imagine trying to solve a mystery and you get stuck. You
need more clues, so you start canvassing the neighborhood looking for people
who might have seen something suspicious. Now suppose that "the neighborhood"
is a software development division with 5,000 people in it. Those interviews
are going to take a while.
But chaos usually takes over long before a team gets that
large. Traceability may not be as important for a team of 50 as it is for a
team of 5,000, but it can still be pretty important. People forget why things
happen, and that forgetfulness is not a function of the size of the team they
You may be thinking, "My team is small. We shouldn't have
these kinds of problems, but this mystery still sounds familiar. Why does this
kind of detective work happen when we've only got 10 people?"
Are you sure you are counting everyone? :-)
How about your customers? They are part of your story.
When a customer asks for something, very often it triggers a sequence of
steps. And somebody will probably want to trace that sequence back to that
SourceGear is a pretty small company. We've got less than
50 people on our staff.
But our flagship product, Vault, is used by about 50 thousand
people. Sometimes we have a mystery to solve. And very often the detective
work leads us to one of those customers. Our customers add to the complexity
of our software lifecycle, and increase our need for traceability.
The Mystery, Part 3
When the plane arrives in Grand Cayman, Sally and Joe are
greeted by a dozen beautiful people with perfect tans who escort them to the main
company sales office, where, as always, a party is in progress.
Joe: Who should we talk to?
Sally: Let's find Bill. He came to the company
headquarters once for a meeting. I think he'll remember us.
Weaving through the crowd, they eventually find Bill,
martini in one hand, cell phone in the other.
Bill: Do I know you? Oh, wait. Don't you work at the HQ
back in Minneapolis? I think we met last summer when I came up for that golf
outing, er, I mean, sales training. So what brings you all the way here to
visit the sales team?
Joe: We're trying to solve a mystery. Between 6.0 and 7.0,
somebody changed the database schema to handle multiple company associations
per person. Any idea why?
Bill: Can I offer you a martini?
Sally: Seriously, Bill, this code change is causing a lot
of problems. We want to just rip it out, but we figure we should understand
the background first.
Bill: Yeah, yeah, whatever. That wasn't my deal. Ask
After a bit more searching and stopping briefly to slide
under the limbo bar, Joe and Sally find Marty in the corner of the room
speaking intensely into his cell phone.
Marty: Don't worry, you can count on me this time! I'll
have the feature in version 8.0, I promise!
Sally: Hey Marty. We're trying to track down some
information. Somebody changed the DB schema during the 7.0 dev cycle to allow
multiple companies to be associated with each person. Were you the one who
requested that feature?
Marty: Yeah, that's me. I needed that tweak to close a
deal. Is there a problem?
Joe: Yes! That was a lot more than a "tweak". It may seem
simple, but it involved hundreds of code changes, and all kinds of things got
Marty: Can I offer you a martini?
Sally: Seriously, can you tell us why this change was necessary?
Why would anybody need to keep track of multiple companies per individual?
Marty: One of my accounts is using our CRM product in
selling to a network of consultants. Those consultants have loose company
affiliations. One day they might be representing company XYZ, and the next day
they're working for company ABC. The assumption of "one company per
individual" just wasn't flexible enough.
Sally: Was it a good deal? I mean, was this worth the
Marty: I think so. The deal was quite lucrative, and it
opened the door to half a dozen more like it, three of which I have already
signed. Look, I'm sorry somebody screwed up this code change, but the business
case behind it was solid.
Sally: Alright, fine. Thanks for the info.
The Whole Team
The full story of every significant software development
project includes many different people. Most of them are not writing code.
Tracing an issue backward can mean more than finding the bug report that
motivated a code change. We may need to go back further, back to the spec.
We might need to go back even further, back to the market
research or the sales engagement or the customer support ticket.
A truly comprehensive approach to traceability would
archive, index and link everything:
- Version control
- Issue tracking
- Marketing research
- Email, discussions
- Help desk tickets
The challenge of an ALM tool is to support traceability
across all stages of the software lifecycle.
The Mystery, Part 4
Joe and Sally head back to the airport to catch a flight
back to the Twin Cities.
Sally: So I guess this code change needs to stay. But now
we've got another mystery. This code change caused a bunch of problems. Why
weren't those problems found in testing?
Joe: Let's go back to that QA guy and ask him.
Returning to the main company headquarters, they find
their way back to cubicle 61-842-A.
Sally: We talked to the sales team and got some rationale
for that PersonCompanyAssoc table change. Now we're trying to figure out why
the resulting problems weren't found during testing.
Phil: Hey, don't look at me. I just do what I'm told.
Joe: Whatever. So the product supports multiple locations
per company, right?
Phil: Yeah, I guess so.
Joe: Do you guys have any tests which verify behavior for
Phil: I don't know.
Sally: You don't know? Why not?
Phil: I just don't. The tests aren't really organized like
Joe: Well how are they organized?
Phil: By number.
Sally: And what do the numbers mean?
Phil: Well, nothing.
Sally: So is there any way to find which tests are designed
to verify which features?
Phil: Uh, well, no. You could always open an individual
test and read it to find out what it does.
Sally: Great. So you've got a bunch of tests and no way of
linking them to anything?
Sally: OK, I think we're done here.
Traceability can do more than just help you figure out
forgotten details of the past. Sometimes we want to trace something "forward"
through the software lifecycle, to see where it goes.
In this case, what we want is the following artifacts to be
- Requirement: The system must support multiple locations
- Test (validity): Verify that the system can support
multiple locations per company.
- Test (performance): Verify that in a situation with
multiple locations per company, the dashboard load time remains
This kind of traceability is most helpful in finding things
that are simply missing. If the performance test above does not exist, our ALM
tool should be able to help us notice that. If a Requirement is dangling, with
no links to anything, it was probably never implemented, and our ALM tool
should be fussing about that.
Traceability: Connecting Everything Together
The ability to connect everything together is called
traceability. It allows us to look at the entire software development process,
even though it involves
- lots of different people
- doing lots of different things
- at lots of different times
- in lots of different locations
- for lots of different reasons.
In a good ALM system, every item is linked to all of the
other items related to it. Code changes are linked to bug reports. Bug
reports are linked to help desk items. Tests are linked to requirements. When
it comes time to do detective work, just follow the links.
You can't get good traceability merely by having one tool
for each lifecycle stage. You can assemble all of your favorite tools, but if
those tools don't support outstanding integration with each other, you won't
have traceability, so the result will not be ALM.
So is that all there is to ALM? Just traceability?
No, ALM is more than that, but traceability is a critical
ingredient. To have ALM, you've gotta have traceability.
Why to use a good ALM system
If CrummySoft had deployed an efficient ALM system with
complete information, Sally and Joe could have solved this mystery in minutes,
without the need to run all over the company and ask people questions.
Why not to use a good ALM system
If CrummySoft had deployed an efficient ALM system with
complete information, Sally and Joe would not have gotten a free trip to Grand Cayman. :-)