What is Architecture?

Welcome to the Data Architecture World blog. Every blog has to start somewhere so lets start by setting definitions. 

ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems, provides the following definition for architecture:

Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. This definition is intended to encompass a variety of uses of the term architecture by recognizing their underlying common elements. Principal among these is the need to understand and control those elements of system design that capture the system’s utility, cost, and risk. In some cases, these elements are the physical components of the system and their relationships. In other cases, these elements are not physical, but instead, logical components. In still other cases, these elements are enduring principles or patterns that create enduring organizational structures. The definition is intended to encompass these distinct, but related uses, while encouraging more rigorous definition of what constitutes the fundamental organization of a system within particular domains.

Here is my definition for Enterprise Architecture:

Enterprise Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their separate fields with minimal interference from each other. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed. An architecture must also incorporate trade-offs, aware that attempts to optimized every desired feature is not possible and can result in systems that do not function effectively.

Benefits of Good Architecture 

• Better Comprehension 
• Division of Labor 
• Greater Reuse, Less Redundancy 
• Greater Consistency across the Company and Industry due to Open Standards 
• Local Optimization of Orthogonal or Layered Code Leads to Global Performance Improvement 
• Possible Performance Gains Through Parallelism

What Constitutes Good Partitioning (separation of concerns)?

• Encapsulates common underlying technologies and design decisions 
• Clear Semantic Description 
• Minimal Coupling between Partitions 
• May Deploy on Different Systems 
• Can Tolerate Changes in Design Paradigms and Technologies at Different Levels

In all this an important principle is:

“Improving the development team’s ability [to make independent decisions] gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck. This leads to the satisfying rule of thumb that an architect’s value is inversely proportional to the number of decisions he or she makes.” — Martin Fowler