Category Archives: Architecture

What I would change if I saw your database

This post briefly covers the history of databases, transaction fundamentals, and then proceeds to explain what I would change if I saw your database. It is highly-opinionated, and based on decades of experience in working with relational databases.

History

The term relational database was Invented by E. F. Codd at IBM in 1970 in his paper “A Relational Model of Data for Large Shared Data Banks.” The first commercially available RDBMS was Oracle, released in 1979 by Relational Software, now Oracle Corporation. Currently, the most popular relational databases are: Oracle, MySql, Microsoft SQL Server, PostgreSQL, DB2, SQLite, Sybase. They all use a variant of SQL. My personal favorite database is PostreSQL. It is free, open-source, and most faithfully implements ANSI-SQL.

Relational Databases Today

The relational database can provide the right persistence solution for most business needs. They are extraordinarily fast and reliable. They can manage petabyte scale data. There are plenty of tools written for them. They are simple to use. Right or wrong, they are also one of the most common enterprise integration patterns.

Continue reading →

Steal this Architecture – Attribute Drive Design

I often ask myself, “What is software architecture?” I asked this same question to all of my co-workers. I struggled defining what is software architecture, and what is it that a software architect actually delivers.

A typical answer to that question is that a software architect designs the interfaces of a software system and the important decisions made to complete it. They will understand the how and the why.

This definition makes perfect sense during a conversation, but I find that definition has less impact when written down, although there is some truth to the above definition.

Is a software architect just a bad ass developer that is good at making sketches on a white board?

I have walked away from many meetings that had architectural sketches in it thinking that although it was a step in the right direction, it was useless as a software architecture deliverable. Quite often, that informal sketch was often the only software architecture guidance.

In this post, I’ll do a deep deep-dive into software architecture in order answer “What is software architecture?”

Continue reading →

The Layered Architecture Pattern

Len Bass, Paul Clements, and Rick Kazman best explain the Layered Architecture as, “The Layered Architecture Pattern defines layers as a grouping of modules or services and a unidirectional allowed-to-use relation among layers. Layers must have a strict-ordering relation, in which a layer can only use public interfaces of a layer below,” in the book Software Architecture in Practice1.

The benefit of the layered-architecture is that it allows for a separation of concerns, allows for a division of labor, and it is typically easy to refactor a top layer.

Its drawback is that there is a performance cost for each layer, and it can be very expensive to refactor lower layers.

Continue reading →