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:

The Further You Go the More Those Relationships Matter

Two people shaking hands
Photo by Cytonn Photography on Unsplash

The other day I read a Pluralsight article titled Leadership guide: Your first 60 days as a CIO (registration required), and it made me think. While relationships are a big deal for CIOs, they also matter for everyone in IT. They matter to varying degrees based on your job role; nevertheless who you know and how well you know them makes a difference in your job and your career. Here is why I think in your career or your business, the further you go, the more those relationships matter.

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 set up a Continuous Delivery Pipeline

Man in green t-shirt and blue denim jeans holding brown cardboard box

Suppose your client or your employer comes to you and says “We need you to help us understand how to set up a continuous delivery pipeline.” They assure you they are committed to the goals and benefits of Continuous Delivery, also known as Continuous Integration/Continuous Deployment (CI/CD):

  • The software development teams want to reduce deployment risk.
  • They like the idea of frequent small deployments during the workday instead of huge deployments once or twice a year.
  • Teams no longer want to dedicate a full weekend to a massive deployment, with all the attendant stresses and risks that brings.
  • The business is less tolerant of waiting months before they see even the smallest change; they want a faster time to market.

They have acquired all the tooling, and all they need is your guidance and leadership for how to set up a continuous delivery pipeline.

How would you approach this? What sequence of steps or phases would you use? In this article I’ll present some of my thoughts and suggestions.

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:

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: