Software as a process

I have always had a (largely concealed) aversion to the term "software architecture". Indeed I even used to think: the less architecture you had, the better. "Software architecture" seemed to me as an euphemism for "premature constraints" that limited the directions into which your software might evolve; the new clothes on the widely disregarded "waterfall" model. Furthermore, before the rather pompous sounding ideas of "software architecture" were invented (and then standardized by ISO commitees), we had already had notions of good "software design" covering about the same themes.

I was also suspicious about comparing software to other disciplines such as civil engineering where physical structures are erected. Another analogy, city planning, commonly invoked by those colleagues who prefer to call themselves "enterprise architects" was somewhat less alien, but still not quite appealing for some reason.

I used to attribute that apprehension to my perceived malleability of software, the relative ease of changing it, adding to it, reconfiguring it. I still think that is a valid reason to object to analogies that also let us think about software lifecycle as "build (or buy)", "use", "replace" phases and that inescapably guide our thoughts toward the established notion of licensed "software products". But I feel there is also a nimbler mental notion which neatly explains my discomfort with those mainstream ideas: software as a process.

Processes - as in "business processes" or "industrial processes" - are a way of modelling the world in terms of events, changes and dependencies. Good things happen. Bad things happen. Resources are consumed and produced. Information starts and stops flowing between entities. Entities come into existence. Entitites disappear. Databases grow. Users request services. Customers are won and lost. Cash flows. The world is in motion. Careful, continuous process control at all levels is what we need to avoid costly mistakes.

Our role as software developers is often not to invent some sort of "best practice architecture" and then naively stick to it, not even to bring a specified product to market. Instead, it is to react to environmental changes and guide our software through a path of constant change. It is to ensure that we maintain control of that what we once built - and keep extending, adapting and improving - and to design our software in such a way that the broader processes in which it participates are supported rather than hindered. It is to anticipate scenarios with risks and opportunities and to make them less or more probable to fulfill business objectives. Such scenarios always concern both the currnet use and the future evolution of the systems we create.

By the way, the distinction between "programming in the large" and "programming in the small" is FUD. When viewed through the lenses of process control, both areas indeed appear much the same, unified even. The structure of our engineering problems is more akin to a fractal or a piece of music: the same (few) recurring themes and prinicipal rules of composition appear both in the large and in the small. However, few people flip-flop between work at different scales, which leads to an unfortunate multiplication of different names for similar concepts.

Today I am relieved to see that for several years I haven't been the dumb one who was stubbornly rejecting the grand concepts of software architecture and marketing myself as some awkward combination of "developer" and "systems administrator" (a jack of all trades...) at my own peril. The ideas outlined above now seem to be gaining increasing popularity among highly respected practitioners charged with maintaining big software systems in big (Internet) companies. Lo and behold, there even seems to be a catchy buzzword: "devops", a mix of the traditional roles "developement" and "operations".

By the way, I am not opposed to the job role of "software architect", if you interpret it as someone who is hired by a client to keep watch against imagination of inexperienced software developers (although "software process manager", "master devop" or simply "chief programmer/designer" might still be more accurate descriptions of the job).

Last, but not least: YMMV. The world of software development is diverse that it is likely that no single mental model will fit all imaginable contexts; or that the signle grand unified model may prove too abstract to be immediately useful. It makes quite a practical difference if you are designing shrink-wrapped software products for consumers or planning or maintaining installations of enterprise or Internet SaaS applications. Pick your specific models wisely, so as to benefit your own work.