The Skeptical Architect April 2014

SkepticalArchitectWhy Apply Analytics to an Architectural Framework?

There is a significant difference in architecture perspectives and analysis approach one uses for business improvement. Is it the structure the enterprise described by the architecture or the enterprise content maintained by that architecture?

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:

  1. 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.
  2. 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.

Share this post

Gil Laware

Gil Laware

Gil Laware is President/CEO of Information By Design, LLC, a firm who delivers consultative solutions for strategic, tactical, and operational management of organizations. He has over 30 years of consulting and industry experience with Fortune 50 companies He has experience in manufacturing, transportation, government, finance and banking services including business and IT strategic planning; business process management, redesign and improvement; data management; warehousing and business intelligence; enterprise resource planning; project management; manufacturing systems; and customer relationship management. Previously, he was an Associate Professor of Computer and Information Technology in the College of Technology at Purdue University, an Associate Director for Fujitsu Consulting, Manager of Data Services for Whirlpool Corporation, Vice President of Information Services for Franklin Savings Bank, held various managerial and consultative roles with the IBM Corporation, and was President of Management Support Systems. He also provides training internationally. Gil published with and has authored over 30 papers including a NIST chapter that discusses the gaps that exist in the manufacturing systems software development process. He served the DAMA International Education and Research Foundation (DAMAF). He may be contacted by email at

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept