One of those vexing questions of IT enterprise architecture is "What is architecture?" It really hasn't made sense to most software designers and developers and it seems to have no role at all in business or organizational management, or in government. Yet, for complex systems of every type, it's exceptionally important.
An architecture is the functional design of a system.
For example, a kitchen architect takes the customer's requirements, decomposes them and derives a set of functions for the kitchen. For example, the kitchen will be used by a near professional chef, then the amount of preparation space, the size of the stove, oven, and refrigerator will be much greater, than for the typical bachelor, for whom the microwave is sufficient for most everything. Therefore, the functions of the kitchen and the budget for redoing the kitchen will be much different.
However, the architect does much more than derive the functions, the architect looks at the space and "structures and orders" the functions with the space for the kitchen to optimize the utility of the functions. This is the functional design. It says nothing about the kind of countertops, or the type of stove or flooring. That is the next step in which the architect "allocates" functions to components.
Likewise, IT system architecture derives, structures, and orders a functional design for the system and then allocates the functions to components, like service components in a Service Oriented Architecture.
While creating an architecture process is hardly ever ignored in building construction, never in aircraft development, and many other complex mechanical systems, it is hardly ever performed, or very poorly performed in software. This is the reason for the adage: "If builders built building the way software developers developed applications, the first woodpecker to come along would destroy civilization."
Therefore:
"Architecture is also the process of taking the customer's requirements and through decomposing, deriving, structuring and ordering, allocating, and performing tradeoff studies creates the systems functional design and defines the components required to meet the customer's requirements."
That's awfully long for a definition of a process, but that is what all architects, in whatever field do.
An architecture is the functional design of a system.
For example, a kitchen architect takes the customer's requirements, decomposes them and derives a set of functions for the kitchen. For example, the kitchen will be used by a near professional chef, then the amount of preparation space, the size of the stove, oven, and refrigerator will be much greater, than for the typical bachelor, for whom the microwave is sufficient for most everything. Therefore, the functions of the kitchen and the budget for redoing the kitchen will be much different.
However, the architect does much more than derive the functions, the architect looks at the space and "structures and orders" the functions with the space for the kitchen to optimize the utility of the functions. This is the functional design. It says nothing about the kind of countertops, or the type of stove or flooring. That is the next step in which the architect "allocates" functions to components.
Likewise, IT system architecture derives, structures, and orders a functional design for the system and then allocates the functions to components, like service components in a Service Oriented Architecture.
While creating an architecture process is hardly ever ignored in building construction, never in aircraft development, and many other complex mechanical systems, it is hardly ever performed, or very poorly performed in software. This is the reason for the adage: "If builders built building the way software developers developed applications, the first woodpecker to come along would destroy civilization."
Therefore:
"Architecture is also the process of taking the customer's requirements and through decomposing, deriving, structuring and ordering, allocating, and performing tradeoff studies creates the systems functional design and defines the components required to meet the customer's requirements."
That's awfully long for a definition of a process, but that is what all architects, in whatever field do.
Your definition of architecture would fit a solution architecture. How well does it fit the definition of "business architecture", "data architecture", "fleet architecture", etc.
ReplyDeleteIf you step back from specific architectures and look at architectures in general, I propose the following definition, of which yours above would be a specific variation.
ReplyDeleteThe architecture of a subject is the representation of the parts of the subject, the relationships between those parts, and the attributes of those parts and relationshiops.
The parts are identified by nouns, the relationships by verbs, and the attributes by adjectives and adverbs. Noun-verb-noun combinations about the subject are triples or assertions. Assertions about broader to narrower meaning of nouns/terms/phrases result in a taxonomy for the subject. Assertions showing equivalence of meaning form a thesaurus. Some assertions show flow or sequence in meaning. Some assertions show composition in meaning. Some assertions show variation in meaning. Some assertions show versioning or change in meaning. Some assertions show description in meaning.
All of these assertions would be captured in an architecture. The subject of the architecture is not relevant to the composition of the architecture, only its noun, verb, adjective, and adverb content.
I agree with your material, overall.
ReplyDelete