Vertical and Horizontal

 There is an overall solution space. It is the full scope of things that are possible to build that will use software to solve a specific domain (often business) problem. 

These days, in most organizations, the demands for new development work most often come in as top-down requirements from the domain, users, or directly from some change in a line of business. It is vertical, which is why it often ends up in silos.

But the construction of the system should really be driven horizontally. That is, you need to get as much reuse with similar code in all of the systems as possible; you are looking for commonality as it crosses different boundaries. Technical issues like authentications, logging, and users are the same everywhere. The setup, configuration, building, and deployment are all the same too. It doesn’t make sense to keep reinventing these all too common wheels.

Sort of looks like this:

At least 50% of most systems development is base infrastructure. Just a platform on which the functionality will sit and perform properly. Often it can be higher than 80%. It changes somewhat by tech stack, and maybe a little for specific domain issues like highly restricted data, but otherwise, it is always the same. 

Similarities most often occur with the interface and the persistence. But what is also very common is the same types of basic and general domain-specific data. Vertical silos are very rarely independent, they overlap as messy hierarchies naturally form everywhere in large organizations. So, you see lots of similar features or systems sharing the same basic data, with the same computations, at least they should all be the same.

The vertical time horizons are usually short-sighted. They are reactive to the needs of the stakeholders and are often too busy dealing with old existing problems to be able to lay out longer or more effective options.

The horizontal time horizons are more similar to long-term issues like physical office space. They are infrastructural, slow to accumulate, expensive, and need continuing maintenance. They take foresight, so they are far easier to ignore. But the costs of ignoring them are a crazy large amount of make-work and a lot of impedance mismatch problems (functionality that should be identical but isn’t).

It gets a little more confusing when you realize that most methodologies, processes, and their tools ignore the horizontal axis as well. They can’t deal with two sets of orthogonal drivers, so they just default to top-down, and help reinforce all of the wasted effort. The controls that we are using to better ensure project success are the same ones that are guaranteeing that lots of work will be reduplicated. That lack of time will drive extreme technical debt.

It is hard though, to try to go something reasonable on the horizontal axis, while also satisfying the vertical one. Realistically, it would mean dividing up the resources between the two, then trying to ensure that they intersect as often as possible. It can be done, but it is a lot rarer than just blindly pushing everything top-down. However, when it’s been done, it has amplified the value of the work considerably. That is, it may be hard, but it is also worth it.