Education / About IT Architecture  

IT Architecture

At times it seems there are as many different opinions about the role and activities of an IT architect as there are people who have heard of or practiced the role. There are thousands of conversations going on right now about this exact topic. In fact, many people attend their first IASA meeting in the hopes of discussing it. The canonical first IASA meeting is "What is IT Architecture".

The reason for this confusion is simple. Definitions arise from the sharing of common experience, yet no successful forum has been able to provide this for IT architects. A couple of organizations have tried but were unsuccessful for many different reasons. Simply put, most IT architects are completely seperated from each other. With a common ratio of 1/100 or even 1/1000 architects per IT staff, we just haven't had the opportunity to standardize our field. This is not a unique situation. The medical profession, the building architect profession and many others faced the same challenge at some point in their history. Take for example building architects, who didn't actually come together as a full profession until 1857 when a few architects got together and founded the American Institute of Architects. Check out the excerpt from their history.

Does this sound familiar?

The group sought to create an architecture organization that would "promote the scientific and practical perfection of its members" and "elevate the standing of the profession."

Until this point, anyone who wished to call him-or herself an architect could do so. This included masons, carpenters, bricklayers, and other members of the building trades. No schools of architecture or architectural licensing laws existed to shape the calling.

The first steps of this small group of 13 were to change the profession of architecture in the United States profoundly.

taken from : History of the AIA

As you can see, building architects were facing the same challenges IT architects face today, even though humans have been building structures for thousands of years! In all other professions part of the answer has been a member-based profession which is inclusive not exclusive. For example, how can you have an "Enterprise Architects only" association, ignoring completely the software or infrastructure architects? Where do the new enterprise architects come from? Does the stork just fly in full-grown experienced EAs?

One key objective of the IASA is the recognition of IT architecture as an independent and self-sustaining profession. This starts with the identification of the "commonality" between all IT architects, be they software, enterprise, infrastructure, data, business, performance, security, information or other. Until we define this common ground we will forever be separate and subject to the whims of our employers, the vendor community, the industry consortia, or other powerful bodies. For IT architects as individuals and professionals to have a seat at the table (be included and considered in industry trends and opportunities) we must see beyond our own current roles and find the common components of our field and particular specializations.


One of the benefits of building this association has been the ability to identify and unify common perspectives in the industry. The following sections identify some of these perspectives. Note: This is not the IASA's recommended approach. For more on the IASA recommended roles and activities see the Foundation Reference Model working group.


Common Perspectives

Regardless of specialty, some common perspectives amongst our members are emerging. Most IT architects appear to practice alone or in silos of twos and threes. Many are frustrated with not being able to find information dealing with their immediate issues at their current skill level. Many are unable to advance their careers directly as IT architects due to a lack of understanding of the role in their organization. Their organizations do not often properly characterize their value and they must spend massive amounts of time justifying their role and authority to both IT and non-IT staff. Many simply don't know what they don't know and have difficulty finding good resources. Most have an extreme amount of influence but very few direct resources (money, time, staff).