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.
No comments:
Post a Comment