I’d like to introduce you to a simple term: Responsibility Driven Architecture.  Like a design pattern that you already use, it’s a term to surround a concept that you probably already have, but may not have named. 

Responsibility Driven Architecture is the practice of partitioning the components of a distributed system along the lines of cohesive sets of responsibility with the goal of building simplicity and flexibility into the system design.

Systems designed from this standpoint illustrate the following attributes:

  • They are easier to explain.  People understand the notion of responsibilities.  It is elemental to the way that we, as humans, organize our own work and lives.
  • They are easier to maintain. If you have a well defined responsibility driving the partitioning, then changes to the requirements can be implemented relatively consistently because it is easier to understand where to write a specific change into the environment.
  • Messaging is simpler: Once you accept the notion of RDA, you can remove so much of the “command and control” aspects of messages that create tight coupling between system components.  If I, as a component, trust you, as a collaborating component, to fulfill your responsibility, then I only have to communicate.  I don’t need to track your progress or audit each and every error condition.  Components can trust one another.  This makes the communications simple.

I guess I’ve always followed the notion of responsibility driven architecture… I just didn’t describe it this way.  Another way to express this idea is: an autonomous component (in a SOA or in older C-S models) is defined not by what code lives on a server or in a library or in a layer, but by what responsibilities live in the code. 

It is not a revolutionary idea.  It is born of the notion of responsibility driven design and more general patterns.  In a real sense, MVC is an RDA pattern in that the Model, View, and Controller partitions are described in terms of their responsibilities.  For all that MVC and it’s bretheren are some of the oldest solution design patterns,  they are still frequently discussed.  Why?  I think it is because they fit in the RDA mold.  That makes them practical.

So when you look over your system, create a ‘responsibility view’ of your components.  Is it clean?  Can you clarify it?  What does it tell you?  I think you’ll find this practice will help you to create better, simpler, more practical systems. 


By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

3 thoughts on “Responsibility Driven Architecture”
  1. Nice concept. I like the idea of thinking about software through a systems perspective, where systems with clear boundaries interact with other systems, contain other sub systems, and are themselves part of larger systems.

    This very much sounds like how I think of contract driven programming where each service, class, module, system will specify well-defined contracts for engagement.

Leave a Reply

Your email address will not be published. Required fields are marked *

fifteen − twelve =

This site uses Akismet to reduce spam. Learn how your comment data is processed.