The Need for an Architectural Body of Knowledge

by Miha Kralj

Contents

Introduction
Architecture in IT
The Importance of Knowledge
IT Profession and Specialized Knowledge
The Body of Knowledge
Potential Misuses
Call for Action
Conclusion
Resources

Introduction

An important step toward defining IT architecture as a stand-alone profession is a clear definition of knowledge areas of the new discipline. A well-articulated body of knowledge will drive the recognition and growth of the discipline, and helps ensure that the title of IT Architect is used only after the necessary competence is acquired and verified through formal qualifications which could be regulated by professional bodies. This article covers why an Architectural Body of Knowledge is an important building block in professionalization of IT Architecture and how the Microsoft Certified Architect (MCA) community drives the creation of Architectural Body of Knowledge (ArcBOK) through its Special Interest Group (SIG).

Architecture in IT

Systems in IT are becoming more and more complex, so it is no surprise that we are witnessing the rise of a new profession in IT, loosely called IT Architecture. Let's ignore the name for the moment and focus on the problems this profession tries to solve.

Defining and designing complex structures is a common activity performed by almost every discipline, profession, and artisanship throughout the centuries. All the disciplines of old discovered that skills and knowledge required for the composition of large complex systems don't match the skills that are required for small bottom-up assembly activities. In IT, the same problem became noticeable about 10 years ago, and the gap between core engineering and high-level system design has grown ever since. Grady Booch's aphorism, you can't build a sky-rise the way you build a doghouse, encapsulates the common dilemma facing high complexity, high interdependency, and low transparency projects: The sheer amount of detail required in complex compositions is so overwhelming that a function of analysis, decomposition, and abstraction becomes vital for the success of such endeavors.

In the structural construction business, architects branched away from civil engineers and construction workers many centuries ago. They were (and still are) groomed, educated, and taught quite different skill sets than their engineering counterparts. If you would ask a civil engineer what a building is, the definition will focus on thickness of the walls, angle of the roof, sturdiness of beams and type of concrete required for house fundaments. Architects on the other side will describe the house as a wrapper around the living space, nested into the environment that allows the inhabitants to do whatever they intend to do in the house.

The following is a sample curriculum for a four-year structural architecture program of study:

• History and Theory of Architecture
• Building Design and Construction
• Materials and Methods
• Architecture Design
• Theory and Method in Architecture
• Structural Systems
• Site and Urban Design
• Space and Composition
• Types of Structures
• Preservation and Restoration
• Heating, Cooling, and Lighting
• Human Settlement Patterns
• Construction Estimating
• Project Planning and Feasibility
• Environmental Systems
• Architectural Internship

Obviously, the knowledge acquired throughout the study of architecture is diverse and often overlaps other professions or arts. It is understood and accepted that one architect doesn't have and doesn't need to have a total knowledge of architecture; interior designers, for example, will use a subset of knowledge that is different from urban or landscape architects.

How does that translate to IT, where we have borrowed the name and title of architecture? Our modern profession has not had centuries to diversify and evolve naturally. It seems that every high-complexity IT endeavor is now called architecture instead of engineering. In the words of Alan Cooper: "[nowadays] Web designers are called programmers, programmers are called engineers, engineers are called architects, and [true] architects are never called."

The Importance of Knowledge

According to Scott B. Parry, a competency is defined by four characteristics:

1. A cluster of related knowledge, attitudes, skills, and other personal characteristics that affect a major part of one's job

2. Correlates with performance on the job

3. Can be measured against well-accepted standards

4. Can be improved via training and development

From the perspective of knowledge growth, the most important is the fourth characteristic—the ability to learn and improve. Let's look at the stages of competence a person typically goes through as knowledge is internalized and put to use during daily work (see Figure 1):

Figure 1. Stages of competence

Beginner

A person that is not aware of the existence or relevance of a certain skill area, or even denies the relevance or usefulness of the skill, is called a beginner. Until of the beginner recognizes a deficit, it is not possible to improve the skill, so we can say that person is incompetent without knowing it.

A cohesive collection of available knowledge areas for a profession would help beginners identify deficits, so that they can determine how to acquire the skills and become learners.

Learner

A learner is aware of the existence and relevance of the skill; the deficiency in this area is often exposed through trying and failing to perform a missing skill and generates a thirst for knowledge. Ideally, a learner makes a commitment to learn and practice the new skill until the adequate proficiency level is met.

People at this stage urgently need to sources of relevant knowledge and training. A reference index of learning resources could direct them to the best sources.

Apprentice

When a certain skill can be performed reliably and at will, the stage of conscious competence is reached. Apprentices need to concentrate to perform the skill deliberately; the apprentice still lacks intuitive command of the skill. The knowledge is gathered, but it requires practice to become "second nature."

Concentrating and thinking about the skill requires frequent reminders and guidelines. A single source of information to help apprentices follow the steps, it would shorten the time required to develop unconscious competence.

Expert

This is the stage when a skill is used without a second thought, just like driving, swimming, or skiing. It becomes so natural that the decision to use it is not conscious; this is the mastery stage when a skill starts to turn into art and the expert can turn into a teacher.

Teaching something that has become second nature can be difficult. People who have been experts in specialized domains for a long time sometimes have difficulty explaining basic concepts. A coherent study guide with rationale behind each skill would also serve experts as a useful teaching aid.

IT Profession and Specialized Knowledge

IT architecture is gradually becoming a stand-alone profession, branching away from engineering and software development. As a vocation and a prospective career, it has its own specialized body of knowledge that will make it different from other professions.

But having specialized knowledge is not enough if IT architecture is to become a respected and sought-after discipline, on par with the other disciplines in computer sciences. The title IT architect should be acquired after achieving a defined level of competence through practice and experience, proven through some sort of formal qualification, and perhaps regulated by professional bodies, which would then protect the reputation and code of practice.

Why such rigor you may ask? With the every nascent profession, there is a risk of using the new terms—names, titles, or accreditations—without controls and verification. Currently, the title architect is used to describe everything from distinguished engineers to developers, from senior consultants to experienced sales specialists.

Figure 2. Facile model of the ArcBOK knowledge areas

Generally Accepted Knowledge

IT architecture is an emerging and quickly evolving profession, so there are many areas that are not yet accepted as mainstream. An ArcBOK should focus on identifying and describing all the knowledge and only the knowledge that is generally accepted in the architectural community.

What is "generally accepted" knowledge? The Project Management Institute in its Guide to the Project Management Body of Knowledge (PMBOK) defines generally accepted knowledge for project management in the following manner:

"Generally accepted" means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. "Generally accepted" does not mean that the knowledge and practices described are or should be applied uniformly on all projects; the project-management team is always responsible for determining what is appropriate for any given project.

In the IT architecture we have another degree of complexity: There are many flavors of architects, and more architectural subdisciplines sprout each year. The generally accepted knowledge of a typical solution architect is quite different from the generally accepted knowledge of an enterprise architect or security architect. The ArcBOK should encompass all of these yet make a clear distinction of which area is core and which area is supportive, depending on the architectural subdiscipline.

The Body of Knowledge

We need to be very precise with the definition of the ArcBOK: It should be the total sum of all available knowledge in the area of IT architecture, classified by the appropriate taxonomy of knowledge areas. Development and recognition of a core body of knowledge is essential to the development of the profession, accreditations, and university curricula.

IT evolves so fast that capturing the architectural knowledge itself would make the ArcBOK obsolete even before it would be consolidated, reviewed, and published. Instead of capturing and republishing the knowledge itself, the ArcBOK should become a metaknowledge reference base, with a complete 360-degree view of the reference material required to perform the job of IT architect adequately.

The process of building the ArcBOK should follow the consensus-building process, asking the community and professional bodies for feedback and comments. It should be divided and subdivided into knowledge areas, the major components of a discipline, or subfields of study.

The following example is a facile model of knowledge areas of the ArcBOK (see Figure 2):

• Design management—Activities related to requirements gathering, modeling, visualization, and communication of IT designs
• Analysis management—Activities related to analysis, deduction, innovation, creativity, and problem solving
• Delivery management—Activities related to project, engagement, transformation, development, planning, coordinating, and quality management
• People management—Activities related to leadership, organizational politics, stakeholder, and relationship management
• Strategy management—Activities related to defining the business intent, enterprise strategy, and road maps
• Financial and Legal management—Activities related to billing, sourcing, legislation, and procurement
• Life-cycle management—Activities that focus on various stages of the IT life cycle, including envisioning, SLA management, change management, and IT decommissioning

Each knowledge area should be divided into knowledge competencies, specific to that area, and each competency should get the list of resources available.

For example, one core knowledge area for architects is design management. Our example divides the area into four competencies and lists the various techniques, frameworks, tools, and skills for each competency (see Figure 3).

Figure 3. Design-management knowledge area

This sample model is by no means verified or accepted by the community; it is just a teaser to gather momentum and invite the participation.

Potential Misuses

We have looked into the benefits of having the ArcBOK as the daily reference for architects; it is also worthwhile to discuss potential misuses of such knowledge collection.

The most obvious misuse of ArcBOK would be the idea that someone must know everything that is in the book in order to use the title architect. You can imagine abuse scenarios, such as being denied a promotion by a small-minded manager because you didn't demonstrate a competency from a remote subdiscipline, or being required to cite whole passages from the ArcBOK during an interview as the proof of architectural knowledge. Such misuse is happening with PMBOK, so it would be naïve to think it couldn't happen with ArcBOK.

Another foreseeable misuse is the premise that knowing ArcBOK would make someone an architect. We all know how common cramming for MCSE exams is, where candidates memorize useless information by heart just to pass the MCP test. The potential pitfall of ArcBOK could be that candidates for MCA or other architectural certifications would cram the ArcBOK in hope that this would be enough to pass the review board. The ArcBOK should not become an "MCA for Dummies" guide and should be very explicit about that.

Putting any sort of measuring scale on top of ArcBOK would be another potential misuse. The knowledge areas are diverse and nonrelated, it would be wrong to evaluate and average competencies against a unified scale—"I'm 4 in Modeling and 2 in Trade-off Analysis, so my average architecture index is 3" would not be a useful measure of anything.

Call for Action

As it would be with any body of knowledge, building the ArcBOK must be a group endeavor, requiring the consensus of many practicing professionals, in IT architecture and related professions. The MCA community has formed a SIG to work on ArcBOK. If you are interested in participating, have an idea or would just like to know more about the project, please register your interest by e-mailing me at miha.kralj@microsoft.com. You don't have to be a certified MCA yourself; as long as you have personal and professional interest in IT architecture, your participation is more than welcome.

Why am I asking for the registration of your interest? There are several ways that work on the ArcBOK could progress. The level of interest based on your feedback will determine which course we take:

• If nobody is really interested, aside from a few architects inside MCA community, we'll continue our slowly progressing work by emailing the drafts to each other.
• If there is interest to read and use the ArcBOK but not to participate in its creation, a blog or some other form of publishing the work-in-progress will be considered.
• If there is indication that many enthusiasts would like to add their opinions and gathered knowledge, a wiki or similar collaborative tool will be launched to support the effort.

Conclusion

The Architectural Body of Knowledge is a big piece of work and requires strong community support both to build and endorse it. The profession of IT architecture must compose such work sooner or later to raise the quality bar. When the time is right, all pieces of ArcBOK should come together with very little effort.

Resources

"Just What Is a Competency?" Scott B. Parry, training material, 1998.

About the author

Miha Kralj is an architect in the Industry Solutions Group, part of Microsoft Enterprise Services organization. His consultancy tenure started in Europe and extended to South Pacific where he worked as a solution architect and enterprise strategy consultant. He has infrastructure background and is a certified MCA architect. E-mail Miha about the ArcBOK at miha.kralj@microsoft.com.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.