Evolving Architectures – Part V – Leaps
When talking about “evolving architectures” a “leap” is one of the worst things that can happen. In the previous installment in this series I defined Kent Beck’s “Leap” design strategy in the context of Software architecture as “Leap – is for when you know where you’re heading and you can afford to stop everything until the new way is in...
Read MoreEvolving Architectures – Part IV – Design mechanics
If we want to evolve architectures or change an existing architecture in general, for that matter, it is important to understand design mechanics. I recently attended a seminar with Kent Beck that talked about “responsive design”, where he provided a good definition for 5 strategies or types of design mechanics*: Leap Parallel Simplification Stepping Stone “Just Do...
Read MoreTier is a natural boundary
When talking about multi-tiered architectures, we need to remember that the tier boundary is significant. The tier boundary is where distribution happens and if you remember the “fallacies of distributed computing“, you know not to take that lightly. A tier is a physical boundary (versus, for example, an Edge in a SOA which is a logical boundary within the service). The implications...
Read MoreWho needs an architect anyway?
Not all projects need architects. There, I’ve said it. Not all projects need architects and I am not talking here just about trivial projects. There are cases (maybe even many cases) where you can get by with what I call “off-the-shelf” architecture – maybe with a few adjustments that any master developer (i.e. seasoned and experienced developer) can handle. For instance a...
Read MoreEvolving Architectures – Part III starting out
Before we talk about the what/how let’s do a quick recap on the why we’re here: Architecture is important to software projects Architecture and agile have some conflicting forces that needs to be reconciled (e.g. up-front work, hard to change vs. delivering business value quickly and embracing change) design can be emergent but architectures can’t and must be grown...
Read MoreEvolving Architectures – Part II but Design is emergent
This is part II of a series on agile architecture. You can read part I here. In the previous installment I provided a definition for software architecture and raised the apparent friction between the up front design implied by software architecture and the YAGNI approach and deferred requirements prompted by agile development in the large. This installment take a look at an additional angle of...
Read More
Profiles & RSS