Why Frameworks Aren’t a Body of Knowledge
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.
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.
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 some technical skill, 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 (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 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.
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 prescriptive 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:
- The variety of practice, consulting and success do not yet reflect differences in the background of the primary specializations (business, information, infrastructure, and software).
- 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).
- The value of architecture as a whole is not fully understood, thus all specializations suffer.
- 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 and professionalization 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. 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.