- Self Assessment
This is the third article in a 4-part series of articles on architecture presented by the BAInstitiute. If the reader has not read the previous two articles in this series, the reader is encouraged to begin the series in its proper sequence. Read: Part 1 | Part 2
In the first article of this series, the reader was asked to visualize how to create a typical low-level workflow model from an enterprise template of architectural primitives or formally defined elements of the enterprise. In the second article, the reader was shown how to build the enterprise template from the DE-construction and normalization (e.g. redundancies eliminated) of low-level workflow models. The reader was also introduced to the concept of the “Assemble to Order” enterprise. Now it is time to talk about the underpinnings of architecture from an enterprise perspective.
An excellent reference for defining and understanding architecture is found in the frequently asked questions (FAQs) section of IEEE. Pronounced "Eye-triple-E," it 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. Since the IEEE develops global standards in the field of information technology, it provides an excellent foundation for defining architecture concepts, principles, tenets and standards. Along with defining the term “architecture,” the approximately ten pages of IEEE FAQs provide additional explanations and discussions on architecture. And using the IEEE as a formal reference for information on architecture can reasonably eliminate most of the misinformation and hyperinformation surrounding this most interesting subject. If one seeks clarity on architecture, one can find it in the FAQs.
The IEEE 42010:2011, defines architecture this way:
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). For example, 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:
In this bulleted item is a most enlightening and critical point; a point frequently misunderstood or maybe even overlooked by many so called “practicing architects,” who have fallen away from best architectural practices. Many see the “the overall structure of 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! However, the implemented system or the enterprise is metaphorically equivalent to a water molecule which is a composite entity, not a primitive like the elements hydrogen and oxygen. The Mendeleev Periodic Table metaphor was discussed in the first article of this series. Primitives, like earthly elements are basic, elementary and fundamental. Primitives are not derived from other things and do not consist of multiple things. On the other hand, a composite model or the physical aspects of the finished product consist of multiple things.
This most important point is further discussed in question #7 which asks, “Isn’t the architecture of a system its top-level structure?” Here again, the reader is asked to pay particular attention to the first principal in this section which is provided below:
If one, for example, is looking at the physical components of an implemented system, one is not looking at architecture, but perhaps looking at the results of architecture. And by the way, the Object Management Group (OMG) definition of architecture agrees with the IEEE, but states it very differently as shown below:
As the reader can see, both the IEEE and OMG definitions are clearly referring to non-physical things¬-A specification of the parts (or primitives) and connectors of the system-not the appearance of the structure. Please refer back to a point in the first article of this series where it explained the “appropriate connectivity” between tasks and consider the above phrase¬-the rules for the interactions of the parts using the connectors. In the “task” example, the rules for the interactions are defined by their shared inputs/outputs and represented in a primitive single variable model; the singe variable in this example is a “task.
”Principle (I) deserves a bit more discussion. Consider the question “What is the architecture of the Internet?” Just look a little further down this same IEEE FAQ page and consider the term “specification” and its context from the OMG definition of architecture with the term “protocols” in the IEEE FAQ. It states:
OKAY, SO WHAT? An architecture is NOT physical, but appropriately and correctly described by primitives (engineering and design artifacts) which are used to build composites (manufacturing and production artifacts). Referring to Figure 1 below, for example, Do 1st Task, Info A and Do 2nd Task are each a primitive and the entire generic workflow is a composite consisting of many primitives. But of what value is this to the reader? The next and final article of this 4-part series will discuss why real architecture is important and how one uses the architecture to build something of value for the enterprise. The article is scheduled for publication in October 2016.
Figure 1. Generic Workflow Model with Formally Named Elements
References and Footnotes:
BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page.BA 101Establishing Business Architecture Governance and Centers of ExcellenceBuilding a Business ArchitectureThe Business Architecture PlaybookPractice-Based Business ArchitectureView the Learning Path for more courses »