Is SOA just an implementation of Responsibility-Driven Architecture?

By |2006-12-06T13:01:00+00:00December 6th, 2006|Enterprise Architecture|

A response to my prior post on Responsibility-Driven Architecture got me thinking… what is the “first principle” that Service Oriented Architecture gives us that makes it “better” than simply COM?  Certainly, the four tenets do a good job of capturing the key distinctions.

 When I see a paradigm shift, I, like others I suspect, will often turn to others to get analysis and data, hoping to work my way up to understanding.  When I first heard about SOA, I looked for the distinctions and the reasonings, and SOA became appealing to me.

But if I look at the four tenets and ask “Why bother?” the answer comes up as the following, for me: to get our designs to routinely and repeatedly reflect the goals of Responsibility Driven Architecture.

In other words, if you were to ask “Why SOA?” the answer would be: to better partition our systems along the lines of a clear interfaces.  What makes interfaces clear?  Partitioning by responsibility.

Just as the alternator in a gasoline-powered-car has one responsibility, and only one, to generate electricity, and that allows considerable simplicity in both it’s design and the maintenance of the overall system, a single part in a SOA only achieves the goal of loose coupling by sticking to a single responsibility and having limited, declared, connections to other components.

Leaves me to wonder: if I were to define RDA in terms of ‘first principles,’ what would they be?  I’ll have to think a bit…

Responsibility Driven Architecture

By |2006-12-01T09:49:00+00:00December 1st, 2006|Enterprise Architecture|

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. 


Enterprise vs. Application Architect

By |2006-12-01T09:29:00+00:00December 1st, 2006|Enterprise Architecture|

A team that I work with is hiring an application architect.  (Solutions architect, if you prefer that title).  This hands-on position requires someone to take day-to-day responsibility for the design level artifacts of large distributed systems being developed in the Microsoft IT setting.  It’s an excellent position.

Of course, this means revising the job description for posting on the recruiting sites.  So we’ve been going over some key elements.

One thing that interest me: the interface between app arch and enterprise arch.  I’m the enterprise arch that most closely works with this team, and I really want to make sure that I do a good job of helping to set clear expectations and to develop a healthy relationship with this new individual. 

So looking at the boundary is a kind of introspection.  My opinions about the relationship between an application (or solution) architect and an enterprise architect:

Both must:

a) be able to communicate using shared diagrams and concepts at a far higher level than the typical functional spec.  UML is a must, as is a generally broad business foundation.

b) be willing to ‘play their roles’ in the team, deferring to the other the items that belong with the other, to keep responsibilities aligned with accountabilities.  This includes a high element of interpersonal communication and the ability to trust in the experience and advice of the other.

c) love design.  It’s a geeky job.  Not everyone is cut out for it.

d) be passionate about system quality.

The Enterprise Architect and Solution Architect are really just two sides of the same coin.  They are architects guided by different alignments but with common goals and interests.  The EA is aligned to “developing the enterprise view and buiding for the enterprise” while the solution architect is aligned to “delivering quality for the current business need within the enterprise context”.  Each makes the other successful.