ESCOT 2010

I have no idea what I’ve gotten myself into now, but I’ve agreed to help out the Empirical Evaluation of Software Composition Techniques workshop will be held as part of the next Aspect Oriented Software Development conference.  I doubt I will attend ESCOT or AOSD but it will be good to collaborate once more with some very enlightening people that I met at OOPSLA last year.
I guess I’ve got quite a lot of reading coming up and it will be fun to read what is coming out of the research channels and cast my own weird industrial perspective on things 🙂

Are you coming to OOPSLA?

In a couple of weeks I will be at the OOPSLA conference in Orlando, USA.  I am absolute OOPSLA nOOb but am already excited about it.  I’ve heard lots of nice things from the OOPSLA “veterans” at factor10 and now I can’t really wait to get there.
I will be giving a tutorial on using AOP to solve some domain problems, not just removing the infrastructural noise from your domain models.  Also, I’ve been invited to be part of a panel on my best-loved-hated subject … modularity.  I will also take part in the Cloud Computing Design workshop.

There’s also an amazing line up for the other tutorials and OOPSLA still has a “Pay for 3 and attend 4” promotion going on.  Take advantage of it.  If you already signed up for 3, then just sign up for the 4th.  If you’ve signed up for 2, then pay for the third and register for the 4th too.

So much happening in just a short week.  But, it will be lot’s of fun and worth the 24 hour travel time from Cape Town.

.NET Rocks! Podcast

Yesterday I had a telephonic chat with Richard Campbell and Carl Franklin from .NET Rocks! I tried to talk about modularity, but it kind of veered off into design in general and how an agile runtime is really important to being really agile.  A lot revolved around getting the domain understanding right before diving into object oriented design.  We touched on SOA, SaaS, UML, tools.  That’s a heck of a mess for less than an hour!
You can listen to the podcast here.  I think I just rambled on a lot about anything and everything and it felt like a wayward discussion to me at the time.  Have a listen and tell me what you think.  I really would like to improve myself for these kinds of events.

So, thanks a lot to the kind folk at .NET Rocks! for having me on their awesome show.  And for persisting with trying to get hold of me at the hotel in Lech, Austria.  I am deeply priviledged and humbled.  I hope I helped someone with my ramblings.

Oh, and many thanks to Jimmy Nilsson for all his help (again!).

Øredev 2008

I’ve mentioned it in bits and pieces before but now that the nice folk at Oredev have more or less finalised their program, I can put the down the talks I will be giving in November 2008.

I certainly did not expect to be doing 4 sessions!  It’s going to be a busy conference but also immense fun.  I hope that I get the time to attend the other talks and learn from some amazing people.  I certainly will be catching up with old friends as well

OSGi Article on DZone

An article I wrote which questions the readiness of OSGi for enterprise development has been published in two parts on the EclipseZone at DZone.  Read the first part at Watch out for the hyphen at the end of the URL, it’s significant 🙂

Many thanks to the kind folks at DZone for the publication.

Are your modules really modules?

I’ve been struggling with the problem of modules for almost my entire working life. And I am convinced that this area of architecture is one of the most underrated challenges. By definition, a module is a set of parts that can be used to construct a more complex structure. Let’s work backwards. Given a complete design or architecture for a problem domain, we should be able to break into parts and then reassemble these parts to reconstitute the original architecture. We, most probably, can justify any form of decomposition strategy, be it functional, sub-system boundaries, sources and sinks of data, etc. Working forwards is a lot more difficult. Creating parts from nothing that can then be assembled into a complex structure is not easy because we often don’t know what the final structure will look like. This exercise is complicated further when working in an agile manner, where a big design up front is against the grain of short, sharp iterations of analysis, design, test, code, release.

Now think back to the start of a new project, those days where you first tackled a new problem domain. Those days are spent analyzing the domain. And if it was complex domain, you most likely started fragmenting it so that it was conceptually possible to understand little parts at a time. Eventually, you reach a single point where everything clicks into place. That’s your light-bulb moment. It’s an immensely satisfying moment that is filled with a great sense of achievement. And with this fulfilling sense of accomplishment, you naturally carry that conceptual decomposition into the design exercises.

In this very act lurks the conflict. Our modular decompositions created for conceptual understanding is often carried, unconsciously, into architectural designs. In my experience, it is very seldom that the conceptual parts are left alone for conceptual understanding of the problem domain and that a separate effort is expended to focus on modular decomposition for architectural soundness. This resonates back to the days when a huge database design was created early in the project and it was the most static design artifact of the solution. Anything that came afterwards, was morphed to fit in with uber-database design.

I think that the reason for trying to maintain that static set of modules (or that database-design-cast-in-stone) is that refactoring of modules is very immature. At best, it is downright painful because it often results in pruning your source tree. Domain Driven Design is very explicit about modules. There are modules of varying granularity. Tiny modules made up of aggregates or an aggregate and its repository. Big, fat modules based on bounded contexts. Medium sized modules that cohesively fit together because they tell a story in the domain. This is great, but refactoring modules as you discover more of the domain is still frightening. But I digress and will elaborate on module refactoring in another post.

I do view modules as parts that can be assembled to construct the complex whole. But I also view modules as part of a graph, kind of. Every module has a meaningful domain relationship to another module. Each module needs another module to fulfill some feature that is required of the complex structure. It is rare for a module to be completely disassociated from every other module. If a module is disassociated, then is it part of the whole? Hence, the module graph perspective. The graph of modules is likely to be significantly different to the modules that are the result of conceptual decomposition during analysis. This graph of modules is a design exercise, not an analysis exercise. By focusing on domain correctness and meaningful relationships that are true within the problem domain, we can still achieve sound architectural principles. Each module has a public interface and shields internal complexity from its neighbors. This gives us low coupling and good separation of concerns that reflect the reality within the problem domain.

I also believe that using a domain driven design approach that focuses on reflecting reality, will allow for less painful experiences in refactoring modules because the domain must change significantly to force changes to the natural interconnection of its parts. Sure enough, when a business changes strategy, its domain changes which will result in significant changes to modules. But that’s an exception.

So, ask yourself these questions:

  • Are my modules artifacts of conceptual decomposition during analysis?
  • Can I combine my modules to reconstruct the complete complex structure?
  • Do my modules reflect the realities and deep truths of the problem domain?
  • Are my modules, modules?