Once an Engineering Work Product Becomes a Baseline It Cannot Be Changed Again

Architecture is not what is tangible, that is the result of architecture.  Compages is the fix of descriptive representations that are required to create an object

There appears to be a gross misunderstanding about Architecture, particularly in the data technology community.  Many people seem to retrieve that an implementation, an end result, is architecture.  To use an architecture and construction example, many people think that the Roman Coliseum is architecture.

The Roman Coliseum is not architecture.  The Roman Coliseum is the result of compages.  The consequence of compages is an instance of architecture, an implementation.  In the stop result, the implementation, yous can run across an instantiation of the Architect's compages.  If an Architect had not created the descriptive representations (the architecture) of the Roman Coliseum, they could not have built the Roman Coliseum.  They couldn't have even ordered the stones they needed to build the Coliseum.

Architecture is the set of descriptive representations that are required to create an object. If y'all cannot describe it, you cannot create information technology.  Also, if you lot ever want to alter the object you created, compages constitutes the baseline for changing the object one time it is created.  Information technology is the baseline for changing the object if you lot retain the descriptive representations used in its creation and if you ensure that the descriptive representations are always maintained consistent with the instantiation.

If the object you are trying to create is then simple that you tin can encounter it in its entirety at a glance and remember how all of its components fit together at an excruciating level of particular all at one time, you don't demand architecture.  You lot can "wing it" and see if it works.

It is only when the object you are trying to create is complex to the extent that y'all can't run into and remember all the details of the implementation at once, and only when yous want to accommodate on-going alter to the instantiated object, that compages is IMPERTIVE.  One time once again, without compages, you are not going to be able to create an object of any complexity and y'all won't exist able to change it (that is, alter it in minimum time, with minimum disruption and minimum cost).

So, the question is, what constitutes the gear up of descriptive representations relevant for describing an object and so that you tin can create information technology and alter it with minimum fourth dimension, disruption and cost?

The answer lies in several hundred years of empirical experience learning how to create and alter circuitous industrial products.

There is a universal set of descriptive representations for describing any or all industrial products.  The sets of descriptions include:

• Bills of Materials
• Functional Specifications (Specs)
• Drawings
• Operating Instructions
• Timing Diagrams
• Design Objectives

I have labeled this ready of descriptions "Perspectives" in the sense that each of the abstractions is created uniquely for different audiences.  Each of the Abstractions have five unlike, I say once more, "unlike" manifestations, depending upon the perspective of the intended audience for whom the brainchild is created.

e.g. Requirements (the Owner'south Perspective)

• Airplanes take requirements.
• Locomotives accept requirements.
• Computers have requirements.
• All industrial products accept requirements.

e.chiliad. Schematics (the Designer's Perspective)

• Airplanes accept schematics.
• Locomotives have schematics.
• Computers take schematics.
• All industrial products accept schematics.

e.g. Blueprints (the Builder's Perspective)

• Airplanes have blueprints.
• Then on … so on … and then on.

Why would anyone retrieve that the descriptive representations for enterprises are going to be any different from the descriptive representations of anything else that has ever been created?

In fact, nosotros, the ENTERPRISE Engineering and Manufacturing community (of which Information technology, Enterprise Information Management, and Information Systems are part) have been reinventing the aforementioned descriptive representations that take already been invented by the older disciplines of Engineering/Manufacturing and Architecture/Construction, only we are putting our own names on them.

Here are the Enterprise equivalent descriptive representations:

e.m. Enterprise Descriptive Equivalents of Abstractions

• Semantic structures equal Bills of Materials (semantic models ARE Bills of Material)
• Process models (or better, "Transformation" Models) equal Functional Specs
• Distribution models (Geography) equal Geometry (Drawings)
• Work menstruation models equal Operating Instructions
• Dynamics models or "Control Structures" (or better, "Timing" Models) Equal Timing Diagrams
• Blueprint Objectives equal Design Objectives

By the same token:

due east.thousand. Enterprise Descriptive Equivalents of Perspectives

• Scoping models equal Telescopic boundaries (CONOPS or concepts packages)
• Models of the business (Concepts) equal requirements
• Models of the systems (Logic) equal schematics (Engineering science Descriptions)
• Technology models (technology constrained models) equal blueprints (manufacturing engineering descriptions)
• Tooling Configurations equal Tooling Configurations and The Enterprise implementation equals the Industrial Engineering product instantiation

Therefore, ENTERPRISE Compages is the total set of intersections between the abstractions and the perspectives that found the full prepare of descriptive representations relevant for describing an Enterprise:

This is the same full set of descriptive representations relevant for describing airplanes, locomotives, buildings, computers, all industrial products. I simply put the Enterprise names on the descriptive representations considering I was interested in Enterprises.

The Framework for Enterprise Architecture (the "Zachman Framework") is just a schema, a classification scheme for descriptive representations of objects (I put Enterprise names on the descriptions and their contents – the metamodel) such that the schema is "normalized", that is, no i (meta) fact tin evidence upwards in more one Jail cell.

The enterprise itself is the implementation, the instantiation.  It is the end consequence of doing Enterprise Architecture, assuming that whatever Enterprise Architecture has been done.

I would observe that over the menstruation of the Industrial Age until at present, all airplanes, all locomotives, all buildings, all industrial products have been architected.  However few (if whatsoever) Enterprises have been architected.  Upward until at present, Enterprises have simply happened … somehow.  There may exist many systems implementations, transmission systems and/or automatic systems, material handling systems (blue collar systems) and/or record keeping systems (white collar systems), a LOT of incoherence and discontinuity (ineffectiveness) and a LOT of compensation for that discontinuity (entropy, inefficiency), lack of sufficient training for about systems professionals.

There is no architecture.  There are no "Primitive" Models (all components occurring within a single cell of  the Framework).  In that location is no baseline for managing modify.  No Enterprise engineering has been done. Enterprise parts have been manufactured … but the Enterprise parts are not fitting together.

I predict that over the catamenia of the Information Historic period, the next 1 or possibly two hundred years, all Enterprises will be architected. The same factors that drove the formalization of Architecture for industrial products in the Industrial Historic period will bulldoze the formalization of Architecture for Enterprises in the Data Age: Complication and Alter. We are already beginning to encounter the tendency.

My observation is that the definition of architecture is not in question and information technology is not negotiable. Compages is the total ready of intersections between the Abstractions and the Perspectives that establish the set of relevant descriptive representations for whatever object to be created.

• If you cannot prove me the Bill of Materials quite independent from Functional Specs quite contained from Geometry quite independent from Operating Instructions … etc., etc. …
• … And if you cannot bear witness me Requirements quite contained from Schematics quite independent from Blueprints quite contained from Tooling Configurations … etc. … etc. …
• …. I practice not believe y'all are doing Compages work (aKa Engineering).  A unmarried variable model which is one Brainchild by one Perspective, a "Archaic" model, is the raw cloth for doing Applied science.  If you have no "Archaic" models, y'all have no raw cloth for doing Technology and therefore, you are non doing Engineering (that is, you are non doing "Architecture").

In dissimilarity, implementations (Manufacturing), are the instantiation of composite, multi-variable models.  An implementation is the creation of the end results.  These composite models are comprised of more i Brainchild and/or more than one Perspective.  A manufactured part (Material) has some functionality in some geometric location for some functioning at some fourth dimension for some objective.  An instantiation, by definition, is a "composite."

The question turns out to be, how did yous create the blended, implementation instance?  From Primitive models you lot accept engineered from the perspective of the Enterprise?  (Architected?)  Or, did you simply create the Composite to produce an implementation ad hoc to whatever yous were implementing (i.due east. information technology was implemented, merely Non architected – i.e. you did non create any primitive models)?  In addition … is the composite you created the whole complete object you are trying to create (the whole airplane, or whole locomotive or whole Enterprise) or is the composite but a function of the whole affair (a fly or a banality or a "system")?

Once over again, if you cannot show me "Primitive" models, I know that you are non doing Architecture (Engineering).  You are doing implementations (Manufacturing).  And, if yous are not creating "Enterprise-wide" primitive models, I know y'all are risking creating implementations that will not integrate into the Enterprise equally a whole.  Y'all can manufacture parts of the whole iteratively and incrementally … however, they must be engineered to fit together or they are non likely to fit together (exist integrated).  Yous tin can even do the applied science, the Architecture, iteratively and incrementally, but in this case, you must exercise something over and above edifice incremental, iterative primitives to mitigate the chance of misalignment and disintegration.  Enterprise-wide integration and alignment practice not happen by accident.  They must be engineered (architected).

If one thinks that an implementation, a issue, a Composite model is Architecture, (whether it is the whole thing or merely a office of the whole thing), then this is probably contributing to the misconception that, for example, the Roman Coliseum is Compages.

The whole finished product, the end effect, is the total drove of instantiated composites of all the abstractions and all the perspectives.  If 1'southward perception that the end event is Architecture, there is petty wonder why Enterprise Architecture (as in Enterprise-WIDE Compages) is perceived to exist large, monolithic, static, inflexible, unrealistic, impossible and generally unachievable.  This misconception creates a DIS-incentive for even attempting Enterprise Architecture.

No!  Implementations are non enterprise architecture!  Implementations are the upshot of architecture … if whatsoever architecture has even been done!

If we always want the Enterprise to be engineered and so it is "lean and mean," so that information technology meets all the requirements of the "owners" and "stakeholders," we must start with architecture.  If we want the Enterprise to be constructive and efficient, then that it is integrated, so that information technology is dynamic, we must starting time with architecture.  If nosotros want to create new instances (implementations) on demand by assembling them to order from the primitive constructs (models) we already have in inventory, so that we tin can "get together the Enterprise to order" (in Manufacturing, "mass customization"), nosotros must showtime with compages.  If we want to take all these things nosotros have to start working on the raw material for doing Engineering, nosotros must start with the unmarried variable, "Archaic" models … the basis for ARCHITECTURE.

I understand that we will take to proceed to satisfy current demand for implementations by edifice Blended implementation constructs in the short term.  However, equally nosotros go some Primitives engineered (architected) and into inventory, we tin can stipulate that any Composite models to exist constructed MUST exist constructed from the components of the architected Primitives we already have in inventory.  In that fashion, eventually, we could migrate (mayhap "evolve") out of the disintegrated, discontinuous, inflexible legacy surround into an architected, coherent, flexible, dynamic, optimized Enterprise.

With planning and diligence using this approach, we could achieve the quality and longevity ascribed to Boeing 747's or hundred story buildings or other high quality, long-lasting, superior performing Industrial Age, complex engineering products that we take learned how to engineer over the last few hundred years.

Otherwise, goose egg volition have inverse … we will just continue doing more of the same … edifice and running systems (legacy implementations, manual or automated, blueish collar or white collar) and it doesn't make any difference what technologies we volition be using.  It is not a technical issue.  It is an ENGINEERING issue, an ENTERPRISE engineering outcome.

Determination

Are we going to commencement doing Enterprise technology work (building Archaic models, i.east. Architecture) … or are we just going to go along doing Enterprise manufacturing (building composite implementations, i.e. building and running systems)?

A quote often attributed to Albert Einstein, "Insanity is doing the same thing over and over once more and expecting different results" can employ to the means we take approached architecture and implementation.For references, please see "The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing". www.ZachmanInternational.com . 2003.

boydstonnagaide.blogspot.com

Source: https://www.ewsolutions.com/an-explanation-of-enterprise-architecture/

Share this post