It seems the basic architecture of Jenkins is such that jobs are individual units of work, meant to be related in very trivial ways with other jobs for the mere purpose of synchronizing the execution of related jobs.

What seems to be sorely lacking is a robust dependency management scheme that allows jobs to be treated as actual inter-related entities with specific functional and behavioral requirements. Because of this limitation there are numerous plugins and extensions that attempt to workaround this issue, such as the Join, Conditional Build Step, Build Blocker and Locks and Laches plugins.

Even the "Advanced" job options for "blocking" jobs when upstream and downstream jobs are running is further indication of this lack of dependency management. If JobA depends on JobB and thus triggers the downstream job upon completion, I can't imagine ever wanting the two to run at the same time - ever. The fact that this behavior is optional is quite illuminating.

This limitation gets even more prevalent when you have large, complex job sequences to orchestrate, with non-linear interdependencies between them. There are countless questions on forums and sites discussing workarounds, often leveraging the features of several related plugins hooked together to "partially" solve these dependency issues, when it seems the problem would be best solved in the Jenkins core functionality.

The one underlying issue that cross-sects all of these topics, and affects nearly all plugins that I've tried which help work around this limitation, is the problem that jobs that are inter-related in different ways are expected to be independent from one another by default, rather than making the dependency enforcement mandatory.

Take for example the Join plugin. It provides a very basic ability to define non-linear relationships between jobs, allowing a diamond-pattern relationship between them. So JobA can trigger jobs B and C, and then once these two jobs complete successfully Job D gets triggered. Sounds fine and dandy until you realize that you can quite easily trigger job B to run and, once complete, it will happily trigger Job D even if Job A and C are broken. Similarly, even if all 4 jobs have the "block" when upstream and downstream jobs "advanced" options set, JobD can still be executed in parallel with Jobs B and C.

Now, some may say that these bugs are probably the not with the Jenkins core but rather with these plugins, and at first glance I would tend to agree. However these limitations are so common and pervasive across nearly all job-management related plugins I have tried that it is hard to deny there is some core feature missing from this tool.

Maybe there is some magic bullet that helps resolve these issues that I'm missing but I have been administering a Jenkins build farm with 10 PCs and nearly 500 jobs for several months now, and I've tried dozens if not hundreds of plugins to try and orchestrate non-trivial dependency management between jobs which, at best, results in a complex sequencing of many such plugins, and at worst has met with utter failure.

thoughts
Perhaps an easy solution would be to provide some kind of a "global" option in Manage Jenkins section that forces all jobs that trigger other jobs to act as if they are actual dependencies of one another rather than just dumb triggers. Then upstream jobs that are running or failing would prevent downstream jobs from running, even when these dependencies follow a complex, non-linear relationship and regardless of which plugins are used to orchestrate these relationships.

Alternatively, maybe what we need is a new job type, call it "component job" or something. When instantiated it would have options that allow complex dependency management between jobs to be handled automatically.

Whatever the solution, I strongly feel that this is a very important feature that is badly needed in Jenkins and would help make the tool much more practical for large scale CI needs.