Patterns of Enterprise Application Architecture by Martin Fowler — Intro

A summary of the Inro chapter

Martin Fowler’s Patterns of Enterprise Application Architecture (PEAA) book is, without doubt, a classic read in the field of Software Engineering. In the book, he illustrates some of the most ubiquitous patterns that are used in the Software Industry. The book was written in the year 2002, but it is as relevant now as it was when it got first published.

In this series, I will try to summarize every chapter in a short article, leaving out anecdotical stories and compiling important information in organized chunks that are easy to read and -most importantly- to remember when needed.

The many meanings of the word “Architecture”

Here the author shares his cynicism and partial despise to the word architecture and how most of the time it does not mean what you think it means. And then goes on to list some of the prominent definitions out there, namely:

1. It is the highest-level breakdown of a system into its parts.
2. It is the decisions that are hard to change later/ the decisions that developers wish they could get right early on because they are perceived as hard to change.
3. It is the shared understanding of a system’s design by the expert developers on a project.

Architecture is the important stuff — whatever that is.

The Definition of Enterprise Applications

Here the author mentions that like architecture, the word Enterprise Application does not have a single, widely accepted definition. So he gives some examples of what he considers an Enterprise Application.

Systems like payroll, patient records, shipping tracking, cost analysis, credit scoring, insurance, supply chain, accounting, and foreign exchange trading.

Enterprise applications don’t include automobile fuel injection, word processors, elevator controllers, operating systems, compilers, and games.

From these two categories, we can start to see what are the main characteristics of an Enterprise application, it usually involves:

1. Persistent data: data has to be persistent because it has to be around between multiple runs of the program.
2. Lots of data: usually systems have to use different databases to store huge amounts of data.
3. Access data concurrently: systems have to have the ability to handle a huge number of concurrent calls, and ensure that all of these requests get handled properly. Possible issues here would be stale reads, temporary updates, phantom reads.
4. A lot of user interface screens: with lots of data, there is usually a lot of user interaction to handle it. The data has to be presented in lots of different ways for different purposes. Think of an E-commerce application, a Customer object in an invoicing service may look a lot different from a Customer object in a loyalty service.
5. Integration with other enterprise applications: enterprise apps will have different collaboration and integration mechanisms in place, be it COBOL data files, messaging systems, legacy Databases.

Thinking about Performance

It is always difficult to give any general advice about performance, that is because any performance advice should not be treated as a fact until it is measured on the actual project configuration. Then one should always measure the system’s “metrics” before and after to get a clear idea about the introduced optimization and whether or not it is worth the work done on it.

Then the author mentions that in order to talk about performance we have to set our definitions and shared vocabulary straight.

1. Response Time: the amount of time the system takes to process a request from outside.
2. Responsiveness: is how quickly the system acknowledges the request as opposed to processing it. an example would be a slow progress bar on some website. low response time, high responsiveness.
3. Latency: is the minimum time required to get any form of response from a system.
4. Throughput: is how much stuff can you do in a given amount of time.
5. Load: is how much stress a system is under
6. Load sensitivity: is how the response time varies with the load.
7. Capacity: is the maximum effective throughput or load.
8. Scalability: is a measure of how adding resources (usually hardware) affects performance.

Newer Hardware is often cheaper than making software run on less powerful Hardware.

What does the author mean by the word “Pattern”

There is no generally accepted definition of a pattern, but maybe the best we could get is this quote.

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” (Alexander et al. 1977).

Each pattern focuses on a recurring problem and offers a particular solution for such a problem. A Pattern is not a complete solution, but rather a starting point for the solution, you have to tweak it a little here and there to make it for your needs.

to be continued …