Architecture - the Zachman way
A software system which is complex, expected to change and be customizable, needs an architecture. After all, the hard truth is that any software system that is built today, is going to be legacy sometime in the future. But, it is the consideration and detail in the architecture of the system that is going to define it's ability to easily transform and adapt to newer technologies in future in quicker time.
Zachman feels that there is a gross misunderstanding as regards architecture in the IT industry. The urge to implement and witness things working, has often resulted in architecture being ignored. However, architecture is important because one cannot create or build what one cannot describe. According to Zachman, the Roman Coliseum is not architecture, but an end-result of architecture (an implementation of the architecture)."In the end result, the implementation, you can see an instantiation of the Architect's Architecture". The end product of an architecture is amenable to change only if there is a description of it's architecture which has been kept updated with it's implementation.
A common theme noticed across working on various projects for customers across geographies, is the relative absence of any documentation concerning the architecture of the product. A majority of projects in the software services industry are maintenance or enhancement requests to existing products. In the offshoring model, all that is often handed over to project teams offshore is - a working instance of the product, the source code and user manuals. With stringent deadlines and high expectations of quick turnaround, changes in the product have to be made by wading through a maze of complex code - some of which is needed, some of which is redundant. Besides, one never knows how changes made in the absence of a 'big picture', could affect other quality attributes. As Zachman mentioned, "without Architecture, you are not going to be able to create an object of any complexity and you won't be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost)" - a statement proved true repeatedly in a number of discomforting projects.
According to Zachman, architecture "constitutes the set of descriptive representations relevant for describing an object such that you can create it and change it with minimum time, disruption and cost". Zachman has been inspired from learnings in complex industrial projects, to draw up the famous Zachman's framework. The framework provides a schema to help describe information in detail relevant to all stakeholders involved in the creation of the product.
The universal set of descriptions ("Abstractions") include an understanding of the product characteristics with respect to the following - What, How, Where, Who, When and Why. The complexity of having to understand the complete system can be reduced by the ability to abstract out one characteristic at a time, and developing a formal, explicit description of that characteristic (keeping all the other characteristics constant). (The OSI Layer is a good illustration where each layer can be described independently and changed without affecting any of the other layers) Now, each of the universal set of descriptions mentioned above, needs to be created uniquely for different audiences (visionaries, executive leaders, architects, designers, developers, users) which Zachman called "Perspectives". Hence, what constitutes Enterprise Architecture (or for that matter any software architecture) is the total set of intersections of the Abstractions and the Perspectives. A primitive model is considered to be each intersection of an abstraction and a perspective and needs to be described completely and independently in the architecture description.
Any implementation must be built in a disciplined manner using a composite of primitives (identified in the architecture description). Building systems from the whole (without consideration towards componentization using primitives) typically results in systems that are big, monolithic and inflexible to changes without major trade-offs. It is indeed true that because of a lack of architectural thought, a number of legacy systems have maze-like, tightly coupled and complicated implementations.
According to Zachman, almost all industrial products (cars, aeroplanes, machinery etc) are architected while software systems just seem to happen somehow. One of the reasons is probably because, most legacy software products developed were originally proofs of concept (POC) with layers and layers of software added over the years - some of of which may inturn, negatively impact certain quality attributes of the system. The lack of interest in leaders (CIOs etc) to initially invest in detailed architecture descriptions of the systems that they own - cause situations where, overtime, the costs of maintaining systems outweigh the revenue generated from them. Zachman noted that "When the energy needed to support the system is more than the energy in the system, the system dies". This is something that should be prevented by describing the architecture and keeping it updated to match changes in the system. Openness to bearing this short term cost will help reduce maintenance costs in the long term.
In legacy software systems (other than banking systems), the cost of software failure was probably not as serious as the cost of mechanical failure (like in aeroplanes or cars for example, where failure could cause impairment or loss of human life). Today, almost all industrial products are controlled by software. To develop a secure and efficient system, there is a need to have detailed software architecture descriptions in place to satisfy all stakeholders involved. With immense competition across industries, failure is not an option today because of huge financial obligations and hence, there is the willingness to do whatever it takes using prescribed methodologies.
It is more relevant than never today, that there should be a lot of focus on developing the architecture of software systems. With cloud computing and SOA, the building and running of systems is moving out into the cloud. Notice, as more and more implementations move to the cloud as services, it is the architecture that remains. It is probably these services that Zachman had identified as primitive models that are reusable (developed and maintained in inventories) and flexible to change.
The Zachman Framework is like a schema (Zachman likens the idea to be similar to the periodic table in chemistry) which can be used as per the understanding of the practioner. Though this seems to have been formally introduced to bring in a structure towards engineering 'lean and mean' enterprise architecture solutions, it is generic enough to be referenced equally efficiently in architecting complex software systems in other software domains too.
