The functions/processes a business performs can be described in multiple ways in Architecture. Even the meaning of the words ‘function’ and ‘process’ can vary depending on the model one uses.

When defining a Business Architecture these days, I see ‘Process’ as defined in the Business Process (Re)Engineering discipline: a set of steps carried out in response to an event or trigger, producing the desired result. The structure of the Process is normally captured in a Map diagram, which can get very complicated quickly. They may not be very stable either, as processes are changed/improved all the time. The meat of a Process is in its constituent steps, where some amount of work is done and completed before the process moves on, such as “Create Customer Record” or “Print Late Notice”. These are the basic information functions in the architecture, and note how they are all verb/noun phrases where the noun will be an entity or attribute in your data model.

This verb/noun combination is the basis of key architecture artifact, the CRUDmatrix. It matches functions to the data they use, and specifically as to whether the function Creates, Reads, Updates or Deletes the data. The Data and Process models and their cross-reference in the CRUD are core to defining the architecture within which Information Systems are created, and therefore for defining the business and the impact IT projects will have. Expanding into the other columns of the Zachman Framework (a subject large enough for its own book and some have already been written) only increases the level of understanding of a business. As Rudyard Kipling wrote:

But, I will attempt to give my views on Why, When, Where, and Who in the coming days. If what I write here whets your appetite for more architecture and models, I recommend author David C. Hay, who has done every one a great favour in collecting many of these models in his book “Requirements Analysis: From Business Views to Architecture”.