What is Software Architecture? (.pdf)

Definitions of Software Architecture

What Software Architecture is Not

Architecture Training

Software Architecture Class:

Enterprise Architecture Workshop

Role of the Architect Workshop

Architecture Consulting

Consulting Services Overview

Join our
mailing list

Consider the HP copy/print/scan device selling at Sam's Club for $45 before Christmas. (I bet Santa got to look good in many more households than just mine in 2005! ) Let me say it again: a copy/print/scan device for $45! Ok, so what are the architectural concerns here: big functionality, cheap hardware. We're talking memory constraints, and we're talking production costs that are minimal, and that doesn't even leave room for R&D. There's no business out there that can produce all that functionality and sell it at $45 a unit, even if they are making their money on the ink!  The development costs have to pushed down so low there's not a whole lot of R&D expense to amortize over each unit sold.

What am I saying? One, given the functionality of this device, it was not created by one or even a handful of developers, not from scratch anyway. And two, you can't have 400 developers create this thing and then sell it at $45 a pop. You have to be amortizing your development cost over other models. OK, so the architectural challenges involve not just the low end, cost/memory constrained devices but other devices with enhanced feature/quality/performance demands. Now we're talking not just about complexity in terms of a feature set, but complexity in terms of scaling across feature sets and memory footprint, form factor, performance considerations, and everything else that makes the various models in the product family distinct from each other and from their respective competitors.

COMPLEXITY is here to stay, and yet complexity is so successfully managed that we get a steady stream of unexpected breakthroughs in what we can do with ever less time and resources. Yeah, we have a lot to gripe about on our bad days, but in truth, we are getting a whole lot of good work done with big projects and ambitious goals. We sell ourselves, as an industry, short by focusing on the missed deadlines and headliner glitches, when the great tapestry of innovations of the past few decades is astonishing. Truly astonishing! Software has transformed our lives. We must have been doing some things right. And most of those things are being done on pretty big projects in aggressive timeframes. Sure, in many cases it has taken heroic stints to pull it off, and the code suffers, and then the organization suffers because we can sustain heroism for just so long before we, or our families, snap.

We are ever more demanding of our products and services (Collins and Porras used the term "big, hairy, audacious goals," or BHAGs, in their 1994 book, Built to Last). We must extend the capability and utility envelope with every release, in timeframes driven by intense global competition. Complexity, and big projects, are hard to get away from.

We just have to get better at architecture, and more clear about the role of architects. And then we can XP on the small, and fake small in the context of big projects through architecture. Then everyone can be happy, go home at 5pm and play with the kids. Yes, and then still have enough energy to work on HelpMatch for an hour instead of feeding on that brain candy otherwise known as TV, before going to bed at the same time as all those folk whose careers promised quality-of-life rather than computer-generated performance feedback. Let's face it, no spouse is more seductive than a piece of code that is not yet quite working, and the gratification from getting it working is hard for mere mortals to match.

On the subject of big organizations, architecture teams and decision making, there is a nice vignette by David Emery of MITRE Corporation on the SEI Software Architecture Essays page, titled "Architecture Team Organization Soviet Style."

References

This column is taken from Ruth Malan's (almost daily) architecture journal, entry date: 4/24/06.