What is infrastructure architecture?
architecture
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
architect:
The person, team, or organization responsible for systems architecture.
IEEE Standard 1421-2000 “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”
When talking with customers, a question that I am often asked is “What do you mean by infrastructure architecture?” The title “Architect” seems to be a popular one these days…even our own Bill Gates goes by the title. It seems that every company has a different definition for what an infrastructure architect is and what they do.
Architecture is the philosophy that underlies any system. It defines the purpose, intent, and structure of any system. Architecture is the discipline of addressing business needs with people, process, and technology. There are various perspectives or kinds of architecture, including business architecture, enterprise architecture, data architecture, application architecture, and infrastructure or technical architecture. Each of these disciplines has certain unique characteristics, but at their most basic level, they are focused on mapping solutions to business value.
Microsoft identifies three communities of architects: Enterprise, Solution, and Infrastructure architects. Enterprise Architects view the business as a whole and provides specifications to solution architects. Solution architects are generally focused on developing software based solutions to problems, within the scope provided by the enterprise architect.
Which brings us to infrastructure architects. Infrastructure architects take the requirements and constraints defined by the enterprise architect, collaborate with the solutions architect, and design the supporting environment for the solution defined by the solutions architect. They do this by specifying a top level design for a given solution, while adhering to a given set of constraints specified by the enterprise architect and the solution architect.
It’s important to note here that architecture is not engineering! Engineering specifies the HOW of the solution. For example, an engineer will be very concerned about how to create and manage a stripe set for a SQL server. An architect will be concerned with the need for that data to be highly available, and how the availability of that server ties into the larger data plan.
Architecture is also not product planning. Architecture is defined by its capabilities and services, not its implementation. If your architecture is defined by particular releases of a particular vendor’s software, then it is probably not architecture.
A great overview of this topic is the "Microsoft Architecture Overview" whitepaper, located here: https://msdn.microsoft.com/library/en-us/dnea/html/eaarchover.asp