Zachman vs Togaf

The Zachman Framework

In 1989, John Zachman, a business process engineer, worked for IBM created the Zachman framework. The Zachman framework is defined as an architecture that is projected to provide an inclusive representation of an information technology enterprise. The framework allows for various organised views about the activities and characteristics that support the architecture. The Zachman framework does not comprise of a specific process or method hence an organisation executes the parts that particularly affect their product or business. The Zachman framework is used for the design of complex products.

Products or systems that are produced using the Zachman framework are designed using concepts relevant to various perspectives. Hence the Zachman framework includes different levels or perspectives. The different levels being the scope or objective (the contextual), the enterprise model (the conceptual), the system model (the logical) and the technology model (the physical). These levels plan the role that people partakes in hence the first level being the scope would be done by the planner, the owner takes on the role of the enterprise model, the systems model role would be of importance to the designer and the builder will take on the technology model.

Within these different levels, each level contains six aspects. These six aspects are common across enterprise architecture. The first perspective are the data, this would be what you would function on or function with. The second one would be functions and processes which are what you actually do with and how you use the data. Thirdly the network and location play a fundamental part, the location is specifically where the components are which are more physical and the network how they come together which is the linking system. The next aspect consists of people which are necessary for any organisation to function. Then time which describes when something happens. Lastly motivation is the reason for something to happen.

The above aspects correspond to the five w’s namely the what, where, who, when and why as well as including the how. These six questions provide answers for all there is to know about a system. The ‘what’ would describe what does it operate with which is the data, how does it work which is the functions and processes, where the location of an even is taking place, the people who use it and in what point in time, the series of events describes the time aspect and the motivation is a reason as to why something needs to be done in a specific way. By using the Zachman framework, it is able to answer questions on any system whether an IT or not. An Enterprise comprises of all the levels or perspectives. Each aspect is useful for specific needs at specific times for an organisation.

What are the benefits and liabilities of the zachman framework?
There are many benefits and liabilities related to the zachman framework. The Zachman framework proves to have multiple benefits, any enterprise architect will be able to comprehend the framework as it is quite simple. The framework does not have a specific process to follow hence no matter which perspective it is viewed from, any organisation will easily be able to implement the Zachman framework for their system or product. It is advantageous as only the sectors a specific organisation finds useful could be used, not every function has to be executed.
The zachman framework is also successful, because there is no other framework that meets or satisfies everyone’s needs. A few other advantages of the zachman framework are improving communications in the information system industry and putting a variety of tools in relation to each other. The zachman framework also helps in developing approaches to produce representational architecture.

Disadvantages of the zachman framework are that some developers have never even heard about the zachman framework, this framework is not well known or well accepted in the community. The zachman framework does not have a step to step procedure for explaining how to create new architecture. Because this framework does not particularly have a process, many originations stray away from the framework as they prefer framework that offers a detailed process to follow. The zachman framework also does not provide any information in deciding whether the future architecture is good and suitable for the organisation.

Where can the zachman framework be used?
There are many factors that influence which enterprise architecture framework a person should use. These factors include questions such as, what you are trying to accomplish, which industry you are in, if you have a federal or state government, what the enterprise architecture framework is intended to be used for, what the scope for your enterprise architecture is. The zachman framework can be used in both government agencies as well as commercial companies. The zachman framework is said to be a better use for data projects, compared to other enterprise architecture frameworks. The zachman framework is also used in times to clarify the concerns of the stakeholders in the organisation. These are the appropriate times for using the zachman framework.

TOGAF
The Open Group Architecture Framework (TOGAF) was developed by The Open Group in 1995. The TOGAF framework has metamorphosed into several versions over time, with TOGAF 9.1 being the latest version. At present, the TOGAF framework is a very popular framework among organisations for enterprise architecture at a global level (Keller, 2009).
According to The Open Group, TOGAF is defined as “an architecture framework - a set of methods and tools for developing a broad range of different IT architectures. It enables IT users to design, evaluate, and build the right architecture for their organization, and reduces the costs of planning, designing, and implementing architectures based on open systems solutions (Group, 2006).” TOGAF provides a comprehensive approach to the design, planning, implementation, and governance of enterprise information architecture (Mary & Rodrigues, 2011) . The scope of the framework includes business, data and applications (Mary & Rodrigues, 2011). TOGAF is intended to provide a practical, freely available, industry standard method of designing enterprise architecture while influencing all the relevant assets and stakeholders in the process (Zakaria, et al., 2009).
TOGAF is not a prescriptive “use it right out of the box” framework. Rather the TOGAF framework will advise you as to what you should do, instead of telling you how you should do it (Keller, 2009). By applying TOGAF, the framework will produce an enterprise architecture that is specific to an organisation’s business needs and goals. A strategic blueprint will be developed for solution implementation. TOGAF does contain a prescriptive element in that the enterprise architecture should follow a top-down approach where business drivers are prioritised first instead of IT-driven initiatives (Perks & Beveridge, 2003). This is done in order to keep an organisation’s enterprise architecture relevant, especially in the long term (Perks & Beveridge, 2003). The process begins at a generic, abstract level and gradually evolves to organisational specific components (Perks & Beveridge, 2003). This approach displays the flexibility and adaptability of this framework. It provides the core generic tools to construct the foundational architecture while encouraging customisation to organisational specific needs and objectives (Perks & Beveridge, 2003).

An important characteristic of TOGAF is the use of ‘building blocks.’ Building blocks represent the fundamental ‘blocks’ that constitute the entire system. It attempts to break down the complexions of the system into smaller sub elements in order to simplify and provide a comprehensive understanding of the system. This approach of breaking down the system into small blocks is applied to all four levels of the architecture domain (Desfray & Raymond, 2014).

TOGAF is designed to support four types of architecture domain in enterprise architecture, namely: business architecture, data architecture, application architecture and technical architecture (Zakaria, et al., 2009).

• Business architecture: Defines the business goals, objectives, strategy, governance and key business processes (Zakaria, et al., 2009).

• Data architecture: Describes an organisation’s data structures, logical and physical data assets and management resources (Zakaria, et al., 2009).

• Applications architecture: This is a blueprint for the individual applications systems to be initiated which describes their relationships with other core business processes of an organisation (Zakaria, et al., 2009).

• Technology architecture: Describes the software and hardware capabilities required to support the deployment of business, data and application services. This includes IT infrastructure, networks, standards and processors (Zakaria, et al., 2009).

The architecture development method (ADM) is the core of TOGAF (Alm & Wißotzki, 2013). The ADM is “TOGAF specific process, consisting of seven major phases for the development and maintenance of an organisation technical architecture (Perks & Beveridge, 2003) ” The ADM is a cyclic, ongoing process in order to maintain and keep an organisation’s enterprise relevant and bring the greatest benefit to the organisation (Zakaria, et al., 2009). The seven major phases of the ADM include: initiations and framework, baseline description, target architecture, opportunities and solutions, migration planning, implementation and architectural maintenance (Abdallah & Galal-Edeen, 2006) .

The strengths of TOGAF include:
• TOGAF is aided by a strong open committee in which anyone can contribute and provide their knowledge and expertise to the framework (Abdallah & Galal-Edeen, 2006).

• TOGAF is a well-established framework that offers a proven method that is an accumulation of many years of research and development by the world’s leading enterprise architects (Abdallah & Galal-Edeen, 2006).

• TOGAF is an easily understood framework because the framework guides users using common vocabulary and standard taxonomy for business, information systems and modelling (Abdallah & Galal-Edeen, 2006).

• TOFAF gives users a visual representation to business concepts and when published, it can be easily communicated and distributed to other relevant parties (Abdallah & Galal-Edeen, 2006).

• TOGAF facilitates in better decision making by providing decision-makers with relevant knowledge in an efficient and timely manner (Abdallah & Galal-Edeen, 2006)

• TOGAF reduces the complexity of an organisations enterprise architecture by improving integration of portfolios, reducing the number of interfaces, increased data integration and easier maintenance (Abdallah & Galal-Edeen, 2006).

• TOGAF improves business – IT alignment of an organisation by focusing the architecture development process in meeting business goals and objectives and not IT initiatives (Abdallah & Galal-Edeen, 2006).

The weaknesses of TOGAF include:
• Since TOGAF is an open framework and is open to contribution from anyone, this has caused the framework to be somewhat ‘loose’ and not tightly integrated since additions to the framework are not strictly aligned with the existing vocabulary and standards (Creative Commons Attribution, 2016).

• The TOGAF document is large and covers a wide variety of content. This has caused the essential elements to be clouded by the non-essential elements (Creative Commons Attribution, 2016)

• Due to TOGAF’s flexible and adaptable characteristics, the framework does not provide enterprise architects with concrete guidance on how to implement the framework within an organisation. This could potentially cause misinterpretation and disastrous results (Creative Commons Attribution, 2016).

• The TOGAF documentation does not offer any formal theory and methodology for addressing organisational complexity and integrated enterprise design (Dietz & Hoogervorst, 2011).

• TOGAF focuses on extending the IT focus to the organisational domain but does include the human beings’ role in the success of the organisation’s enterprise architecture since human beings’ play a vital role in this regard (Dietz & Hoogervorst, 2011).

SOA
service-oriented architecture (SOA) is a style of programming outline where administrations are given to alternate segments by application segments, through a Coms protocol over a system or network. The essential standards of service oriented architecture are autonomous of vendors, items and advancements or technologies. A service is a discrete unit of usefulness that can be remotely accessed and followed up on and refreshed freely, for example, recovering a financial record on the web.
A service has four properties as indicated by one of numerous meanings of SOA.

1. It legitimately represents a business activity with a predetermined result.
2. It is independent.
3. I It is a black box for its shoppers.
4. It may comprise of other hidden services Distinctive services can be utilized in conjunction to give the usefulness of a big programming application. Up until this point, the definition could be a meaning of modular programming. Service-oriented architecture (SOA) is less about how to modularize an application is, and more about how to create an application by combination of distribution, independently kept up and deployed programming components. It is supported by advances and benchmarks that make it less demanding for parts to impart and collaborate over a system or network, particularly an IP network. In SOA, services utilize protocols which depict how they pass and parse messages utilizing metadata. This metadata depicts both the useful attributes of the administration and the quality-of-service characteristics. Service-oriented aims are to enable clients to consolidate large portions of Functionality to form applications which are fabricated simply from existing services and joining them in an ad hoc manner. A service exhibits a basic interface to the requester that modified works away the fundamental unpredictability going about as a black box. Advance clients can likewise get to these independent services with no learning of their inward execution.

Attributes of Service Oriented Architecture Services

• Reusable: dependent upon their granularity, services can be utilized by different procedures and other coarse-grained services.
• Loosely coupled: service contracts are intended to be as free of the service usage as would be prudent, limiting the requirement for service contract changes if the execution changes. In a firmly coupled framework, an execution change (e.g. an adjustment in a back-end information sort) would require a change to the interface and in this way the associating frameworks.
• Discoverable and area independent: services are situated through a service registry/index and got to by means of all-inclusive asset locators, and along these lines may move after some time without interruption to consuming frameworks.
• Standards-based: services are constructed, consumed, and portrayed utilizing standards, for example, Web Services Definition Dialect (WSDL), which gives data about the service, and Simple Object Access Protocol (SOAP), a bundling system.
• Platform-independent: both the consuming and SOA benefit frameworks can be on any stage that backings the service transport and interface prerequisites.
• Contract-based: interface and arrangements are entirely portrayed by an interface specific.
• Autonomous units of business usefulness: each service gives a business capacity that is autonomous of different services.

Benefits
-As opposed to the utilization of substantial applications, which have a tendency to be "information silos" that can't promptly trade data with each other, the utilization of better software services gives more liberated data stream inside and between enterprises. Coordinating significant applications is often costly. SOA can save integration costs.
-A service-based software architecture is simpler to change – it has more prominent organizational adaptability, empowering it to keep away from penalties and harvest commercial advantage. (This is one of the courses in which SOA can make an enterprise more “agile”.)
-Organization as a service makes it easier to reveal the functionality of the business, which in turn leads to increased visibility that adds value to a business. An example would be a logistics company allowing the tracking of shipments to its clients thus in turn increasing customer satisfaction and reducing the cost of status enquiries.
-SOA empowers changes to applications while keeping customers or service consumers segregated from developmental changes that occur in the service implementation.

Liabilities
-SOA will not be suitable for GUI functioning applications. The applications will then require a heavy data exchange.
-Applications requiring asynchronous communication cannot be used, also with standalone and short-lived applications, SOA will become a burden.
-Implementation of SOA includes a high investment cost by means of HR, development and technology.

Why SOA?
The truth in IT enterprises is that the framework is heterogeneous across working frameworks, applications, system programming, and application infrastructure. Some current applications are utilized to run current business forms, so starting without any preparation to design a new foundation isn't an alternative. Enterprises ought to rapidly react to business changes with agility; use existing interests in applications and application framework to address more up to date business necessities; bolster new channels of collaborations with clients, accomplices, and providers; and highlight an architecture that backs organic business. SOA with its loosely coupled nature enables enterprises to connect to new administrations or update existing administrations in a granular manner to address the new business necessities, gives the alternative to make the services consumable over various channels, and uncovered the current enterprise and heritage applications as administrations, thereby protecting existing IT framework investments.
What do I get from using SOA

• Reuse and organization. This is especially capable for making new business forms rapidly and dependably.
• Recomposition. The capability to change existing business forms or different applications considering service aggregation.
• The capability to incrementally change the framework.
• The capability to incrementally change the framework.

Bibliography:

IbmKnowledgeCenter,(2009).The IBM Zachman Framework. [online] Available at: https://www.ibm.com/support/knowledgecenter/SS6RBX_11.4.3/com.ibm.sa.bpr.doc/topics/r_IBM_Enterprise_fmwk.html [Accessed 25 April 2017].

Techtarget,(2005). Zachman Framework. [online] Available at: http://searchcio.techtarget.com/definition/Zachman-framework [Accessed 28 April 2017].

Zachmaninternational,(2007).The framework for enterprise architecture. [online] Available at: https://www.zachman.com/resources/ea-articles-reference/327-the-framework-for-enterprise-architecture-background-description-and-utility-by-john-a-zachman [Accessed 30 April 2017].

Abdallah, S. & Galal-Edeen, G. H., 2006. Towards a Framework for Enterprise Architecture Frameworks Comparison, Cairo: Cairo University.
Alm, R. & Wißotzki, M., 2013. TOGAF Adaption for Small and Medium, Rostock: The University of Rostock,.
Creative Commons Attribution, 2016. Things to know about TOGAF. [Online]
Available at: http://grahamberrisford.com/00EAframeworks/03TOGAF/AM%20TOGAF%200%20Things%20to%20know.htm
[Accessed 20 April 2017].
Desfray, P. & Raymond, G., 2014. Modelling Enterprise Architecture with TOGAF. 1st ed. Waltham,: Morgan Kaufmann.
Dietz, J. L. & Hoogervorst, J. A., 2011. A Critical Investigation of TOGAF – Based on the Enterprise Engineering Theory and Practice, Delft: Delft University of Technology.
Group, T. O., 2006. TOGAF as an Enterprise Architecture Framework. [Online]
Available at: http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap02.html
[Accessed 14 April 2017].
Keller, W., 2009. TOGAF 9.1 Quick Start Guide for IT Enterprise Architects, Berlin: Wolfgang.
Mary, S. R. & Rodrigues, P., 2011. Survey and Comparison of Frameworks in Software, Chennai: Hindustan University.
Perks, C. & Beveridge, T., 2003. Guide to Enterprise IT architecture. New York: Springer-Verlag.
Zakaria, N. A., Razak, R. A. & Dahalin, Z. M., 2009. Assessment of Enterprise Architecture (EA) Implementation Using, Sintok, Kedah: Universiti Utara Malaysia.

Anon., n.d. ehealthblueprint. [Online]
Available at: http://www.ehealthblueprint.com/en/documentation/chapter/characteristics-of-service-oriented-architecture-services
[Accessed 01 May 2017].
Anon., n.d. Wikipedi. [Online]
Available at: https://en.wikipedia.org/wiki/Service-oriented_architecture
[Accessed 01 May 2017].
Opengrouporg. 2017. Opengrouporg. [Online]. [1 May 2017]. Available from: http://www.opengroup.org/soa/source-book/soa/p4.htm
Oraclecom. 2017. Oraclecom. [Online]. [1 May 2017]. Available from: https://blogs.oracle.com/rtenhove/entry/why_soa
Baytcom. 2017. Baytcom. [Online]. [1 May 2017]. Available from: https://www.bayt.com/en/specialties/q/23516/what-are-the-advantages-and-disadvantages-of-service-oriented-architecture/