Yesterday I posted the three initial boundaries for software architects. I said there were three and posted many more than 3. I can count, I was trying to refine my list of three and ended up with many more.
- I will not create solutions that impact the business negatively (unless the gain on the other side is huge)
- 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)
- I will not create solutions whose documentation is so complex no one else can implement or modify my solution.
- 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.
- I will not picks solutions based wholly on the last vendor in my office.
- I will not select solutions because that is the only thing I know.
- My solutions will not directly impact the business.
Number seven is a repeat of number 1 so in effect there are six. They really together into three areas where software architects have responsibility and impact in an organization.
Technology solution selection is an area where software architects frequently contribute both the question and the answer. In some companies the software architect is in a position of standard setting and roadmap directions but not directly involved in the business selection of software. In the gray areas where software architects move from decision maker to influencer and guider is where the software architect has to be most careful. This is an area where personal bias may impact what you say and do. Removing your personal bias is the best possible answer for your organization.
Boston Consulting Group created the experience curve many years ago. It says that as an organization matures it gets better at what it does and reduces cost over time. With automation and technology that curve can instead look more like a bumpy mountain road rather than the nice stair steps depicted here. Over time costs are reduced but it may a different long term model. Like the one show here. Where for a time costs may be increased. The value of a solution is the value it brings to the organization over time. If the value of a solution over time is far greater than the cost initially, then consider the solution.
With the first two ethical boundaries we now see why people define software architects in a number of categories. Solution architects bring new systems to an organization or work to improve existing solutions with specific projects. Enterprise architects gather information about the business and how it works and build roadmaps and guides that help the business achieve its goals. Add to that specialized roles like business architect and information architects, security architects and product specific architects and so on. Business isn’t simple. Government and NPO’s are not simple. They have missions, goals and markets. The job of the software architect is to live within the goals of the organization while doing the best possible job to improve the functionality within the organization.
Perhaps, a professional creed is needed to kick off the code of ethics.
As a software architect I design, build an implement systems that benefit the organization where I am working.
It’s a start….