While reading over the latest issue of Perspectives from the IASA, it struck me my current thinking about philosophy rings true for how I'm thinking about architecture, at least in one rather important aspect. You see, in considering all of the various philosophical systems developed over human history, it strikes me that there is no one philosophy that suits all people, at least not realistically speaking.

Sure, as a devout Roman Catholic and amateur philosopher myself, I do think, ideally speaking, that Catholicism is the best philosophy for all human beings. The problem is that, first, not all humans are philosophers. Second, and vastly more importantly, all philosophers and non-philosophers alike are humans.

As humans, we're made up of more than just plain ol' objective reasoning. Indeed, I rather think that we are first and foremost a bundle of nerves and emotions, and only a few among us even try to tame that bundle into something resembling objective and rational thought. Even those are still far and away subject to the non-rational whims of humanity, including prejudices, presuppositions, and all that other non-rational goo that makes us who we are.

This is why I say, realistically speaking, there is and can be no unifying philosophy that all humans can follow, as much as I might like for it to be otherwise. I think this much has proven true in that neither by force nor by argument has any one philosophy been able to subdue humanity in all our history, despite attempts at it by both the very strong, the very intelligent, and the very persuasive among us.

If this is true, what is then the best thing that we can do? Right now, it seems to me that perhaps the best thing that philosophers can do is to try to discover philosophies that are the best for persons with a given background, a given culture, and at a given time. I don't think this is the same thing as relativism because, first, we can still talk about the best objective philosophy for all humans (even if all humans will never follow it), and second, we can talk about an objectively best philosophy for persons of similar backgrounds, cultures, and times. We can still say that our philosophy is the best for humanity while realizing that perhaps the best for this person over here is another, given all the factors that have shaped him or her.

About now, my technical readers will be wondering when I'll get back to talking about architecture and how it relates to these ramblings, and, happily for them, here we are. The most recent issue from the IASA has several articles purporting what it means to be an architect, how to become an architect, and how best to educate for architecture, among other things. In reading these, I was struck (I should say again) that there doesn't seem to be one unifying idea of what it means to be a IT architect or how to become one.

Certainly, there are commonalities and core competencies, but I think that ultimately, the question of whether or not one can know if he is an IT architect (shall we say, the epistemology of IT architecture) and consequently whether or not you can tell someone else you are one, depends largely on the context of the question. Just as there are many different industries, company sizes, and corporate cultures, so it seems there should be many different categories of architects to match.

In an earlier blog post and article this year, I tried to throw out some ideas about what software architecture is and how we should be thinking about it. I still think that the distinctions I was drawing are valid as are the key differentiators between software architects and developers, and incidentally, I'd suggest that the distinctions are also valid for the infrastructure side of IT. It seems to me that the key defining aspect of an architect is the ability to tangle with both the business and the technology problems and effectively cut through that Gordian Knot, arriving at the best solution.

If so, then what makes a person an IT architect depends on the business at hand and the technology at hand, not on some presupposed host of experience with different businesses and architects. The issue I take with Mr. Hubert in his "Becoming an IT Architect" (IASA Perspectives, Issue 4) is that it sounds as if one must have visited all his "stations" in order to know one is an architect. While he starts out the article saying he is just recounting his particular journey, most of the article smacks of an attempt at generalizing his individual experience into objective truth, in much the same way that some philosophers have tried to draw out the best objective philosophy based on their own experiences and cultures. In the end, such attempts invariably fall flat.

Without digging into the specifics of the "stations" that I don't think are core to becoming an IT architect, let's stick to the central proposition at hand (which makes such a specific deconstruction unnecessary), namely that IT architecture at its essence is the previously described weaving of business and technology skill, with an admittedly stronger technical than business bent. If that is the case, there is no one definition for what it means to be an IT architect, nor is there consequently any one path to become one. With that in mind, reading Mr. Hubert's story is valuable in as much as one wants to know how to become a software architect at the kinds of companies, projects, and technologies that Mr. Hubert works with today, but it is only one story among many in the broader realm of IT architecture.

Rather than trying to establish some single architect certification that costs thousands of dollars and requires specific kinds of experience to achieve, we should think in terms of what it means to be an architect for a company of this size, with this (or these) primary technologies, this culture, and at this time in the company's life. Only within that spectrum can we realistically determine the best definition of an IT architect, much like there may be a best philosophy for individuals within the spectrum of particular backgrounds, cultures, and times.

Does this mean we can't talk about skills (truths) that apply to all architects? I don't think so. The chief skill is what I've already mentioned (solving business problems with technology), but perhaps we could say that all architects need deep experience and/or training in a technology (or technologies). Similarly, we could say that architects need training or experience in business in general (those concepts and skills that span different industries). We might also say that they need training or experience in particular industries, at least one. These individual truths combine to form something of an objectively best architect, but the specific best architect definition will vary depending on the context.

This kind of talk provides a broad framework for speaking about IT architecture as a profession while leaving room for the specific categories that could be specified to enable better classification of individuals to aid in both education and recruiting. We already have some of these definitions loosely being developed with such terms as "solutions architect," "enterprise architect," and "infrastructure architect." However, I feel that these may still be too broad to be able to sufficiently achieve an epistemology of IT architecture. Maybe "enterprise" is the best one among them in that it historically does imply a large part of the context needed to have a meaningful category within IT architecture, but I tend to think that "solutions" and "infrastructure" are still too vague and lacking context.

I don't propose to have the solution all worked out, but I do think that the key things, both in philosophy and software architecture, are to provide contextual trappings to determine the most meaningful solution to the problem at hand. If that means speaking of a software architect for a local, small, family-owned brewery on the one hand, and an infrastructure architect for a multinational, Fortune 500, telecom company on the other, so be it. But if we can generalize these sort of highly-contextual categorizations into something more usable for education and certification, all the better. Granted, we won't have categories that sufficiently address every meaningful variation (as is the case with all taxonomies), but as long as we're working forward with the necessary framework of context, I think we'll get a lot closer than many of the current attempts that result in over generalization (and thus lose meaning as categories per se).

In the meantime, I'd suggest that my assertion that the key distinction is in one's purpose (see the aforementioned article) is the best way to establish a basic epistemology of IT architecture. I think it is certainly sufficient for individual knowledge and broad group identification, though clearly more needs to be worked out to assist in the development of training, education, and certification that will feed into trustworthy standards in the various categories of IT architecture.