CSC/ECE 517 Fall 2010/ch6 6k JP
Similarities of Enterprise Architecture and Object Oriented Programming
Enterprise Architecture describes a plan or strategy to incorporate a systems different divisions into an efficient system for achieving a system's goals. Similarly, Object Oriented Programming describes a design of classes and objects working together to achieve a particular output. Enterprise Architecture is a overarching term that deals with a number of different systems within an organization, most notably Information Technology. So it is no coincidence that similarities exist between Enterprise Architecture and Object Oriented Programming.
Enterprise Architecture methodologies were created to address the increasing complexity of information systems in large organizations. Software Engineering is a growing field created by the need to organize more and more complex applications. The airport example has been used many times in class when discussing design for an application. Consider the complexity of designing an airline company which consists of one airport hub and one plane. This example is fairly trivial and can probably be completed by one individual. Now consider an airline management design that deals with multiple airport hubs, with multiple planes, connecting flights, delays, gate changes, and flight schedules. That example is many times more complex. As the IT and management needs for industries grew more and more, the industries needed a more structured approach to design these systems, Enterprise Architectures fulfilled that role.
This chapter will discuss some of the major methodologies of Enterprise Architecture and how their underlying principals reflect the underlying principals of Software Engineering and Object Oriented programming design.
Popular Enterprise Architecture Frameworks
The Zachman Framework for Enterprise Architectures
Many attribute the beginning of the term "Enterprise Architectures" to an article written by J. A. Zachman, "A framework for information systems architecture". [2] Zachman describes the framework as "simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise, as well as to the development of the Enterprise's systems" [3] Paramount to this framework is the classification of artifacts. Artifacts can be anything from a design document or a model or a diagram. [1] Zachman breaks up the overall design based on the key players of the system (Planner, Business Owner, Designer, Implementer, and Subcontractor) and the jobs that they have, then for each job and player there is a specific type of artifact. [4] A good diagram of the Zachman Framework can be found here, The Business Analyst’s Toolbox
In OOD/OOA we also classify our design documents into specific types based on the job at hand. CRC Cards, UML Diagrams, Inheritance modeling, and Use-case diagrams are all examples of artifacts used in OOD/OOA. The person designing the database schema for an application doesn't necessarily need to know the class hierarchy and the person designing the class hierarchy doesn't necessarily need to know the details of the database schema. With OOD/OOA specific diagrams and documents are created and used by the appropriate parties. This is the same concept in the Zachman Framework for Enterprise Architectures.
The Open Group Architecture Framework (TOGAF)
TOGAF takes the Zachman approach one step further, and defines a process to help you create your design specifications. Basically, the TOGAF takes an overall design or architecture and breaks it up into separate categories or levels. The levels are ordered from very general to very specific. [1] The process involves the design of each level in that order. In OOD/OOA we also have taken this approach. Software engineers do not start creating inheritance hierarchies before they know what classes they need; they also don't making class diagrams before reviewing the system requirements document. A Comparison of the Top Four Enterprise-Architecture Methodologies contains a good diagram of the TOGAF process, showing the different architecture levels and the Architecture Development Method (ADM) defined in the TOGAF.
Similar to the levels of enterprise architecture setup in the Open Group Framework, there are different levels of software design [7]:
- Requirements analysis, which provides the basic charter for the system's functions
- Domain analysis, which provides the key logical structure of the system
- System design, which provides the key physical structure of the system
In each level, a specific set of documents (or artifacts) are created:
| Requirements Analysis | System Charter | System Function Statement | |
| Domain Analysis | Class Diagrams | Inheritance Diagrams | Use-Case Diagrams |
| System Design | Package Diagrams | Component Diagrams | Sequence Diagrams |
(Diagram taken from Lecture 15: Introduction to OOA/OOD)
Federal Enterprise Architecture (FEA)
The Federal Enterprise Architecture was created by the federal government to organize the many agencies and divisions. [1] FEA breaks up common functions of an enterprise into segments. [1] For example, Human Resources, Accounting, and Marketing could all be considered segments that can be used by each agency. This allows for reuse of designs across many different divisions. The same working setup for human resources in one division can be used in many other divisions
Code reuse and the D.R.Y principal are fundamental concepts in object oriented programming. Reuse-ability, the ability to create code that can be used in many completely different settings, is one of the ten criteria for elegant software. [5]
Enterprise Architecture and Service-Oriented Architecture
Service-Oriented Architecture is another way of thinking when it comes to design. Service-Oriented Architecture can mean many things, but generally it means designing a system around the services that system offers. Enterprise Architecture deals with breaking up a system design into its different components, steps, levels and making a process to integrate each one and define how they work together. Contrastingly, Service-Oriented Architecture breaks a system up into the different outputs and focuses more on loose coupling between the different parts. Going back to our airline example, a service-oriented approach may be to design an available flight search module, purchasing module, flight status checker, and check-in module separately from one another and have each accessible from a common interface. Web services is a good example of this approach. These separate systems wouldn't necessarily need to be directly tied to one another, but can be called through he common interface. [6]
References
[1] Sessions, Roger. "A Comparison of the Top Four Enterprise-Architecture Methodologies". ObjectWatch. ObjectWatch, Inc. May 2007.
[2] Sessions, Roger. "A Better Path to Enterprise Architectures". April 2006.
[3] Zachman, John A. "The Framework for Enterprise Architecture: Background, Description and Utility." Zachman Institute for Framework Advancement (ZIFA). Document ID: 810-231-0531
[4] The Business Analyst Toolbox
[5] Skrien, Dale. (2009). "Object-Oriented Design Using Java". New York, NY. McGraw-Hill Companies, Inc.
[6] Ibrahim, Mamdouh and Gil Long. "Service-Oriented Architecture and Enterprise Architecture". 26 Apr 2007.