Leadership Techniques for the Software Architect

Man standing in front of people sitting beside table with laptop computers.

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. Your 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

Write More Maintainable Software With a Hexagonal Architecture

Adopting the hexagonal architecture pattern produces software that is more maintainable. It enables you to respond to changes with less fuss than many other architectural patterns. In this article I’ll explain why and offer my thoughts on this pattern.

What is a Hexagonal Architecture?

Alistair Cockburn first coined the term Hexagonal Architecture on his blog in 2005. Also known as the Ports and Adapters pattern, it is a layered architecture. It is a way of separating the domain concerns while making unit tests easier to write and changes simpler to accommodate.

Read more

Are Microservices The Same Old SOA?

Are microservices the same old SOA (Service Oriented Architecture)? Isn’t it just a rehash of the SOA hype? Let’s discuss the similarities and differences.

While microservices and Service Oriented Architecture (SOA) are two architecture patterns that deal with services, they have some differences. In fact, despite all the attention you see being given to microservices there are a couple use cases where SOA is the better choice.

So What Is a Microservice?

A microservice a stand-alone process that communicates with its clients using a lightweight mechanism, usually HTTP. Its datastore is a database of some sort. The service is the only application that interacts with its datastore. So let’s say for example you have a CustomerService that reads from and writes to the CUSTOMER table and any related child tables. Only the CustomerService performs SQL actions on those tables; any other services that do something with Customer information must go through the CustomerService using its published interface.

Read more

A Target or a Radar For Your Architecture?

Radar dish

Should you use a target architecture or an architecture radar for your organization? In this post I’ll explain what each one is. I’ll then highlight the differences between them. Finally, I’ll provide my opinion on which one is better and why I think so.

Many organizations, once they get to a certain size, see the need to decide on a particular technology stack. And rightfully so, because a proliferation of various competing technologies leads leads to an organisational drain. IT people need to become conversant and in most cases proficient at JBoss, WebSphere, and WebLogic if all three of these application servers are used. It means the organization ends up going “wide and shallow” across these three instead of “narrow and deep” on just one. In other words, they don’t develop a deep level of expertise on one application server, making problems harder to solve.

Note that this applies to programming languages, databases, application frameworks, and the key libraries an organization uses. It can also apply to server operating systems, routers and other network infrastructure, firewalls, etc.

Read more

Managing and Monitoring Your Java Applications

Managing and monitoring you Java applications
Photo by Chris Liverani on Unsplash

The Problem

So your team has developed and implemented the five principles of object-oriented design. You’re using Spring Framework as your dependency injection mechanism in your Java applications. You’ve tested the app, it’s been in production for some time now. But how is it doing? Is it healthy? Is it up and running? Oh sure, you can wait for a service desk call to come in, but wouldn’t it be much better if that call came in and you could say “yes, we’re aware of a problem and we’re working on it”? Some form of managing and monitoring your Java applications is moving from “nice to have” toward “essential”.

And when that ticket come in, your first thought. is to see if the app is actually running. You could check log files. You could log in to the app itself, oh wait, your credentials don’t allow you to log in to the production app. Is there a set of support credentials you can use? Where are they?

There has to be a better way.

There is. It’s called Spring Boot Actuator.

Read more

Don’t Be Human About Application Deployment

A robot
Photo by Franck V. on Unsplash

Humans are fallible. To err is human. These are noble assertions when it comes to living the human experience. But when it comes to application deployment, humanity is the weak link in the chain. In this post I’ll explain why and offer arguments in favour of automation.

We like to be in control. We want to make sure a process is done properly, and ultimately our bosses want to know we provided the necessary oversight. But how many manual deployments have you participated in when someone inadvertently omitted a step? Sure, you documented it clearly in the deployment instructions, and reviewed them with your implementers in the days leading up to the big deploy. Even so, that omission caused some sort of delay or worse, cause a data corruption. Now you are still there late Sunday night cleaning up the mess. There has got to be a better way.

Read more

What Makes a Successful Software Project?

Man and woman using a laptop computer

Solve a Real Business Problem

Some software projects succeed, and others fail. What’s the difference? What are the clues that indicate whether a software project is going to succeed (or fail)? Here are four characteristics.

Number one, in order for any software project to succeed, it needs to solve a business problem. The magnitude of that problem, in terms of dollar value, needs to be greater than the money (time and effort) spent on the project. Otherwise, you’re just blowing an even bigger wad of cash.

Top Management Support

Number two, it needs the commitment and support of top management. Invariably there will be conflicts with allocation of people, time and money. Without this commitment and support, a loss of these resources can cause a project to be delayed, de-scoped, or both. The end result can be disappointing to the business customers. Having this commitment means having an executive on your side to advocate for your project.

Read more

But We’re Not Ready to Deploy Yet!

Pre-deploy work can drive you crazy.

Does it seem like you’re always waiting for something to be completed before you deploy your application to the User Acceptance Test (UAT) environment? You want to wait for the development team to fix the last few bugs. They have not yet agreed on which transaction manager to use. We’re only a couple days away from finishing feature X. We might have time to get feature Y in. There is no end to the myriad of details to sort out and questions to answer before you deploy.

Not only that, the product owner or project manager is getting impatient. You promised her it would be deployed two weeks ago, but due to factors beyond your control there’s still more work to do. The Quality Assurance (QA) folks have their test scripts ready to go, but they’re just twiddling their thumbs while they wait for you to deploy the application.

Read more

The Grail is Eating Properties

Problem: You are developing a Grails application. You are using scaffolding to build out your views and controller actions. Yet for some mysterious reason Grails is not rendering some properties in the views.

Solution: Did you designate some properties as transient? If so, then by default Grails does not generate transient fields in views. To fix this you need to install the template plugin, and change the value of the persistentPropNames variable:

  1. Install the view templates:
    1. grails InstallTemplates
  2. Now open the pertinent templates (list.gsp, show.gsp) in src/templates/scaffolding
  3. Change the line that reads allowedNames = domainClass.persistentProperties*.name to allowedNames = domainClass.properties*.name for each template.
    1. Note you are changing persistentProperties.* to just plain properties.*. This opens the door for Grails to generate fields in your views that include your transient properties.

Thanks to lo_toad for pointing this one out. This solution saved me so much time.

Living In A Subversive World

This describes how to use Subversion on a day to day basis. If you have inherited or been assigned to a software development project that uses Subversion, but are unfamiliar with how it works and how to use it, then this post is for you.

So What is Subversion?

Apache Subversion is a Source Configuration Management (SCM) system that has one central repository, usually located on a web server. Each of us works on our own copy of the Subversion-controlled project. When post our changes back to the central repository, Subversion merges them with the existing code and increments the Revision number. Anyone who then updates their local copy of the project will now see the changes we just made. As long as everyone performs frequent updates to their local copy, it all works fine.

What’s So Great About It?

Subversion uses the copy-and-merge philosophy, in contrast with the Lock-Modify-Unlock method used by older SCMs such as RCS, and Microsoft Visual SourceSafe (VSS). In these systems, only one person can change a file at a time, while everyone else is locked out. Veterans of RCS or VSS may point to a risk of running into conflicts and other problems when using Subversion’s copy-and-merge. While the risk of conflicts is still present when two or more people are working on a file, in practice this is only a concern when these people are changing then same part of a file.

Read more