It is safe to say that Agile methodologies are considered mainstream this day and age. One of the main precepts of the Agile methodologies is using of cross-functional teams and delivering applications in vertical slices for rapid feedback and early exercise of integration.
There can be no debate that the feedback loop and early integration is critical for the success of the project. However, what happens in the systems where infrastructure is significant, perhaps biggest, part of the system? It is hard to create slices of the infrastructure based on vertical slices of functionality being developed for the current iteration/sprint/user-story.
Such a low-level and application specific infrastructure has much higher affinity within itself than with any of the vertical silos where it might be used. It makes sense therefore to develop this infrastructure separately from the vertical slices and leverage it later with the usual Agile iterations.
An important point in this is that by infrastructure I don’t mean DAO layer or service layer. In typical web-apps such layers are nothing but an amalgamation of parts of vertical pieces of functionality. By infrastructure here I mean something like low-level networking, threading models and abstractions, core messaging abstractions, or low-level application-specific services.
Sometimes parts of an infrastructure can be harvested through an evolutionary architecture and emergent design. But in any big and especially non-plain web-systems there is a significant amount of upfront infrastructure that needs to be in place in order to start developing the “end-user” functionality.
Focusing on a single level of abstraction (SLAP), in this case the low-level infrastructural services increases productivity and helps creating a consistent system.
It is therefore important to carefully examine which parts of the system exhibit highest levels of affinity and develop them together as a fundamental block upon which rest of the system will be built later.