Software Architecture Explained

What is Software Architecture ?

Software architecture is an elusive term. The SoftwareEngineeringInstitute of CMU recognizes that much that there's no generally agreed definition for Software Architecture although they are the primary promoters of software architecture http://www.sei.cmu.edu/architecture/definitions.html. It competes semantically with the notion of SoftwareDesign, it is threatened in its legitimacy by the resurrection and acceptance of geek culture as in ExtremeProgramming / Agile. The best approach to such an elusive concept is the tried and true I know one, when I see one.

Approaching it loosely we can say that the software architecture acitivity is some part of the SoftwareDevelopment activity, it is related to design decisions early in the SoftwareDevelopmentStack?, those decisions will constrain the activities upwards on the stack such as design and coding. It is important to note that not all software projects and not all software artifacts have a need for something pompuously called SoftwareArchitecture. Some projects may have a recognizable software architecture but a "no big deal" software architecture (in the sense that if it was your business, you wouldn't hire a full-time SoftwareArchitect to be the gatekeeper of architecture). While other projects have a full blown software architecture, with a full time software architect or an architecture team in charge of maintaining it. It is important to distinguish those situations.

Examples of software systems with a notable software architecture: Oracle RDBMS, Google, Yahoo shopping, .NET framework, JVM, gnu compiler collection, Microsoft Office, JakartaTomcat?, ApacheHttpServer?, business software suites like SAP, Oracle Financials, etc.
Examples of software for which talking of an "architecture" is too much: JUnit, an XML parser, a command line utilities like diff, sort, cat, gzip, etc.
Examples of somewhere in-between: your average custom developped business system (including web projects), an average wiki engine.

So what does an architecture consist of ?

A software architecture consists of a set of decisions in the large:

Some decisions that affect primarily the structure of the software system on a large scale -- or coarse granularity. The decomposition in subsystems and components, and the connectors between those element.

For example PostgreSql database management system will have of a supervisor process who will fork/exec for each database client, and the worker processes who will cooperatively use Possix SharedMemory and interprocess communication primitives to access the buffer/cache database disk area and logging.

Some decisions in the practice of software architecture establish general patterns to follow at the lower level.

For example it is decided that all the modules in the project will be written in Java with the exception of command line utilities to be written in Perl. Or that all modules should expose their services through SOAP, and should have WSDL definition.

Some architectural decision reflect the structure of data/information to be processed by the system if suich is non-trivial.

For example, the layout of rows in the database pages in PotgreSql? involving the decision to use versioning of rows and perform garbage collection of unused entries only on demand. In the architecture of business software the E/R view of the information processed in the system, and relational schema(s) may be considered part of the architecture of the system

What are the problems related to software architecture ?

The most famous problem related to SoftwareArchitecture is ArchitectsDontCode. Anecdotal evidence suggests that there can be a lot of problems with architects who take decisions at high level without having to suffer directly the consequences of their decisions. This creates anymosity between developers and architects. To alleviate this problem, some projects have an architect involved in the development (especially in the most critical parts of the code), or for more complex project the architect should be somebody who's programming competence is unquestionable (on the level of GrandMasterProgrammer). It is important for project manager to realize when a project is not on the size of say Oracle RDBMS or an Operating Systems and the architect cannot justify his usually high pay just by sitting on top of architecture documents (UML diagrams, Powerpoints, Word docs, etc). Even in some software projects of the largest scale (such as Linux OS) the architects are having their hands full with coding activities (implementation, code review, debugging, etc).

Yes, SoftwareArchitects? should also code. Since AllAbstractionsLie you should code TestDriven to find those lies. Another problem with SoftwareArchitecture is the fact that there are also multiple ArchitecturalViews?. Each view shows a set of different decisions in the large, either decisions about ConceptualIntegrity, infrastructure, interfaces with other systems, or something else. You have to figure out how the views relate to each other. One of my main interests is ConceptualArchitectures?. A ConceptualArchitecture? is similar to a SystemMetaphor in XP. It facilitates communication and still leaves room for different implementations. --FrankScholten

As a curiosity for c2 site I do not believe in TestDrivenAnything?, especially not in TestDrivenDesign, but YMMV. Though I believe in tests and UnitTests. In a test driven project there is certainly value in the architect writing the tests, but then test driven processes don't quite have an "architect".--Costin

Another recognized problem with SoftwareArchitecture (and architects) is that is more voodoo SoftwareEngineering than ComputerScience. As such architects (especially the AchitectsDontCode? kind) may fall into Dijkstra's prediction: "software engineering is the art of how to program when you can't". Many architectural decisions are the product of informal reasoning based on personal experience and some literature but may have some far fetching consequences. The antidote to that is that critical decisions should be advised by prototyping and measurements and/or the system should allow for easy change later in the project should any problem be identified (architecture refactoring).

Architecture is to Construction as Strategy is to Tactics:

Architecture: This is how we will do it.
Construction: This is how we will do it this time.

--MarcThibault

Blame the deficiencies of this page on CostinCozianu ("software architect"), waiting for others to share some of it. See SoftwareArchitecture for an older discussion.

CategoryArchitecture