Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I work on and write about asynchronous messaging systems, distributed architectures, and all sorts of enterprise
computing and architecture topics.
Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
Architects can often be found commenting or complaining that many things in IT are the same old stuff in new packaging, created by marketing departments who were in need of a new buzzword. For example, aren't microservices really just SOA done right while SOA itself stands for "Same Old Architecture"? And the whole reactive movement seems to have re-discovered callbacks. Maybe there is some truth in this as at the recent SATURN conferences I found myself saying more often than I had expected "I blogged about this". So let's see which of my past ramblings are still relevant these days.
The first rambling appeared October 2003, almost 12 years ago. The ramblings were intended the be a blog format consisting of short articles, but allowing for the occasional rant or personal opinion. They were also a vehicle to keep publishing ideas that arose after the book was sent to the printer. The ramblings now count around 127,000 words, which is approaching the 185,000 words in the book. The ramblings initially came in pretty regularly at a rate of about 2 a month, then slowed a little and took a notable interruption of almost 4.5 years from 2010 to 2014. In the first 6.5 years 75 ramblings accumulated, which comes out to about one rambling per month. The length of the ramblings is fairly uniformly distributed with just a few outliers at the bottom (one being censored and the other one simply pointing to an article) and one at the top (so much going on at JAOO 2006):
In the old days we would have called all this useless statistics, now it is data science!
The funny naming scheme of the rambling HTML files actually derives from using rather primitive shell scripts for HTML page generation, which needed something simple to sort on. As I am approaching 100 ramblings soon I should consider an alternative - it looks like I created my own Y2K problem! I am sure the odd naming does not help the search rank either.
Many discussions on microservices highlight again that separating systems into independent components or services enables reuse through re-composition. It also brings new complexities, e.g. by having to manage the composition layer at design and run-time. The available tools at the run-time composition level often are not up to the level we have come to rely on at the coding level, making Good Composers Few and Far in Between (2004).
Discussing the architecture of large applications broken down into recomposable services places the emphasis on how the individual components interact. Therefore, it is still the case that when we speak Of Boxes and Lines (2006) we should pay a lot more attention to the lines than we usually do: the lines define the coupling between components and determine run-time overhead. Poorly sliced microservices architectures are bound to be poor performers and provide little benefit.
Another recurring theme, especially in vendor presentations and corporate IT departments, is the "no coding required" pitch. It amazes me how afraid corporate IT can be of code, especially since we know that pretty much all value generated by IT comes from software, which consists of code. Nevertheless, code is seen as a source of problems and bugs created by pesky overpaid programmers who hold the business hostage. Therefore, the lure of "it's just configuration, not coding" is as strong as ever. While raising the level of abstraction is generally beneficial, I don't see the magic line between coding and configuring. And often, configuration lacks all the great tools and discipline coding benefits from, making it cumbersome and dangerous to "just" Configure this (2005).
If there is one universally desired property in system design, it's statelessness. Especially in cloud-ready systems, statelessness brings horizontal scalability and resilience. At the same time, a (probably wise) person also once noted a completely stateless system never earned a Dollar. I may even go further and claim that pretty much all systems are stateful, so claiming statelessness without specifying at which abstraction level can make you an Enemy of the State (2004).
A good friend of mine recently showed me a slide titled "The most widely used domain concepts". In giant letters the slide contained the two words "int" and "string". This reminded me that March is Not a Number (2006). I guess Eric Evans does not have to worry about job security. His search rank now also easily outdoes the one of his "actor" namesake.
OK, what does this have to do with software? It's pretty easy: slow feedback loops cause systems to overswing. This is what happens during Drunk driving and in much of IT innovation. We tend to oversteer from one extreme to the other before we realize we are too close to the curb. For example, some of our microservices will end up being too "micro" causing performance degradation and management complexity.
I really enjoyed Simon Brown's talk at SATURN 2015. He highlighted the fact that architecture is not something abstract and decoupled from the code - architecture lives in the code. Therefore it is best to extract the architecture from the source code, aided by annotations or similar mechanisms as needed. This has the advantage that the architecture diagrams are accurate and always up-to-date. Simon's talk reminded me of my work Visualizing Dependencies (2004), which showed that my beautiful messaging system was really just a bunch of synchronous calls managed by a central instance (and bottleneck). Generated architecture diagrams don't lie.
Speaking of pictures, drawing a good picture can be useful design tool, leading to Diagram-driven Design (2010). Digrams are concrete and can accommodate limited levels of abstraction, forcing architects to focus on the essentials. If it becomes very difficult to draw a picture of a system it may be an indication that the system structure is problematic.
One topic high on my mind these days are conversation patterns, which I am currently
documenting and preparing for publication on this site. Conversation patterns look
ate stateful exchanges between participants over time, which is a nice complement
to the message-centric view of Messaging Patterns. The original trigger for a "conversation view" on messaging systems came in 2004
when I compared Correlation and Conversations.
Not all ramblings are treasures of deep historic relevance. While the concept is still relevant, the collection of EAI Art drawn in TIBCO Integration Manager hosted at GeoCities and linked from my rambling on Doodleware (2003) is long gone. The Wayback machine captured the page but not the images. Luckily I preserved one of them for posteriority (see right). Who says integration can't be fun?
Alas, no one talks much about Mashups (2007) anymore. Facebook has long moved out of their Developer Garage (2007) and Google Wave (2009) has transcended into Internet Nirvana many moons ago. Google Developer Day (2007) has long become a massive conference (2009) with a lottery to buy tickets. Many good developer events like Colorado Software Summit (where you would give each talk 3 times) and SD folded. I am no longer a Microsoft MVP (2007) and I never installed the copy of Vista I bought at the company store. My good intentions to write a Chapter a Day (2010) were good for just two more ramblings before a 4.5 year hiatus.
On the upshot, ramblings are now categorized via tags as I found myself talking about more than just integration and messaging. And the layout got cleaned up a tiny bit. In the end the ramblings provide a time capsule with some items as relevant as ever and some making you go "oh my". Thanks for reading through all these years.
I am looking for a top-notch Cloud Infrastructure Architect and a Principal Software Architect to help establish a private cloud infrastructure for one of the largest insurance
companies in the world and nd re-architect critical core applications to efficiently
run on it. You'll be working in a highly motivated team of technical experts with
your hands deep in technology but immediate visibility to board-level management.
Gregor is a cloud architect and author. He is a frequent speaker on asynchronous messaging,
IT strategy, and cloud.