 |
I often hear this kind of thing in design sessions...
| "Sure, the architecture would be better if we made it more extensible (or reliable, maintainable, etc.), but we just don't have the time." |
Beyond the standard BDUF vs. YAGNI debate, the tacit assumption here is that architectures that contribute to better extensibility, scalability, reliability, etc. are inherently "good", and those that don't, aren't. Sometimes, extensibility, for example, may need to be sacrificed to meet business goals, but in these cases the business consciously chooses the inferior architecture to survive.
I disagree.
In my opinion, the "goodness" of an architecture is only discernable within the context of the entity it's serving (e.g. business, organization, author, etc.). I submit (humbly!) this simple definition:
| A good architecture is one which meets the needs of the entity that funds its existence. |
In the example I first gave, the "good" architectural choice would actually be to not make the system extensible, since to make it extensible would be to exceed the schedule and budget. Sure, a more rigid system might incur more cost later in terms of refactoring, etc., but if the business isn't around later because of budget over-runs, how "good" is the architecture really?
The implications of this definition, I admit, feel kind of dirty at first. For example, it'd have to be claimed that a JSP page with the kitchen sink embedded in it (HTML, JDBC, business logic, the works) could actually be "good" architecture under certain business conditions - for instance if it's a non-business-critical stand-alone app, never to be touched again, and needed to be written by a coding newbie, etc.. In most cases, however, this single-layered JSP page would be what we expect - bad - since typically systems will need to be maintained, deadlines aren't COB tomorrow, etc., and so this architecture would cost the business more than it earns.
I guess my point is that the "goodness" of an architecture isn't some intrinsic property of the system, irrespective of the purpose it serves. I often see technologists join a new project, look at the source code, UML diagrams, etc. and immediately deride the architecture as a the worst slop they've ever seen. It's as though "good" architecture was some Platonic ideal, and whether the system helped the company make oogles of money (and give them a job to boot!) was just some periphery side-effect.
Instead, as technologists, I think we need to better appreciate how business conditions drive architectural decisions, taking into consideration not only functional and non-functional requirements, but business conditions like operating costs, cash-flow, time-to-market goals, and others. It is these things that "good" architecture is a function of, not just the architectural concepts (e.g. coupling, cohesion, separation of concerns, etc.) we usually think in terms of.
For example, if I'm working for a start-up that has only 2 months of funding left, then the architecture that facilitates the quickest release is in fact the best one, regardless of whether it just consists of PHP pages and a MySQL database, and not some elegant ORM persistence layer or flexible rules engine. If the architecture allows the company to land that first client or next round of funding, then by the very virtue of it supporting their success, it is "good".
I need to make clear that I'm not advocating cutting the corners of maintainability, extensibility, performance, etc. for the sake of laziness itself. These things typically do help businesses and should be designed for. However, when they actually hinder the business's end goals, they should just as readily be jettisoned, and without an ounce of guilt. Letting go of extensibility so that your business can survive is not promoting bad architecture. In fact, just the opposite!
I'd love to hear what you think. Do you buy this? Does "good" architecture depend on the business context, or could you look at the system artifacts alone and tell whether the architecture is "good"?
