Print Friendly, PDF & Email

Enterprise Architecture Tutorial

Enterprise architecture tutorial by TONEX intends to introduce you to the field of enterprise architecture (EA) and to give you some hints and insights on what topics you need to learn. This tutorial acts as an abstract of the EA book, demonstrating the big picture and general idea of enterprise architecture. The idea is you explore what you might be interested in off this tutorial to go deep about it with other trainings and readings.

Let us give you an introduction on the definition and background of enterprise architecture first.

Introduction to Enterprise Architecture

Enterprise architecture (EA) is developed to facilitate the process of decision-making by comprehending the complexity of the structure of organizations, their function, and the technology supporting those functions. Some might confuse EA with IT, which they couldn’t be more wrong, as EA is way wider than IT. Though, one cannot ignore their occasional relationships, since often too much complexity of IT motivates people to use EA. In this case, the unexpected escalation in IT portfolio size, an aftermath to a merger or acquisition, would justify for EA projects.

EA intends to model the connections among the business and technology in a way that main variables are revealed from the principal complexity and thus be used to support more effective decisions. One might consider this a crucial path of dependencies between the two domains of operational and technology. Let us elaborate with an example: by determining the business processes supported by a certain software application, and also the platform on which the application runs, you can measure the effect on the business of hardware obsolescence. In addition, it would also make it possible to test the expenses of substituting the application, or that which other processes could be redesigned to decrease the IT portfolio. Once other dimensions are also established including data models, organizational configuration and values, the extremely complex questions, provided the dependencies between domains are all identified.

The necessary information for an EA can often be attained from the relevant units and departments of the organization. For example, the IT department most likely has a logical model of the application placement across the organization, or HR will probably keep an organization structure, and the management consultants would probably have modeled the organization’s processes several times. Therefore, gathering the required information from the trusted sources shouldn’t be a difficult or impossible task. However, organizing and assembling such information to analyze may not be an easy job, particularly in large scales. Therefore, EA should never be commenced before making sure of whose answer would give adequate business profit to validate the cost of analysis. You should always keep this in mind that EA is not an audit practice, but is a tool to support the decision-making process. And, when an enterprise scale is produced, it is normally much more economic to sustain it rather than let it “go sour” and have to conduct the entire process again next time it is demanded.

Take-home message?

The term “enterprise” usually does not accomplish to “corporate-wide”. The size of the enterprise architecture is defined by the boundaries set by the analysis – varying from the size of a department, a project, a team, or a government of a country.

Enterprise Architecture Models

As-is

  • Used to understand the dependencies

To-be

  • Used to test the effect of modifications, or as a blue-print for a certain change program
  • To overlap a small part of a larger as-is model. Such hybrid models are often called “transitional architectures”, as they support changes in the enterprise

Enterprise Architecture Tools and Models

  • Zachman
  • TOGAF
  • DoDAF
  • FEAF
  • CEAF
  • NAF
  • MoDAF
  • RUP
  • AGATE
  • NASCIO
  • 4+1 View Model
  • PI and service management
  • REST
  • JSON
  • Databases, data modeling
  • RDBMS, SQL, PLSQL assessment
  • SOAML
  • Regulatory and Compliance (SOX)
  • COBIT
  • COSO

EA Enablers

Given the extensiveness of information run by an Enterprise Architecture model, it is crucial to have a standardized way of classifying the information. In other words, it would require a universal framework to present the information in a way that is understandable and accessible for anybody.

John Zachman invented the best-established architecture framework, in which he described a set of views on the enterprise. These views are designed to support the needs of various stakeholders such as business process models, logical data models, etc. Since then, there has been a overabundance of frameworks, coming from national governments, IT associations and businesses. The table below summarizes the Zachman FrameworkTM

Data

(what)

Function

(how)

Network

(where)

People

(where)

Time

(when)

Motivation

(why)

SCOPE
Business

Model

System

Model

Technology

Model

Detailed

Representation

Functioning

Enterprise

How Can You Learn More?

You can receive detailed and hands-on training by participating in one of our hands-on training courses, listed below:

California Enterprise Architecture Framework | CEAF Training

FEAF Training – Federal Enterprise Architecture Framework

Enterprise Architecture Training

NASCIO Training – NASCIO Enterprise Architecture Development Training

FSAM (Federal Segment Architecture Methodology) Training

Enterprise Architecture Tutorial