IMAGINE the “Assemble to Order” Enterprise

INTRODUCTION

Is it possible to take the very same concept of “Assemble to Order” for a manufactured product and apply it to the enterprise itself? 

Most every reader of the Modern Analyst web site has ordered something from the Web. The order was perhaps for a PC, Smartphone or some other thing the reader wanted. For example, if one is ordering a new laptop, after deciding on the particular PC manufacturer, the customer then selects from a variety of options from the processing chip, to the RAM, to the amount of memory and other numerous choices even the color. In many cases, the physical laptop does not exist at the time of order; that is, it is not in the manufacturer’s warehouse as a finished item. However, all of its components/parts are in inventory and available for assembly into a customer specific laptop. Once the order is placed, it is promptly scheduled for 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.” 

Within the PC manufacturing enterprise described above is an event driven business process called Fulfill Order. The order for a laptop is assembled exactly to the customer ordered choices and specifications, and usually delivered within a couple of days. In today’s environment, this example of mass customization is fairly common, but it took several years to design, implement and fine tune the integrated business processes to make this work as well as it does today. Obviously, the return on investment (ROI) was well worth it.

NOW JUST IMAGINE! Can the design of the enterprise’s business processes evolve to a state where the Business Analysts can customize the business processes specifically to the requirements of the owner using inventoried primitive elements; similar to using the metaphorical inventoried components/parts for a laptop? And can these primitive elements get assembled into new/enhanced business processes within a short period of time? Just as in the laptop where the multiple combinations of processing chips and RAM are designed as integrated components/parts to work in harmony, can the enterprise design multiple business processes using the very same individual primitive elements, that when integrated will work in harmony with one another? And then, can the enterprise inventory these primitive elements for reuse across the enterprise?

HOW ARE THE ENTERPRISE’S INVENTORIED PRIMITIVE ELEMENTS USED?

When considering the business requirements for a new or enhanced strategic initiative, most development teams start with some sort of existing interaction[1] models such as the workflow models, sometimes assuming that these models are metaphorically speaking, components/parts. In reality, referring to these highly valued and very useful workflow models as components/parts is an innocent misnomer; these workflow models represent interactions between component/parts, but are not the component/parts themselves. The component/parts in the workflow models are the lowest level primitive elements down to excruciating detail - things, processes, locations, people, time and reasons - that collectively describe the various interactions found in the workflow model. In fact one can dissemble or deconstruct any low level swim lane workflow model down into these lowest level primitive elements[2]. In order to optimize enterprise reusability, it is necessary to inventory these lowest level primitive elements.

The behavior of reuse is not only instinctive in many business and IT professionals, but practiced by them as well. However, most reuse the interaction models or pieces of them rather than the primitive elements to build out the new workflows they are considering. If one were to improve and exploit this instinctive behavior by going down to the lowest level primitive elements, then even more and improved reusability is possible. And if these primitives are inventoried in a tool repository, then all the primitives are available to the whole enterprise for reuse in exploiting marketplace opportunities and solving enterprise problems.

By developing the new/enhanced lowest level swim lane workflow models with the lowest level primitive elements, one can quickly bring the analysis and design of the new or enhanced strategic initiative’s business processes to fruition. These multiple combinations of the lowest level elements are by design, integrated to work in harmony with one another; only their relationships are changing in the new/enhanced workflows. These new business requirements may also necessitate the development of new or enhanced low level primitive elements, but the development mandates that the design of these new low level primitive elements fit, where appropriate, with other new and existing low level primitive elements and work in harmony with one another. This means that every primitive element is designed for integration with some other primitive elements, and this design imperative expands the combinations available for reuse. Isolationist behavior is not permitted in this scenario.

Sometimes a complete interaction model is commonly used and saved in hopes of reusing the entire interaction model in a future implementation. As long as the interaction model is encapsulated and maintained in its entirety, then its reuse is possible. If the basic interaction needs to change, then it is changed once, and then regenerated in all implementations. However, if the interaction is merely copied and “tweaked” in several ways with some different business requirements, and then used in a variety of other implementations, keeping up with these variants become difficult and time consuming. If something has to change in the basic interaction model, then most likely all variants are required to change as well. In this example, one does not have a single reusable interaction model, but several similar interaction models that require ongoing maintenance.

HOW IS THE INVENTORY OF ENTERPRISE PRIMITIVE ELEMENTS MANAGED?

By now, many have realized that managing enterprise primitive elements and the concept of “Assemble to Order” for the enterprise are based on “The Zachman Framework for Enterprise Architecture^TM, The Enterprise Ontology^TM.” This formal ontology for managing enterprise primitive elements has existed for almost three decades. As stated from the Zachman web site: “More specifically, the Zachman Framework™ is an ontology - a theory of the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, …..). The Zachman Framework™ IS NOT a methodology for creating the implementation (an instantiation) of the object. The Framework IS the ontology for describing the Enterprise. The Framework (ontology) is a STRUCTURE whereas a methodology is a PROCESS. A Structure is NOT a Process. A Structure establishes definition whereas a Process provides Transformation.”[3]

The familiar 6 x 6 matrix developed by John Zachman represents the schema for inventorying enterprise primitive elements. And the key point to understand here is that the matrix inventories primitive elements in cells within the matrix, NOT interactions, instantiations or composite models that are built using legitimate combinations of integrated primitive elements; a simple point that is frequently misunderstood! Legitimate combinations of primitive elements include the following: “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. Using only horizontal and vertical mappings avoids misinterpretation[4].”

WHAT DO THESE INTERACTION MODELS USING PRIMITIVE ELEMENTS LOOK LIKE?

Based on The Enterprise Ontology^TM as described above, the typical lowest level swim lane workflow model represents the integration of all primitives in Row 2; this is the owner’s row. These models are referred to as legitimate “composite models” in Zachman terms. This lowest level swim lane workflow model represents “some THINGS transformed by some PROCESSES in some LOCATIONS by some PEOPLE at some TIME for some REASONS.”[5]

All Business Analysts are familiar with the business process models or interaction models like the one depicted in Figure 1. This model represents an event driven business process called Fulfill Order. It is also the highest level representation of the Fulfill Order workflow model. Since this is a high level model, some workflow model (or interaction model) information is aggregated in order to summarize Fulfill Order in a meaningful and easily understood manner. Although some will prefer a little more detail and others will prefer a little less detail in the model, but this is a decision for the owner. The six aggregated workflow models (or interaction models) are denoted by red arrows and are represented by the “collapsed sub-process” object used in the Business Process Modeling and Notation (BPMN)[6]. As the reader can visualize, this model represents the integration and interaction of six aggregated workflows, commonly called business processes, and numerous primitive elements into a higher level composite model.

Figure 1. Fulfill Order – Highest Level Workflow (click on image for larger view)

A few examples of the primitive elements used to build the interaction model in Figure 1 are depicted in Figure 2. Examples of the aggregated workflow model (or interaction model) – sometimes referred to as a business process model – used for higher level representations are depicted in Figure 3. The reader should take note that the examples of business processes in Figure 3, illustrate an aggregation in that several low level swim lane workflow models called composite models are aggregated for representation in a higher level business process model. If one were to decompose the aggregated higher level business process models in Fulfill Order, for example, Select Item from Catalog or Configure Item, one would find lower level composite models with all of the primitive elements used to build them. Depending on the complexity of each aggregated business process model, decomposition down to one, two or more lower levels is very likely. Therefore, Figure 1 is used to represent both the interactions between primitive elements as well as the ability to aggregate business process models for representation in higher level business process models, even as high up as a value stream.

Figure 2. Primitive Examples (click image for larger version)

Figure 3. Aggregated Business Process Examples

For example, Review Order, Change Order and Return Order are all closely related to Fulfill Order and when integrated and connected with one another are represented in Figure 4. The decision to integrate these particular models is a design choice made by the owner.

Figure 4. Aggregated Event Driven Business Process Models for Order to Cash (click image for larger version)

Continuing with the aggregation of Figure 4 up to an even higher level model, such as a value stream is quite simple. However, one must strictly adhere to the formality of balancing all inputs/outputs between each level of process aggregation.[7] Figure 5 represents the value stream, Order to Cash and it too, is a higher level composite model.

Figure 5. Order to Cash Value Stream (click image for larger version)

Figures 1, 4 and 5 as just presented are relatively speaking; either lower level representations used to expose excruciating levels of detail for analysis and examination, or higher level representations of composite models using aggregation to summarize information from lower level models. It is metaphorically similar to the decomposition of a bill of materials for a manufactured product, since Figure 5 decomposes into Figure 4 and Figure 4 decomposes into the four workflows – Fulfill Order (illustrated in Figure 1), Review Order, Change Order and Return Order - and each of these decompose further depending on the complexity of each of these four aggregated processes.

Obviously, each level of model has its purpose and uses. Sometimes Figures 1, 4 and 5 are used in management presentations to set context or in brainstorming sessions. The lower level models with excruciating levels of detail are used in workshops for analysis of new and enhanced business requirements. However, one important thing to remember is that these models are always integrated with one another and each “reuses” the very same inventoried primitive elements.

CAN THE READER IMAGINE THE CONCEPT OF “ASSEMBLE TO ORDER” FOR THE ENTERPRISE?”

Here again, the reader is referred to a John Zachman presentation on this most interesting enterprise archetype, titled “Eng. Design Obj. Reducing Time-to-Market[8].” Just IMAGINE that you have all of the enterprise primitives inventoried according to The Enterprise Ontology^TM and properly maintained in a tool and repository. For instance, one could automatically within seconds generate and display on a computer screen the owner’s Row 2 aggregated and composite Figures 1, 4 and 5 illustrated in this article and they would represent the Order to Cash Value Stream in the functioning enterprise in Row 6.

Oh by the way, IMAGINE that the figures are not simply displayed from a finished static model stored as depicted in each figure of this article, but dynamically assembled by connecting one primitive element to another, and to another, and so on. If one could significantly slow down the speed of the display on a computer screen by the tool and repository (e.g. taking twenty seconds to build the display instead of less than a second), one would observe each primitive “fly in” from a Row 2 cell, get combined with other Row 2 primitives and in some instances, get aggregated up to a higher level for presentation purposes to create each figure in this article. Only the model’s general appearance and positioning of primitives and aggregates are governed by the owner. Metaphorically speaking, this visualization is similar to some creative auto company TV advertisements where all of the integrated components/parts for a car (or truck) seem to “fly in” to the center of the TV screen and get assembled into a functioning car (or truck) all within a few seconds.

Now IMAGINE a new strategic enterprise initiative that requires “a smart phone text message automatically transmitted to a customer’s mobile device from the enterprise’s order entry department at some point in time after some conditions are met.” That is, “Some THINGS transformed by some PROCESSES in some LOCATIONS by some PEOPLE at some TIME for some REASONS.”[9] Having completed the analysis and development of enterprise-wide changes, these approved changes and the supporting primitives are created, updated and inventoried in the tool and repository according to The Enterprise Ontology^TM. It is now necessary to update and rebuild the appropriate lowest level swim lane business process models with these changes. To see the resultant enterprise-wide changes, for example in the Order to Cash Value Stream, one simply regenerates the appropriate figures. Obviously, this creates new composite models. The generation of any aggregated higher level composite models will automatically incorporate the representations of the newly integrated primitives since each model when generated, assembles the composites from the inventoried primitives. The composite models and aggregated business process models are NOT saved in any manner, but generated on demand from the inventoried primitives.

With the new architectural primitives added to the inventory, and the subsequent transformations of Row 2 to Row 3, Row 3 to Row 4, Row 4 to Row 5 and finally Row 5 to Row 6 as well, the enterprise is essentially prepared for “Assemble to Order.” The primitive models are descriptive of the enterprise and available for reuse on an enterprise-wide basis. When implemented, the new composite higher level models that are generated from the low level swim lane workflow models will represent the current implementation of the new or enhanced strategic initiative. 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.”[10]

Not only are the composite models dynamically and quickly updated, but the implementation of the strategic enterprise initiative occurs much faster as well since every architectural primitive is designed to fit each operational instantiation of the enterprise; this is enterprise engineering! Again, metaphorically speaking, the enterprise architectural primitives are prefabricated vehicle components/parts in inventory that are designed by the auto company for assembly into more than just one vehicle. One more important thing; all of the new architectural primitives are available to the rest of the enterprise for reuse and future operational enhancements. The design of the new primitives takes advantage of the existing enterprise infrastructure, thereby ensuring compatibility throughout the enterprise. This is an impossible feat if one were to attempt to use artifacts of application development point-in-time work products, instantiated models, or physical models instead of architectural primitives[11]. While this is an overly simplified example of the archetype of “Assemble to Order,” most likely the reader can IMAGINE the impact of it on the enterprise.

CONCLUSION

Enterprise Architecture is a significant undertaking, not necessarily from the perspective of the initiative itself, but from the cultural changes required. As previously noted, the ROI on developing and fine tuning the integrated business processes to support “Assemble to Order” for the enterprise was significant. In many manufacturing enterprises, it has become a generally accepted operating model. However, getting the enterprise itself to adopt and adapt to the “Assemble to Order” discipline is even more demanding. The tough part is overcoming the isolationists’ or functional behavior, and the “let’s just get it implemented ASAP and we will fix it later mentality.” So, it is a behavioral or cultural problem, rather than one based on developing enterprise skills, competencies and abilities.

The enterprise must begin to store the primitive artifacts according to The Enterprise Ontology^TM in a tool and repository. This enables the enterprise-wide reuse that was described in the smart phone text message example. And just as the composite models in Figures 1, 4 and 5 are regenerated with new/enhanced primitives, the integrated business processes of the enterprise get regenerated as well. With the Business Analysts and Enterprise Architects putting into practice these architectural design principles, the enterprise can significantly reduce the time-to-market for implementing a strategic initiative. Working in harmony with one another, they can design, build and implement the “Assemble to Order” enterprise.

Can the reader IMAGINE this achievement?

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: