This section of the BTABoK will examine two topics: ethics and principles. Ethics are the guiding values that help us make products and services for our market and customers; principles are the internal rules which guide us to efficient solutions for our organization. These are two complementary aspects, reflecting our external audience and our internal one.

With all the headlines of organizations misusing customer data, profiting off defective products, and executive criminality, the professional solution builders in the digital domain have an increasing obligation to establish and follow a common set of ethics. In so many cases, companies rush products – often digital – to market without adequate policies, technology safeguards, or external controls, to gain market share early even anticipating legal challenges later. Though there is a certain amount of risk inherent in any undertaking, the architect is often able to see this ahead of time and put in place appropriate mitigations. Whether there is a civil or criminal penalty assessed, the digital architect needs professional ethical standards to identify when initiatives and behaviors are not providing value to customers and the organization. These are often represented in a written set of guidelines circulated among the organization, and are socialized through training and open discussion, shared experience, formal job requirements, or even compliance requirements from outside the organization (for example, being part of a HIPAA covered entity or legal practice with confidentiality). IASA recommends having a set of ethics, posting them visibly, and educating all architects on their usage.

Principles, on the other hand, are the experiential rules we have learned as an organization to guide how we construct efficient solutions or how we try to frame decisions we come across repeatedly. They represent how the organization delivers the highest value to customers and what those customers see in our technology choices that enable them. These, also, are often represented as one or more lists of statements in prioritized order of decision-making. Many technology organizations need multiple sets of principles as they grow, and over time: for instance, a small IT department might need only one set of rules whereas a larger technology product organization might need overall enterprise/product architecture standards as well as solution architecture principles and customer experience principles. IASA recommends starting with a small set (8-10) of written statements on how the organization makes decisions and sees value in different areas and growing this over time.

In practice

In this section, show how to get started with a blank “canvas” and start writing up our ethics and principles.

Here’s how to do it.

No particular knowledge is required beyond a basic understanding of the organization’s culture and knowledge management practices. The canvas or tool we will use to capture either the statement of ethics or the principles is a simple list. The architect should call a meeting and have the group discuss the following sections, often in order first, and then with general discussion to revisit problematic areas:

  1. Identify key aspects of culture (as experienced by the group) – can be key words or phrases like “we act like a family,” “we aspire to be customer-centric”
  2. Establish the goal for either principles or ethics or both (possibly reviewing some examples)
  3. Brainstorm key principle/ethics titles – can be single words or phrases like “knowledge sharing,” “opt for lowest cost,” “in compliance wherever we operate,” “trustworthy,” or “predictable.”
  4. Split into smaller groups or individuals to write a short description for each – no longer than 50 words.
  5. Review the complete list and ask external organization members to suggest any gaps or unclear areas.
  6. Team reassembles to complete the version, and convert to a shareable graphic/web site/etc. for sharing with the broader organization.

This process should take a 2-4 meetings, some basic supplies (post-it notes, flip charts), some graphic communication technique familiarity (communications).

What are the pitfalls

There are three primary areas where writing down principles and ethics can fail:

  1. Other leaders do not buy-in to the principles and are not willing to practice them,
  2. The architects involved do not know how to implement the principles and cannot make them part of their personal practice,
  3. The socialization of tenets or ethics becomes a paralyzed process and potentially leads to arguments.

For the first pitfall, the architect may have only the options to not write down principles or leave the organization. For the second, a series of discussions with case studies or examples may be helpful. For the last, setting a timeline for the first version to be drafted, making sure the goal is understood by all participants, and meeting facilitation techniques are employed will often help.

Do note that the Dilbert cartoon strip and others which have their roots in modern corporate behavior often show antipatterns – both in ethics and tenets – which are both human and altogether common. These can be a useful way to start discussion without being perceived as either boring or negative.

Description

Ethics and principles do not generally depend on other areas of the BTaBOK and instead often inform those areas. In this section, we describe three examples: one set of ethics, and two sets of more technical principles.

Ethics

From the medical profession – one with a long history of ethics, which also help define behavior outside of self-interest – we have the Hippocratic Oath and Percival’s code of medical ethics. These define the relationship between the patient and the physician in areas such as diagnosis and clear communication, limits to advice and conflicts of interest, humane treatment and empathy, and knowledge sharing and accountability between physicians as a group of professional practitioners.

A working group of IASA-certified architects has developed the sample ethics statement below, with similar concerns as applied in information technology.

Architecture tenets

The EA perspective often blends this ethical obligation to external customers and stakeholders with internal business principles (how the organization comes up with solutions in a technical sense). The following set of principles was adapted from a council of global manufacturers to describe how solutions would be preferred.

In general, the understanding of these would guide architects towards selecting solutions which met #1 (safety [to human life], disaster resilience, and compliance) first. Then the second criteria would be evaluated, and so forth. If a solution or program did not meet the first three criteria (without exception), it would be rejected. This systems-level view added to a corporate culture (which had a strong ethical similarity between the manufacturers – a commitment to the customer), and provides a more day-to-day interpretation of how a group might align decisions. This also helped the architecture teams expose this thinking to the business units in order to be more predictable over multiple initiatives.

Solution architecture guidelines

This example example here is a set of principles from a high-tech manufacturer’s global IT team used to orient new technical or business architects. I would like to thank Jared Kunz for his original work here and discussions in refining this.

Agile Note: In many Agile Architecture @ Scale environments, guidelines are often called guardrails and are guided by the road mapping efforts as a part of program or solution releases.

Sample principles list for the business or technical architect: Understand and follow these (in no particular order): · The ISC2/CISSP Code of Ethics (abbreviated items, my favorites) o Protect society, the common good, necessary public trust and confidence, and the infrastructure. o Act honorably, honestly, justly, responsibly, and legally. o Provide diligent and competent service to principals. · The 10 Commandments of Computer Ethics (abbreviated items, my favorites) Thou shalt not use a computer to harm other people. Thou shalt not interfere with other people’s computer work. Thou shalt not snoop around in other people’s computer files. Thou shalt not use a computer to steal. Thou shalt not use a computer to bear false witness. o Thou shalt always use a computer in ways that ensure consideration and respect for other humans. · Strive to be a genuine servant leader · If you make a mistake, own up to it, where applicable, apologize, do your best not to repeat, if you repeat, seek help, remove yourself from the recurring situations. · Smile, laugh as appropriate, stay positive and have fun (within the bounds of ethics and laws). · Be curious, experiment – try new solutions but reduce the time required to validate the results. · Bring the best facts and the best data for the situation and your audience, know your audience. The facts and data speak volumes and often at much higher decibels. · Business Terms, Business Facts, Business Rules, can’t run a business without them, yet many leaders of business don’t even know they exist · A healthy business recognizes and values its information resources (data, applications, technology as well as people) and these resources are valued and managed like any other critical business resources. · The fundamental problem with “systems thinking” or looking at the world from a “systems” or “application” or “object” view is that processes and data are orthogonal. Processes, data are very free flowing, they cross many boundaries of systems, boundaries of what people want to draw lines around into “applications” so there are many better ways to manage processes and data than just “systems” and “applications”. Microservices, event driven, cloud, and continuous integration architectures are an answer to the limited way of “systems” thinking due to the complexity of processes and data flowing freely. · Aim to provide detailed designs to a majority of stakeholders at the last responsible moment: · When applicable, leverage the advantage gained by reasonably delaying some architectural decisions o Rationale – Additional information may become available, priorities may change. Avoid thinking you can predict the future and over-engineering the design. · Reduce or completely eliminate through your designs the amount of technical debt · Find the appropriate level of data, process and software coupling · Strive to design self-healing systems that can monitor/repair themselves · Design to limit propagation of failures with proper monitoring, alerting when failure propagation limits are difficult to design.

This list is more easily composed by a lead architect for his team or for his immediate customers. In lieu of organization-wide principles, the architect can still define some of his or her immediate environment and show themselves as technical leaders through example.

Iasa BTABoK Professional Tenets

The final example of tenets are those that the BTABoK team feel are important for the health of the profession and for best use of the BTABoK in your architecture practice. These principles reflect in many cases the attitude and culture of the architecture team as opposed to hard and fast rules.

The team has gathered principles which you will find throughout the BTABoK here in one place.

Just-In-Time Architecture

Just in time architecture is the practice of putting architecturally relevant decisions to the latest responsible moment and to do so with just enough objective evidence of their value to allow for high-speed delivery of systems and change. Just in time architecture is driven by practiced and experienced architects being assigned full time to any project or product as a part of the team and responsible for value and technology strategy direction. (Note: this must be handled carefully in very large architecture practices with multiple specialists and large projects).

Build Stuff and Own Stuff, Don’t Govern Stuff

Many architecture practices have taken on the role of governance, reviewer and in positive situations mentors. However, these teams always suffer from lack of value recognition and a lack of clear understanding of their contribution to the enterprise. Architecture is a creative function not an oversight process. The team must focus on innovation and delivery and allow for other roles to sink or swim with their decisions. Focus the team on building and areas where clear ownership of value can be achieved and avoid governance and review roles as much as possible.

Partner Role Empowerment

A truly mature architecture program results in empowerment for other business and technology roles instead of competition. The practice fulfills the niche of value management, technology value ownership and innovation and delivery focus with depth in digital strategy and delivery which by and large does not exist in organizations in a systematic and highly experienced way. The architecture team then does not attempt to oversee, govern or full the roles of other professionals but takes on a new role of business technology strategist deployed throughout the enterprise, with direct business and technology relationships.

Engagement Principle: The Customer Is Never Internal

The IT as a service model from years ago has littered business with thinking about the internal customer. This language confuses the definition of stakeholder with customer. The customer is always external. The user may be internal, the stakeholder may be internal, but the customer is always the customer. Technologists must change their language or forever remain order-takers.

Perspective

There are a number of organizations – both in the public good and commercial – who have advanced statements of ethics and principles, listed below. In this section, I am going to summarize an elevator pitch I heard consistently while at a major aircraft manufacturer. I asked the group of architects I was talking with how they prioritized principles and they almost unanimously replied with this simple statement, “We do:

First, what is right for our customer [to be safe, see value in our solutions, …]

Then, we do what is right for the whole of the company,

Finally, we look at what is right for our own work group.”

Ask around your organization and see what answers you might get. One of my own teams (which had had some ethical issues in the past) came back with a completely reversed order and I realized that we had a significant gap in our shared understanding of these core principles and how as a group we understood them.

IASA believes that architecture as a profession – not a role or an elevated engineer – should have long-term statements on ethics and principles, both to show the roles and professions around us how to work with us, and also to show that we take our customer and our customer’s customer seriously when it comes to the application of technology which now affects human health, welfare, culture, business, and society.

References and citations

For ethics, please take a look at the following examples and sources:

For principles, please take a look at the following examples and sources:

IASA Code of Standards

Pre Amble

IT architects preform mission and business focus roles within organizations around the world. The roles, solutions and problems solve by IT Architects impact the ability of organizations, businesses and government to deliver the critical services each provides.

Based on the value of IT Architecture this document contains the initial code of standards by which IT Architects are expected to build, deliver and document the solutions provided for the organizations they work for.

Canon I General Obligations

BT Architects should maintain and advance their knowledge of the art and science of IT Architecture, respect the body of BT Architectural accomplishment, contribute to its growth, thoughtfully consider the social and environmental impact of their professional activities, and exercise learned and uncompromised professional judgment.

1.1 Knowledge and Skill: BT Architects should strive to improve their professional knowledge and skill. Rule In practicing architecture,

1.101 BT Architects shall demonstrate a consistent pattern of reasonable care and competence, and shall apply the technical knowledge and skill which is ordinarily applied by architects of good standing practicing in the same locality. Commentary: By requiring a “consistent pattern” of adherence to the standard of competence, this rule allows for discipline of an BT Architect who more than infrequently does not achieve that standard. Isolated instances of minor lapses would not provide the basis for discipline.

1.102 BT Architects who have achieved an Architectural Certification (CITA – A, CITA – F and CITA-P) shall continue their education with the acquisition of a minimum of 10 hours of classroom training or 10 hours of contribution to the profession (contribute to IASA, BTABoK others).

1.2 Standards of Excellence: BT Architects should continually seek to raise the standards of BT Architecture, BT Architect education, research, training, and practice.

1.3 Natural and Cultural Heritage: BT Architects should respect and help conserve their natural and cultural heritage while striving to improve the environment and the quality of life within it.

1.4 Human Rights: BT Architects should uphold human rights in all their professional endeavors. Rule BT Architects shall not discriminate

1.401 In their professional activities on the basis of race, religion, gender, national origin, age, disability, or sexual orientation. IASA Code of Standards

Canon II Obligations to the BT Architects Client

BT Architects should serve their clients competently and in a professional manner, and should exercise unprejudiced and unbiased judgment when performing all professional services.

2.1 Competence: BT Architects should serve their organizations in a timely and competent manner. Rule In performing professional

2.101 services, BT Architects shall take into account applicable laws and regulations. BT Architects may rely on the advice of other qualified persons as to the intent and meaning of such regulations. Rule BT Architects shall undertake to

2.102 perform professional services only when they, together with those whom they may engage as consultants, are qualified by education, training, or experience in the specific technical areas involved. Commentary: This rule is meant to ensure that BT Architects not undertake projects that are beyond their professional capacity. BT Architects venturing into areas that require expertise they do not possess may obtain that expertise by additional education, training, or through the retention of consultants with the necessary expertise.

2.103 Rule BT Architects shall not materially alter the scope or objectives of a project without the organization’s consent.

2.2 Conflict of Interest: BT Architects should avoid conflicts of interest in their professional practices and fully disclose all unavoidable conflicts as they arise.

2.201BT Architect shall not render professional services if the BT Architect’s professional judgment could be affected by responsibilities to another project or person, or by the BT Architect’s own interests, unless all those who rely on the BT Architect’s judgment consent after full disclosure. Commentary: This rule is intended to embrace the full range of situations that may present an BT Architect with a conflict between his interests or responsibilities and the interest of others. Those who are entitled to disclosure may include a client, owner, employer, contractor, or others who rely on or are affected by the BT Architect’s professional decisions. An IT Architect who cannot appropriately communicate about a conflict directly with an affected person must take steps to ensure that disclosure is made by other means.

2.202 Rule When acting by agreement of the parties as the independent interpreter of contract documents and the judge of contract performance, BT Architects shall render decisions impartially. Commentary: This rule applies when the BT Architect, though paid by the owner and owing the owner loyalty, is nonetheless required to act with impartiality in fulfilling the architect’s professional responsibilities.

2.3 Candor and Truthfulness: BT Architects should be candid and truthful in their professional communications and keep their clients reasonably informed about the clients’ projects.

2.301 Rule BT Architects shall not intentionally Or recklessly mislead existing or prospective clients about the results that can be achieved through the use of the BT Architects’ services, nor shall the IT Architects state that they can achieve results by means that violate applicable law or this Code. Commentary: This rule is meant to preclude dishonest, reckless, or illegal representations by an BT Architect either in the course of soliciting a client or during performance.

2.4 Confidentiality: BT Architects should safeguard the trust placed in them by their organizations. Rule BT Architects shall not knowingly

2.401 disclose information that would adversely affect their client or that they have been asked to maintain in confidence, except as otherwise allowed or required by this Code or applicable law. Commentary: To encourage the full and open exchange of information necessary for a successful professional relationship, BT Architects must recognize and respect the sensitive nature of confidential client communications. Because the law does not recognize an architect-client privilege, however, the rule permits an BT Architect to reveal a confidence when a failure to do so would be unlawful or contrary to another ethical duty imposed by this Code.

Canon III Obligations to the profession IT Architecture

BT Architects should uphold the integrity and dignity of the profession.

3.1 Honesty and Fairness: BT Architects should pursue their professional activities with honesty and fairness. Rule BT Architects having substantial

3.101 information which leads to a reasonable belief that another BT Architect has committed a violation of this Code which raises a serious question as to that IT Architect’s honesty, trustworthiness, or fitness as an BT Architect, shall file a complaint with the National Ethics Council commonly known as the Board of Directors Ethics Committee. Commentary: Often, only an architect can recognize that the behavior of another architect poses a serious question as to that other’s professional integrity. In those circumstances, the duty to the professional’s calling requires that a complaint be filed. In most jurisdictions, a complaint that invokes professional standards is protected from a libel or slander action if the complaint was made in good faith. If in doubt, an BT Architect should seek counsel before reporting on another under this rule. Rule BT Architects shall not sign or seal

3.102 drawings, specifications, reports, or other professional work for which they do not have responsible control. Commentary: Responsible control means the degree of knowledge and supervision ordinarily required by the professional standard of care. With respect to the work of licensed consultants, IT Architects may sign or seal such work if they have reviewed it, coordinated its preparation, or intend to be responsible for its adequacy. Rule BT Architects speaking in their

3.103 professional capacity shall not knowingly make false statements of material fact. Commentary: This rule applies to statements in all professional contexts, including applications for licensure and Iasa BT Architecture.

3.2 Dignity and Integrity: BT Architects should strive, through their actions, to promote the dignity and integrity of the profession, and to ensure that their representatives and employees conform their conduct to this Code. Rule BT Architects shall not make

3.201 misleading, deceptive, or false statements or claims about their professional qualifications, experience, or performance and shall accurately state the scope and nature of their responsibilities in connection with work for which they are claiming credit. Commentary: This rule is meant to prevent BT Architects from claiming or implying credit for work which they did not do, misleading others, and denying other participants in a project their proper share of credit. Rule IT Architects shall make reasonable

3.202 efforts to ensure that those over whom they have supervisory authority conform their conduct to this Code. Commentary: What constitutes “reasonable efforts” under this rule is a common sense matter. As it makes sense to ensure that those over whom the BT Architect code of standards an architect exercising supervision be made generally aware of the Code, it can also make sense to bring a particular provision to the attention of a particular employee when a situation is present which might give rise to violation.

CANON IV Obligations to Colleagues BT Architects should respect the rights and acknowledge the professional aspirations and contributions of their colleagues.

4.1 Professional Environment: BT Architects should provide their associates and employees with a suitable working environment, compensate them fairly, and facilitate their professional development.

4.2 Intern and Professional Development: BT Architects should recognize and fulfill their obligation to nurture fellow professionals as they progress through all stages of their career, beginning with professional education in the academy, progressing through internship and continuing throughout their career. Rule BT Architects who have agreed to

4.201 work with individuals engaged in an architectural internship program or an experience requirement for licensure shall reasonably assist in proper and timely documentation in accordance with that program.

4.3 Professional Recognition: BT Architects should build their professional reputation on the merits of their own service and performance and should recognize and give credit to others for the professional work they have performed. Rule IT Architects shall recognize and

4.301 respect the professional contributions of their employees, employers, professional colleagues, and business associates. Rule BT Architects leaving a firm shall

4.302 not, without the permission of their employer or partner, take designs, drawings, data, reports, notes, or other materials relating to the firm’s work, whether or not performed by the BT Architect. Rule an BT Architect shall not

4.303 unreasonably withhold permission from a departing employee or partner to take copies of designs, drawings, data, reports, notes, or other materials relating to work performed by the employee or partner that are not confidential. Commentary: An BT Architect may impose reasonable conditions, such as the payment of copying costs, on the right of departing persons to take copies of their work

1.Consider the enterprise fitness of the client organisation to be your first priority.

2.Respect the rights, autonomy and freedom of choice of the client & stakeholders. Clarify what are client decisions, what are agreed and what decisions are yours to make

3.Avoid exploiting the client & stakeholders in any manner.

4.Practise the art and science of architecture to the best of your ability with moral integrity, compassion and respect for human dignity & society.

5.Protect the clients private information for as long as is appropriate

6.Strive to improve your knowledge and skills so that the best possible advice and treatment can be offered to your clients & stakeholders.

7.Adhere to the fundamental practices of architecture while acknowledging the limits of current knowledge and contributing responsibly to innovation and research.

8.Honour the profession, its values and its principles in the ways that best serve the interests of clients & stakeholders.

9.Recognise your own limitations and the special skills of others in the diagnosis, prevention and treatment of disease.

10.Accept a responsibility to assist in the protection and improvement of the client organisation and it’s surrounding ecosystem.

11.Accept a responsibility for maintaining and improving the standards of the profession.

Principles

Architecture is a profession not a role.

Architecture impacts health and human value, corporate fiscal interests and culture.

Architects get one major value proposition to society and business just like other professions.

Architects are(n’t) engineers.

Architects have excellent technology skills and focus on pure business.

Architects having good technology skills or experience has nothing to do with reporting to IT or elsewhere.

Architects must grow and retain both business and technology skills over time, we accept that other groups disagree with our choice.

Architects share some skills with other roles but serve a different purpose than any other profession.

Architecture is about value delivery over system delivery.

Meet them where they are

Up and Out Not Down and In

Form over Feature

ITABoK 3.0 by ITABoK 3.0 is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Based on a work at https://btabok.iasaglobal.org