Vertical versus Lateral Architecture

Recently I started a thread on IATA discussion group with this post.

Are you a lateral or a vertical architect?

• A lateral architect is one that tends to look across multiple options before drilling down.
• A vertical architect is one that tend to go down quickly (usually a known path) and then problem solve issues on that path.

Examples:

• LA may survey consequences of using a Nordic Database, SQL Server, Oracle etc, C#, C++, F#, NetBeans, MVC, etc
• A VA will try to reuse their last success and just twig issues.

There are places for both (and places where they are not matches).

Two responses stood out:

"Successful architecture is rarely accomplished by a single architect. Typically architecture will be done as a team of architects. This team is usually composed of an LA leading a team of VA's. The VA's are responsible for specific architecture (data base, email, etc) whereas the LA is responsible for the global picture and aligning the solution with the business goals. My experience has been than an LA can also be a VA if required but not all VA's are well suited to be an LA. There definitely is a place for both. The trick is to make best use of VA's and LA's."

David Wilson Technical Architect at Bourse de Montreal Inc.

And

"I agree too, as I see VA being just a developer leader..."

Paolo Lioy IT Architect at Paolo Lioy

It's more than just Impedence mismatch!

Reflecting on the impedence mismatch today I was drawn towards the issue of scalability and web farms. RDBMS supports scalability in many ways such as federated databases and partitioning. An RDBMS application can be code for a single database and with small effort and no uncertainity be scaled out for use by a web farm.

Looking a dotNet or C++, the ability to handle stateless processing across a non-sticky webfarm really have no clean solution. A more important aspect is that if Object such as a "Book for Sale" changes it's collection of copies available for sale there is really no way that a concurrent object instance can discover this without the use of a database or proxy database. The concurrent instance may be on a different machine so having a global instance falls aparts.

Reflecting further it becomes apparent that OOP was designed for a single instance with items like parallel processing and distrubuted processing being afterthoughts, Early in my career I programmed with Simula, the father of C++, where instances were independent or tightly coupled. Databases were designed for multiple clients. C++ and Simula was single client.

The stateless non-sticky web farm is trivial for RDBMS to handle, but OOP really does not have a native infrastructure for handling this environment. There are a variety of kludges that can be done -- but none are inheritantly obvious. In short, there is not only an impedence mismatch, but OOP is unable to handle the AC voltage of the web. OOP is ideal for DC voltage.

Time to dust off the pen

It's been a few years since my last article on MSDN as part of Dr.Gui. Looking at the quality of posts on the Web cause me concern over the very low quality that appears, especially with 99% of them being rehash of examples with little real contribution to the Art and Science of coding...

So I thought that I will take up the pen again ...