The beginnings of a code of ethics for software architects

Software Architecture ethical Rule One: I will not limit solutions to those I know. If something I do not know is a better solution I will select that option.

The reality of ethics in particular for a profession is that they evolve. The what and how of the profession drive the addition of new ethical boundaries. There are many examples of impacts that forced changes. The discovery of bacterial transfer caused the medical profession to implement the hand washing rule.

So the first rule is out there. What are the initial modifiers for the first rule? Because frankly the modifiers are the borders that make the ethics easier to implement. The initial modifiers are:

  • I will consider the impact of change on my organization as a part of the evaluation process for new solutions
  • I will consider and value the impact of my solutions on the ability of my organization to function both technologically as well as financially.

To achieve the first modifier you have to understand the organization in question. But this is not a short term understanding. Change isn’t always bad. Short term learning for long term gains can be an effective tool for solution architects. Short term learning for no gain is a very dangerous solution to consider.

The second goal has to do with portfolio management. What does my organization have deployed today? Does the introduction of portfolio change result in business impact? Is that impact good or bad? A drop of water creates ripples. Those ripples impact other systems. A meteor striking a planet causes much more catastrophic impacts. Where does your solution fit on that scale as far as impact to the existing portfolio and operations team, and cost to the business.

The three initial ethical boundaries for Software Architects are actually very simple. Initial draft is below:

  1. I will not create solutions that impact the business negatively (unless the gain on the other side is huge)
  2. I will not create or deploy solutions that require significant increases in operational staff (if the cost is x and the value is x2 than it is acceptable)
  3. I will not create solutions whose documentation is so complex no one else can implement or modify my solution.
  4. I will not create solutions that are islands forever. Any solution I create that changes my organization will expand to become a new continent for my organizations technology going forward.
  5. I will not picks solutions based wholly on the last vendor in my office.
  6. I will not select solutions because that is the only thing I know.
  7. My solutions will not directly impact the business.