Software Architecture

I was promoted to Application Architect based on performance as engineer and project lead. At that time, like most people, my idea of software architecture was basically high level design. And also being responsible for various aspects of application that cut across many components of the application, for example, performance, scalability, reliability, availability, diagnosability , security, extensibility, reusability and many other "ilitis".

It was not until after several years that I had the "aha" moment.

We all wear engineer hats and architect hats and if you take a senior engineer and a hands-on architect, you cannot always tell a difference. But on a theoretical ground, architecture differs from design and engineering in that, an architect attempts to find patterns or blueprints when solving problems, rather than coming up with algorithms and data structures. Software architecture defines an abstraction of the system modules (separation of concerns) and defines interactions between them.

Not sure how good this analogy is, but lets take painters vs artists. Artists also paint, but it is the creativity aspect that separates them from painters.

Similarly, it is the pattern or blueprint aspect that separates architects from engineers.

If you notice, architects typically generate as much Powerpoint slides as Word documents, if not more. Once upon a time I had disdain for architects who were all Powerpoint and talks rather than being hands-on coders, at least some of the time. I used to call them Powerpoint Architects, and I didn't find them effective in pushing their ideas into product features. Over time I have softened my views, because it was upper management's failure that these architects were not as effective as they could have been.

Still, architects need to be hands on, because code can be better expression than Powerpoint slides. More importantly, architects need to learn from trials and errors and lots and lots of refactoring of code.