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

Animportant step toward defining IT architecture as a stand-alone profession is aclear definition of knowledge areas of the new discipline. A well-articulatedbody of knowledge will drive the recognition and growth of the discipline, andhelps ensure that the title of IT Architect is used only after the necessarycompetence is acquired and verified through formal qualifications which couldbe regulated by professional bodies. This article covers why an ArchitecturalBody of Knowledge is an important building block in professionalization of ITArchitecture and how the Microsoft Certified Architect (MCA) community drivesthe creation of Architectural Body of Knowledge (ArcBOK) through its SpecialInterest Group (SIG).

Architecture in IT

Systems inIT are becoming more and more complex, so it is no surprise that we arewitnessing 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 professiontries to solve.

Definingand designing complex structures is a common activity performed by almost everydiscipline, profession, and artisanship throughout the centuries. All thedisciplines of old discovered that skills and knowledge required for thecomposition of large complex systems don't match the skills that are requiredfor small bottom-up assembly activities. In IT, the same problem becamenoticeable about 10 years ago, and the gap between core engineering andhigh-level system design has grown ever since. Grady Booch's aphorism, youcan't build a sky-rise the way you build a doghouse, encapsulates the commondilemma facing high complexity, high interdependency, and low transparencyprojects: The sheer amount of detail required in complex compositions is sooverwhelming that a function of analysis, decomposition, and abstractionbecomes vital for the success of such endeavors.

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

The following is asample 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 andoften overlaps other professions or arts. It is understood and accepted thatone architect doesn't have and doesn't need to have a total knowledge ofarchitecture; interior designers, for example, will use a subset ofknowledge that is different from urban or landscape architects.

How doesthat translate to IT, where we have borrowed the name and title ofarchitecture? Our modern profession has not had centuries to diversify andevolve naturally. It seems that every high-complexity IT endeavor is now calledarchitecture 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 otherpersonal 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 theperspective of knowledge growth, the most important is the fourthcharacteristic—the ability to learn and improve. Let's look at the stages ofcompetence a person typically goes through as knowledge is internalized and putto use during daily work (see Figure 1):

Figure 1. Stages of competence

Beginner

A personthat is not aware of the existence or relevance of a certain skill area, oreven 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 theskill, so we can say that person is incompetent without knowing it.

A cohesivecollection of available knowledge areas for a profession would help beginnersidentify deficits, so that they can determine how to acquire the skills andbecome learners.

Learner

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

People atthis stage urgently need to sources of relevant knowledge and training. Areference index of learning resources could direct them to the best sources.

Apprentice

When acertain skill can be performed reliably and at will, the stage of consciouscompetence is reached. Apprentices need to concentrate to perform the skilldeliberately; the apprentice still lacks intuitive command of the skill. Theknowledge is gathered, but it requires practice to become "secondnature."

Concentratingand thinking about the skill requires frequent reminders and guidelines. A singlesource of information to help apprentices follow the steps, it would shortenthe time required to develop unconscious competence.

Expert

This is thestage 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 notconscious; this is the mastery stage when a skill starts to turn into art andthe expert can turn into a teacher.

Teachingsomething that has become second nature can be difficult. People who have beenexperts in specialized domains for a long time sometimes have difficultyexplaining basic concepts. A coherent study guide with rationale behind eachskill would also serve experts as a useful teaching aid.

IT Profession and Specialized Knowledge

ITarchitecture is gradually becoming a stand-alone profession, branching awayfrom engineering and software development. As a vocation and a prospectivecareer, it has its own specialized body of knowledge that will make itdifferent from other professions.

But havingspecialized knowledge is not enough if IT architecture is to become a respectedand sought-after discipline, on par with the other disciplines in computersciences. The title IT architect should be acquired after achieving a definedlevel of competence through practice and experience, proven through some sortof formal qualification, and perhaps regulated by professional bodies, whichwould then protect the reputation and code of practice.

Why suchrigor you may ask? With the every nascent profession, there is a risk of usingthe new terms—names, titles, or accreditations—without controls andverification. Currently, the title architect is used to describe everythingfrom distinguished engineers to developers, from senior consultants toexperienced sales specialists.

Figure 2. Facile model of the ArcBOK knowledge areas

Generally Accepted Knowledge

ITarchitecture is an emerging and quickly evolving profession, so there are manyareas that are not yet accepted as mainstream. An ArcBOK should focus onidentifying and describing all the knowledge and only the knowledge that isgenerally accepted in the architectural community.

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

"Generallyaccepted" means that the knowledge and practices described are applicable tomost projects most of the time, and that there is widespread consensus abouttheir value and usefulness. "Generally accepted" does not mean that theknowledge and practices described are or should be applied uniformly on allprojects; the project-management team is always responsible for determiningwhat is appropriate for any given project.

In the ITarchitecture we have another degree of complexity: There are many flavors ofarchitects, and more architectural subdisciplines sprout each year. Thegenerally accepted knowledge of a typical solution architect is quite differentfrom the generally accepted knowledge of an enterprise architect or securityarchitect. The ArcBOK should encompass all of these yet make a cleardistinction of which area is core and which area is supportive, depending onthe architectural subdiscipline.

The Body of Knowledge

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

IT evolvesso fast that capturing the architectural knowledge itself would make the ArcBOKobsolete even before it would be consolidated, reviewed, and published. Insteadof capturing and republishing the knowledge itself, the ArcBOK should become ametaknowledge reference base, with a complete 360-degree view of the referencematerial required to perform the job of IT architect adequately.

The processof building the ArcBOK should follow the consensus-building process, asking thecommunity and professional bodies for feedback and comments. It should bedivided and subdivided into knowledge areas, the major components of adiscipline, 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

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

Forexample, one core knowledge area for architects is design management. Ourexample divides the area into four competencies and lists the varioustechniques, frameworks, tools, and skills for each competency (see Figure 3).

Figure 3. Design-management knowledge area

This samplemodel is by no means verified or accepted by the community; it is just a teaserto gather momentum and invite the participation.

Potential Misuses

We havelooked into the benefits of having the ArcBOK as the daily reference forarchitects; it is also worthwhile to discuss potential misuses of suchknowledge collection.

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

Anotherforeseeable misuse is the premise that knowing ArcBOK would make someone anarchitect. We all know how common cramming for MCSE exams is, where candidatesmemorize useless information by heart just to pass the MCP test. The potentialpitfall of ArcBOK could be that candidates for MCA or other architecturalcertifications would cram the ArcBOK in hope that this would be enough to passthe review board. The ArcBOK should not become an "MCA for Dummies" guide andshould be very explicit about that.

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

Call for Action

As it wouldbe with any body of knowledge, building the ArcBOK must be a group endeavor,requiring the consensus of many practicing professionals, in IT architectureand 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 knowmore about the project, please register your interest by e-mailing me atmiha.kralj@microsoft.com. You don't have to be a certified MCA yourself; aslong as you have personal and professional interest in IT architecture, yourparticipation is more than welcome.

Why am Iasking for the registration of your interest? There are several ways that workon the ArcBOK could progress. The level of interest based on your feedback willdetermine 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

TheArchitectural Body of Knowledge is a big piece of work and requires strongcommunity support both to build and endorse it. The profession of ITarchitecture 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 verylittle effort.

Resources

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

About the author

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

This articlewas published in the Architecture Journal, a print and online publicationproduced by Microsoft. For more articles from this publication, please visitthe Architecture Journal Web site.