The 3D extension of Zachman’s Framework was introduced in June 2002 in the article A 3D Software Architecture Framework. A new dimension (depth) was added to the original 2D framework enabling a complete specification of each of the original artifacts.

Applying the Zachman’s framework paradigm for each of its cells, we reached a complete definition of the original artifacts consisting of:

Each of these subjects map to the original framework structure, so we defined the following topic-based frameworks:

The framework’s height represents the abstraction levels used to perform the analysis:

The main enterprise activity layers are represented on the framework’s width:

The framework’s depth is composed by the topics detailing the original framework:

In the introductory article A 3D Software Architecture Framework mentioned above there is also a brief presentation of each 3D artifact. Detailed specifications of each artifact, as well as several applications of the slices through the 3D cube, will be presented in future articles in this series.

This article is introducing a formal representation of the 3D Analytical Framework with the ultimate goal of defining a "measure" of how well is defined a Framework application to an real-life endeavor, like a program or a project. In order to be able to measure the specifications completeness we will define formal structures modeling the analytical cube. This will ensure that we can measure the specifications quality with a certain objectivity degree, regardless if the 3D Framework is used for enterprise architecture or a small departmental project.

We will use as a stepping stone the definition of role-specific 3D frameworks, representing a 3D sub-structure of the complete framework. These are inspired from the real-life interest area of various roles involved in an IT project, as it is quite obvious that the Project Sponsor and a Developer, for example, will have different perspectives of the same project.

Each artifact is well defined in itself by the intersection of the 3 dimensions: Abstraction, Activity and Topic, so each one has inherent value as a stand-alone construct. Moreover, the artifacts defined in the analytical cube are not simple building blocks stacked together in no particular order. Any experienced practitioner can identify the natural order of the levels located on each dimension:

The natural order identified on each dimension requires to re-organize the 3D Framework as seen in the following figure:

In practice we define one initial artifact and derive the subsequent ones from the previously defined artifact. We have to mention that this derivation also takes in consideration additional real-life information, not included in the scope of the previous artifact definition.

The natural order that we observed on the cube dimensions allows the definition of a tri-dimensional coordinates system based on the Analytical Level, Enterprise Activity and Topics axis. Each axis is defined as a ordered set of 6 values, such as:

We can now introduce a first step of formalization of the 3D Architecture Framework as reflected in the figure below:

As an interesting enough observation, in the physical world we are usually using the coordinates system with the origin in the left-low-front corner. But most of the 3-dimensional technological applications, like image composition on a TV screen for example, are using the left-up-front corner as the origin of the coordinates system, same as it resulted from the previous analysis.

We will use the notation "® " to represent the elements derivation based on the natural order on each the axis, such as: a ® b , where a , b Î À , with À Î {AL, EA, T}.

Using the sets definition, we can immediately see that À _i ® À _j Û i < j, where À _i, À _j Î À , with À Î {AL, EA, T} and i, j Î {0,1,2,3,4,5}.

Moreover, it is obvious that the derivation is transitive: if À _i ® À _j and À _j ® À _k then À _i ® À _k, where À _i, À _j, À _k Î À , with À Î {AL, EA, T} and i, j, k Î {0,1,2,3,4,5}. This leads us to the following:

Definition: Let us consider À _i, À _j Î À where i,jÎ {0,1,2,3,4,5}. We will say that z (À _i, À _j) is a path from À _i to À _j if there is at least one combination of derivations À _i ® À _x® …® À _y® À _j.

We will use the notation À _i Þ À _j to represent a path originating in À _i and ending in À _j.

Let us also observe that, for any À Î {AL, EA, T}:

Now we can extend the definitions to consider 2 dimensions in the same time.

We will also use for h the notation J _ij = (À _i, Â _j), with i, j Î {0,1,2,3,4,5}. We can extend the derivation definition to the 2D framework elements such as:

Definition: Let us consider J _ij, J _tu Î Á , where Á is a 2D framework and i,j,t,uÎ {0,1,2,3,4,5}. We will say that J _ij derives into J _tu (J _tu is derived from J _ij) if one of the following is true:

Because the 2D derivation can be reduced to 1D derivations alongside each axis (as proven in the following lemma) we can use the same "® " notation. The context will dictate if it is a 2D or 1D derivation.

Lemma: Let us consider J _ij, J _tu Î J , where J is a 2D framework and i,j,t,uÎ {0,1,2,3,4,5}. If J _ij ® J _tu is a valid 2D derivation, then there is a combination of 1D derivations starting with J _ij and ending in J _tu.

From the above lemma is obvious that a 2D derivation can be decomposed into a combination of 1D derivations.

Also, we have direct extensions of the initial and final element such as:

To complete the definition of the 2D Framework let’s observe that the derivation within a 2D Framework is not transitive any more, as it was within the 1D model. It is visible from the above definitions that even if J _ij ® J _kj and J _kj ® J _km are valid derivations, J _ij ® J _km is a valid derivation only if either i=k or j=m.

Definition: Let us consider J _ij, J _tu Î J , where J is a 2D framework and i,j,t,uÎ {0,1,2,3,4,5}. We will say that x (J _ij, J _tu) is a 2D path from J _ij to J _tu if there is at least one combination of derivations J _ij® J _xy® …® J _wz® J _tu.

We will use the notation J _ijÞ J _tu to represent a 2D path originating in J _ij and ending in J _tu. We will also use the name path instead of 2D path and we will deduct from context if it is a 1-dimensional or 2-dimensional path.

As a direct consequence from the above definition we can see that the path operation is transitive in the 2D Framework. This is because, if J _ijÞ J _mn and J _mnÞ J _tu, then we have valid derivation combinations J _ij® …® J _mn and J _mn® … ® J _tu, so there is a valid J _ij® …® J _mn® … ® J _tu, equivalent with J _ijÞ J _tu.

Now we can extend the definitions to consider all 3 dimensions in the same time.

As before, we will use the notation G _ijk = (À _i, Â _j, Á _k) to identify the elements of a 3D framework G .

Let us observe now that each artifact defined for the 3D Architectural Framework is a 3-uple in the 3 dimensional product: W = AL ´ AE ´ T (particular case of G = À ´ Â ´ Á ). We can also use the notation: W _ijk = (ALi, EAj, Tk), with i, j, k Î {0,1,2,3,4,5}.

Definition: Let us consider G _ijk, G _tuv Î G , with i, j, k, t, u, v Î {0,1,2,3,4,5}. We will say that G _ijk derives into G _tuv (G _tuv is derived from G _ijk) if one of the following is true:

We can immediately observe that the 3-dimensional derivation reduces to the uni-dimensional derivation alongside one of the axis, while the other two components are constant. Therefore we can use the same "® " notation and we will understand from context if it is a 3D derivation.

Lemma: Let us consider G _ijk, G _tuv Î G , where G is a 3D framework and i,j,k,t,u,vÎ {0,1,2,3,4,5}. If G _ijk ® G _tuv is a valid 3D derivation, then there is a sequence of 1D derivations starting with G _ijk and ending in G _tuv.

Again, we have direct extensions of the initial and final element, such as:

To complete the definition of the 3D Framework let’s observe that the derivation within a 3D Framework is not transitive. As in the 2D frameworks we will introduce:

Definition: Let us consider G _ijk, G _tuv Î G , where G is a 3D framework and i,j,k,t,u,vÎ {0,1,2,3,4,5}. We will say that z (G _ijk, G _tuv) is a 3D path from G _ijk to G _tuv if there is at least one sequence of derivations G _ijk® …® G _tuv.

We will use the notation G _ijkÞ G _tuv to represent a 3D path originating in G _ijk and ending in G _tuv. We will also use the name path instead of 3D path and we will deduct from context if it is a 1, 2 or 3-dimensional path.

As a direct consequence from the above definition we can see that the path operation is transitive in the 3D Framework. This is because, if G _ijkÞ G _mnp and G _mnpÞ G _tuv, then we have valid derivation combinations G _ijk® …® G _mnp and G _mnp® … ® G _tuv, so there is a valid G _ijk® …® G _mnp® … ® G _tuv, equivalent with G _ijkÞ G _tuv.

Also, we can clearly see that there are many combinations of derivations that leads us from an artifact G _ijk to another one G _tuv, so, in fact, we have multiple paths between the starting artifact to the ending one.

It is visible that the path length is equal with the number of artifacts that have to be specified in order to reach an ending artifact from a starting one.

Theorem: Let us consider the artifacts G _ijk, G _tuv Î G , where G is a 3D framework and i,j,k,t,u,vÎ {0,1,2,3,4,5}. If m=t-i, n=u-j and p=v-k, then all the paths G _ijkÞ G _tuv have equal length of m+n+p.

Demonstration: Because G _ijkÞ G _tuv, based on the definition, we have a sequence of 3D derivations G _ijk® …® G _tuv. Based on the previous Lemma, the 3D sequence is equivalent with a sequence of 1D derivations.

The above theorem allows us to say that all the ‘paths’ between 2 artifacts are equivalent, so the derivation sequence used to reach the "destination" artifact from the startup one will always have the same number of steps.

This article introduced some basic definitions and formal representations required for further conceptual constructs based on the 3D Software Architecture Framework.

We introduced the ordered cube concept, very important for the formal representation but especially for the real-life usage of the 3D Framework. Formal representations of the framework, artifact, derivation and path concepts were introduced, as well as several related results.

Before continuing the formal build-up to achieve a definition of the implementation quality measure we will define in plain language, in the next article, each of the 3D artifacts that compose the 3D Software Architecture Framework.