Event driven architectures (EDA) will come in the following years more to the front in distributed applications and their architectures. Some think they are the next step after SOA, others have the idea that the 2 (reference) architectures complements. Eitherway, in todays distributed applications some concepts of EDA are already used, although mostly the defined/used software delivery cycles don’t position them very explicitly in a good structured quality generating delivery process. Contemporary SOA is becoming a mature technique and a new standard in enterprise architectures. The possibilities are that EDA undergoes the same and delivers some extra or other quality characteristics than contemporary SOA. It can bring the continuous seek to unification intra and inter applications and/or enterprises to a new level. What EDA certainly shall do is bring our designs closer to an inherent attribute of nature: send and move on.

Dan Rawsthorne wrote an interesting post about “Scrum is Effective, not Efficient“. I don’t follow fully so i made some comments. I write it here again because it has some aspects that are related to software architectures and which are important to produce quality. To have the full context of this post it is important to read Dan’s post.

Dan says: “The more feedbacks you have the more effective you’ll be… “

I think the amount of feedback is not so important to determine the  effectiveness, what is more important is the quality of the feedback which is aligned with business goals. Can’t a few good feedbacks be enough to know how effective you are? You can specifiy some quality scenario’s for measuring your effectiveness. Ofcourse lines of codes or function points are to vague and don’t tell much business/product relevant effectiveness. Thereby, finding the right feedback through quality scenarios can help to reach the effectiveness efficiently instead of going for a lot of feedback.
Maybe it is not easy to specify precisely what needs to be done, this is where agility comes into the picture i think, but in general every project has some clear business (case) goals and for those, quality scenarios can be provided to measure the overall effectiveness.

Dan says: “In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?

If you can specify how to be effective, and you say that agility is effective it means you can specify effectiveness, than you can specify a way to reach it efficiently. I think too that agility is effective and i would measure it with quality scenarios. This also gives the possibility to have a reduced set of feedbacks related to the Q scenarios and allow us to get there efficiently because we know our goal.

Dan says: “…if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.”

Why can’t you add efficiencies in your inspect and adapt cycles?  Rethinking and implementing the way to produce a powerfull effect can also ask for incorporating some efficient steps.

Dan says: “waterfall is efficient — agility is effective”.

I think if you say it is efficient, it means that it also has to be effective.  Saying something is efficient means its result is effective.  So in the conclusion it sounds to me that waterfall is the ultimate way to go, which i doubt and probably also not the one of Dan.

For those among us who wants to bring the architect’s mind more explicit into projects, Microsoft published very interesting information about how they see what architecture means in their world and what the architectural aspects will be with/in the cloud:

• Patterns & practices: Application Architecture Guide 2.0 (Beta 2 Release)
• PDC 2008 Architect Edition

Event Driven Architecture is brought into attention in the (latest) Microsoft architecture journal 17 and more specifically in the article: Using Events in Highly Distributed Architectures. David Chou points out that SOA can be nicely extended with the event principle and gives some extra general quality advantages provided in the application when using events (others are described here in the context of the AMM) :

• Effective data integration
• Reduced information latency
• Enablement of accurate responce
• Improved scalability, managebility, reliability, flexibility…
• Improved business agility

When we look to the Dynamics Ax messaging module we see that it fits in the EAD as the intermediary flow manager (message broker). It propagates events in the Dynamics Ax EPR system to modules (partially) isolated by separation of concern and to applications outside the system. Also events from outside Dynamics Ax can be propagated to modules inside the system.

The events outside Dynamics Ax can use the SOA communication infrastructure or any other infrastructure. Inside Dynamics Ax all events are event objects in the object oriented architecture. The mapping of event formats and the propagation of these events is done automatically in the message broker with the use of the necessary channel adapters.