Treat enterprise architectures with a pinch of salt
Architecture applies to various aspects of software systems development, understandably so given its generic and flexible terms of reference. The classification of an architecture into a particular type may be obvious from its context and is, arguably, irrelevant to its success. Nonetheless, it can be useful to have an understanding of the breadth of the discipline - it may also help to put the subject of these essays into perspective.
Consider the various types of architecture that the IASA Glossary lists:
We won't delve too deeply into the definitions provided for each of these here but it suffices to say that they refer to each other, overlap greatly, create cyclic dependencies and are subjective in places. This is probably a fair reflection of how the term "architecture" is understood within the industry, albeit with the added complication of people not necessarily agreeing on which words to use for each term. The IASA terms offer valuable insight but are perhaps a little overwhelming as a starting point and don't (yet) offer a lingua franca for the discipline.
Within the field of software development, several forms of "architecture" are commonly referred to and, as such, form a good basis for a more philosophical consideration of what "architecture" might mean. Since they are perhaps the more universally used and provide good coverage of the information systems domain we'll explore them further and use them as a basis for our terminology.
The term "technical architecture" is a common first attempt to describe architecture but without the need to be specific about what type of architecture you're referring to. Therein lies a failing when using this term: it is too unspecific to be particularly meaningful when discussing a responsibility or project requirement.
Formally, a technical architecture can refer to any of the "architectures" that a system may have. It is thus
arguably a more general term than "architecture" which is commonly understood to mean "system architecture". Often
Thus it is recommended to avoid using the term "technical architecture" when attempting to define a specific area of architectural concern.
It may well be that the term "technical architect" is popular as it doesn't pigeon-hole its owner. It may also be that the term "software architect" doesn't sufficiently elevate the architect from the development team to their satisfaction. In either case, the authors believe that software, if done properly, is nothing to be ashamed of and that "software architect" offers a succinct, if not complete, description of the skills involved in the sort of hands-on architecture that we typically undertake.
"System architecture" refers to the way in which desired functionality is met by hardware and software components as well as how these components relate to each other and the intended users of the system. The term "architecture" is often generically used to refer to the system architecture, at least within the context of software systems development. The system architecture can span several different business functions.
Since the system architecture deals with the system as whole it naturally focuses on the system-wide design decisions and similarities. While it needs to consider the implication of these decisions for individual business functions it may not resolve them fully within each so as to move those decisions closer to where they are best addressed, namely the application architecture relating to each function.
"Application architecture" is really a subset of the system architecture. The scope of the application architecture, as opposed to the system architecture, is often determined by business function.
It is typical for the application architecture to be defined to a lower level than the system architecture, particularly as it needs to refine the system architecture to provide the design decisions that relate specifically to the business function rather than to the system as a whole.
Enterprise architecture is a term often mistakenly used by architects that work on "enterprise" systems or systems that involve components that are touted as enterprise-level. However, enterprise architecture is more concerned with mapping the business processes and needs to the technical capabilities of the organisation, including personnel, strategy, distribution and how the business' changing needs will be met.
The enterprise architect role is therefore extremely wide-reaching, being enterprise-wide, and requires careful inspection of all the business' functions and their strategic requirements. Many people may contribute to the enterprise architecture, but that doesn't make them responsible for it and thus doesn't make them enterprise architects.
It's worth being aware of the various types of architecture that are commonly mentioned, particularly within the context of your own organisation. Treat enterprise architectures with a pinch of salt - they are often just the system architecture or application architecture for some enterprise software.