Architecture modelling using standardized content

Standardized generic infrastructure functions

From the desire to regard infrastructure as a combination of functions, comes the need for a vocabulary of generic infrastructure functions. At the highest level, infrastructure has only three functions: store/retrieve client data, transport client data, and process client data. Since the three functions at this level of detail do not deliver much descriptive power, OIAm aims to work with a standardized set of generic (or archetypical) functions of sufficient detail to be useful in a functional architecture context. Over the years, the community of infrastructure architects that work with OIAm have postulated and tested an array of generic infrastructure functions for this standardized set. Those functions that have proven effective, have been included in set of generic infrastructure functions, published in this repository. The functions included in the standard set cover most, if not all, of the infrastructure landscape. Furthermore, the set is continuously maintained, so that the usability of the individual generic functions is steadily improved, and new infrastructure functionality is included as it becomes available. Use of this standard set has two distinct advantages over architects making up their own functions "on the go" for each individual project:

• an architecture created from standardized generic functions is easier understood by all with access to the standard set, and thus easier shared between colleagues, departments and organizations, and
• using the set of standardized generic functions in a project saves time.

OIAm refers to the standardized generic infrastructure functions as Generic Function, abbreviated GF.

Standardized generic infrastructure patterns and services

The interesting thing of functionally modelling an infrastructure facility from generic Infrastructure Functions is this: it reveals basic structures that are very much alike for most infrastructure facilities that offer comparable functionality. OIAm refers to these basic structures as "aggregated functions" or "patterns". In the work "A Pattern Language", patterns are defined as follows: "Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." Even though Alexander was talking about (constructional) patterns in buildings and towns, what he says is true for functional infrastructure architecture models as well: an aggregation of interrelated infrastructure functions can describe the functional solution for a class of infrastructure problems. A request for an architecture presents the architect with an infrastructure problem that falls into one such class (or possibly spans several classes). From Alexander’s definition it follows that the corresponding infrastructure pattern(s) can serve as the outline of the solution of that infrastructure problem. The OIAm community has taken inventory of the infrastructure landscape, and identified several dozens of aggregated infrastructure functions that together cover most, if not all, of the infrastructure landscape functionality. These aggregations of generic functions are referred to as Generic Patterns or GPs. As with the Generic Functions, the Generic Patterns have been published in this repository. Furthermore, services have been formulated that can be realized by these Generic Patterns. These services can be referred to as Generic Services (GS). The concept of a Generic Pattern is especially powerful, as each Generic Pattern is a basic infrastructure facility recipe, that’s independent of technology, products, vendors, and organizational details. Therefore a single Generic Pattern can serve as a mould for many infrastructure implementation models. With this in mind, OIAm have formulated and tested a number of Generic Patterns. Those Generic Patterns that prove effective have been published as a set of standard Generic Patterns in the same location as the Generic Functions. These Generic Patterns collectively cover a large part of the infrastructure landscape. The set of Generic Patterns remains under constant development, so that the breadth of the Generic Pattern set and the usability of each individual Generic Pattern is steadily improved.

Implementing Generic Patterns to arrive at Applied Patterns

When the architect from a Generic Pattern creates a functional model for a specific application, then this will be a pattern in itself. OIAm refers to this specialized version of the Generic Pattern as an Applied Pattern or AP. The infrastructure functions that make up this Applied Pattern will each have been specialized for use in this model. Such a specialized version of a Generic Function is called an Applied Function or AF. We can now plot this idea on the first stage of the OIAm Workflow. In this stage, the architects select one or more Generic Services from a library, and from that find the Generic Patterns that can realize those services. If multiple Generic Patterns are found, they can combine them into a single pattern. They can now select which Generic Functions to keep, leave out, and/or add. Then the architects can specialize the Generic Functions (among other by adding quality attribute levels) into implementation specific Applied Functions; the Pattern as a whole thus becomes an Applied Pattern, a specialization of the original Generic Pattern(s). The resulting functional model is one of OIAm’s core benefits for the architect, as the Applied Pattern enables the architect to provide the designer with a comprehensive description of the functionality required from the infrastructure facility under design. But a model created according to the OIAm best practices offers more: it can be used not only in the project in which it was created, but also in all subsequent efforts that require information at the architectural level about the target infrastructure facility.

---

' References