Software Architecture vs. Data Architecture

Enterprise Architecture is not simply the composition of all sub-domain architectures, but the synthesis of them. 

From Wikipedia: In information technology, data architecture  is composed of models, policies, rules or standards that govern which data is collected, and how it is stored, arranged, integrated, and put to use in data systems and in organizations. Data is usually one of several architecture domains that form the pillars of an enterprise architecture or solution architecture.

The word software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations 

1. Data & Software Architecture are Different Architecture Domains 

Software Architecture and Data Architecture are separate architecture domains, with different concerns. Although not absolutely required, they should be integrated under the defining and governing umbrella of Enterprise Architecture.

1) Software Architecture Focal Point: If you are answering questions as to the performance or the detailed design of software that is software architecture, whether it is part of a single area or across the whole company.

2) Data Architecture Focal Point: If you are answering questions as to how information is stored, normalized, and joined together this is data architecture. Even meta-data falls into this category.

3) EA Scope: If you are answering questions as to how well the software integrates with the company's processes, its ability to change to a particular company's needs, and how this software fits within the context of the company's strategies, this is enterprise architecture. How the data fits within this context, who owns the data, how is it created (where does it originate) and how does it fit within business understanding, this is enterprise architecture. There are natural cross-over and the enterprise architect, from a sign-off, perspective takes responsibility for the overall architecture, but should be able to assign sign-off to the technical level architects to enable their decisions. 

2. Deep Connection between Data & Software Architecture 

While the techniques and artifacts of data architecture and of solution/application architecture are distinct, there's also a deep connection between state and behavior. The well defined and executed Data Architecture is a necessary prerequisite for well defined and successful software architecture. Addressing them completely independently would be unwise. 

Data and software architecture should be considered as integral components of an enterprise architecture strategy. Although many times the data architecture as it pertains to the flow of information through the organization to enable decision making (sometimes referred to as Information architecture) does not get much focus. So the check list may include:

1)     What role does business have in defining the enterprise architecture strategy so you don't end up such deficiencies?

2)     Or how does the business provide input to ensure that you don't end up in data silos? Why do so many companies end up with data silos even though they may have enterprise architects as roles?

3)     Does that mean the enterprise architecture strategy has simply not delivered on its promise? Or is there something about the way enterprise architecture is perceived within an organization that results in such situations?

3. Data and Software Architecture as two Different Aspects of EA  

Enterprise architecture is the integration of people, processes, and technologies. It touches the other sub-domain architectures and must be aware of them.

Data & Software architecture are two different aspects of EA, but they should reside under the same roof of the EA group. However, EA is new to many organizations and oftentimes, mis-managed. When not deployed correctly it leaves a bad aura and people are no longer embracing it. If you approach it comprehensively and actionably, silos will talk to each other. Know that you have in place before you gather them to talk.

 In most cases the software architecture would be an interplay of BIDAT (business, information, data, application, technology), though the emphasis of D (data), A (application), T (technology) dimensions at a point in time, could depend on several factors, including
• Extending software architecture beyond conventional boundaries, to integrate internally with other business units, externally with partners, service providers and others
• Coupling of several internal/external services to enhance software architecture.
• Flavors of Cloud: certain to extend conventional architectures, where data and integration plays an increasingly significant role

Therefore, data architecture and software architecture are two different sub-domains of Enterprise Architecture, but they are closely related, by managing them cohesively, enterprise can breakdown the data/information silo, to make business as a whole more effectively and efficiently.

Posted in: EA,Information/Data Management