The field of [adjective] architecture is still quite immature when compared to more established fields such as Accounting or Dentistry. This makes it difficult to observe and define consistent architecture roles across organizations and therefore is an issue that immensely affects an architect’s career. There needs to be broader acceptance of common terms.
In order to better understand an architect’s role, one should first fully understand the difference between logical and physical. For example, timesheets (or logging the number of hours worked by an employee) existed before computers. Over the years a timesheet may have been physically implemented differently – on pen and paper, a punch card, or a computer application. From a logical architectural view, the timesheet has NOT changed. From a physical architectural view, the timesheet has significantly changed. When architecting large solutions, the business is generally more concerned with the logical view.
One easy to understand metaphor: Logical = Music Notes and Physical = Orchestra.
Architectural role definition can be more easily understood in terms of logical and physical.
The Solution architect tends to work from a logical view and the Technical architect tends to work from a physical view – all for a particular program or line of business. Both Solution and Technical architects work across all or a subset of architectural domains (business, application, data, and infrastructure). In large organizations or programs (e.g. $100M+), the solution and technical architect roles may be performed by separate individuals.
Furthermore, both the logical and physical view responsibilities may be combined to individuals performing Business, Application, Data, and Infrastructure architect roles. The Business, Application, Data, and Infrastructure (or Technical as defined in TOGAF) architect works at both the logical and physical views for their respective architectural domains. For example, an application architect is responsible for both the logical timesheet and the physical timesheet implementation such as vendor ABC timesheet system. In this case, the Solution Architect is more in the role of coordination, as opposed to architecture definition, across the architectural domains.
One common pattern is the Solution Architect defines the logical application architecture while the Data Architect defines the logical data architecture for a given solution. In other words, the Solution architect may “outsource” pieces of the logical solution to be fulfilled by other, more specialized architects. The actual working relationships amongst architects depend on a myriad of factors such as business industry, business size and program size.
From a modeling perspective, the Enterprise Architect tends to work at the logical view for the purpose of shaping and choosing business strategies and investments. Additionally, the Enterprise Architect performs governance (manages business change) and manages enterprise debt to remove or shorten the gap between business strategy and execution. An Enterprise Technical Architect tends to work at the physical view (e.g. choosing an Enterprise wide technology such as an Enterprise Service Bus technology that all future solutions will use).
As stated previously, the same individual may wear different architectural hats depending on the size of the business or program. As size increases so does number of specialized architectural roles.