The future for ethics is not what can your company do. The future is what can YOU do!

Why are ethics important?

It is a question I have asked myself a lot over the years. The easy answer is that ethics are what bind us to the world we are in. For example, companies that don’t pay for other company’s intellectual property, don’t care about their employees much. Why leap to that conclusion? Simple. If you don’t care about another companies IP, why would you care employees IP? You wouldn’t. So, when you encounter a company that doesn’t pay for its software, do not walk away. Run away as fast as you can. Don’t look back, don’t stop at go, don’t collect 200 dollars just get away.

Who is responsible ultimately if you as a person are working in a situation like that? Is it you or is it your employer? I ask because frankly when I ask that question of younger people I get a different answer than when I ask people my age. I find myself agreeing with the younger view. It is your responsibility; your employer is trying to make money. If they are willing to cut corners to make money, you are responsible for what you do.

That said it is not cut and dried. There are accidents. Situations that exist in the wild that weren’t designed or accounted for. In those situations, you move into a gray area between right and wrong. Where wrong, not paying for software you use, using IP without permission or knowledge of the provider and so, you wander into a gray area. Where perhaps one person willingly copied something they shouldn’t have and that is now widely used. It’s a gray area in that the person did the wrong thing not the company. If, however, the use is widespread it is the responsibility of the company to stop the use of the illegal IP.

Sad.

Why is it sad? Companies and people need to be responsible. So far, many companies have demonstrated that they are not willing or able to be responsible and that is sad.

The same is true for managers. There are, just like in the situation of companies needing to be ethical, ethical behaviors for managers as well.

· Don’t judge employees on where they were. Judge them on where they are.

· Just because one person says something, even if they are your (managers) favorite it doesn’t make it true.

· Don’t promise something you cannot deliver.

· If you give vague guidance don’t expect clear results.

· If you DON’T say something to the employee directly don’t say something about the employee.

I have had the fortune of working for great companies (and companies that felt entitled to take IP from partners and other companies). I have worked for bosses whose ethics were beyond reproach and I have worked for front line managers who had no qualms about selling someone down the river.

In the end, you are responsible for what happens next. If where you work is using IP illegally (in violation of user agreements, copyright law, patent law) then it is your job to report it. If your manager is breaking the rules above, it is your job to get away from that manager. You see the situational ethics falls to the lowest common denominator which is always you.

It is not your job to end your career on the hill of fixing bad managers. You can’t. Bad managers who are willing to have squishy ethics are always going to rise in the organization. Just make sure you aren’t in their path when they fall back to earth.

.doc

IT Ethics thinker

Published: Draft 1 IT Architect Standards…

For those of you interested all that wandering around the concepts of ethics and architects led to the publication of the first draft of the code of standards for IT Architects (here).

There is also a more formal board of directors (of IASA) code of standards that will be adopted and published as accepted before we finish the draft code of standards now published in the ITABoK.

The BoD felt that they should adopt standards before asking members to do so. But thank you to everyone who sent me an email. or commented on the code of standards on Linkedin. Your thoughts, ideas and suggestions were incorporated as much as they could be.

Some of the suggested penalties couldn’t be embraced or well considered. We did start a new process where an IT Architect will be able to submit complaints to the ethics committee of the Board of Directors. We as I said before will also be incorporated a much stricter code of standards for members of the Board of Directors.

It has been a long Journey. I started working with IASA in 2005. During the ensuing 10 years I have watched a profession grow. I have seen the world around that profession change. The importance of software architecture and IT Architects hasn’t diminished.

The dawn of the IT Architect profession is here. Take a moment, read and comment on the code of standards. Eventually the IT Architect profession will adopt and embrace the standards of conduct. How you behave as a professional shows much to the world. IT Architects are critical components of what IT builds and delivers to the organizations of the world.

I am very happy that we have this draft out and again I thank everyone that emailed, suggested, argued and of course made fun of the initial thinking process.

.doc

Chairman IASA Ethics Committee

The three pillars of professional standards. And the ITABoK!!!!!!

Great email question yesterday. What is the best way for a profession to implement standards (and eventually move to a formalized code of ethics)? Well the easy way to have standards is to evolve the profession to the standards. IT Architecture and the nature of what IT Architects do lends itself to a number of standards.

The three pillars depicted here are great starting points. The first being Professional Knowledge. Then there are the various professional practices and finally the professional engagement itself. Those three pillars help a profession move forward.

The Board of Directors of IASA, is in the professional of adopting a code of standards for members of the board. By no means will the restrictive rules applied to the BoD apply to the members. But it is important to know that we aren’t creating rules without applying rules ourselves.

I have argued for years against the long help belief that people pay for what we know. I fought against the knowledge hoarding culture for many years. But frankly KM systems are difficult. For KM systems to work you encompass more than just process. You have to capture people and technology.

IASA has developed and continues to develop professional knowledge that is freely available. The ITABoK is located off the main IASA Site (iasaglobal.org) and is ultimately where the professional standards will live. We will be publishing the BoD code of standards on the ethics tab of the ITABoK as well as a more formalized professional code of standards in the next few weeks.

The evolution of the ITABoK adds professional and professional practices into an easily consumed format. It gives both IT Organizations and IT Architects one place to go for the what and how of IT Architecture. Practices and Knowledge in one managed place that is both peer reviewed, but open to submission. The birth of an IT Architect body of Knowledge. Now ITABoK has been around for awhile but the new V3 pushes us further and further into the capturing of knowledge and the practices of the profession.

Our last pillar is the reality of IT Architects. If, an IASA Certified or Open Group Certified architect appears at your door step and you decide to engage them what in the end do you get? More to come on this last pillar. Check out the ITABoK a growing repository of what is possible for the IT Architect profession.

.doc

ITABoK consumer!

Professional Standards for IT Architects

The IT architecture of an Enterprise is effectively a system of systems. The intent or goal of the system is to either achieve the mission of the organization or drive to profitability (make money) for the business.

IT Architects align technology with the mission of the organization. They live in many disciplines within the organization and spend time looking not only at how to better achieve the goals of the organization but also how to make things work better.

The standards against which IT Architects deliver are fairly straight forward. Matching the requirements of the solution (technology) to the needs of the organization (be it mission or market). In all cases referring back to the larger enterprise view of the organization to deliver solutions that Compromise a holistic enterprise view.

A holistic enterprise IT Architecture approach takes into account not only the impact of the single solution but the impact on the overall enterprise. Deploying a great ERP solution that requires significant network bandwidth may work, as long as your entire organization has the bandwidth required. There are many more ripples than bandwidth that IT Architects deal with. Bandwidth is just the first of many.

If only the decisions were this simple. Go left or go right. IT Architects have to balance the needs of any specific problem against the goals of the organization and the abilities and capabilities of the solution. There are fiduciary and roadmap responsibilities as well. A solution that fixes the problem of today, but will cost 10x its initial cost in two or three years isn’t a good solution. The IT Architect has to balance the standards of the IT Organization, The competitive stance and competitive value of the solution and the market, long term technology roadmaps and the specific needs of the business.

Now, also take into account time. IT Architects are asked to create solutions for the mission and business of an organization. Sometimes they are asked to reduce or remove the competitive advantage another organization has gained. In these cases the reality of time enters the picture. When your organization cannot preform at the level of a competitor you lose customers and market share. Or in the case of government or social agencies you end up with an overloaded system, If I can’t use your web site because it doesn’t function the way I expect, I call your telephone number.

IT Architect Standards.

• The role IT Architect does not have to be technology focused.
• IT Architects have loosely defined roles. Only loosely as we continue to add new roles to the overall definition. Business, Information, Infrastructure, Solution, Enterprise, Operations and Security are all disciplines within IT Architecture today.
• IT Architects build solutions that benefit the delivery of the mission or function of an organization or business.
• IT Architects must consider the impact of their solution on the enterprise, potential future markets, potential future costs and on the end users and customers of the system.

.doc

The foundation of IT Architecture–the standards we deliver to!

A strong foundation is what keeps the building from toppling over. The foundation for a profession is the standards. The better the standards the less likely the profession is to topple later. Again standards are not a code of ethics. A code of ethics is something a profession expects new members to accept and swear to. The profession IT Architect is not ready for a code of ethics. There have been a few attempts around the edges of the IT  Architect profession that have ultimately failed.

Standards answer the why question before you interact with a professional. You know your doctor will adhere to certain standards of care as they engage and treat you for an issue. The same is true for IT Architects. There are standards that all IT Architects regardless of discipline adhere to and deliver on.

I posted three yesterday. I later realized the first one is actually a description of the role IT Architect and not a standard.

• IT Architects are not technologists only. This is actually a description and not a standard. The standard is The role IT Architect does not have to be technology focused.
• IT Architects have loosely defined roles. Only loosely as we continue to add new roles to the overall definition. Business, Information, Infrastructure, Solution, Enterprise, Operations and Security are all disciplines within IT Architecture today.
• IT Architects build solutions that benefit the delivery of the mission or function of an organization or business.

These initial three standards are the building blocks upon which the foundation is delivered going forward.

.doc

building a foundation

Defining the Standards (well first three) of the IT Architect Profession.

Standards of conduct allow a profession to say “act within the boundaries of our profession.” while not a overall code of ethics the standards of a profession allow the profession to both govern its members but also to present itself to the world. We are IT Architects, that means you will see the following behaviors (list to be created).

As a note. The intent of these posts is to build the standards for the IT Architect profession. While the long term dream is to build and polish a code of ethics,. we first have to have standards for our profession.

A code of ethics can be difficult. It is something however that professions adhere to, call them a code or call them standards but they are the same. Sometimes they are hidden in a professional oath. But ethics are a component of what makes a profession a profession.

The standards of a profession are comprised of the ethics of the individuals. What they do when presented with something that isn’t defined. There are a number of psychological or moral dilemmas made famous by Kohlberg. What would you do if you came across a 20 dollar bill on the ground with no one around? What about 100 dollar bill? What about a dollar bill, knowing that you just passed a crying child that couldn’t pay for his ice cream because his dollar had fallen out of his pocket?

Hopefully as you find that dollar, it replaces the dollar you already gave the crying child.

The standards for IT Architecture are extremely interesting. First, because it is new in the sense that no one has documented the edges of the profession. Secondly it is interesting because well, I am an IT Architect.

• IT Architects are not technologists only.
• IT Architects have loosely defined roles. Only loosely as we continue to add new roles to the overall definition. Business, Information, Infrastructure, Solution, Enterprise, Operations and Security are all disciplines within IT Architecture today.
• IT Architects build solutions that benefit the delivery of the mission or function of an organization or business.

A wise man once wrote “I can see as far as I am willing to look.” Beyond where I am isn’t as clear as right next to me.

There are many more boundaries and edges to the IT Architect profession. The concept of standards will allow IT Architects to explain who and what they are.

More to come…

.doc

IT Architect Ethicist.

Professional Standards (the implementation of ethics)…

It is interesting in the end. First I realize that as I blog I use the phrase in the end a lot. It was pointed out to me. As I lay out the various components of a code of ethics it is important to denote the distinctions. So today we will talk a little about the difference between the types of ethics we have, the reality of ethics as standards and standards as ethics and finally a discussion of the gaps between personal, professional and social standards. (there are also legal standards that should reinforce one of the three as well). Reality is that as IT Architecture matures we will codify our ethics as professional standards.

Each of us operates with both a personal and a professional code. We add or layer additional social and legal codes on top of that. It is not a simple process to merge the four. The first thing is what we are building, there is the broad concept of IT Architects Standards. The way IT Architects act and operate within the IT environment.

The four parts that comprise a set of standards are detailed in the graphic. Best practices become guidance. Guidance become working standards and finally you have program or professional standards. This is not linear growth. Many things stop as best practices and never progress. Some things age out of program standards and never return. All of these are the balancing act that create professional standards.

Some of the code of ethics I have been working on really fit in the Best Practices area. They fit in that area between personal and professional ethics and standards. I act this way. IT Architects act this way. I am an IT architect therefore I act this way. Simple.

Reality though is that there can be gaps between personal standards and professional standards. You always hope that the persons personal standards are much higher. We don’t aspire to be seen as IT Architects we aspire to seen as human beings that are IT Architects. So how do you fill the gap?

That is a topic for a later blog – making standards (and ethics) actionable. For now we are discussing the gap. The easy gap to plug is the delta between personal and social standards and ethics. Yes we all prefer honesty. In all forms at all times but when someone doesn’t look good, we don’t tell them “oh my god you look awful.” Even though our personal standards focus on honesty, our social standards may include a few small moments of dishonesty.

.doc

Birding the gap between standards and ethics

Wandering the two trails presented to software architects. The ethics blogs continue….

Great question earlier on this blog about what about the concept of good enough. Beyond good enough what about the road not taken.

As we consider the concepts of ethics and software architects there are two distinct divergent paths. The easy way is to continue down the path that has been before. The harder way is to make the changes that will result in more efficiency and eventually a stronger solution.

It is the upgrade dilemma. I asked a few month’s ago and got a number of brilliant responses about responsibility beyond design. It has always been held that the software architect must be involved in the deployment of the designed solution. But is the architect responsible beyond that deployment? When the solution as designed is designed for a system that shifts to the left or right post deployment is the architect responsible.

Within a code of ethics are the boundaries of a profession. For software architects it is important to note that the first couple of boundaries have to do with removing personal bias. The drive reason for that is the potential that you will be bound to your solution for the rest of your career. Software Architects can end up having great careers on one success, or be see as failures because of one failure. That one solution can change your career and the perception of you as an professional.

You will notice in Draft 5 of the Code of Ethics for software architects there isn’t a mention of time. That the architect owns the solution beyond deployment. If you have gathered requirements without bias and selected technology without bias, you don’t own the solution after deployment. Unfortunately the success or failure of that overall solution you do own.

There are professions that live in the same reality as Software Architects. The what have you done for me lately and what did you do to me last time. I love American football. One of the things that the announcers always say really resonates for software architects. They always say “cornerbacks have to forget.” If they make a mistake and it costs their team 6 points, they have to line up the next time and play the game. That is what software architects have to do. If we make a mistake we have to own and move on. We have to have short memories.

The business may not have short memories but the software architect has to have a short memory. Own the mistakes that you make every time.

.doc

working through the ethics of the software architect profession…

9th post in the code of ethics for software architects series…

This represents the 9th blog in my series on a code of ethics for software architects and the profession of software architecture. There is also a Linkedin discussion you can find here. I now have a draft that includes 5 ethical boundaries for Software Architects. I don’t really have a swear to it as I join the profession code yet but that will come in time. The initial questions of why and what are answered. Why a code of ethics? Because software architecture is a profession that impacts every organization and business on earth.

The initial 5 will grow. Today we have guidelines about finding the requirements without bias for a solution and selecting the solution itself without bias.

There isn’t a simple piece of code however that will let us remove bias. That will require training and ultimately an adherence to a code. It is easy to pick what you know. It is hard to pick what you don’t know.

A code of ethics has to fit and ultimately define a profession. Certainly the how a profession operates lives in the code of ethics for that profession. What you do and why you do are much your personal ethics, In reviewing a number of codes from a number of organizations (and many more to go) I find three things are relevant.

1. The code cannot be so big it can’t be followed
2. The code cannot be written in such a manner (arcane) that it cannot be understood
3. The code must be shared in such a way that anyone can see it and use it

Some of the codes I’ve read are heavy into the jargon of that profession. That’s not a good thing. Practicing professions know the code and choose to adhere or ignore it already. Those beginning their career in the profession are the target audience anyway. From that I have found there are distinct rules about the what of a code ethics.

• The code must be written in standard English without professional jargon so that it can be easily translated into other languages.
• The code must represent the profession. A better way to say that is you have to be proud of your professions code.
• The code should never be something to hide behind.

I will end today with some initial thinking on removing bias. First off bias is a difficult thing to consider. You have to evaluate both the origin and the impact of your bias. It crosses two areas that make it difficult to mandate an action. Human Dynamics and Personal Skills/Knowledge are the two areas that it crosses. The architect profession values both aspects but bias is something we have to consider. How to remove bias…

.doc

Simple Architecture Movement

Mismatched Socks and Draft 5 of the Software Architects code of ethics…

The concept is simple, a mismatch. There are a few times I have appeared at work with socks like this by accident. It is a simple honest mistake.

So why, in an ethical blog series am I talking about mismatches? Because how people view the ethics of situation can be colored by the socks they are wearing.

Well not the socks. But the glasses can change not only what you perceive as ethical but also how you perceive ethical actions. Certainly you can overcome someone wearing mismatched socks to work occasionally. Mismatched ethics though can be a serious problem.

So let’s continue the clothes metaphor. There are men who wear undershirts and men who don’t. If you asked one about the other they would think it was strange and different. The same is true for ethics.

Software Architects spend a lot of time communicating. Getting to a point in a project with the ethical road sign to the left is a bad thing. The ethics within a team should never diverge. Establishing a standard within and on the team is critical for the software architect and project manager.

The team has to have a common and uniform code of ethics that they operate under. Establishing a code of common ethics is not the responsibility of the software architect. That is the responsibility of the overall profession “software architecture.” Knowing and understanding how the various steam members interpret the ethical boundaries is critical. Like mismatched socks you can have multiple interpretations of ethics. For example when someone wears mismatched socks to work by accident you can perceive them as rushing or hurried in the morning. Or if they do it several times you may perceive them as sloppy and that they don’t pay attention to detail. If they do it all the time they may be an iconoclast.

In all cases we perceive the socks as representational of the person. Ethics are the same way. It is important to remember that ethics are perceived differently by different people. Not wrong but different as software architects it is our job to connect those dots from a technical ethical perspective.

Draft Five 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 understand the values and opinions of my team and will work to support their goals and objectives within the overall solution (if possible). If not possible I will explain to them why.

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

The technical opinion of all team members will be considered during the technology evaluation period.

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

Industry and company specific ethics will be applied before requirements are gathered.

Comments are welcome!!!!

.doc

struggling with the ethics of blogging