Evolving Architectures – Part VI – Simplification

Evolving Architectures – Part VI – Simplification

[Edited: added explanation of the difference  between upfront design with iterative implementation and Simplification] The previous installment in the series talked about leaps as a technique to change the architecture. Leaps are more of a revolution than an evolution and even though they are sometimes needed evolving an architecture is the more interesting topic. This and the next post deal...

Read More

SOA anti-pattern: Transactional Integration

SOA anti-pattern: Transactional Integration

Transactional Integration It all starts with a business requirement – as it always should. We have an ordering system (say the same one from the Knot anti-pattern) and the business says they only want to confirm an order to the user if the item is already secured for that order in the stock.  From the technical point of view we have 2 separate services – one handles orders the other...

Read More

SOA – Contracts, Events and ownership

SOA – Contracts, Events and ownership

I recently listened to Udi Dahan’s excellent “Avoiding a failed SOA” presentation from QCON London (it is about an hour long, but it is worth your time). I agree with most of what Udi says except two points. One is that pub/sub is not the only way to go (and you should minimize duplex message). Events and choreography are definitely my preferred way to go since they make it...

Read More

Evolving Architectures – Part V – Leaps

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 More

Evolving Architectures – Part IV – Design mechanics

Evolving 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 More