  For a software system, its architecture is typically defined as the
fundamental organization of the system incorporated by its components, their
relationships to one another and their environment, and the principles
governing their design. If contributed to by the artifacts coresponding to
engineering processes that govern the system's evolution, the definition gets
natually extended into the architecture of software and software process.
Obviously, as long as there were no software systems, managing their
architecture was no problem at all; when there were only small systems,
managing their architecture became a mild problem; and now we have gigantic
software systems, and managing their architecture has become an equally
gigantic problem (to paraphrase Edsger Dijkstra). In this paper we propose a
simple, yet we believe effective, model for organizing architecture of software
systems. First of all we postulate that only a hollistic approach that supports
continuous integration and verification for all software and software process
architectural artifacts is the one worth taking. Next we indicate a graph-based
model that not only allows collecting and maintaining the architectural
knowledge in respect to both software and software process, but allows to
conveniently create various quantitive metric to asses their respective quality
or maturity. Such model is actually independent of the development
methodologies that are currently in-use, that is it could well be applied for
projects managed in an adaptive, as well as in a formal approach. Eventually we
argue that the model could actually be implemented by already existing tools,
in particular graph databases are a convenient implementation of architectural
repository.
