Real Business Architecture in Action© Part 3 of 4

Rate this:
Total votes: 0

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[1].  Since the IEEE develops global standards in the field of information technology[2],  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.[3]  If one seeks clarity on architecture, one can find it in the FAQs.

The 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[4]

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:

  • 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.[5]

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![6]  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:

  • (I) The fundamental concepts of systems are increasingly non-physical and increasingly removed from what has been traditionally called "structure". In this tradition, "structure" usually refers to the components and organization of physically identifiable things, such as hardware entities or software objects such as modules.[7]

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.[8]  And by the way, the Object Management Group (OMG) definition of architecture agrees with the IEEE, but states it very differently as shown below:

  • A specification of the parts and connectors of the system and the rules for the interactions of the parts using the connectors.[9]   

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:

  • 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.[10]

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:

  1. See http://www.ieee.org/about/index.html  About IEEE. 
  2. See http://en.wikipedia.org/wiki/IEEE_Standards_Association  IEEE Standards Association
  3. http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3212/Archit....  Whittle, Ralph.  “Architecture Information, Misinformation and Hyperinformation,” Modern Analyst, March 9, 2015.  
  4. 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.
  5. See 4.  IEEE
  6. See 3.  “Architecture Information, Misinformation and Hyperinformation.”
  7. See http://www.iso-architecture.org/ieee-1471/faq.html#whstruct, just below question #7, Look for Isn’t the architecture of a system its top-level structure?  From Frequently Asked Questions: ISO/IEC/IEEE 42010. 
  8. Zachman, John A.”Architecture Is Architecture Is Architecture.”  Zachman International, 2007, http://www.zachman.com/ea-articles-reference/52-architecture-is-architec...
  9. See Object Management Group Terms And Acronyms, http://www.omg.org/gettingstarted/terms_and_acronyms.htm, Architecture definition.
  10. See http://www.iso-architecture.org/ieee-1471/faq.html#whstruct, just below question #7, Isn’t the architecture of a system its top-level structure?  Look for What is the architecture of the Internet?  From Frequently Asked Questions: ISO/IEC/IEEE 42010

 

Comments

Join the Discussion

Your email address will remain private.

Shopping cart

View your shopping cart.

Editorial DIrectors

Gregg Rock
Gregg Rock
Editor & Founder
BAInstitute.org

Jeff Scott
Editorial Director
BAInstitute.org

Andrew Spanyi
Editorial Director
BPMInstitute.org

Related training courses

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 PlaybookBusiness Architecture / IT Architecture AlignmentView the Learning Path for more courses »