Enterprise Architecture: What and Why?


Enterprise Architecture (EA) has recently become a “hot” topic. Articles and seminars here and elsewhere have discussed Enterprise Architecture (EA). This paper will define Enterprise
Architecture and answer the questions: What it is? and Why it is useful? In later papers, we may discuss: What are EA deliverables? What are EA meta data? How can we organize to develop the
Enterprise Architecture, and how we administer and maintain the EA models?

What is Enterprise Architecture?

An enterprise has been defined as a business association, consisting of a recognized set of interacting business functions, able to operate as an independent, stand-alone entity. There are
enterprises within enterprises. For instance, a business unit within the overall corporate entity may be considered an enterprise as long as it could be operated independently.

Architecture provides the underlying framework, which defines and describes the platform required by the enterprise to attain its objectives and achieve its business vision. Architecture is an
amalgam of engineering art and engineering science. There is no single enterprise architecture. Instead, the information architecture can be considered to consist of four interrelated architectures
or architectural views.

Figure 1.

Architectural Views

Like the Zachman Framework, upon which our architectural approach is based, the four Architecture Views (Information Architecture, Business Architecture, Application Architecture, and Technology
Architecture) may be considered to contain levels of detail. The highest architectural view level is the Policy Level. The Policy Level may contain the following architecture deliverables:

  • Architecture Policies
  • Vision Statements
  • Standards and Procedures
  • Best Practices.

Examples of Conceptual Level deliverables are:

  • Conceptual Data Model
  • High Level Use Cases
  • High Level Event Process Models
  • Data Entity to Process Matrix

Examples of Solution Level deliverables are:

  • Logical Data Model
  • Detailed Event Process Models
  • Package Evaluation Criteria
  • Data Attribute to Process Matrix

Examples of Implementation Level deliverables are:

  • Database Design
  • Presentation Layer Design
  • Designed Application Modules
  • Detailed Network Design

Information Architecture

The Enterprise Information Architecture consists of data models, and databases that serve all participants in the enterprise business environment and the strategies, standards, policies required to
develop and implement them. An Information Architecture implies that the enterprise no longer develops “islands of databases.” An Information Architecture enables the enterprise to develop a
common, shared, distributed, accurate, and consistent data resource.

Business Architecture

Business Architecture models the business enterprise using logical service units (business processes) and the events that trigger them to represent the re-architected approach to satisfying
customer requirements. It attempts to show how business is to be done.

Application Architecture

Application Architecture links the data and business architecture to reflect applications. It supports the work activities of the business processes, and provides automated procedures. Application
Architecture manages information storage and retrieval in support of the enterprise objectives. It addresses location considerations and how information is utilized.

Technology Architecture

Technology Architecture links up with the Application, Business, and Data Architectures to provide interoperable technology platforms that meet the needs of the various user roles (Actors) at
identified work locations.

Enterprise Architecture – What’s in it for Senior Business Management?

Enterprise Architecture provides senior management the basis for obtaining consistent, higher quality answers from both detailed operational data and from informational data processed to answer
their specific business analysis questions. An architectural approach allows consistent, higher quality control of the various business processes and their underlying business rules. With an
architecturally designed system, the productivity of information system users will likely increase because of better systems analysis and design. An architected system will usually provide a common
“look and feel” that makes all systems using it seem more familiar and therefore easier to learn and use.

As quoted in a presentation Four Days with Dr Deming, Dr Deming says, “In the opinion of many people in industry, there is nothing more important for the transaction of business than the
use of operational definitions. It could also be said that nothing is more neglected.” An architectural approach provides operational definitions as a part of its common business terminology and
therefore facilitates common business rules enforcement mechanisms.

Enterprise Architecture provides an entree into Business Process Improvement (both re-engineering and/or Total Quality Management (TQM)) by defining a starting point business process model and the
event dependencies so important to the improvement of business processes. EA provides a method to relate architecture components to business goals and objectives, thus providing insight into the
business motivation of both data and business processes.

A well managed EA initiative seeks to protect the present information management investment, as much as possible, and encourages the use of metrics to measure the quality and quantity of both
business process and supporting Information Technology productivity.

Enterprise Architecture- What’s in it for IT Project Leadership?

Information Technology Project managers and Leaders will usually observe productivity improvement accruing from the use of a common Information Management development methodology and a commonly
used suite of development tools. EA facilitates the ability to move to new and improved methods and tools, for example, Object Orientation, Rapid Application Development, and the Data Warehouse. EA
normally includes Packaged Application Software Assessment, for example, when to use the SAP products, as is, or with customization. Project Leaders in EA-influenced shops can gain greater
confidence in Information Management Project results because of the completeness of the user requirements specifications. All requirement elements will have been accounted for. Business Decisions
and Business Rules are defined relating all development objects and the best source of requirements and data are utilized. The best source of information about data availability is determined and
documented in an Information Meta data Repository. An EA architectural approach contains:

  • A methodology for setting priorities, ensuring that all components and component relationships are well defined.
  • A method for determining the impact of an Information Management system change request.

Enterprise Architecture -What’s in it for Actual Developers?

Developers will gain an increased confidence of success in their work. EA provides a ready source of user based requirements documentation, that will facilitate understanding of the actual user’s
requirements. Developers will be able to do things “Quick but less dirty”. They can achieve increased productivity without sacrificing creativity by using better tools, more standard methods, and
more useful meta data. A well-measured approach provides metrics for recognizing and rewarding success. Developers will gain satisfaction from “doing things right.” EA facilitates the definition,
development, and management of Reusable Components that tend to eliminate development of the tedious and allow concentration on the interesting and creative.

Enterprise Architecture – The Starting Point

As discussed above, Enterprise Architecture may provide value in and of itself. More importantly, EA is an important starting point for various business initiatives requiring Information Technology

Figure 2.

Enterprise Architecture helps identify and define business processes in need of improvement. We can see main business events that trigger these processes or are the results of these processes to
provide a context for the Business Process Improvement work. The relationship of Business Processes to Data enable Information Technology to improve the imformation needed to support Business
Process Improvement.

The relationship of Business Processes and their required data to existing and planned Applications enables us to plan the improvement of the portfolio of applications supporting a business
enterprise. EA models and meta data can be used to align proposed technology change to business objectives and requirements. EA models and methods can be used in scoping major project initiatives.

Share this post

Thomas Finneran

Thomas Finneran

Thomas R. Finneran is a principal consultant for the IDennedy Project. He has proposed an approach to use the Organization for the Advancement of Structured Information Standards (OASIS) UML Standard for privacy analysis. He was a consultant for over 25 years for CIBER, Inc. He has acquired over twenty-five years of experience in the field of information technology. His strengths include Enterprise (including data, information, knowledge, business, and application) Architecture, business and data analysis, UML Object Analysis and Design, logical data modeling, database systems design and analysis, Information Resource Management Methodologies, CASE and metadata repository tools, project management and Computer Law.  

Mr. Finneran has held such titles as Director, MIS; Manager, Corporate Data Strategy; Manager, Data Administration; Managing Consultant; Manager, Standards and Education; and Systems Designer.  These companies include The Standard Oil Company, Corning Glass Works, ITT, ADR, and the U.S. Navy.  In addition, he was Vice President and General Counsel of TOMARK, Inc., the developer of the highly successful ABEND-AID software package. He has a Bachelor of Arts, Ohio State University, a Master of Business Administration, Roosevelt University, and a Juris Doctor Degree, Cleveland State.  He is a member of the Bar of the U.S. Supreme Court and of Ohio, New Jersey, and Connecticut.  Member of Patent Bar.


scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept