In this last post on the infrastructure domain, I cover the fifth and final viewpoint that is important for an infrastructure domain representation, and that is the location view. As mentioned in previous posts, the viewpoints I think are most representative of the infrastructure domain are:
Like with the component view, the location view is a layered approach. While I initially wanted to call it the network view, "location" might be a broader term that matches the content better. Still, it's not a perfect name, but the name is less important than the content, not?
When an organization has an extensively large, and heterogeneous infrastructure, infrastructure architects will attempt to make itless complex and chaotic by introducing and maintaining a certain degree of standardization. While many might consider standardization as a rationalization (standardizing on a single database technology, single vendor for hardware, etc.), rationalization is only one of the many ways in which standards can simplify such a degree of complexity.
In this post, I'd like to point out two other, very common ways to standardize the IT environment, without really considering a rationalization: abstraction and virtualization.
When using virtualization extensively, you will pretty soon hit the limits of your system (at least, the resources on it). When the virtualization is used primarily for testing (such as in my case), the limit is memory. So it makes sense to seek memory optimization strategies on such systems. The …