Once you begin to fear your technology, you will shortly have cause to fear it even more. The Fear Cycle goes like this: Small changes have unpredictable, scary, or costly results. We begin to fear making changes. We try to make every change as small and local as possible. The code base accumulates warts, knobs, and special cases. Fear intensifies. Fear starts when an innocuous change goes badly.

There's a well-known architectural style in desktop applications called "Components and Glue". The central idea is that independent components are composed together by a scripting layer. The glue is often implemented in a different or more dynamic language than the components. The C2 wiki's page on ComponentGlue has been stable since 2004, so obviously this is not a new idea. Emacs is one example of this approach.

I have a rich and multidimensional relationship with Amazon. It started back in 1996 or 1997, when it became the main supplier for my book addiction. As the years went by, I became an "Amazon Affiliate" in a futile attempt to balance out my cash flow with the company. Later, I started using AWS for cloud computing. I also claimed my author page. Let's contemplate the data architecture needed to maintain such a set of relationships.

My last post on the subject of inverted ownership felt a bit abstract, so I thought I might illustrate it with a typical scenario. In this first figure, we see a newly-extracted Catalog service, freshly factored out of the old monolithic application. It's part of the company's effort to become more maneuverable. We don't know, or particularly care, what storage model it uses internally. From the outside, it presents an interface that looks like "

One of the sources of semantic coupling has to do with identifiers, and especially with synthetic identifiers. Most identifiers are just alphanumeric strings. Systems share those identifiers to ensure that both sides of an interface agree on the entity or entities they are manipulating. In the move to services, there is an unfortunate tendency to build in a dependency on an ambient space of identifiers. This limits your organization's maneuverability.

On the subject of maneuverability, many organizations run into trouble when they try to enter new lines of business, create a partnership, or merge with another company. Updating enterprise systems becomes a large cost factor in these business initiatives, sometimes large enough to outweigh the benefits case. This is a terrible irony: our automation provides efficiency, but removes flexibility. If you break down the cost of such changes, you'll find it comes in equal parts from changes to individual systesm and changes to integrations across systems.

Agile development works best at team scale. When a team can self-organize, refine their methods, build the toolchain, and modify adapt it to their needs, they will execute effectively. We should be happy to achieve that! I worry when we try to force-fit the same techniques at larger scales. At the scale of a whole organization, we need to look at the qualities we want to have. (We can't necessarily produce those qualities directly, but we can create the conditions that allow them to emerge.

If I had to guess, I would say that "Layers" is probably the most commonly applied architecture pattern. And why not? Parfaits have layers, and who doesn't like a parfait? So layers must be good. Like everything else, though, there's a good way and a bad way. The usual Neapolitan stack looks like this: On one of my favorite projects of all, we used more layers because we wanted to further isolate different behaviors.

One company that gets this right is Github. I exist as my own person there. I'm affiliated with my employer as well as other organizations. We are long past the days of "the company man," when a person's identity was solely bound to their employer. That relationship is much more fluid now. A company that gets it wrong is Atlassian. I've left behind a trail of accounts in various Jirae and Confluences.

Inspired by Glenn Vanderburg's article on Clojure templating frameworks, I decided to try using Fleet for my latest pet project. Fleet has a very nice interface. I can call a single function to create new Clojure functions for every template in a directory. That really makes the templates feel like part of the language. Unfortunately, Glenn's otherwise excellent article didn't talk about how to connect Fleet into Compojure or Ring. I chose to interpret that as a compliment, springing from his high esteem of our abilities.