Monday, February 15, 2010

Brains-Brawn Architectural Pattern

I've been wanting to do some more programming and I have an idea that I'd really love to dive into. Of course, time is a problem, but that's not why I'm posting. I'm posting because while figuring out what I want to do, I came up with an idea for a new architectural pattern for creating software: Brains-Brawn.

I tried to come up with a very formal definition for this, however I don't think I did very well, so I'm going to try to describe what I mean. In this particular pattern, I see two distinct layers: the top layer which takes care of deciding what is to be done, who does it, etc. and the bottom layer that actually does the work. E.g. the top layer is the brains and the bottom layer is the brawn.

The closest I have to a real world example is MySQL and it's derivatives. The top layer is the, for lack of a better term, database engine where the SQL is parsed, an execution plan is created, etc. The bottom layer contains all of the different storage engines that actually deal with the data.

Now, in my thinking that isn't quite what I'm thinking with this pattern. What I was more focused on was having a architecture that would allow the user to use the best programming language for the job at the appropriate layer. A higher-level language like Perl or Erlang would be used for the brains since they are more easily updated, which is good for the brains aspect of the architecture since it may have to be adapted over time. With respect to the brawn, this is where you would want to use something like C, D, or Haskell. E.g. languages that can produce efficient code. Ideally, anything at this level would be relatively dumb and optimized for speed.

A side-effect of having the brawn layer being simple is that it can be made to be very reliable. This is very nice as my plan is to have that layer updated rarely while the brains would be updated as needed. I'm not sure how well that will work in practice, but it's at least a nice thought. This is also one of the reasons why I feel a heterogeneous set of languages is a good thing: higher-level languages are typically easier to update. So if things need to change, the change can occur at this level instead of the lower level where the performance critical code is.

Now, as one can tell, the brains may not be the fastest code in the world. This, I think, is acceptable considering the advantages. Also, my expectations right now are focused on long-running processes, so any speedups to the brains are negligible. However, there are cases where I'm sure speed at the brains level is important and there isn't really anything keeping one from having a homogeneous solution, so perhaps sticking with a low-level language at both levels is acceptable at times.

Hopefully one day I'll have some real-world code to show this off and prove if it's useful or not. However, I do know one thing I do need, especially if this works: a good manager-friendly name. Brains-brawn is accurate, but I'm not sure that it's something a manger wants to hear if they're considering something like this.

Anyway, it feels good to post this. I'm a bit excited about this and hopefully I'll create something impressive that uses this.

Labels: , , , , , ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home