Enterprise Architecture FAQs

How do you "cost-justify" Enterprise Architecture?

How do you "cost-justify" Enterprise Architecture?

Technically, you can't cost-justify Enterprise Architecture because Enterprise Architecture is NOT an expense... it is an asset. Cost-justification is an expense-based concept that has to do with saving money in the current accounting period. In contrast, return on investment (ROI) is an asset-based concept that has to do with deriving value in multiple, future accounting periods through reusing an asset in which an investment was made. Enterprise Architecture does not save money in the current accounting period. Enterprise Architecture requires an investment which can be reused to derive value (potentially, a LOT of value

Sometimes, isn't redundancy and complexity necessary or even desirable? For instance, isn't a large retailer more successful with thousands of redundant stores and massive complexity?

Sometimes, isn't redundancy and complexity necessary or even desirable? For instance, isn't a large retailer more successful with thousands of redundant stores and massive complexity?

You can have as many instances (redundant retail stores) as you want in Row 6:Operations Instances, but you only want a single abstraction in Row 1:Scope Contexts, Row 2:Business Concepts and Row 3:System Logic. It is conceivable to have more than one abstraction in Row 4:Technology Physics and Row 5:Tool Components, but if you do, you have to keep track of them as they relate to Row 3:System Logic or else you will go out of control- potentially have an entropy problem. They will get out of sync.

That is, you don't want any discontinuity in the Concepts (Row 2) or the Logic (Row 3). It is conceivable that you might want to implement in more than one Technology (Row 4), but now you have a synchronization problem that you will have to manage. 

In terms of Row 6:Operations Instances, there can by "n" of those, but you want each instance to trace back to the Components Transformation (Row 5), the Physics Transformation (Row 4), the Logic Transformation (Row 3), and the Concept Transformation (Row 2), and probably the Scope Transformation (Row 1) as well. That is how you insure that the reality of the Enterprise is consistent with the Enterprise Architecture. And when the "Systems" say there are 423 Employees in stock, there are actually 423 Employees in stock, etc., etc... and when we say the Concept "Employee" (Row 2:Business Concepts), it means the same across the entire Enterprise and that all the Employee instances (Row 6:Operations Instances) obey that authorized Enterprise Concept (Row 2:Business Concepts) definition.

If you did this, you could actually manage the Enterprise.



Why is Rapid Application Development really Implementation and NOT Architecture?

Why is Rapid Application Development really Implementation and NOT Architecture?

Usually, by its very name, a "rapid application development"- style methodology

Do I have to build models in order to do Enterprise Architecture?

Do I have to build models in order to do Enterprise Architecture?

Enterprise Architecture is all about PHYSICS. Nothing magic is going to happen and you can

What is Enterprise Architecture and why do we do it?

What is Enterprise Architecture and why do we do it?

"Architecture is a set of descriptive representations that are relevant for describing something you intend to create and that constitute the baseline for changing an instance of that thing once you have created it. Therefore, Enterprise Architecture is the set of descriptive representations relevant for describing an Enterprise and that constitutes the baseline for changing the Enterprise once it is created." - John Zachman, taken from interview with Roger Sessions, Editor-in-Chief: Perspectives of the International Association of Software Architects 

"If you get really honest and search all of history, seven thousand years of known history of humankind, to find how humanity has learned to cope with two things, complexity and change ... there is one game in town, ARCHITECTURE.

If it (whatever it is) gets so complex you can't remember everything all at one time, you have to write it down... ARCHITECTURE. Then, if you want to change it (whatever it is), you go to what you wrote down... ARCHITECTURE.

How do you think they build hundred story buildings, or Boeing 747's, or IBM supercomputers... or even simple things like a one-bedroom house or a Piper Cub or the PC on your desk? Somebody had to write it down... at excruciating levels of detail... ARCHITECTURE. Now, if you want to change any of those things (with minimum time, disruption and cost), how do you change them? You go to what you wrote down... ARCHITECTURE.

The key to complexity and change is ARCHITECTURE.

In the Industrial Age, we had to learn what architecture was relative to physical objects (products) in order to deal with product complexity and product change.

In the Information Age, it is the Enterprise that is complex and changing and therefore, now we are having to learn what architecture is relative to the Enterprise ... Enterprise Architecture.

This is what is making the Framework for Enterprise Architecture so significant in the Enterprise community as we move into the Information Age. The Framework is putting some definition around Enterprise Architecture."

-John Zachman

 

Stay Connected