This article is the first in a planned series in TDAN which will attempt to contribute in a meaningful way to the much-discussed subject of Information Technology Architecture, by presenting some
hopefully new and useful proposals regarding the matter in a precisely-defined manner.
To be of value, an Information Technology Architecture should be verifiable by testing and observation, and useful for making accurate predictions. It should be relevant for an entire enterprise of
any scope, as well as any subset of an enterprise, down to and including a given application system or even parts within an application system.
Above all else an Architecture must offer a mechanism for managing change which has become the single most critical activity in the application of information technology in business. It should
define comprehensively all the Information Technology “things” about which decisions must be made in order to move from a current state to future state. If the model is indeed valid for
implementing cost-effective change, then it should aid in achieving changes required to move from pre-architected state to an architected state. The model should assist its users in recognizing
“force multipliers”, levers, and synergy among the pieces and parts of the architecture model. It should identify interrelated areas where non-optimal decisions can result in diminishing returns,
but more importantly those areas where optimal decisions offer increasing returns.
Fields of endeavor other than Information Technology speak of architecture, but discussions in few if any other disciplines focus, with such frequency and reverence, around one or another
expositions of “an”architecture–as a thing in and of itself. “An” architecture in IT terms, is, more precisely, a model. Furthermore, just as C. J. Date has postulated that a database is
simply a large, structured variable, a model (e.g., an Information Technology Architecture) is also simply a large, structured variable (or more precisely, a set of variables) which forms one side
of an equation. An equation is a mathematical statement that says that two things are equal. In our IT equation, on the left of the equal sign is the model (architecture); on the right is either
the existing state, or some desired state. The desired state is that ideal state of information technology usage allowing for, at the least possible cost, the best continuous informing
(“informing” being the removal of uncertainty) of the business it supports.
Putting this all together we can assert that: an Information Technology Architecture is a model, comprised of a set of variables, forming one side of an equation, in which the other side is a state
of information technology usage allowing for, at the least possible cost, the best continuous informing of the business it supports.
Now if indeed a IT Architecture is such an equation, we are faced with a considerably large set of variables! The only hope we have of beginning to solve this beast of an equation is through the
only means by which any equation is solved–by assigning constant values to the variables. The more constants that can be assigned to the variables in the equation, the fewer variables we are left
to solve, and the closer we are to solving the equation. In this IT architecture equation, we will call the variables component types, and the constants that are assigned to component-types are the
standards for component types.
“In the great civilizations, a higher and higher standard of living requires more and more standardization, which produces both brilliant and beautiful improvements.” –Marilyn vos Savant
Supposing we can indeed accomplish this, we will find that solving for, or standardizing, the component-variables in the equation is, believe it or not, only half the job–and the lesser half, at
that. The more important half of the job is determining and solving for (again, standardizing) the functions with which the variables are interrelated–that is, functions which cause the value of
one variable to be dependent on the value of another. While this may appear to make our intimidating job even more complicated, accomplishing the standardization of functions is even more powerful
than standardizing component-types. Standardizing functions allows components of the same type to be fungible; that is, interchangeable. In the IT architecture equation, the functions are interface
types, and the constants for interface-types are standards for interface types.
An interface is a common boundary. A standard interface is a common boundary implemented widely enough to enable non-disruptive replacement of components, effectively, a commodity interface. We
will define for our purposes the term framework, widely-used and accepted in discussions of IT architectures, as specifically the set of interfaces within the IT architecture. One can conceive of
this architecture model as a honeycomb, with the framework of interfaces being the comb, and components “snapping in and out of” the cells in the comb.
Some examples may be helpful to clarify. Let’s say that in this IT architecture, the highest-level (i.e., most general or abstract) component types are humans, data, hardware and software. The
highest-level interfaces could therefore be represented, in functional-dependency notation, in this way:
Human –> Data
Human –>Hardware
Human –> Software
Data –> Software
Hardware –> Software
We have chosen this set of five dependencies carefully from the set of all possible combinations. The criteria for making this choice will be described later.
A further qualification of a component type within this model is that it must possess a common, standard set of interfaces. We are immediately qualifying component types by their interfaces. What
enables something to be a component type is its encapsulation–to the extent that it appears as a black box to anything outside of it. Its contents are hidden; all that it exposes are its
interfaces.
The nature of these interfaces is absolutely crucial to component encapsulation–in that they in essence enable the encapsulation. Component interfaces, by being general enough to deal with
whatever nature the component’s contents may assume, render as inconsequential any distinctions between any two instances of a given component type. The most significant result of this is that the
“contents” of the component “black box” may be completely replaced, if required, with absolutely no effect on the functioning of its interfaces, or on any component instances with which it
interfaces. The resulting implications for change management are enormous.
We may initially encounter some mental difficulties when attempting to conceive of components and interfaces above and beyond their more usual application in software design. It is much easier to
conceive of a class of software code as a component type than to conceive of human beings, organizations, or entire marketplaces as component types. But this mental effort will bear rewards. Just
as the component framework concept promises to bring significant benefits within the relatively narrow scope of the development of software, I am confident that the benefits resulting from applying
component framework concepts to IT Architecture as a whole are at least an order of magnitude greater. This is not just another silver bullet–it could well be a nuclear weapons cache. Stay tuned.
