Architecting Harmony: A Primer on Enterprise Integration Patterns

A group of people using laptop computers.
Photo by Annie Spratt on Unsplash

What are Enterprise Integration Patterns?

Design patterns, in general, and enterprise integration patterns, in particular, are common solutions to common problems where there is wide consensus on their fitness for use. They are technology agnostic. These solutions emerged and evolved over the last 20-plus years in response to problems we see in practice over and over again.

Gregor Hohpe and Bobby Woolf wrote their seminal text (paid link) on enterprise integration patterns back in 2004, to establish a common vocabulary of common patterns that have proven to be effective. The book does not deal with specific technologies that would rapidly fall out of date. Rather, it is all about design patterns that have withstood the test of time.

In this post I’ll introduce you to enterprise integration patterns. I’ll explain why you should consider using them, and the pitfalls to watch out for. Finally, I’ll give you a high-level overview of the main pattern categories. By the end you’ll be able to make an informed decision on using integration patterns, and be able to list their major categories. Future articles will provide examples of these patterns.

Read more

Share this:

Application Security for the Busy Software Architect

Two bullet surveillance cameras attached to a wall.
Photo by Scott Webb on Unsplash

You’re a software architect, or a developer who is thinking about architecture. You know application security is important but, my goodness, there is so much to it. Where do you even begin?

Here I’m going to talk about security from your perspective. I’ll discuss the important aspects of IT security that you need to worry about, and how you can get started with them. There is a wide variety of information security (InfoSec) topics, so I’ll make sure to point out which ones you will be responsible for, and which ones you just need to be aware of because someone else worries about it.

Read more

Share this:

When to use the Event-Driven Architecture Style

Two people drawing on a whiteboard
Photo by Kaleidico on Unsplash

What Is Event-Driven Architecture?

Event-driven architecture is an architectural style where applications and services talk asynchronously with each other. So instead of Application A calling each of Services B, C and D, and waiting for all of those services to finish, it posts its request or event to a messaging service. That messaging service returns immediately with an acknowledgement, so our Application A can move on to other work. Meantime, Services B, C and D each consume their copy of the event and process it. This is roughly analogous to your boss giving you some work to do, and walking away rather than standing there waiting for you to finish. An event-driven architecture can boost performance, maintainability and scalability, at the expense of some more complexity. So let’s dive in.

Read more

Share this:

So Explain To Me What Is Dependency Injection

Apple fruit with plastic syringes
Photo by Sara Bakhshi on Unsplash

So what is dependency injection? What does it do for the design of your application? What are the benefits (and drawbacks) of dependency injection? In this post I’ll explain what it is, and provide some Java code examples to show you how to use it.

Dependency Injection is one of the five principles of object oriented design. These principles help you design and develop cleaner code that is easier to read, understand, maintain, and is more robust and more maintainable.

Read more

Share this:

There is Such a Thing As Too Much Sharing

bowl of tomatoes served on a person's hand
Photo by Elaine Casap on Unsplash

As we grow our application portfolio, we soon discover common bits of code used by two or more applications. Often our first reaction is to break these common bits out into shared libraries. If you’re still using an application server, you might even put these libraries in the server itself so other applications can pick them up. After all, why repeat yourself? Certainly there are situations where that makes a lot of sense. Improved application startup time is one benefit. But not always. Sometimes these shared libraries actually hinder your team’s ability to deliver working software. Here I’ll explain why there is such thing as too much sharing.

Read more

Share this:

Get Organized With a Simple Development Approach

bicycle leaning on an organized shelf
Photo by Roman Mager on Unsplash

As a software development team grows and adds more members, what worked with one or two people no longer works as effectively. The team realizes they need to set up some sort of standard process for developing software. It need not be complicated, just a lightweight process will do. All they need is a way to get organized with a simple development approach. Here is what has worked well for my teams. Adapt it according to your team’s circumstances.

Read more

Share this:

Control Your Deployments With Feature Flags

Control your deployment with feature flags

Application deployments have usually meant deploying a new version of an artifact to Production, with stops along the way in Test, Staging, etc. All the new features and bug fixes become active when you deploy this new version. Although you’ve thoroughly tested the application with automated unit tests, functional tests, load tests, and performance tests, you’ve only reduced the risk of something going wrong in Production. If and when something does go wrong, you may need to rollback to the previous version. But what if the fix wasn’t as dramatic as a rollback? What if you could revert the one mis-behaving feature? Even better, what if you could select which features to activate? In this article I’ll explain how you can control your deployments with feature flags.

Read more

Share this:

How to Design an Effective REST API

Two people touching each others finger tips

History of Representational State Transfer

Roy Fielding coined the term Representational State Transfer (REST) in his 2000 doctoral thesis Architectural Styles and the Design of Network-based Software Architectures. In essence, he argues an API should use the existing HTTP verbs, and it should focus on representations of business objects rather than backend implementations. An example might be to model a Customer object the way the business knows and interacts with it rather than how it’s stored on the customer database table. In this post I’ll describe how to design an effective REST API using some of the concepts Fielding pioneered.

Read more

Share this:

So What Does A Software Architect Do Anyway?

White concrete building

Most software development teams have one person with the role of Architect. Small teams of one or two people may not, but someone is thinking about architecture. This person’s title may be Solution Architect, Application Architect, Data Architect or Systems Architect. For now let’s consider all of them under the collective name of Software Architect. In this article I’ll talk about the characteristics of a good architect, and I’ll explain what a software architect does. I’ll also address the evolution of the role of software architect, and where it is today. By the end I hope you’ll have an answer to the question “so what does a software architect do anyway?”

Read more

Share this:

When to use the Pipeline Architecture Style

Gray pipe on green grass photo.

What is it?

The pipeline architecture is one of the most common architecture styles used in designing software systems. Also known as pipes and filters, it consists of a series of discrete steps performed in a predictable sequence. This is different from the model-view-controller pattern in a layered architecture. In this article I’ll define what it is and when to use the pipeline architecture style.

Read more

Share this: