The True Technical Architect

21 09 2008

Architecture“… what a grand word. Grand words with grand meanings emit a mysterious aura of sophistication and elegance. I won’t deny it. I, myself, fell in love with that word.

The Architect of “The Matrix” is pictured as a calm old fellow with the wisdom of Buddha and the profoundness of Shakespeare. That’s how Hollywood (read: people) perceives software architects… ahem, well, that’s not so far from the truth.

Many times, I see “Technical Architect” on business cards and in resumes. But what does that title or role really mean?

When there is ambiguity, I go back to the basics for an answer. That’s why, in a humble attempt to make things clear, I try in the following paragraphs to meticulously define the concept of “Architecture” and then move on to sketch a rough drawing of the true architect like I picture him or her.

Architecture… of What?

That’s the first wise question one should ask. I like to poke “Architects” and ask them… what do you architect? what kinds of decisions do you make? I either get back a blank stare, or another question plus some pseudo-random output: “what do you mean? I just do it. High-level stuff. I pick technologies.”

Well, we – developers and software engineers – build systems. But let me be more precise. We actually develop Applications. We might also integrate our Applications with other Applications into a System of Applications (think your web app, DBMS, FTP, Email, and BlaBla servers for example). These applications we build and integrate do not run in vacuum. They run, possibly, on top of other applications (think containers) that run over platforms (think Java) which run on operating systems which, in turn, run on hardware. Applications may also need to communicate over networks.

The union of all the above mentioned elements represents an IT Solution a wild beast, and a complete answer to your customer’s business need or problem.

Great. Now, let’s define “Architecture” In the context of IT solutions. Architecture is essentially “Design” — only a high-level form of it. To design something is to…

…plan something for a specific role or purpose or effect; “This room is not designed for work”

The True Architect

So basically, to call myself an “Architect”, I should have had planned – at least once – either an entire IT solution or part of it for a specific intended role or purpose or effect. If that sounds easy, think again.

The very first purpose of any kind of IT solution is to be functionally correct and functionally complete; i.e. the solution (including all custom-developed applications) completely and correctly fulfills functional requirements, plain and simple.

But that’s just the beginning. All the “neat” tricks and conquered challenges behind great architectures (such as Google’s) were direct results of ruthless non-functional requirements and constraints – Performance, Scalability, Security, and Availability to name a few. Fulfilling those requirements is therefore an essential part of overall IT solution architecture. How to do that under different project constraints (available budget/time/ resources, imposed technologies/platforms/operating systems, etc.) is the name of the game.

That’s on the solution level. On the Application level, amongst the most important non-functional requirements are Maintainability, Extensibility, and Configurability. Architectural patterns such as Model-View-Controller (MVC) for example became so popular because they facilitate maintenance, extensibility, and configurability of otherwise spaghetti-coded web apps.

Another important aspect is that technologies bring along their limitations and performance characteristics. That’s why choosing technologies that most fit the purpose of the application/solution is one of the most fundamental and far-reaching decisions in IT solutions development. Technology is always a means to an end.

Bottom line

So anybody who did application or solution architecture once can mark himself as an architect. However, a true architect who earns my respect is one who has lots of real-world experience in meeting non-functional requirements in ruthless production environments. A true architect is someone who has developed a rich tool box of principles, patterns, and anti-patterns of solution and application architecture.