Articles tagged with: Enterprise Architecture

Continual Professional Development

Written by Dr. Cort Coghill on Tuesday, 10 December 2019. Posted in FEAC Institute

The argument for maintaining a reference library.

As professionals, we understand and appreciate the need for continual professional development (CPD). Associations, training organizations, etc. exist to help facilitate this need. However, one of the most important aspects of a well-balanced approach to CPD is having access to a diversity of thought. We all know a professional or two who believe in the one method or tool or whatever that will “rule them all” (my apologies to Tolkien). The reality is that there is no one approach or solution to the broad range of challenges facing any single organization. There is no Silver Bullet that is going to solve 80% of problems your organization is dealing with, regardless of the hype presented during a training course or conference presentation. Professionals need to have a breadth of approaches, techniques, and understanding to help define a problem, analyze it as well as develop and test possible solution alternatives, etc., etc. Diversity of challenges requires access to a variety of knowledge and thought. The Forgetting Curve shows how information lost over time when there is no attempt to retain it. These challenges alone are a solid rationale for establishing and maintaining a professional reference library. 

Designing for Flexibility

Written by John A. Zachman on Wednesday, 20 November 2019. Posted in Zachman International

Relative to Dewey’s conceptual innovations, in addition to his observation that the secret to the whole thing lies in the coding and classification of the data, Dewey identified and formalized the Process orientation in the late ‘60s long before Mike Hammer and Jim Champy popularized the concepts of Process Reengineering in their 1993 book.


Enterprise Architecture Defined: Primitives and Composites

Written by John A. Zachman on Friday, 13 September 2019. Posted in Zachman International

To return to the basic point ... the kind of descriptive representations (models) you need for engineering are different from the descriptive representations (models) you need for manufacturing.

ZF Abstractions

For engineering purposes, you want to see one and only one thing in any one descriptive representation and you want to see the total set of occurrences of that one thing in the context of the entire object being described. You are trying to “normalize” the set of occurrences, get rid of any redundancies (except for “controlled redundancies”), make it as simple as possible ... LEAN.

In contrast, for manufacturing purposes, you want to see only one part (one implementation, one “piece”) of the object being described and you want to see (optimally) all of the “Abstraction” characteristics for that one part. You are trying to deliver a single implementation (part) defect-free as quickly and cheaply as possible.

Enterprise Architecture Defined: Architecture Abstractions

Written by John A. Zachman on Friday, 08 February 2019. Posted in Zachman International

Architecture: Abstractions

You can classify the set descriptive representations of anything (buildings, airplanes, locomotives, battleships, computers, etc.) in a two dimensional classification structure, a “schema”.

One dimension of the classification I call “Abstractions” ... I chose to call this dimension of the classification “Abstractions” because you can abstract out, or separate out, or factor out a set of six single, independent variables or focal points of descriptions that are common to every architected object. 

The architectural descriptions of anything will include:

1) Bills of Material 2) Functional Specs 3) Drawings (or, Geometry) 4) Operating Instructions 5) Timing Diagrams and 6) Design Objectives

Enterprise Architecture Defined: Complexity and Change

Written by John A. Zachman on Thursday, 07 February 2019. Posted in Zachman International

Architecture is a SET of Descriptive Representations.

I the object you are trying to create is simple, you can see the whole thing at the level of definition required to create it ... like a log cabin ... or a computer program ... you don't need Architecture. All you need is a tool, like an axe of a compiler or something and some raw material like a forest, or some data or something, and some time, then build log cabins or write computer programs.

On the other hand, if the object is complex and you can't see it in its entirety at the level of definition required to create it, like a hundred story building ... or an Enterprise ... now you need Architecture!

In short ... the reasons you need Architecture are complexity and change.

Enterprise Architecture Defined: What is Architecture?

Written by John A. Zachman on Thursday, 07 February 2019. Posted in Zachman International

I think before we can define Enterprise Architecture, we need to ask ourselves the first question: “what is Architecture?”

Architecture ... what is it?

Some people think the Roman Coliseum is Architecture. This is a COMMON MISCONCEPTION!



Written by John A. Zachman on Thursday, 15 December 2016. Posted in Zachman International

In the Information Age, the characteristics we understand to date are complexity and change. The customer wants a product specific to his or her specification... a custom product. The customer is a market of one. And, the customer may not even know what they want until they want it and then they want it now... immediately. And, if you can’t produce to those requirements, click! They get a new supplier. Once again, It is a global market and very easy to switch suppliers.

The question is, what is your strategy to accommodate orders of magnitude increases in complexity and orders of magnitude increases in the rate of change? And, this is not an IT issue. The question Chief, is not whether this is happening or not... it IS happening. The question is, what are you going to do about it?

Strategy Spectrum for Enterprise Engineering and Manufacturing

Written by John A. Zachman on Thursday, 11 August 2016. Posted in Zachman International

My goodness! I'm so sorry to take so long with another blog! I'll bet this year is the most people we have Zachman Certified ever! HUNDREDS of folks this year so far!

Alright let me continue this disccusion:

If you REALLY want to reduce the time it takes from when you discover you need a new system until it is operational:

If you wait until you get the order before you begin to engineer and manufacture, you an only reduce the time-to-market by reducing size/ complexity of the product. Reduce size, scope. Simplify. Proliferate legacy problems. Build smaller parts that don’t fit together in higher volumes.

If you want to buy rather then build and someone has created an inventory of standard products, you can reduce the time-to-market to virtually zero as long as you change the use of the product to fit the product. Packages. COTS. Implement as is. Change the Enterprise to fit the package. (Don’t change the package to fit the Enterprise!)

If you have prefabricated parts that are designed to be assembled into more than one product, you can reduce the time-to-market to just the time it takes to pick the parts and assemble them to order... virtually zero. What do you think had to be in inventory to assemble Enterprises to order?... Enterprise Architecture.

The challenge is not technical... it is cultural. The culture at one of end of the strategy spectrum is diametrically opposed to the culture at the other end. I have included Figure 4 which depict some of the cultural characteristics at either end of the Strategy spectrum.

The New EA Paradigm 5: The Pattern: Assemble-to-Order

Written by John A. Zachman on Wednesday, 23 March 2016. Posted in Zachman International

My goodness! Cort and I have been teaching non-stop! We have Zachman Certified just over 65 people in the last month!

OK, on with this blog...

Clearly, you have to change the strategy... to an Assemble-to-Order strategy... Mass-Customization, “custom products, mass-produced in quantities of one for immediate delivery”... but this is a completely different kind of a business. You have to have PARTS in inventory... NOT finished goods... and those parts have to be engineered such that they can be assembled into more than one product. How do you engineer parts that can be assembled into more than one thing? You have to know the total set of things you have to assemble at any given point in time. You do the engineering Enterprise-wide. After you engineer the parts to assemble the Enterprise set of products, you can pre-fabricate the parts and have them in inventory before you get the order. Then when you get the order, the only time it takes to produce the custom product is the time it takes to map the specifications of the product in the order to the inventory of parts, pick the parts and assemble the custom product to order.

The New EA Paradigm 4: Provide-from-Stock

Written by John A. Zachman on Friday, 04 March 2016. Posted in Zachman International

Initially, the customer is willing to accept these limitations... they don’t know any better. But, over long periods of time, 50 or a hundred years, they get frustrated and the drive the manufacturer out of a Job Shop into a Standard Production Environment (mass production) in order to solve the problems. Actually, the problem is the strategy. As long as the strategy is make-to-order... those are the problems. If you want to solve those problems, you have to change the strategy. Provide-from-Stock. Manufacture standard products to inventory before you ever get an order and then when you get an order, deliver the standard product off the shelf. That will fix some of, but not all of, the problems.

The New EA Paradigm 2: Expenses and Assets

Written by John A. Zachman on Monday, 08 February 2016. Posted in Zachman International

Back to the Toyota illustration... now that Toyota has all these parts engineered to be assembled into any Toyota and have pre-fabricated them and have them in inventory before they get any orders... how does Toyota “cost-justify” those parts? They don’t have any orders so there is no revenue. They are not making any money... they are not saving any money in the current accounting period.

The New EA Paradigm 1: The Toyota Illustration

Written by John A. Zachman on Monday, 08 February 2016. Posted in Zachman International

I'd like to put some posts together about what I think "The New Paradigm" for Enterprise Architecture is. I will break this up into 5 or 6 blogs that deal with this in terms of Enterprise Architecture expenses vs. assets, cost justification of Enterprise Architecture, providing from stock vs assemble-to-order strategies, mass-customization of EA and some cultural implications of this new paradigm. 

That said, I need to set some context for you. I usually use the Toyota illustration to make the New Paradigm point:

A few years ago, Toyota announced in North America that if you give Toyota the specifications for the automobile you want to take delivery on, they will deliver your automobile, custom to your specifications, in 5 days! Five days is not zero, but it is pretty close to zero as those automobiles these days are pretty complex. When I grew up, I worked on my own car... but when you opened the hood, all that was in there was a four cylinder block and a carburetor. Today, I will buy a car and drive it until either it or I die... and never open the hood! There is so much stuff in there that I can’t even find the dip stick anymore! I can’t even change my own oil!

The Information Age: Powershift

Written by John A. Zachman on Friday, 04 December 2015. Posted in Zachman International

In the third blog of three about "The Information Age," the third book Toffler wrote about change was “Powershift." The basic idea in this book is, if you give everyone the same information at the same time, the power will shift outboard. No longer will the power be concentrated in two or three people at the top who know everything, decide everything, control everything... the power will shift outboard. In fact, if the customer, the recipient of the product or service of the Enterprise has access to the same information that the Enterprise has access to, the power will shift into the external environment ... to the customer. It will become “market driven”! Those of us that come from the Information Community see all kinds of evidence of this over the last 15 or 20 years... all kinds of activity around Data Warehouse, most of it centered around customer. We don’t know much about the customer... we know lots about the products or services but little about customer.

The Information Age: The Third Wave

Written by John A. Zachman on Friday, 27 November 2015. Posted in Zachman International

The second book Toffler wrote about change is "The Third Wave," and this is my 2nd in a series of three blogs.  In this book he was contrasting the characteristics of the major “Waves” of humanity:

In the Agricultural Wave, the basic discipline of humanity was Farming.

98% of humanity were farmers.

In the Industrial Wave, 2 % of humanity are farmers.

In the Agricultural Wave, there were Rural Communities

In the Industrial Wave, there are Urban Communities

In the Agricultural Wave, natural sources of energy, Wind, Waves, Slaves, etc.

In the Industrial Wave, electric Motors etc., etc.


The Information Age: Future Shock

Written by John A. Zachman on Wednesday, 25 November 2015. Posted in Zachman International

The Information Age

Here is a little context around the Information Age. In the interest of time and space, I will try to be brief but there is a key point I have to make. Having made this observation, I will limit my comments about the Information Age to some well-known works by Alvin Toffler, and I will probably break this blog into three separate parts based on the following, so look for those shortly:

"Future Shock" (1970) - The rate of change.
"The Third Wave" (1980) - The structure of change.
"Powershift" (1990) - The culture of change.
-Alvin Toffler

Alvin Toffler is a well-known name, certainly in the academic community. He is a sociological prognosticator, a futurist, and has written a lot of books. The ones that I refer to above are the ones he wrote that have to do with change.

[12  >>  

Stay Connected