Software: Modular Architecture

I spent today listening to some of the old DotNetRocks podcasts. In particular I found the Mark Miller interviews interesting. Not because I disagree with him, but because I’ve been preaching this methodology for over 11 years now. Part of me is protesting, “Why do we keep going over this!” But the practical part of me realizes that we’ll probably be going over it for the rest of my life.

Mark Miller was talking about the importance of component-based software architecture. (Podcast: “Mark Miller Wraps it Up”) I have always called it Lego programming. I first realized the importance of this methodology while working at KaseWorks building the Kase:VIP for OS/2 product. I heavily pushed two concepts: Lego programming and open architecture. These two methodologies where the critical factors that allowed me to build in functionality that my boss said couldn’t be done.

Take a moment and think about what a Lego is; it’s a self-contained building unit (brick) with standardized interfaces that allow the unit to be attached to another unit. One Lego isn’t all that much fun but when you have a whole bucket of them. Well, then you can build whatever you can imagine.

From a software perspective many engineers cringe if you mention the need for internal architectural standardization. But standardization is extremely powerful. Think about it. The Internet as we know it would not exist, driving our cars would be extremely dangerous, and the doors of our homes would have to be custom made. Standardization creates opportunities. And for those of you lamenting the loss of your creativity...realize that you can use your creativity to build what’s on top of the architectural standards. And that even the standards themselves can be a creative effort.

Now I’m not totally keen on the current definition of components. I don’t think everything needs to be an ActiveX control, COM object, or whatever the latest component object model is. What I do believe in is creating a flexible architecture that the engineering team can take apart and put back together quickly. This allows an engineering department to quickly respond to changing market requirements. The key is not only to build quality software solutions quickly. But to build easily maintainable and enhanceable solutions as well.

For the first few years of my career I totally rejected everything to do with the business-side of software. Many engineers do that. But the problem with this is that most of us work in a business and in some cases what we’re building is a vital determinate of our company’s success or failure. The technical decisions we make today have long-term financial repercussions. You can not afford to ignore a methodology that empowers you and your team to help your company succeed.

If everyone could learn to build software using a flexible, modular architecture (using Lego bricks as a model), a lot of time, money, and creativity would be saved and could be put to better use building even cooler things. Doesn't that sound like more fun?