Responsible Software Architecture

Lately, I have had an overload of information regarding “software architecture”. I have been doing software for like a decade or more already and I have seen a bit enough to know what works out there and what are just passing fad. Today, developers, programmers or whatever you want to call them are so enamored to discuss anything about software architecture with vigor and gusto that I have not seen before.

In 2000, when I was doing some software architecture work as an external consultant to some really large project, the technical project manager cautioned me not to “over-architect”. It occurred to me that probably she had experienced something that make her said that. I saw the objectiveness of that cautious remark and I have instilled that remark into every design work I had thereafter. Until now, I think I had been a responsible individual in doing software architecture work.

I recently ask that technical project manager why the warning. She said something to this effect:

– The first time you piece together the super design of your mammoth killer-app, you make all the mistakes of a first timer.
– The second time you piece them all together, you tend to over-compensate on the shortcomings of the first.
– The third time you piece them together, you now have the confidence of having a near perfect architecture.

Perhaps this was the reason why there is a saying in the software development space that “you can’t make it right until you reach version 3.0”. Or was I referring to Microsoft apps of the past?

The big question to us right now is that, how many of us have managed to stay on to reach version 3.0?

Pundits have advocated that this could be avoided and have things right the first try, thus, we now saw everywhere guides to the best patterns and practices in various colors and flavor. And you would see everywhere heated debates on almost everything. Scrutinizing each approach and questioning motives why a particular practice is best to implement while others should not be. Some worked, some failed. Some were misapplied, some were near perfect. But there is one thing conclusive … all these are no SILVER BULLET that would solve all our woes in software architecture and the business of software design.

What is very noticeable nowadays is that developers tend to believe in almost everything that they’ve read out there. They are enamored to the fact that they can technically articulate and converse proficiently at any technical subject at hand and bask at the feeling of knowing the differences between subjects. However, with these observations, I also happen to notice that these same software architects and designers build their software around the capabilities and limitations of each technology architecture they tend to believe (or perhaps the easiest to them) instead of understanding first the requirements and adopt something that fits with what is needed based on the limits of what they know. Often, they blame the lack of support from the architecture they preferred when they encounter something that is really hard to accomplish.

In almost all cases too, software architects and designers seem to spend too much time architecting a solution. Some without regard to known constraints such as time and financial resources, experience or the lack of it for the said solution. Some would tend to apply the complexities of a multi-tiered architecture to even the simplest of apps just so to be known to peers as architecture savvy.

So I ask, what do others do? Do they understand first the requirements then find and apply appropriate patterns and practices that can deliver the requirements and expectations of users? Do they try to instead fit the user requirements to that of their preferred architecture? Do they pick several of the best out there and find ways and means to glue things together to come up with something deliverable?

As for me, I tend to absorb first the requirements and know my constraints (time, manpower, logistics, technical capability, experience, etc). Then, I tend to immerse myself into what the software be like in its final form. Once I get a clear picture of what the software would be like, that is when I start doing technical work. This involves picking the right architecture to adopt. It is not always necessary for me to check on what is new. If what I have known and tested to work fits given all the scenarios and what-ifs, I pick that architecture regardless how relevant, or how obsolete it has become. Sometimes, I see people who have a knack on choosing whatever is new and untested out there as long as it is popular. If I find my architecture stock insufficient to the work at hand, then that is the time I start investigating other possible options. This can be real hard sometimes, since in most cases, you don’t have the benefit of experience. If I am not careful and responsible in choosing the right stuff, the consequences could be unimaginable.

By and large, I think having too much architecture can be as bad as having none or too little. I also strongly believe that software designers and architects should be on responsibly knowing how much architecture is needed for a particular software and not how to produce the technically most elegant or advanced architecture for any software to prove we are architecture-savvy.

Since there is really no silver bullet when it comes to software architecture, and forever we will be avid learners of what is new and cool out there, and, forever we will be adopting to changes as dictated by our users, I am espousing that let us be responsible in selecting and applying what we think is the right architecture.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s