Ethical boundary or Ethical guideline….

I got a great question yesterday about the ethical boundaries I published. I was asked did I see them as boundaries or as guidelines.

A boundary, such as the lines on a map are actual limits. You don’t cross the border of a country without the permission of both the country you are leaving and the country you are going to. It is a hard and fast limit. A guideline is more well you probably should do this, but you don’t have to. Speed limit is a boundary, drive slower at night is a guideline.

So the software architecture ethics I am working through are boundaries. Do not cross those lines without understanding the impact and cost of doing that.

A cycle that balances the requirements of the solution, the value to the business the cost of the solution and the users of the system.

Building a system that forces users to start over and relearn everything has to provide either significantly lower cost or much greater business value!

Now business value and costs have spectrums. It is conceivable that greater costs in the short run that produce greater revenues later on can be considered. The tradeoff is can you get to the point where the costs begging to decrease. The experience curve (Boston Consulting Group) says you can. Overtime the overall costs of a solution will decrease as people get better in the building and delivery of a solution.

To a degree it is about getting up this spectrum quickly. If the value of a solution is visible quickly then the risk of the solution being halted is reduced. The same is true of course on the other side. Low visibility of value, high probability of cancellation.

Where on this spectrum does the software architect have responsibility. Normally it would be in the first two buckets. The value derived is a process that can’t normally be controlled directly.

So initial boundary in selecting a solution for software architecture would be the cost of the actual solution ad the impact of the change for the organization.

.doc

wandering the software architect ethical desert…

Draft 4 software architect code of ethics…

Continuing on the Software Architect’s Code of ethics.

Draft 4 Software Architect Code of Ethics

• I will act without bias in gather requirements.

My criteria will focus on the needs of the organization.

My personal preferences for software and solutions will not drive my decisions in how and what requirements are gathered.

• I will select solutions based on the overall technical need balancing the monetary, technological, user and operations impact of the solution that is selected.

Good enough (technically acceptable lowest cost) is an acceptable option if my organization considers cost the primary driving change factor.

• I will align with organizational guidelines when considering both the overall solution and the requirements for that solution.

If I am working with a business unit as a software architect I will adhere to the broader overall Enterprise Architecture

If my solution requires new infrastructure I will coordinate with the central IT team regarding the impact and value provided by the new infrastructure.

Software architects also need to be aware of all standards within an organization. That would include security, data standards and device requirements. Building a solution that only works on Android tablets as your organization implements its BYOD policy isn’t wise. You now force everyone to carry multiple devices or worse have devices iOS and Windows Phone) that cannot access your overall solution.

As you gather requirements (without bias) you also have to consider the value of trade offs. IE which requirements are absolute and which and be traded for other functionality. A fire department building a new dispatch system would say the ability to accept inbound emergency calls and to dispatch fire tracts can never be down. The same is true in hospitals when it comes to patient care, those system can never be down. There are however systems that say they can never be down but reality they can. Understand the value of the system.

For the stock exchange it is the software that supports the buying and selling of stocks. When that is down they lose money. Understanding the impact of the system in question is not an ethical problem but it is one that software architects face. The ethical decision is around the value of the solution to the business. The software architect has to understand the business well enough to understand the tradeoff criteria.

Years ago as a consultant I remember a customer telling me that the worst thing about consultants was that everything was a nail, luckily the consultants always carried hammers. I have carried that with me ever since. Not everything is a nail.

Software Architects examine the component in question and consider is it a screw, nail, glue or Velcro. Not everything has to be a nail and not everything needs a hammer.

.doc

Software Architect

A Software Architect Code…

Continuing my ethical posts. I had a conversation with a friend and while we were talking he reminded me of a couple of ethical sticking points architects sometimes run into.

First off software architects have to consider their personal bias. As you consider solutions and gather overall requirements you have to consider the reality of your own bias. Your bias can change not only what you gather as requirements but also how you rank those requirements as needs in building a solution.

The other trap is forgetting the business in gathering requirements. Not that you aren’t working with the business to gather requirements but more that you forget how the business makes money or meets its mission while gathering requirements.

It was a good conversation and really helped me start to codify some of the initial ethical boundaries that we have to consider as we move into the software architecture space.

Draft 3 Architect Code

• I will act without bias in gather requirements.
• I will select solutions based on the overall technical need balancing the monetary, technological, user and operations impact of the solution that is selected.
• I will align with organizational guidelines when considering both the overall solution and the requirements for that solution.

Slowly but surely moving towards a code of ethics. Now there are other parts like how a software architect acts within various scenarios. But that is more an interpersonal communications issue not an ethical issue. The ethical boundaries within a profession shouldn’t have to extend to morality. A profession shouldn’t have to say you will act within the laws of the country you are operating in. That should just be a given.

.doc

Continuing towards an ethical tomorrow

Software architect ethics continued, defining boundaries…

In my first couple of posts I shared the easy boundaries for software architects and their application of professional ethics.

Remove my bias from decision making. Now, that is really easily said but a lot harder to do in reality. Bias is one of the things that shapes and makes decisions. It is the reality of the comfort zone. In the diagram here are three groups. Each group represents a competing technology. The software architect has to choose not based on their preference for colors (I like blue) but on the capability of the solution.

Then the business asks about the impacts of the solution. A complete redo of an infrastructure (where the infrastructure represents not simply the plumbing  and pipes of an organization but the entire solution set required to run the business) has training and productivity impacts as well. All of this constrained by the expected timeline of ROI (return on investment).

Solutions like all things have horizons. The limit of how far you can see ahead. For example corporations started deploying mail systems in the 1980’s. In the world of dial up and controlled access, you communicated within your company (or within AOL or Compuserv and so on). Some companies adopted x.400 a transport protocol designed to move information between companies. Hard to setup and complex x.400 died a painful death. Why because SMTP (simple mail transport protocol) replaced it. It simply required the adoption of the universal messaging @organization. whatever the organization was (.edu, .org, .com and so on).

The horizons for the solution continued to change. By 2000 most organizations were received more SPAM mail per day that real mail. That required the implementation of SPAM and virus filters. This already implemented solution (mail) required suddenly training. Although as I have said now for more than 15 years, DON’T CLICK on a message that says I love you from people you don’t know.

So the next boundary is how far to the horizon is an architect responsible for a solution?

.doc

Ethicist

Continuing the Ethical Software Architect conversation…

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.

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.

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

.doc

Software Architect…

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.

.doc

Ethicist.

Code of ethics for software architects (starting point)

I have been thinking about the ethic’s of software architects for the past few months. First off, I am not under the magical spell of an architectural unicorn that leads me to believe the mixed bag of software architects is any different than the population as a whole. Nor am I convinced that there is a lifecycle of ownership beyond the creation of a solution. This blog and the others I’ve posted in the past represent an initial set of thinking. Hopefully this will evolve into a code of ethics over time.

When you consider ethics there are a number of interesting questions you have to ask. The first question is why ethics. Is your profession to the point that it needs a code of ethics? The other side of the why, does a code of ethics move your profession forward. In the case of software architecture I do in fact think it is time for a code of ethics.

The first question then is how do you create a code of ethics that isn’t so onerous people won’t consider it. Ethics is a higher order thinking set. You don’t respond to the fight or flight situations with ethical questions. You have to stop, consider and then act ethically.

The problem is that any one software architect is a drop in the ocean of all software architects. That means that a code of ethics has to be broad enough to touch all the disconnected water in the ocean and yet still be actionable enough that you can say – hey repeated violations of the code of ethics result in us kicking you out of the profession.

Ethics have to be the boundaries in which you operate. Not fenced guarded boundaries that cannot be crossed. Those don’t even work for entire countries. The problem with checkpoints is you have to have egress and entrances. You have have people checking documentation and verifying that things are the way they should be. Professional boundaries have to be self applied.

My grandfather always said “ethics are what you do when no one is around to see you.” So how to software architects act when no one is around?

The initial question has to do with the very selection of the solution they are building. The ethical selection of a solution is critical. Not everything fits into this box because this company pays me, but the solution you require maps to the requirements.

So, properly gathering and evaluating requirements is the first ethical responsibility of a software architect. Gather the requirements and then you have pick the right solution. The ethical response is rising above your bias to select the right solution regardless of your personal knowledge. IE just because you don’t know a technology

more to come….

.doc

Ethicist

Ethics and (of) Software Architects….

http://docandersen.podbean.com
https://docandersen.wordpress.com
http://scottoandersen.wordpress.com
My Amazon author page!!!!
http://www.safegov.org

One of my favorite IT sayings (why drives what and how) came up yesterday in a conversation. The person in question asked me why I thought why drove what and how. I found myself back in a classroom in Chevy Chase Maryland in 1998.

• Why is the motivation for doing something.
• What is the thing we are doing.
• How is what we do to get it done.

Without Why neither What or How can drive something to completion.

The first comment from the person in the question was “wow you’ve practiced that.” The second comment was “I get it now.” Yes I have practiced that. Its right up there with “Do the right things and the Money will follow.”

As stated earlier this week I will be diving deeper into the why of software architects this weekend with the launch of my new blog series on the Ethics of Software Architects.

The reason for the advertising a little is to drive readers but also I am floating through my process of creating formal content. I like to throw out parts of what I am putting together to gage interest.

Right now as I consider the what and how of ethics overall I am a little concerned. Today the country I call home is a very litigious country. While no one has sued a software architect yet for architectural failure it could happen. If it does happen it would most likely happen in the US.

The other side and the other reason why I am embarking on this is that I am intrigued by the concept and application of ethics. Years ago I was a huge fan (my grandfather introduced me to the world of Candid Camera) of the TV show Candid Camera. One of their tricks was the 20 dollar bill on a string. Watching someone trying to catch that 20 without giving away to other people that they were chasing it was hilarious. It got me thinking, would I turn in money that I found?

Interesting answer – the boys and I found money the other day while walking. We tried to turn that money in to two different stores. Neither would take it. We ended up donating the money to Montgomery Hospice Kids. Why? Because we couldn’t keep it and it had to go somewhere we couldn’t give it back either.

Coming this weekend – ethics and software architects.

.doc

Scott Andersen

IASA Fellow.