CSC/ECE 517 Fall 2010/ch6 6k JP
- This page is currently under construction -
Similarities of Enterprise Architecture and Object Oriented Programming
Enterprise Architecture describes a plan or strategy to incorporate a companies different divisions into an efficient system for achieving a company'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, including 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 induvidual. 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 approch 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 programmig design.
Popular Enterprise Architecture Frameworks
The Zachman Framework for Enterprise Architectures
Many attribute the beginnig 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 artefacts. Artefacts 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 spcific type of artefact. [4]
picuture: http://sonoffiverivers.com/2010/02/the-business-analyst%E2%80%99s-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 artefacts used in OOD/OOA. The person designing the database schema for an application doesn't nessesarily need to know the class heierarchy and the person designing the class heierarchy doesn't nessesarily 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 Enterpise ARchitectures.
The Open Group Architecture Framework (TOGAF)
TOGAF takes the Zachman approch 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 seperate 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 approch. Software engineers do not start creating inheritance heirarchies before they know what classes they need; they also don't making class diagrams before reviewing the system requirements document.
picture: http://i.msdn.microsoft.com/dynimg/IC90893.gif
Similar to the levels of enterprise architecture setup in the Open Group Framework, Skrien describes three levels of OOA and OOD:
Requirements analysis, which provides the basic charter for the system's fucntions 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 documennts (or artefacts) are created:
picture: picutre from notes "Object-oriented Languages and Systems" page 3 lecture 15.
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 Resourcese, 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 resoruces in one division can be used in many other divisions
picture: http://i.msdn.microsoft.com/dynimg/IC19073.gif
Code reuse and the D.R.Y principal (link to another wiki) are fundamental concepts in object oriented programming. Reuseability, the ability to create code that can be used in many completly different settings, is one of the ten criteria for elegant software. [5]
Enterprise Architecture and Service-Oriented Architecture
Service-Oriented Architeture is another way of thinking when it comes to design. Service-Oriented Architeture can mean many things, but generally it means designing a system around the services that system offers. Enterprise ARchiecture 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. Contrastly, Service-Oriented Archiecture 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 approch may be to design an available flight search module, purchasing moduel, flight status checker, and check-in module seperately from one antoher and have each accessible from a common interface. Web services is a good example of this approch. These seperate systems wouldn't nessisarly need to be directly tied to one another, but can be called throught he common interface. [6]
[1] http://msdn.microsoft.com/en-us/library/bb466232.aspx
[2] http://msdn.microsoft.com/en-us/library/aa479371.aspx
[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] http://sonoffiverivers.com/2010/02/the-business-analyst%E2%80%99s-toolbox/
[5] Skrien
[6] http://www.ibm.com/developerworks/webservices/library/ws-soa-enterprise1/