Introduction
With 24-hours a day, unceasing news being forced in our ears and down our throats, with computers that blog, phones that text and everything that twitters, we have information rushing back and forth at us at speeds that can only be measured in nanoseconds. It is information on steroids and it can and often does get us in trouble [1]. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.
Most likely, many Modern Analyst readers have recently participated in a typical meeting to discuss something on architecture–the Enterprise Architecture or the Business Architecture, for example. During the fast paced delivery of information in the meeting, the presumed architectural artifacts are presented, discussed and analyzed, but rarely does a meeting participant question the authenticity of the artifacts. It is usually assumed that the artifact under analysis is architecture simply because the presenter said “this is architecture.” Considering the overwhelming number of meetings required for attendance along with all of the voicemails, texts, tweets, and emails required for review, many participants just accept the presenter’s declaration, “this is architecture.” But is the artifact presented for analysis really architecture?
Just about everyone knows the difference between a word document and a spreadsheet. For example, if a meeting presenter refers to an artifact as a spreadsheet, but its appearance is similar to the pages and text of this article, numerous meeting attendees will call the artifact into question and demand an explanation. And if an artifact with rows/columns of numbers and calculated results is presented and referred to as a spreadsheet, most will accept the artifact as genuine. However, a few meeting attendees may want to see the actual spreadsheet in order to validate the calculations, formulas and results of the information presented in the spreadsheet; and this is a good thing!
Now, what will happen later in this very same meeting if an artifact is presented and referred to as architecture? ………… Most likely, no one attending the meeting will question the artifact’s authenticity or validity; and this is NOT a good thing! What should a knowledgeable and learned Business Analyst do in this situation? Most everyone understands word documents and spreadsheets, but sadly, very, very few really understand architecture! Hence, this explains the reason for the casual acceptance from a presenter who proclaims that an artifact is architecture
So, what is architecture really about, and not about?
As an engineering discipline, legitimately understanding architecture will require some rigorous study of its definition and context, along with some examples or illustrations of architectural artifacts. Obviously, one cannot just “tweet” architecture! However, this article will concentrate on just three essential precepts of architecture that are easy to remember:
- An architecture is NOT physical [2].
- An architecture is an abstract idea or concept [3]
- An architecture description documents an architecture [4]
The reader must not simply limit their research on architecture to these three essential precepts, but rather use them as a starting point for learning about architecture. Depending on the architectural experiences of the reader, the veracity of these precepts may seem unclear. However, the reader is asked to keep these three precepts in mind throughout the discussion in this article.
The following text will first present prominent, notable and well-known references briefly expounding upon the aforementioned precepts. Careful examination of these references along with the descriptions of these essential precepts is a must! Hopefully as the article progresses, the reader will see how the various references and precepts come together to help one understand architecture in the context of an enterprise.
What is the definition of architecture?
For those beginning the journey in architecture, studying and analyzing the IEEE definition of architecture is an excellent starting point. IEEE, pronounced "Eye-triple-E," stands for the Institute of Electrical and Electronics Engineers. IEEE is the world's largest professional association dedicated to advancing technological innovation and excellence for the benefit of humanity [5]. Since the IEEE develops global standards in the field of information technology [6], it provides the foundation for this article’s discussion on architecture. To refute or to renounce this reference rejects the IEEE’s worldwide acceptance as a formally recognized international standards organization. Using the IEEE as a reference for information on architecture can reasonably eliminate most of the misinformation and hyperinformation surrounding this most interesting subject.
The Systems and software engineering - Architecture description ISO/IEC/IEEE 42010:2011, defines architecture this way:
- fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution [7]
1st Essential precept - An architecture is not physical
While the IEEE 42010:2011 definition of architecture just stated above is a very concise statement, one may find it hard to clearly and precisely understand and apply; and without some context even more difficult. Therefore, the reader is encouraged to carefully study the supporting information presented by the IEEE in the Frequently Asked Questions (FAQ). On this web page, question #5 asks, “So, what is an architecture?” and it provides the source of the definition above. The reader is also encouraged to carefully study the bulleted information following the definition and to pay particular attention to the last bulleted comment which is stated below:
- Finally, there are some things that an architecture definitely is not. An architecture is not merely the overall structure of physical components that make up a system. While physical structure can be fundamental to a system, it need not be [8].
This is a great place to start one’s understanding of architecture. In this bulleted item is a most enlightening and critical point. And this is where some of the confusion about architecture usually begins. Many see the “physical components that make up a system”--the physical aspects of the finished product, the implemented system or the enterprise--and innocently assume that “it” is the architecture. “It” is not architecture, but perhaps “it” is the RESULT of architecture.
2nd Essential precept – An architecture is an abstract idea or concept
The essential precept that architecture is a conception is also referenced in the second bullet of question #5 and is stated below:
- An architecture is a conception of a system – i.e., it is in the human mind. An architecture may exist without ever being written down [9]……………………….
As one can discern, the fact that “architecture is a conception of a system” reinforces in a way the first essential precept that an architecture is NOT physical. But, how does one describe or communicate architecture information? And, what are the concrete work products used to express the conception of a system so that one can share it with others? These answers lie in the third essential precept of architecture.
3rd Essential precept - An architecture description documents an architecture
Question #4 posed by IEEE in the Frequently Asked Questions (FAQ) asks, “What are the main contributions of the Standard?” A review of this link discovers the key to describing, communicating and sharing architecture information. It states in the second bulleted key tenet on this web page:
- that an architecture description documents an architecture [10];
And to better understand this essential precept and the rationale supporting the definition of architecture, one needs to refer back to the question #5 in the FAQs. Near the bottom of this section, just above the last paragraph is a reference that explains, “For further discussion of the definition, see [Defining architecture].” A click on this link presents more on the definition and discusses its rationale. Near the bottom of the second page of this link (or maybe the top of the third page) the reader will find two enlightening and critical paragraphs that may clear up some confusion about architecture.
Under either philosophy, an architecture is abstract — not an artifact. The Standard uses another term, architecture description, to refer to artifacts used to express and document architectures.
Alas, there is widespread usage of the term “architecture” which confuses the abstract idea with the artifacts capturing that abstraction—particularly in the field of enterprise architecture [11].
An architecture description relates to the abstract concept of architecture; however it does not represent a physical component of a real object or the real object itself. The architecture description is a fundamental element that is predefined and independent of a real object or an implementation.
Seeking clarity on architecture
The reader is asked to consider the following. In a metaphorical context, the fundamental elements just described in the IEEE definition are primitives, just like those found in Mendeleev’s Periodic Table of elements. For example, hydrogen and oxygen are both examples of atoms—primitive elements—found in Mendeleev’s Periodic Table. In their natural state on earth, each is a gas, but when combined to form water—a composite molecule made of two hydrogen atoms and one oxygen atom or H2O—it is found on earth mostly as a liquid, but also as a solid and a gas. Obviously, water is not found in the periodic table since it is a composite molecule consisting of two primitive elements. The behavior of these two gaseous atoms is independent of one another and of the water molecule. All atoms are unique in Mendeleev’s Periodic Table of elements and found only once, not unique in the numerous composite molecules such as water, in which they are found on earth. In the same context, an enterprise architecture description—a primitive element—is independent of its physical implementation. It is therefore, unique in the enterprise; not unique to how it is implemented in the enterprise.
Unfortunately, it is true that the confusion and misinformation just described about architecture exists, and that is why it is necessary to focus on the three essential precepts of architecture that are easy to remember. Further down in the web page at [Defining architecture] located in the gray area, is a reference to a most instructive 8-page article written by John Zachman in 2007 titled, “Architecture is Architecture is Architecture.” On the first page of this article, Zachman states under a picture of the Roman Coliseum, “The Roman Coliseum is NOT Architecture. The Roman Coliseum is the RESULT of Architecture.” In the next paragraph, Zachman goes on to say, “Architecture is the set of descriptive representations that are required in order to create an object. If you can’t describe it, you can’t create it [12].” As the reader can verify, the IEEE definition along with its rationale and this Zachman article are in accordance.
This critical perspective is not assumed from an isolated comment, but one that is clearly reaffirmed in the IEEE FAQs. Question #7 asks, “Isn’t the architecture of a system its top-level structure?” In the indented section below the first paragraph in this link, one finds another reference to the “non-physical” nature of architecture in the first of two principles of the IEEE Standard [13].
(I) The fundamental concepts of systems are increasingly non-physical and increasingly removed from what has been traditionally called "structure"……………….
(II) All architecture views of the system are of equal importance. The Standard does not assume that a physical-structural view is primary or that it can be used to derive other views or properties of the system.
Following just below the indented paragraphs is another provocative question, “What is the architecture of the Internet?” and these points are presented below for analysis:
“A short reflection should convince you that the fundamental, unifying organization of the Internet is neither its physical structure nor its software structure. Both are quite volatile. Rather, the enduring, organizing elements of the Internet are its protocols, especially IP and its key routing concepts. From IP and the routing concepts, one can infer a great deal about possible network structures, limitations on possible services, and much more. However, from the momentary physical, or even software, structure, one can learn very little about the fundamental nature of the Internet [14].”
The problem with defining physical structures as architecture lies in their volatile nature and how difficult they are to change and maintain once they are created. Think of a laptop once it is physically manufactured. If a manufacturer decides to build up inventory according to a standard product configuration or base laptop item, how difficult is it to modify the laptop to meet a meet a wide variety of specific customer requirements AFTER it is built? Since it is already built and sitting in inventory, the manufacturer must pull the item from finished goods inventory, disassemble the laptop, make changes according to specific customer requirements and then reassemble the laptop. These extra activities are inefficient and costly.
It is better to design the laptop with the ability to assemble the desired product with numerous options, specifications and features that meet a wide variety of specific customer orders. Then build/assemble it once AFTER order placement, rather than disassembling, modifying and reassembling the base product subsequent to order placement. The manufacturer can then manage all product components/parts in inventory and build/assemble the product AFTER the customer places the order with all their specific requirements. This approach is referred to as “mass customization” and it is defined as follows:
Production of personalized or custom-tailored goods or services to meet consumers' diverse and changing needs at near massproduction prices. Enabled by technologies such as computerization, internet, product modularization, and lean production, it portends the ultimate stage in market segmentation where every customer can have exactly what he or she wants [15].
In the “mass customization” approach, the product is engineered and designed so that it can get manufactured and assembled with numerous options, specifications and features that meet a wide variety of specific customer orders. The architecture is critical in design and engineering. This is where the engineered product design ensures that all component/parts fit together properly, integrate as a whole, and will work in harmony with one another once it is built.
For an assemble-to-order business model, the physical laptop–the RESULT of architecture–does not exist at the time of order; that is, it is not in the manufacturer’s warehouse as a finished good. However, all of its components/parts are in inventory and available for assembly into a customer specific laptop based on the product design. The product design is documented in the architecture descriptions which are used to build or buy the physical components/parts for assembly into a laptop. Once the order is placed, it is promptly scheduled for assembly and manufacturing based on availability of components/parts and production capacity. Generally, within a couple of days, the laptop is delivered to the customer as specified, just as ordered with all of the purposely chosen options–processing chip, RAM, memory, color. This is an example of “mass customization.” [16]
If it ain’t architecture, what is it!?
As for the artifact presented in the meeting described earlier, well, it could be anything! Perhaps it is some sort of model required from an application development methodology, or a rendering that explains the rationale for making a decision, or a drawing that illustrates some relationships between disparate functions or a list of physical components that will require modification. Just because the model, rendering, drawing or list is not architecture does not prevent it from deserving critical analysis in support of an enterprise initiative. Its usefulness may lie in its ability to provide insight into problems and opportunities, or to broadly communicate something of relevance and importance. The artifact may very well have value, but it is just not architecture; that’s all!
Some innocently misuse the term architecture when referring to enterprise artifacts. Desperate for acceptance or invested in a particular solution, perhaps others may purposely misuse the term architecture or generate hyperinformation to mean their enterprise artifacts are more important, relevant and significant than other non-architectural ones. After all, calling something architecture implies that it is better than just some other model, rendering, drawing or list, and therefore, more critical to acceptance of a proposed solution or deserving of a higher priority consideration [17]. Therefore, the reader must challenge artifacts presented as architecture if the artifact, for example, merely depicts some relationships between physical components of a system. The presenter must discuss the merits of the artifact, its usefulness and its supporting rationale rather than hoping that calling it something that sounds more important or fashionable, will lead to acceptance. That is, one must seek honest objectivity and avoid workplace politics along with its self-serving nature.
How does one understand architecture in the context of an enterprise?
Before going much further in this discussion, perhaps the reader should spend some time at www.zachman.com researching “The Zachman Framework for Enterprise ArchitectureTM, The Enterprise OntologyTM.” Zachman’s ontology–it is NOT a methodology–is described by the well-known 6 x 6 matrix consisting of 6 rows called perspectives and 6 columns called interrogatives. Each intersection or cell represents a single variable model or a primitive. One may combine several primitives from a row to create a composite, multi-variable model. For example, most every business/IT professional is familiar with a typical workflow model. This artifact is a multi-variable model [18]; it is a row 2 composite. It is “some THINGS (from column 1) transformed by some PROCESSES (from column 2) in some LOCATIONS (from column 3) by some PEOPLE (from column 4) at some TIME (from column 5) for some REASONS (from column 6).” [19] Just refer to the generic color coded workflow example in Figure 1 below:
Figure 1. Generic Workflow Model - Row 2 Composite, Multi-Variable Model
After carefully reviewing the Zachman web site, the reader might want to scrutinize the IEEE definition of architecture to better understand the correlations between them; please do this research. Zachman’s single variable models or primitives in each cell of the Framework, refer to the fundamental concepts embodied in its elements as described in IEEE definition. Zachman’s carefully defined legitimate relationships or composite, multi-variable models refer to the phrase embodied in its relationships from the IEEE definition. Zachman’s cell relationships are defined below:
“Every Cell is related to every other Cell in its Row. Also, every Cell is related to the Cell above and the Cell below in its Column [20]
In the field of Enterprise Architecture, an earlier IEEE reference noted confusion in the term “architecture” between the abstract idea and the artifacts capturing the abstract idea [21]. From Zachman’s 6 x 6 matrix one can now realize that each intersection or cell represents a primitive model that is descriptive of the enterprise, NOT descriptive of a physical implementation within the enterprise; it represents the abstract idea. And each composite, multi-variable model is descriptive of a physical implementation within the enterprise. Metaphorically speaking, a Zachman primitive is conceptually similar to oxygen or hydrogen atoms, whereas a composite, multi-variable model is conceptually similar to a water molecule.
On a side note, the reader will find an excellent discussion on the transformation between the rows of Column 1 in a most excellent article written by Loretta Mahon Smith and published in a Modern Analyst article titled, “Data Analysis for Business Analysts: The Zachman Framework and Data Architecture.” [22]
How does one determine if an artifact is architecture?
In order to overcome the innocent or purposeful misuse of architecture, the reader must have a basic understanding of architecture in general and of Enterprise Architecture (EA) specifically. And the same basic principles of architecture defined in the IEEE are inherited in Enterprise Architecture. An excellent reference for determining if an enterprise artifact “is or is not” architecture is a 7-page article written by John Zachman in 2000 titled, “Architecture Artifacts Vs Application Development Artifacts.” [23] The reader is encouraged to carefully read, study and analyze this most excellent article.
On the first page of the article, Zachman defines Enterprise Architecture as “the set of primitive, descriptive artifacts that constitute the knowledge infrastructure of the Enterprise. It is purely structural.” The most important characteristic of this definition is that the artifact “be descriptive of the Enterprise, not merely descriptive of an implementation within the Enterprise.” [24] If it is descriptive of an implementation within the Enterprise, it represents something physical; and that ain’t architecture according to IEEE! If it is descriptive of the Enterprise, in this context it means that it represents the abstract idea or concept of architecture according to IEEE; it is an architecture description! Later in the article beginning at the top of page 3, Zachman also provides three test criteria for determining if a model or artifact represents Enterprise Architecture or an implementation in the form of an Application Development work product. It is important to remember that Zachman’s article clearly emphasizes the critical point made earlier by IEEE in that “An architecture is not merely the overall structure of physical components that make up a system.” [25]
The first test criteria described in Zachman’s article ask the question; “is it a single variable model (primitive, all components occurring within a single cell of the Framework), or is it a composite, multi-variable model (comprised of components from more than one cell of the Framework)?” [26] A primitive is independent, unique in the enterprise and unaware of how it is implemented. For example, a single variable model from Row 2, Column 1 is a model of THINGS; a single variable model from Row 2, Column 2 is a model of PROCESSES and so on. One may conduct a variety of analyses on these primitives–the THINGS or the PROCESSES. However, if the artifact looks like the generic workflow model depicted in Figure 1, then it represents a composite, multi-variable model, not a primitive one [27].
The second test criteria described in Zachman’s article ask the question; “is this composite model being composed from primitive architectural representations (in which case, ‘show me the primitive models!’) or is the composite simply representing a point-in-time application solution?” [28] For example, if the artifact appears to look like the generic workflow model depicted in Figure 1, then it represents a composite, multi-variable model. If the primitive models supporting the artifact do NOT exist, then one simply has an application development, point-in-time, work product.
The third test criteria described in Zachman’s article ask the question; “are the architectural primitives designed such that they are Enterprise-wide in scope?” [29] For example, one corporate division might have only Product Orders and another division might have only Service Orders. Does a reference to Order represent a divisional prospective–a Product Order or a Service Order? In this case it is unclear? Or might Order represent an Enterprise-wide perspective? Again, it is unclear. Defining the primitive simply as Order prevents one from determining whether the subset of any one primitive depicted in the composite, multi-variable model represents an Enterprise-wide perspective or a divisional one; it’s a scope issue. .
Conclusion
This article summarizes some detailed information from some critically important IEEE web pages and from two supporting Zachman articles in order to start the reader on a journey of learning about architecture, specifically in the context of an enterprise. This article is in fact an introduction and NOT a substitute for all of the comprehensive information provided by the IEEE and found in the works of John Zachman. The reader is encouraged to carefully review and scrutinize the information presented in this article and the supporting information found in the references and footnotes section.
Using the three essential precepts presented from the IEEE as a foundation for architecture principles and the three test criteria presented from Zachman’s article, the reader can determine during a meeting if an artifact presented and described as architecture is really architecture; not just some model, rendering, drawing or list. So, if one sees for example, a business workflow model–a composite, multi-variable model–connected to some various aspects of IT–perhaps another composite, multi-variable model–then the reader will have the knowledge to ask the proper questions and to determine it the artifact “is or is not” architecture; and that is a good thing! And this is what a knowledgeable and learned Business Analyst should ask!
Author: Ralph Whittle is co-author of a book titled,
Enterprise Business Architecture: The Formal Link between Strategy and Results, CRC Press 2004. He is a Strategic Business/IT Consultant and subject matter expert in Enterprise Business Architecture development and implementation. He has built Enterprise Business Architectures in various industries, such as manufacturing, healthcare, financial, and technology. He has worked in the IT industry for over 26 years, conducting engagements in enterprise business process modeling, strategic/tactical business planning, enterprise business requirements analysis, enterprise business architecture and IT architecture integration, strategic frameworks integration with systems development methodologies and IT service offering enhancement. He is a co-inventor of a patented Strategic Business/IT Planning framework. The reader can contact the author at:
Email:
[email protected]
Website: www.enterprisebusinessarchitecture.com Internet Explorer (IE) is required for viewing and navigating through the case study models. Other browsers do NOT support the IE hyperlinks used for navigation.)
References and Footnotes:
1. The Baptist Record, “Information, Misinformation, and Hyperinformation” by Jim Futral, page 4, “Directions,” July 31, 2014.
2. See http://www.iso-architecture.org/ieee-1471/faq.html#wharch Select from FAQ, “5. So, what is an architecture? From Frequently Asked Questions: ISO/IEC/IEEE 42010.
3. See 2. IEEE
4. See 2. IEEE.
5. See http://www.ieee.org/about/index.html About IEEE.
6. See http://en.wikipedia.org/wiki/IEEE_Standards_Association IEEE Standards Association
7. See 2. IEEE
8. See 2. IEEE
9. See 2. IEEE.
10. See http://www.iso-architecture.org/ieee-1471/faq.html#whcontrib Select from FAQ, “4. What are the main contributions of the Standard? From Frequently Asked Questions: ISO/IEC/IEEE 42010.
11. See http://www.iso-architecture.org/ieee-1471/defining-architecture.html Defining Architecture.
12. Zachman, John A.”Architecture Is Architecture Is Architecture.” Zachman International, 2007, http://www.zachman.com/ea-articles-reference/52-architecture-is-architecture-is-architecture-by-john-a-zachman
13. See http://www.iso-architecture.org/ieee-1471/faq.html#whstruct Select from FAQ, “7. Isn’t the architecture of a system its top-level structure? From Frequently Asked Questions: ISO/IEC/IEEE 42010.
14. See 13. What is the architecture of the Internet?
15. See http://www.businessdictionary.com/definition/mass-customization.html Mass Customization definition.
16. See http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3015/IMAGINE-the-Assemble-to-Order-Enterprise.aspx Whittle, Ralph. “IMAGINE the ‘Assemble to Order’ Enterprise,” page 1. Modern Analyst, July 21, 2014.
17. See http://www.bptrends.com/bpt/wp-content/publicationfiles/09-03-3013-ART-Examining%20Capabilities-Whittle%20%282%29.pdf Whittle, Ralph. “Examining Capabilities as Architecture,” page 2. BPTrends, September 2013
18. See https://www.youtube.com/watch?v=75H5rXiAaFM Zachman, John A., Jha, Sunil Dutt, “Part 6 of 22: Can BPMN Models be classified in the Zachman Framework Column 2, Row 2?”
19. See
links.enterprisearchitecture.dk/links/files/Arch_Artifacts_versus_Applic_Dev_Artifacts.pdf Zachman, John A., ”Architecture Artifacts Vs Application Artifacts.” Zachman International, 2000.
20. Zachman, John A., THE ZACHMAN FRAMEWORK FOR ENTERPRISE ARCHITECTURETM: A Primer for Enterprise Engineering and Manufacturing, ©Copyright 2003 Zachman InternationalTM
21. See 11.
22. See
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/844/Data-Analysis-for-Business-Analysts-The-Zachman-Framework-and-Data-Architecture.aspx Smith, Loretta Mahon, “Data Analysis for Business Analysts: The Zachman Framework and Data Architecture.” Modern Analyst, March 5, 2009.
23. See 19
24. See 19, page 1.
25. See 2. IEEE.
26. See 19, page 3
27. See 19, page 3
28. See 19, page 3
29. See 19, page 5