What "Architecture" Is Not

One of the long-standing difficulties in the enterprise architecture space - in practice, the literature, and in the blogosphere is agreement on what "enterprise architecture" is specifically defined as being. That's one of the reasons I keep an unedited list of attempts to define EA on this blog as I come across them to gather more perspective on this conundrum.

In fact, the whole concept of "architecture" within IT is muddled - there are "system" architects and "data" architects and "infrastructure" architects. On top of that, there are "application" architects and "solution" architects (primarily offered by software vendors and consulting firms). In the blogosphere, there have been a number of attempts to get traction around the concept of "business" architecture, which personally strikes me as redundant to EA but may turn into a legitimate discipline in its own right. As always, time will tell.

Part of the reason "architecture" as a whole gets a bad rap within IT and the business is because without definitions that can be embraced, it's difficult to set goals, expectations and outcomes to measure the value "architecture" activities and deliverables provide to an organization. If these attributes are not set or not in alignment with all of the beneficiaries of the efforts, it's easy and common for those disappointed or disagreeing with the concepts to point fingers at "architecture" as "ivory tower" or the overwrought "enterprisey" meme. I can't really say that I blame them for feeling that way.

So, I've decided to take a counterintuitive approach to the the definition of what "architecture" is in the above-mentioned forms and make some assertions on what "architecture" is not:

• "Architecture" is not playing "framework bingo" with Zachman, TOGAF, FEAF, DODAF, or other established enterprise architecture frameworks. The frameworks provide interesting and comprehensive rigor to areas and processes of interest, but are not the whole that drives well-thought-out and actionable processes, infrastructure, and capabilities that support business.
• The manner in how an "architect" makes one's living - as a consultant, an academic, or as an employee - is irrelevant to the depth, quality, or value of a produced "architecture." Last I checked, employees change jobs as frequently as consultants do. So much for longevity being a key characteristic of good "architecture."
• "Architecture" is not development-centric, although developers are a key constituency of its processes and output. There are many constituencies of "architecture" efforts, and all must get their proper due. Those that don't, be it business or technical, are the ones with the greatest disappointments in such efforts.
• The use of platitudes such as "strong technical leadership" and 2.0-anything with respect to "architecture" are just that - bromides with little substance. "Strong technical leadership" by itself never solved a business problem or issue, and at the end of the day, solutions to those problems are what we're here for.
• "Architectures" that do not address business needs, strategy, capabilities, processes, costs, and other issues are not architectures. They can be lots of other potentially useful things, like business analysis or data models as examples, but they usually aren't architectures.
• "Architectures" that are not actionable by others in the scope of their work within an organization are not architectures, they're academic exercises, mandates, musings, or wishful thinking. In other words, a waste of time and resources within a business.
• Software developers and business analysts are not "architects" doing "architecture." They're writing/testing code and performing business analysis, respectively.
• There are a lot of books on "architecture" and the various conjugal forms such as enterprise, data, system, IT, etc. Any worthwhile book with "architecture" or "enterprise architecture" in the title must take a firm stand on the definition of "architecture," whether or not readers agree with the definitions. Those that don't, for example one in particular with "practical" and "enterprise architecture" in the title, are pure crap and must be avoided.
• Software toolsets that support the production of "architecture" artifacts are fine, but they are not, in and of themselves, an "architecture" nor are they absolutely required for the production of the artifacts of  "architectures."
• "Architectures" touted as silver bullets or some other form of IT or business salvation that promises results at the speed of fast food drive-thru service usually have a number of serious flaws that eventually make themselves apparent. There are many valid ways to accomplish architecture-related tasks that take into account the exceptions and nuances each organization has as part of its operations and culture. "Architectures" evangelically touted as the only way to 'do things right' should be viewed with deep skepticism.

I'm certainly interested in the viewpoints of others on this - as I mentioned, I went about this exercise from the "what architecture isn't" angle, but if anyone who hasn't already wants to take it from the "what it is" angle, that would be great too...