Thinking Architecture, 3rd Edition Downloads Torrent
Klacee Sawatzky
People in the software world have long argued about a definition of architecture. For some it's something like the fundamental organization of a system, or the way the highest level components are wired together. My thinking on this was shaped by an email exchange with Ralph Johnson, who questioned this phrasing, arguing that there was no objective way to define what was fundamental, or high level and that a better view of architecture was the shared understanding that the expert developers have of the system design.
Architecture is a tricky subject for the customers and users of software products - as it isn't something they immediately perceive. But a poor architecture is a major contributor to the growth of cruft - elements of the software that impede the ability of developers to understand the software. Software that contains a lot of cruft is much harder to modify, leading to features that arrive more slowly and with more defects.
This situation is counter to our usual experience. We are used to something that is "high quality" as something that costs more. For some aspects of software, such as the user-experience, this can be true. But when it comes to the architecture, and other aspects of internal quality, this relationship is reversed. High internal quality leads to faster delivery of new features, because there is less cruft to get in the way.
While it is true that we can sacrifice quality for faster delivery in the short term, before the build up of cruft has an impact, people underestimate how quickly the cruft leads to an overall slower delivery. While this isn't something that can be objectively measured, experienced developers reckon that attention to internal quality pays off in weeks not months.
Such a loose definition leads to many potential sizes of an application, varying from a few to a few hundred people on the development team. (You'll notice I look at size as the amount of people involved, which I feel is the most useful way of measuring such things.) The key difference between this and enterprise architecture is that there is a significant degree of unified purpose around the social construction.
One of the undecided problems of software development is decidingwhat the boundaries of a piece of software is. (Is a browser part ofan operating system or not?) Many proponents of Service OrientedArchitecture believe that applications are going away - thus futureenterprise software development will be about assembling servicestogether.
One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation (UI), domain logic (aka business logic), and data access. So you often see web applications divided into a web layer that knows about handling HTTP requests and rendering HTML, a business logic layer that contains validations and calculations, and a data access layer that sorts out how to manage persistent data in a database or remote services.
While application architecture concentrates on the architecture within some form of notional application boundary, enterprise architecture looks architecture across a large enterprise. Such an organization is usually too large to group all its software in any kind of cohesive grouping, thus requiring coordination across teams with many codebases, that have developed in isolation from each other, with funding and users that operate independently of each other.
Much of enterprise architecture is about understanding what is worth the costs of central coordination, and what form that coordination should take. At one extreme is a central architecture group that must approve all architectural decision for every software system in the enterprise. Such groups slow down decision making and cannot truly understand the issues across such a wide portfolio of systems, leading to poor decision-making. But the other extreme is no coordination at all, leading to teams duplicating effort, inability for different system to inter-operate, and a lack of skills development and cross-learning between teams.
Like most people with an agile mindset, I prefer to err on the side of decentralization, so will head closer to the rocks of chaos rather than suffocating control. But being on that side of the channel still means we have to avoid the rocks, and a way to maximize local decision making in a way that minimizes the real costs involved.
A Trace is what I called my journal -- where I write my notes as I explore what it takes to create architecture and be a great architect. You might consider it a warning about my sense of humor and delight in Life's irony and the jokes the Universe plays on us, that a person who helps shapes the field of architecture, predominantly writes in so "disorganized" and emergent a style as a journal. [grin] But it is a format that emphasizes that we are, individually and as a collective, a field, on a learning journey --- many journeys, really. Individually. And across the lot of us.
I need to carve out time to get to Part II of the Visual Architecting keynote slidedeck -- going into more of the architecture modeling and heuristics that guide architecting, and then widening the field of view, to explore what architecture means, when we take another look at what is significant in "architecturally significant decisions." In the meantime, here's Part I (it's also on the Bredemeyer site):
The award takes place at the annual SATURN conference and I was asked to give a keynote in conjunction with accepting the award. It was an honor -- and a predicament, as I'd decided formal talks are not my forte. I was asked to focus the talk on work that led to the award, which is rather broadly scoped for 30 minutes. Eventually I settled on talking about how we view software architecture and visual architecting. Which resulted in another conference slideset, so at least there's that. My slides are available as a .pdf on SEI's SATURN conference site, and on Slideshare (where you can download the slides; and remember to Like them if you do).
How we approach architecture, defines what architecture, in effect, is, at least for our system. That is, no matter what we say architecture is (for), architecture is (an outcome of) what we do. This is a POSIWID (the purpose of a thing is what it does -- Stafford Beer) kind of point, noting that what the thing does, trumps what we may think it is and ought to do. Still, intentions influence behavior. How we conceive of architecture, influences what we do. If we think software architecture is a set of decisions, say, we're going to try to notice when we're making a decision so we can write it down. If we think architecture is diagrams or maps, we'll direct attention there. In short, what we do in the name of architecture, shapes what it is; what we think it is, shapes what we do. At any rate, I wanted to elaborate a richer understanding of what software architecture is, to inform how we advocate approaching the architecture of systems we're design-evolving. So here, after the passage of several months, is more or less the thrust of the talk: Annotated Keynote Slides
As a bridge from Bill Pollack's generous introduction and presentation of the award, I of course thanked Dana Bredemeyer for his contribution to the work I was being recognized for, as well as what I was about to present. Anything "Visual Architecting" is very much a "standing on the shoulders of giants" endeavor, and not just Dana's, but every architect (of any title) we have ever worked with.
By way of an outline of the talk, I told the audience the sketch (above) was a fairly accurate visualization of my talk -- I would iterate on, and elaborate, build out, our notion of software architecture. And I wouldn't be complete, in that self-set mission, in a timebox (of 30 minutes, or even, if my 20+ years in software architecture is anything to go by, a lifetime).
Let's sidestep the discomfort we have with someone (else?) doing "the important stuff" and getting "sumptuous emoluments," for a moment anyway, and follow the arc of software architecture to its recurrent destination, namely Grady Booch and
Michael Nygard's post on Documenting Architecture Decisions presents a useful template. It has echoes of the patterns template used by the Gang of Four, and subsequent, in that it draws attention to the essential elements of Context (presenting forces and demands) and Consequences, not just the Decision itself.
It's a template I and others recommend (though I like to add Alternatives Considered). Still, too much of a good thing sinks itself under its own weight, so an Architecture Decision Record leaves itself begging the question -- which decisions?
In a modular approach, parts of the system that are unstable, due to uncertainty and experimentation to resolve that uncertainty, can be shielded from other, better understood and more stable parts of the system.
Parts can be plugged in, but removed if they don't work out, making for reversibility of decisions that don't pan out. They can be replaced with new or alternative parts, with minimal effect on other parts of the system, enabling responsiveness to emerging requirements or adaptation to different contexts.
Further, it's a mechanism to cope with, and hence harness, complexity. Partitioning the system, reduces how much complexity must be dealt with at once, allowing focus within the parts with reduced demand to attend (within the part) to complexity elsewhere in the system. We give a powerful programmatic affordance a handle with minimal understanding to invoke it, and can selectively ignore (not all the time, but for a time), or may never even need to know (it depends), its internals.
So modularity and parts, or components, is key to managing change and associated costs. Returning to Martin Fowler's paper, indeed software architecture is acknowledged to include how the system is divided into components, and how they interact.
Going back to 1992, when Kent Beck was giving the architecture-architects thing a \_(ツ)_/, Perry and Wolf were defining (software) architecture as being concerned with "the selection of architectural elements, their interactions, and the constraints on those elements and their interactions."
b37509886e