Why – good architecture is good architecture right? I don’t ever remember the advanced OO design and analysis courses I’ve taken covering cost as part of their curriculum. OO, Design Patterns are supposed to be universal. The scope of the project shouldn’t matter – encapsulating data is good, no matter what!
GOOD ARCHITECTURE IS GOOD ARCHITECTURE NO MATTER THE CONTEXT, right?
- That’s what the engineers say.
- That’s what computer science and programming books teach us.
- As a practitioner of good OO I used to evangelize that.
- Academics and architects say that.
How would one arrive at the conclusion that good architecture concepts, such as encapsulation, polymorphism, etc are good architectural concepts regardless of the context? We must FIRST look at the definition of what GOOD ARCHITECTURE is.
| ACCORDING TO WHOM | DEFINITION OF GOOD ARCHITECTURE | EXAMPLES |
| ENGINEER | A collection of systems, programs, data that supports leading application and system development methodologies, concepts, patterns, and leading thinkers to minimize defects and increase reliability and extensibility | Polymorphism, encapsulation, web services, component based architecture, standards based development, etc. |
| CEO/SHAREHOLDER (BIZ) | Capital investment(of time/money) to:
|
Virtual Clusters, enterprise monitoring, standardize on J2EE, investing in coding standards, building infrastructure services and components |
Fundamentally these are not in opposition. They are complementary and hardly ever are they directly opposed. The engineers view has pieces that will enable many of the BIZ requirements for good architecture. If they line up, and they are mostly in line and are complementary, when might they be in conflict?
BIZ users evaluate their capital expense in a variety of methods… Nearly all boil down to a very simple question of ROI. What is the benefit to me over time if I spend this money today? The strategy will be (no real surprise here), to invest capital that will have maximize benefit and minimal investment (do more with less). There is no shortage of the differing calculations, tweaks, estimations involved in this process.
So let us say that as an engineer or an organization engaged in commerce (ie, an IT department at a corporation) that given there are no motives for academic excellence or intellectual achievement that the true definition of GOOD ARCHITECTURE outside those endeavors is that of the BIZ:
- Decrease costs
- Increase reliability
- Decrease time to market for new technology
Again, the engineers view is not in direct contradiction. They line up quite nicely and indeed are mostly congruent. Good engineering principles, from an academic perspective, can have immense benefits to a business including decreased costs, increased reliability, and shorter implementation times.
Let us, for the sake of clarity, label these two camps that are nearly always in agreement the Academic(predominant view of an engineer) and Applied(view of a business owner or executive management) architectures.
Yeah… but you promised to tell us when they are in conflict… We’re getting there…
Ok, so when might an architectural decision be good Applied architecture but bad Academic architecture? Let’s take a practical example:
Two particular architectures supporting two separate methods (A & B) for producing widgets:
- METHOD A : Requires X staff to produce Y widgets. Rates an 8.5 on an abstract ACADEMIC QUALITY SCALE.
- METHOD B : Requires X-10% staff to produce Y widgets. Rates a 9.5 on the ACADEMIC QUALITY SCALE.
Let’s look at some example numbers. There is a proposal to expend capital C (10k/year) on architecture/infrastructure to enable method B. X is 5k per year.
The engineer inherently evaluates on the ACADEMIC quality, and straightforwardly evaluates (according their engineer precepts) that CAPITAL C is money well spent on GOOD ARCHITECTURE because it increases the academic quality and saves 5% on X per year.
The biz evaluates on the APPLIED model, looking for ROI. In this case, it would take 20 years to recoup the cost of the capital with no increased revenue (still Y widgets). In this example the cost required to implement method B, while significantly improving productivity and the academic quality of the architecture, is actually greater than the benefit. In this case, doing the right thing (from an academic perspective) is actually a bad architecture based on the BIZ definition.
In cases where the projected COST OF BAD ACADEMIC QUALITY (decreased output, slower response times, difficult QA periods etc) is less than the estimated/projected COST SAVINGS OR BENEFIT from the invested capital in the GOOD ACADEMIC QUALITY ARCHITECTURE then it’s a better business decision to go for poor academic quality.
GET TO A POINT!!!
I’m not saying engineers striving for good architectural concepts is bad. It’s noble in precept and may also make great business sense. One can’t put a solution up on a white board and say, trust me, it’s good architecture because depending on what your IT charter is, it might not actually be. You have to prove it – add projects estimates, efficiencies, use statistics from trade organizations. Tell the people funding the cost of the shiny well tuned machine that it’s in their best interest because they’ll get 30% more application throughput, 30% reduction in time to delivery for requests, 75% cost of maintaining systems X,Y, and Z.
UPDATE: I was thinking it would be prudent to point out that I’ve observed the most successful implementations of sound engineering techniques has always been done by groups of people who fundamentally understand the concepts, where they are currently are, where they want to go, and then just consistently and opportunistically “realize” that vision through projects over time. If you see opportunities to make things better; do well.