Author:  Scott Anderson


In a recent conversation, another architect mentioned a concept that I found interesting. He called it “Ethical Decision Making.” He used a simple explanation of the process for “doing the right things.” I asked if I could borrow the concept and expand it for a blog.


First off, an explanation of ethical decision making: It is more than simply doing the right thing. It is about measuring the impact—both immediate and long-term—of the things you are doing. Don’t make decisions that will cause people harm later even if it doesn’t cause harm now. You can think of Isaac Asimov’s three laws of robotics and apply the same concept to decision making. In this case, the Architect’s Laws would be:

  • I will make decisions about my solution based on input from real users.
  • I will build solutions that map to the day-to-day functions performed by the people using the solution.
  • I will evaluate potential solution changes by considering not only how people use the solution that is deployed today, but also the amount of change required to implement the new version of the solution and the time gained by users if we make that change.


No software architect is directly responsible for layoffs and downsizing. But your solution can harm people in the end.  If your solution isn’t easy to use, it impacts the people that are using it. If you software has issues with other solutions that your company uses, that impacts users as well. If it takes me 20 minutes to learn how to use the software and I will gain 20 seconds a month in productivity, it isn’t worth it. You must determine that core threshold for change versus value.


Perhaps the biggest impact of software on people, however, is the reality of mobility. As mobile devices become more prevalent, the quickest way to create a solution that has a negative impact on a user is to create a solution that has more data per screen than the user can consume. You can evaluate not only the amount of screen real estate available but also the information consumption rate. Highly technical or numerical information cannot be absorbed as quickly as a blog or a text stream can be.


How do you then approach a new solution while living by the three rules of ethical decision making? There aren’t easy answers for this. User acceptance testing (UAT) is the initial and quickest way to evaluate the success or failure of your ethical decisions. The other option you have is to actually follow the people around as they do the job you are building the solution for. It isn’t enough to just read a report or talk to them for twenty minutes to determine how they use technology and by default the potential solution. You have to actually follow the user around for a couple of days. Walk, as the old adage goes, a mile in their shoes. See how they have adapted the solution you have deployed to solve the problems they experience during their day.


Then come back to the office, now armed with the knowledge of what they do so you can start designing the new solution. Now you need to start talking to people again to make sure you aren’t heading down a complexity path that results in a bad series of decisions. How do users handle problems today? How do they handle upgrades?


Once you have a prototype, shadow a different user and see how the new prototype fits into the user’s day. Does it make things easier? Understanding that sometimes a little change in the short run can make things much better in the long run do the comparison. Don’t be afraid to change the prototype at this point—that was why you built it in the first place: to create positive change.


What you get is a software solution designed to meet the needs and fit the requirements of the users. Plus, you lived within the concept of ethical decision making and didn’t create a solution that missed what the users needed.