The document discusses enterprise architecture and its importance. It provides:
- An introduction to enterprise architecture, defining it as a conceptual blueprint that determines how an organization can effectively achieve its objectives.
- Background on the origins and early development of enterprise architecture, including contributions from Dewey Walker in the 1960s and John Zachman's influential framework in the 1980s.
- An overview of Zachman's framework which provides a comprehensive representation of an IT enterprise through its six rows (scope, business model, system model, etc.) and six columns (who, what, when, etc.).
- Additional definitions and discussions of data warehouses, granularity, network and business rule models, and how enterprise architecture can help
2. In this article John Zachman, discusses the
need for enterprise architecture. It includes:
Introduction
Background
Framework
Definition of architecture
Granularity
Data ware house
Network and business rule
models
Architecture is free
3. Introduction
• The Enterprise Architecture practice has been there for decades but in last few
years it is regaining popularity.
• some confusion remains about what enterprise architecture is all about ???
• Enterprise architecture is the name given to the process of leadership and
control.
• It provides a link between the business strategy and the development teams
who design the detailed technical solutions.
4. Introduction (cont’d)
• An enterprise architecture (EA) is a conceptual blueprint that
defines the structure and operation of an organization.
• The intent of an enterprise architecture is to determine how an
organization can most effectively achieve its current and future
objectives.
5. Background
• Late 60s…
• Dewey Walker, the grandfather of architecture
methodologies
• IBM’s Director of Architecture in the late 1960s
• Produced architecture planning documents that
later became known as Business Systems Planning
6. • During the mid 1980s, one of Walker’s students, John
Zachman, contributed to the evolution of BSP
• Published “Business Information Control Study” in the
first edition of the IBM Systems Journal in 1982.
• Became widely recognized as a leader in the field of
enterprise architecture, identified the need to use a
logical construction blueprint (i.e., an architecture) for
defining and controlling the integration of systems and
their components.
7. Zachman’s framework
• John Zachman published an article describing “A Framework for
Information Systems Architecture” in the IBM Systems Journal.
• John Zachman’s Zachman Framework is widely recognized as the
foundation and historical basis for Enterprise Architecture.
• His framework provides a way to identify and describe an entity’s existing
and planned component parts’ relationships,
8. Six rows
Scope
Business model,
System model,
Technology model,
Components,
Working system
Six columns
Who,
What,
When,
Where,
Why,
How
• The Zachman framework is a logical structure intended to provide a
comprehensive representation of an information technology enterprise.
• It allows for multiple perspectives and categorization of business artifacts.
• A framework takes the form of a 36-cell table
9.
10. Definition of Architecture
• Architecture is the
bridge between strategy and implementations,
establishes enterprise environment.
• In the case of enterprise, the definition of architecture would be,
• “That set of descriptive representations (i.e. models) that are relevant for
describing an enterprise such that it can be produced to management’s
requirement (quality) and maintained over the period of its useful life
(change).”
11. Granularity
• In the field of building architecture and product engineering, the component
within component issue is called granularity.
• In a granularity case , the architect must ensure that every sub-part is
architected to fit within the super part.
• It must be:
Structurally consistent
Spatially consistent (related to the position, area, and size of things)
Behaviorally consistent
12. What is a Data Warehouse?
• A single, complete and consistent store of data obtained from a variety of
different sources,
• made available to end users in what they can understand and
• use in a business context.
13. • “Data ware house” should have been highly predictable as somehow, we had to find
an approach to compensate this for this historical lack of the enterprise –wide data
architecture.
• The data in existing systems, the “legacy” is so discontinuous , so inconsistent, so
incorrect so redundant it borders on useless for management purpose as cited in
CEO survey.
• Sid Adelman associates in a recent presentation observed that the meta group
estimates the cost of a single data warehouse implementation project runs around $3
million initial implementation.
• By far and away , the major effort in data warehouse project lies in the “reverse
engineering” (digging trough the legacy and archived files, element by element trying
to figure out the meaning and how its polluted)
14. Contd…
• And then cleaning up the errors in the actual instance data and
files.
• Had an enterprise architecture and some respect for its sanctity
been in place, there would no need for reverse engineering,
reconciliation and cleansing process as we know it today.
• It would be relatively straight forward to load the data into a
specialized data base, or construct a different schema.
15. • I would suggest that the expenditure on data warehouses is somewhat after-
the-fact indicative of the value of data architecture in the first place, and
before an Enterprise gets done with building data warehouses, there is going
to be a lot of money spent that could have otherwise been avoided.
• With reference to this architectural integrity issue, Bill Inmon of Pine Cone
Systems said at the Barnett, Snowmass conference, “I never said to build a
mess on top of a mess! I said this is the opportunity to clean up the mess!”
16. The Network and Business Rules Models
• I have not even begun to address the architecture problems associated with the
network (column 3) and the business rules (Column 6). For one thing, the state-of-the
art is still somewhat limited in business rule modeling (column 6) and virtually all of
the business strategies, business rules, conditions, triggers, etc. are currently expressed
in either the semantic (data) structures or procedural code.
• However, I guarantee, when competitive pressures begin to force attention on the
business rule models to be responsive to the changes in the marketplace, it will be far
easier to address them if the existing data and process architectural models are defined
and being managed!