Introduction
The paper discusses the Zachmans’ architecture model and the benefits that it can give to Canaxia. Other points include an examination of 3 high level concepts of Zachman and a discussion of the learning objectives.
Benefits Canaxia get from EA
The benefits obtained from Enterprise architecture are: improve professional communications in the information systems community; understanding the reasons for and risks of not developing any one architecture representation; placing a wide variety of tools and methods in relation to one another and developing improved approached to produce each of the architectural representation and rethinking the nature of the development process.
The framework has attempted to map the practices of architects in the construction industry and the manufacturing industry to information systems development. Therefore a bubble chart is equal to the scope and objectives; the architects drawings are equal to the business model description; architects plans are equal to the model of IS; contractors plans are equal to the technology model; shop plans are equal to the detailed description whine numerical code programs are equal to machine language description or object code and the completed building is equal to the information system (Zachman, 1987).
Benefits that Canaxia would get from EA are:
Breaking down silos of information of legacy applications through redesign of the architecture. This allows information pools and isolation to be avoided and allows applications to speak to each other and exchange data (McGovern, 2003).
System architecture and project should match with the underlying business process and its return on investment should determine where the budget goes. Architecture must be kept simple and one should adopt the concept that the architecture efforts must reflect a wide range of perspectives (McGovern, 2003).
An architect has to map all the company’s business processes to the applications and infrastructure that is supposed to support it and mapping has to be taken down at the lowest level of business requirements and areas such as data and security architecture should not be forgotten (McGovern, 2003).
Stovepipe Architecture should be avoided. Stove piping is characterised by a hodgepodge of equipment and software scattered through the company’s physical plant. This equipment and software were obtained for short term, tactical solutions to the corporate problem of the moment and interconnectivity was never thought of. Stovepipe architecture is usually the result of large well planned projects that were designed to fill a specific functionality for the enterprise.
These systems will often be mission critical and effective functioning of the company will depend on them. These systems involve both an application and the hardware that runs it. The replacement of these systems is considered prohibitively expensive. The software design process used to build application imperfectly captured the business requirements during the design phase. The monolithic design of most stovepipe applications make it difficult to rationalize discrepancies between business process and application functionality. Data does not integrate with the enterprise data model, usually due to vocabulary, data format or data dictionary issues.
It is difficult to obtain the information required for business intelligence or business process management. The merging of application and hardware operating system that is part of some stovepipe applications creating a maintenance and upgrade inflexibility that results in stovepipe applications having a high total cost of ownership (McGovern, 2003).
How Components work together
Following figure lists the components and illustrates how they work together.
Components are self contained software modules that has a well defined interface of set of interfaces. It is easily composed into an application to provide useful technical or business functions. A component is delivered, installed, and used by connecting and executing an interface at run time and it is also considered to be a software block box. A component can be a shared run time software entity such as a logging component, a billing service or an ActiveX control.
There are two types of components, business components and technical components. The component types are differentiated because even the components are part of their own product line and each serve a different purpose. A business component serves a business function such as customer service. A technical component has a technical purpose such as logging or configuration. Both these components and the technical components have a distinct set of quality attributes and each component product line includes the core assets and production plans required to create and maintain components of each type (McGovern, 2003).
Zachman’s 3 high level concepts
Zachman’s model attempts to bridge the gap between two or more entities and creates a relation between them, based on a set of business rules. When a system is to be developed, there would be a number of stakeholders and these are the planner, owner, designer, builder, integrator and the user. Each of these stakeholders would have their own views of how the system is supposed to function (Zachman, 1987).
There are various other entities that in turn influence and impact these views and these are data, function, network, people, time and motive. The Zachmans model attempts to create a relation between these entities through a set of business rules and these are contextual, conceptual, logical, physical, as built and functioning. With these relations developed, the model attempts to define what, how, where, who, when and why of a project (Zachman, 1987).
By adopting such a framework, it is possible to view the system as a whole and develop a solution taking the needs of the entire stakeholder and yet operate under the defined constraints of scope, time and money. By adopting such a system, it is possible to obtain an information systems architecture that is based upon the neutral objective framework (Zachman, 1987).
4 Learning objectives
The learning objectives of the assignment are:
Understand the evolution of enterprise architecture including the seminal works in the practice: It is important to understand how EA has evolved over the years, from mainframe based rigid systems to the current web based and ERP systems that are scalable, flexible and allow different modules to be added.
Develop an understanding of methodological processes and best practices for Zachman’s enterprise architecture development: Bu understanding this model, it would help in developing an architecture model that have borrowed from the construction industry where an architect plays a very crucial role an whose plans and designs form the core basis for the model
Develop an understanding of the challenges and critical success factors of enterprise architecture: There are many constraints and challenges in developing architecture systems and it is important that these have to be understood and identified. Part of the challenge lies in understanding different views of the stakeholders and knowing what they exactly need and once this is established, one can develop information systems that would be a one size fits all.
Design and build architecture models based on the business scope and environment: This would be an end objective that would show how exactly a system has been developed by considering various stakeholders roles, their views and the constraints that are in force along with the business rules in force.
Conclusion
The paper has examined Zachman’s framework model of architecture systems and how it can help to increase the effectiveness and acceptance among various stakeholders. The paper has also discussed the benefits of applying the model and the learning objectives.
References
McGovern. James, et.al, 2003. Practical Guide to Enterprise Architect. Prentice Hall.
Zachman JA, 1987. A framework for information systems architecture. IBM Systems Journal, 26(3), pp. 454-469.