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:

How to Migrate Your Web Application to the Cloud

photography of cloud and forest trees

So it’s time to move one of your legacy web applications from your on-premise data centre to a public cloud provider such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). This may be a decision you made, or one that your leadership team made. In this post I’ll explain what you need to think about when figuring out how to migrate your web application to the cloud.

Read more

Share this:

Microservices: When to Use Them

Brown and white long coated small dog wearing eyeglasses on black laptop computer

Introduction

Microservices are all the rage these days. You’ve seen so many blog posts, technical articles, even job postings calling for microservices experience. So it must be the new way to architect applications, right?

Well, as with everything else in software architecture, it depends. It depends on the context you are dealing with. It depends whether the benefits of microservices outweigh their drawbacks for your situation.

In this post I’ll describe what microservices are, why they’re so good, and what their drawbacks are. I’ll finish off by giving you some guidelines to help you decide whether microservices are right for your situation.

Read more

Share this:

Software Product Teams are Better Than Project Teams

People working at a table.

When it comes to software development, product teams are better than project teams. I’ll explain why.

Seen This Before?

Have you noticed a pattern that most organizations use to build software? They assign a project manager to prepare the project charter that broadly defines the scope, cost and schedule. Senior management approves the charter, and then they assemble a team. Developers, analysts, QA testers join the new team even though they may be winding up other projects. Management assigns an architect. They might also assign a DBA, network and middleware experts on a part-time basis.

Read more

Share this:

Become a Great Software Architect by Being a Great Communicator

Man giving a presentation.

Software architects are responsible for the technical solution to ensure it achieves the desired business outcomes. To do so requires broad technical and business knowledge with a deeper understanding in a couple technical areas. It requires being able to see the big picture. It requires the wisdom to evaluate different solutions to the problem. But most of all it requires really good communication skills to convey the solution. You can become a great software architect by being a great communicator.

Read more

Share this:

When to Use the The Layered Architecture Style

Layer cake

A layered architecture style is one where the presentation, business and persistence layers are bundled into one deployment unit. In this article I’ll discuss what it is, and point out the situations where you would choose to adopt it.

This is one of a series of articles where I am going to discuss each of these architecture styles: Layered, Microservices, Pipeline, Microkernel, Service-Based, Event-Driven, Space-Based, and Orchestration-Driven Service-Oriented Architecture (SOA). I’ll provide some insights based on my experiences, and I’ll mention some of the Java / JVM frameworks that support the style we’re talking about.

Read more

Share this:

Leadership Techniques for the Software Architect

Man standing in front of people sitting beside table with laptop computers.
Photo by Campaign Creators on Unsplash

Why is Leadership Important?

The typical path to becoming a software architect begins with years spent in the trenches of hands-on software development. You’ve accumulated technical knowledge that is broad and deep. Along the way you’ve developed your communications skills. And I don’t just mean status reports. I mean by mentoring junior developers, by giving presentations to your peers on the knowledge you have gained in a specific tool, framework or language, and by interacting with systems and business analysts.

Now that you’ve become an architect, more people will look to you as an authority, as an expert. Now you’re starting to provide guidance on software design and the usage of tools and frameworks. You notice you have more influence. You are now responsible for the technical solution of the product your team is building. You are now in a position of leadership.

Read more

Share this: