Is data modeling (entity-relationship) part of software architecture?
Apr 6, 2008 | George Fairbanks
David Garlan recently asked me what I thought about data modeling and
its relationship to software architecture. I’m including the answer
here because it was effective at articulating some of my philosophical
assumptions about software architecture that are not shared by all
researchers and practitioners.
- The currently defined field of software architecture has a bias to address quality attributes to the exclusion of functionality. I think this may have originated because researchers wanted to differentiate their work from earlier work on high level design, which primarily addressed functionality.
- It is impossible to meaningfully discuss many architecturally-relevant topics without referencing domain-specific types, e.g., cars, accounts, sensor readings. You need to reference them when defining ports/roles and behaviors. Modeling these types has historically been covered under high-level design, not software architecture.
- In order to effectively zoom-out of implementation complexities (and premature commitments), software architecture should seek out surrogate representations of low-level commitments. Properties in Acme are a good example of this because they do not commit to a data representation.
- In MAp (and CAM, Catalysis, …) we commit to types of information, but not their representations. This allows us to refer to essential types (cars, accounts, sensor readings) while maintaining a zoomed-out view of a large system.
Since data(base) modeling commits to a data representation, it hurts
your ability to zoom out. It also introduces discussions of N-th
normal forms and efficient use of varchar vs. string(20). What MAp
calls “information modeling” commits you to the existence and
relationship between types, but not their concrete data
representations, which allows it to uncover design defects related to
the problem domain.
Data modeling is a large and specific concern at companies, because
the data and its schema may span applications and outlive all of them.
It may have a place in architecture descriptions simply because its
significance to companies, but I am unconvinced that it is an
architectural style or at the same level of abstraction as the rest of
the software architecture ideas.