The development of a body of knowledge (BoK) is no small effort. At Iasa, we have been working to perfect a body of knowledge based on member accomplishments and contributions for over 10 years. We have been through many versions, although in the end we decided to set the official version number of this release to 2.

This body of knowledge is intended for any type of architect, at any point in their career. If treated as a framework, the ITABoK should be considered a people framework and not a process or artifact framework. For more on that see the requirements below.

The ITABoK is neither prescriptive nor limiting in the choice or use of any other framework, standard or technique except in such cases where their use limits the effectiveness and purpose of the practicing architect. For example, while an architect may, in some cases, be charged with management, the body of knowledge will not include that as a primary element of the professional practice (See HBR – No, Management Is Not a Profession).

Although an architect, software, business or otherwise, may at times fill another role in an organization or for a customer, the ITABoK ensures that Iasa professional architects have a clearly defined and separate value proposition. That is, the Iasa architect should not, for any signficant period of time, extensively overlap another role or profession. For example, an Iasa software architect would not be considered equivalent to a senior software developer or engineer, although they would have extensive experience in software development. An Iasa business architect would not replace or be equivalent to business relationship managers, or business managers, though they do have extensive experience in business. Instead, all Iasa architects are at their core, business technology strategists who may specialize in optimization of business, software, infrastructure, information, solution or enterprise technology strategies.

The ITABoK does not claim to be the only relevant definition for the practice of all architecture everywhere. Instead it should be seen as a comprehensive, cohesive and structured practice of architecture that guarantees levels of success at business technology strategy. Essentially, Iasa makes no claim that other practices do not work, simply that this one does work to maximize the value generated from technology in a business or customer setting. Where possible, the ITABoK seeks to be connected with other frameworks, bodies of knowledge and industry offerings such as TOGAF, Zachman, SAFE (Agile), COBIT, ITIL, etc. However, Iasa will not sacrifice cohesion and efficacy for that purpose.

Architect Body of Knowledge Requirements

A body of knowledge should fulfill a certain set of requirements to provide the basis for practice and competency. These requirements are based on the adoption of the BoK and the fulfillment of a clearly identified professional function for customers and society.

Descriptive Versus Prescriptive

A BoK should endevour to be as descriptive as possible without prescribing everything a professional should do or achieve. As much as possible should be left to the practitioners without limiting the value of the BoK. Instead the BoK should attempt to describe working practice within any common framework or process.

Skill-based Versus Process-based

Skilled professionals will create a successful architecture practice regardless of process or framework, while unskilled professionals will fail regardless of the quality of their framework.

A BoK forms the basis for competent practice in a profession and therefore should be capability (skill) based instead of being based on processes, methods or artifacts. A degree of method is required of course, but given the vast number of contexts architects deal with throughout their careers, it is a mistake to enforce a single proscriptive process to those environments. Trying to enforce a large framework on a small agile organization is as much risk as not having any relevant method at all. Throughout the ITABoK, we have attempted to keep the focus on the people as opposed to the process or artifacts while allowing for the benefit of using an artifact or method based framework.

Baseline For Specializations

A Body of Knowledge should be a foundation for all specializations within the field instead of a representation of a single specialization.

In today’s world each ‘type’ of architect treats their body of knowledge as separate. Many of our practicioners will describe a business and a software architect as fundamentally different. In many ways this is accurate. The day in and day out work of the differing types of architects is distinctly different. Unfortunately, however, in current practice, our customers do not make this distinction nor understand such nuanced definitions. A business architect and a solution architect must have a shared basis for communication and professional practice to meet the expectations of customers and employers and to effectively deliver on the full value of architecture to an organization.

Although the reasons behind this are continually debated, they boil down to the following:

1. The variety of practice, consulting and success do not yet reflect differences in the background of the primary specializations (business, information, infrastructure, and software).
2. The customer is not yet sophisticated enough to know when to request one type of architect versus another. (Imagine a customer requesting a surgeon when they need a psychiatrist or podiatrist).
3. The value of architecture as a whole is not fully understood, thus all specializations suffer.
4. The career path of specialists is sufficiently varied that there is a need to unify the skills first before further diversification.

Distinguish the Core Value of the Profession

A Body of Knowledge must distinguish a primary value proposition for the profession. While it is not commonly understood in our professional practice, architects of all types must have a primary value proposition to society and customers to be successful. This is well understood at a personal level with existing professions. For example, it is not necessary to clarify why one would use a building architect. Nor are accountants confused with medical doctors. One does not take their broken arm to an attorney. Each of these professions has distinguished their core value proposition independently from other professions and they have done so to the degree that lay people understand it. Unfortunately, architecture still suffers from an inability to agree on this value proposition. In many circles there is a constant struggle to define the one thing that all architects must do well. The BoK must successfully define this to be successful.

Iasa and the Requirements

As we said, Iasa members and thought leaders are fully aware that not all current architects will fully agree with our method of meeting these requirements. However, we feel confident that our answers to them justify the existence of this body of knowledge and are a valuable addition to the global population of architects. We claim that the ITABoK represents the single best instantiation of a professionals capabilities and does more to aid in the success of the profession than a single framework. For example, currently TOGAF stands as the most common form of architect certification and yet is meaningless inside of US government agencies (where FEAF is supreme) as well as many other types of companies and environments. Instead, the Iasa BoK allows for and encourages the use of both of these frameworks (or any others), if they are applicable, and we have created a BoK which can be used with any of them. In areas of incompatibility we simply ask that instead of complaining, you join us in creating an effective mapping and improve those areas of support.

Why IT Architecture Instead of Enterprise Architecture or Other

We realize the naming of the body of knowledge will turn off or repel certain architects. Many business or enterprise architects would prefer to be aligned outside of the IT department, and there is some evidence as to the veracity and value of that argument. The basis for the Iasa body of knowledge and practice is completely compatible with any reporting structure in existence. Some of our practitioners report outside of IT. Unfortunately, there are as many software, infrastructure and information architects who are repelled by the use of the terms enterprise or business architecture for the key definition of their professional body of knowledge. Thus we have been handed a difficult situation. Any term used before the term architect endangers adoption by at least one significant body of practitioners.

Why Not Multiple BoKs or Organizations

The simple answer is that the separation of architects within an organization appear to be a major risk to the pracitce of architecture overall. We have seen organizations on their 5th, 6th or 7th EA only initiatives. We have seen and researched organizations and teams, referenced by top analysts, book authors and seminal works such as, Enterprise Architecture As Strategy, fail for lack of a clear value proposition. By connecting architects to a single value proposition, which we call business technology strategy, we remove the amorphous and difficult to understand role that challenge the success of many organizations. It appears, at least anecdotally, that as long as all architects retain the core skills in business, in technology and in strategy, they are more successful (Note: Iasa is working with organizations to better prove this empirically).

Additionally, for repeatability in practice and for creation of a common value proposition to our customers, it is essential that the body of knowledge and the skilled architect have a unified set of foundation skills. These skills create common practice, capability and outcomes which our professional clients can trust. For example, if a body of knowledge does not contain at least some technical skills, then architects in that field will not be able to deal with complex technology strategies any more than standard business management. If the BoK does not include business skills or human dynamics skills then practitioners will be known only as technologists and not be able to deliver on complex business scenarios or business value. Thus we have chosen to keep for the time being the information and technology portion of the title to reflect that the vast majority (we estimate around 97% of current practitioners with the title) have a strong set of technical skills and in our surveys describe those skills as essential for success. This includes both the enterprise and business architects we have interviewed. Please note that this does not limit the ability of Iasa Certified Architects to engage effectively as business strategists but simply enhances their ability to play a key ownership role in that strategy.

We are aware that some members and architects will continue to disagree with this choice and ask only that you understand that it reflects both the current practice and what we see as essential in creating new generations of architects. The Iasa body of knowledge is deeply business focused but we cannot ignore our technology roots.

The Structure and Content of the Guide

The ITABoK has been designed to meet the most pressing demands of the individual architect and the architecture team based on information gleaned from our members.

It contains the following sections.