Solving Complexity with Message Based Architectures

 

Ultimately most complexity in software comes not from the requirements, the business logic, or even the underlying systems. Most complexity comes out of a poorly considered and managed architecture, and this is commonly seen in tightly coupled systems that rapidly degrade into Big Balls of Mud.

The key to simplifying architectures is to decouple their component parts, making each more specialised and less dependent on the others. This allows every component to focus on a specific task without risk of those tasks becoming compromised by, or interfering with, others.

The basic premise of most architectures that succeed in this way is that they are message based, rather than being glorified CRUD systems pulling data to and from databases. Operations are central to the system, data is ultimately just the storage for the results of those operations.

This separation of concerns allows development teams to concentrate on component parts with little impact upon other teams, and no more reliance upon them than an agreement on the messages they will listen for and those they will publish. While messages share some characteristics of service interfaces, they differ mostly in their granularity and lack of dependence upon one another. Messages allow true decoupling, where traditional service layers only promise this and usually end up creating even more tightly coupled systems.

"Message based" does not inherently mean SOA, and in many ways differs substantially. Although both can be considered message based, SOA brings significant overhead and generalisation, along with an organisation wide remit. Simple message based systems operate on the basis of message within the application rather than across an enterprise.

Poor software architecture ends up impacting more than just the software system under development, and frequently the impact can be felt across an organisation; in the way development teams approach problems, in the way they respond to new requirements, and throughout the SDLC.

More often than not, the SDLC is a reflection of the weaknesses in software architecture, and is frequently trying to play 'catch up' to attempt to deal with the issues weak architecture brings. These compromises and aspects of the SDLC then start to propagate and impact other areas of the development and support process. Often decisions about software architecture become the underlying drivers for the entire IT department, and the SDLC turns into a point of conflict as it becomes more about trying to restrain and control a big ball of mud than it does about providing a framework for providing business value.

 


Posted 02-04-2010 7:55 AM by Jak Charlton

[Advertisement]

Comments

Joe wrote re: Solving Complexity with Message Based Architectures
on 02-04-2010 8:34 AM

Any samples of this type of architecture you can share?

jdn wrote re: Solving Complexity with Message Based Architectures
on 02-04-2010 11:52 AM

What is even better (sarcasm) is when you have a CRUD based SOA.

Billy McCafferty wrote re: Solving Complexity with Message Based Architectures
on 02-04-2010 5:00 PM

Jak, I've been digging in recently to Enterprise Integration Patterns quite a bit and have been getting some good? ideas about how they might be useful in various scenarios.  I'll be doing some posts in the near future concerning this; I look forward to your feedback after doing so.  Messaging is something little discussed on the blogosphere...I'd love to see more of your ideas concerning this.

Jak wrote re: Solving Complexity with Message Based Architectures
on 02-04-2010 5:18 PM

@Joe

I'll hopefully extend this blog post soon with more examples and discussion around message based architecture

@jdn

You never change, we can at least rely upon that :) But yes, that's what SOA usually turns into, canonical data model over canonical databases

@Billy

Will be good to read, messaging is a very powerful way to decouple systems and provide SoC, scalability, reliability, resilience, and a whole host of other easy wins, pretty much for free.

Anonymous wrote re: Solving Complexity with Message Based Architectures
on 02-07-2010 7:26 AM

"The basic premise of most architectures that succeed in this way is that they are message based, rather than being glorified CRUD systems pulling data to and from databases. Operations are central to the system, data is ultimately just the storage for the results of those operations."

Doing this you 'll have very bad performance. If you design a CRUD system... it can work. For complex operation on big bunch of data, performance would be very low.

Jak Charlton wrote re: Solving Complexity with Message Based Architectures
on 02-08-2010 3:26 PM

@anon

On average, message based architectures will improve performance significantly, especially when combined with concepts like CQRS (devlicio.us/.../ddd-command-query-separation-as-an-architectural-concept.aspx)

In a perfect happy path, a message based architecture will have performance directly comparable to any CRUD style system, but in any scenario where network or servers suffer performance issues, or even complete failure, message based architectures will perform significantly better - notably they will continue to perform when CRUD style systems would be reporting "system unavailable" or similar.

Billy McCafferty wrote re: Solving Complexity with Message Based Architectures
on 03-03-2010 3:02 PM

Finally got around to it Jak:  devlicio.us/.../message-based-systems-for-maintainable-asynchronous-development.aspx

Your feedback is always most welcome.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)