Reference architecture attempts to provide a standard process and representation for architects. There have been several attempts to develop reference models^[1] in order to structure the architectural process and define the deliverables to be produced. There are almost as many frameworks for architecture as there are architects. KPMG has a framework embedded within the Enterprise Technical Architecture Methodology now incorporated into the Traction methodology. The competitors of KPMG have similar architecture frameworks differing only in terminology and glossiness of the graphics. Let us take a look at a few of these reference models to learn more.

In 1978, the lack of interoperability between computers, combined with the growing desire for inter-computer communication, prompted the International Standards Organization (ISO) to standardize protocol creation.

One of the first reference models for developing architectures was the Zachman framework. John Zachman broke up the architecture space into perspectives (owner, builder, sub-contractor) and domain (data, function, network, etc.). In the graphic to the left each cell represents the artifacts produced in architecture engagement. With the advent of distributed computing and the development of the services concept, the Zachman framework underwent further morphing. Something similar to the "layer cake" was eventually adopted by most professionals for use in thinking about IT architecture.

Customize and extend the application functionality using abstraction layers, rather than in the application package itself.

This layer cake required a lot of slicing and dicing in order to view architecture from different stakeholder perspectives. While it was a useful framework for IT people to think about ERP systems and large-scale enterprise application portfolios, it did not necessarily make it "easy-to-do" architecture. Nor did it convey useful information to those stakeholders unfamiliar with the IT domain.

The BIT cube represents architectural artifacts as bricks (or components) on specific topics that make up the cube. These artifacts are difficult to integrate as a continuous thread through the business, information and technology architecture views. This difficulty has made the BIT as separate architectural steps a less-favored approach. With the emergence of e-Business, separation of technology, information, and business architectures no longer makes sense. The architect's framework must enable the integration of these separate steps, automatically reconciling and aligning
the requirements of various stakeholders (perspectives) across more natural partitions of the problem space (domains).
You will learn more about architecture frameworks and the approach prescribed in this course. Namely, the module entitled the building blocks of architecture will introduce you to the concepts and approach prescribed by the authors of this course. Creating separate business, information, and technology architectures no longer works in e-space. There needs to be another way to think about architecture and represent the results of that thinking, in order to drive more quickly through the architectural process.

[1]Reference models: Diagrams that are used for understanding. That is, people reference these models for the purpose of helping them make decisions or create an architecture.