Why Apply Analytics to an Architectural Framework?
There are a couple of points about applying analytics when using an architectural framework. While you can use a number of architectural frameworks for analysis, we favor the Zachman approach. Our previous articles have distinguished a number of differences in architecture approaches. However, there are two critical points that favor the Zachman approach. One point is that you can take advantage of Zachman’s ontological structure to convert artifacts from other frameworks into the Zachman framework. The other point is that executives need various analytics to evaluate various architectural solutions that are better fits for the organization. Analytics are easier and more meaningful with the Zachman framework as the underlying organization of architecture components. By having the facts maintained in, and integrated into one place – the Zachman Framework provides the opportunity to apply analytics for discovery, diagnostic, prescriptive and predictive analysis using the architecture itself!
Architecture and Architecture Content
There is a lot of discussion about data mining, process mining, text mining, and so on. These techniques depend on searching content to discover, diagnose, prescribe and predict things about the enterprise. All of these techniques rely on having architecture to guide the searching. Data mining depends on data architectures; conceptual, logical and physical. Process mining depends on process flows that are part of the process architecture but the material for analysis comes from database logs which are dependent on the data architecture. Finally, text mining depends on documents and phrase-based models that are based upon business architecture or some subset that drives the searching.
There are two assertions that can be made about architecture and business analysis:
- You can perform analytics on the architecture itself. This uses techniques that analyze the structure represented by the architecture using discovery, diagnostics, prescriptive and predictive analytics. After that you can look at content of what is actually in the architecture. This is useful for analysis of the impact of change on the content. For example, we see what the impact of strategic change is, find the processes and applications that are related to the change, then, assess impact on the structure of the data models not on the content of the database itself. That comes later.
- Most analyses are focused on using the architecture to analyze content. Like looking at the furniture in a house and ignoring the structure of the house itself but using the structure to locate types of furniture like the sofas, chairs, and tables in the living room, beds, nightstands, TV in the bedroom etc. The equivalent is asking the question “How you find things in a database by using the structure (architecture) of the data?: The content is analyzed through the architecture and then some impact on the structure is identified backwards. Most navigation occurs through the architecture relationships to find some grouping of content often based on a keyword or phrase or data point as the focus of grouping. To find some grouping of text or quantitative content, an individual uses the relationships as defined by the enterprise architectural representation.
As an example, if you are looking through the lens of the Zachman framework analyze the meta-models of the framework by starting with the top 3 rows for the business view and then the bottom 3 rows for the execution view. Most architecture tools focus on the bottom 3 rows of the framework (implementation or construction models) and infer some things up to the top 3 rows.
The Structure (the Architecture) versus the Content of the Architecture
Our perspective is that architecture provides the fundamental structure of the enterprise, whereas, the content of the architecture represents the specific instances related to the operational aspects of the enterprise.
The Architecture is the Structure of the Enterprise
The architecture of the enterprise is defined and described by the relationships that exist in the enterprise. Most of this information is contained in the metadata (information about the data) of the enterprise. A pictorial characterization of the architecture might look like a high-level data model.
The Architecture Content is the Execution of the Architecture
The content of the architecture is the instances that occur when you populate the architecture itself. This is most obvious when looking at the data of the enterprise (i.e., data model). It is less obvious when looking at things like the process architecture. The process metadata of the flow includes the name of the flow and the attributes of the process flow (start time, connection from / to, participants who use content, frequency, participants, etc.) for each instance of the steps in a flow.
What Does All This Mean?
The value of one approach (structural) versus the other (content) depends on the problem.
When considering a merger, acquisition, consolidation or any other structural change, the value is in looking at the structure independent of the content. Whereas, if you are looking for specific things like correlating consumer buying habits then using the architecture to search content is more important.
Sometimes companies start with structure and sometimes with content. Whichever one an enterprise starts with eventually both are impacted and both need articulation. The good news is these can be done incrementally and updated incrementally. So a “big bang” project is not needed! So, you need to understand both ways of analyzing.
Most of the interest today is in short-term analysis that uses content to find things out. Long-term impact is with the structure of the enterprise, which translates to the architecture components themselves.
