Software Architecture vs. Domain Complexity: Overstated Claims

The folks at SEI know something about software architecture. It's not surprising that their Saturn Network voice opines -- or rather, bemoans -- that poor software architecture adds to complexity and a host of related problems -- especially maintainability. Anyone who's taken over a software project of any magnitude can attest to how a different or better architecture could have been improved to simplify the transition to a new team.

Hindsight is 20/20. Yes, projects morph and grow in ungainly, unplanned ways. Sometimes they are wrongly planned, which is SEI's point.

But something is missing. What is left out of this scene is the unacknowledged complexity of the subject matter being automated. Today's ERP, air traffic control, or web analytics application has complexity that increases at least as steadily as the resources used to automate those processes. Not mentioning domain complexity while discussing software complexity is a troubling omission. The omission is important because it goes to the heart of the sort of competencies needed to architect software systems. There is an unstated assumption that this should be the purview of software engineers, but an equally compelling case could be made that software engineers are less likely to grasp the subtle ontologies of systems brought on line to solve new problems.

A complete vision of the domain's model is unlikely to become clear until too late in the design process. Grasp of central use cases and critical requirements is likely to elude all but the rare software specialist who is also familiar with the domain being automated. Domain Specific Languages are part of the answer, but they too may be too late in the game.

◦

Software Architecture vs. Domain Complexity: Overstated Claims