I did some consultancy work recently where my primary task was to review the development environment and build processes for a software system. From an external perspective it's a relatively simple looking system but behind the scenes it's a more complex set of interactions between a number of disparate systems. In order to understand and improve how a software system is developed, built and deployed, you need to have an understanding of a number of things from the basics of the technology stack through to the structure of the overall system (components and interactions). When I started exploring the system with the team, it became apparent that there was a lack of technical leadership and overall architectural guidance.
As an example, nobody had a single big picture understanding of the overall system, it's components and the interfaces with other systems. Everybody knew about their own areas of work but the same level of effort hadn't been placed on the integration of those areas into a single cohesive system. The result is that the development, build and deployment processes in use across the system feel different and disconnected. Essentially each team member is taking a siloed approach to building components and this also reflects the lack of a clear and consistent approach to dealing with architectural aspects such as data access, configuration, etc. While the team may be able to keep on top of the system at the moment, future development won't be able to take advantage of common infrastructure services because they simply don't exist. Reuse opportunities are being missed and the system will be harder to maintain in the future because standard approaches to solving problems aren't being adopted.
The situation here is common to many software projects and issues like those I've mentioned are warning signs that the projects are lacking technical leadership. This technical leadership doesn't have to come in the form of upfront architecture but it does require team members to be architecturally aware, defining reusable approaches and services to tackle common problems where appropriate. My task was only to look at improving the development processes, but those existing processes highlighted some problems with the overall architecture of the system. The build process usually sits on the sidelines for most software projects but it *can* be an excellent architectural health indicator.