In my job as domain architect for "infrastructure", I often come across stakeholders that have no common understanding of what infrastructure means in an enterprise architecture. Since then, I am trying to figure out a way to easily explain it - to find a common, generic view on what infrastructure entails. If successful, I could use this common view to provide context on the many, many IT projects that are going around.
Of course, I do not want to approach this solely from my own viewpoint. There are plenty of reference architectures and frameworks out there that could assist in this. However, I still have the feeling that they are either too complex to use for non-architect stakeholders, too simple to expose the domain properly, or just don't fit the situation that I am currently faced with. And that's OK, many of these frameworks are intended for architects, and from those frameworks I can borrow insights left and right to use for a simple visualization, a landscaping of some sort.
So, let's first look at the frameworks and references out there. Some remarks though that might be important to understand the post:
- When I use "the infrastructure domain", I reflect on how I see it. Within the company that I work for, there is some guidance on what the scope is of the infratructure domain, and that of course strongly influences how I look at "the infrastructure domain". But keep in mind that this is still somewhat organization- or company oriented. YMMV.
- While I am lucky enough to have received the time and opportunity to learn about enterprise architecture and architecture frameworks (and even got a masters degree for it), I also learned that I know nothing. Enterprises are complex, enterprise architecture is not a single framework or approach, and the enterprise architecture landscape is continuously evolving. So it is very well possible that I am missing something (and I will gladly learn from feedback on this).
The Open Group Architecture Framework (TOGAF)
If you would ask for one common framework out there for enterprise architecture, then TOGAF is probably it. It is a very exhaustive framework that focuses on various aspects of enterprise architecture: the architecture development methodology, techniques to use, the content of an architecture view (like metamodel descriptions), and the capabilities that a mature organization should pursue.
A core part of TOGAF is the Architecture Development Method cycle, which has several phases, including phases that are close to the infrastructure domain: "Technology Architecture (D)" as well as areas of "Opportunities and Solutions (E)" and "Information Systems Architectures (C)". Infrastructure is more than 'just' technology, but the core of it does fit within the technology part.
The ADM cycle, taken from The Open Group, TOGAF 9.2, Chapter 4
With TOGAF, you can support a full enterprise architecture view from the strategy and vision up to the smallest change and its governance. However, the key word here is support, as TOGAF will not really give you much food for simply representing the scope of infrastructure.
I'm not saying it isn't a good framework, on the contrary. Especially with ArchiMate as modeling language (also from The Open Group), using TOGAF and its meta model is a good way to facilitate a mature architecture practice and enterprise-wide view within the organization. But just like how application architecture and design requires a bit more muscle than TOGAF's metamodel supports, the same is true for infrastructure.
There are also plenty of other enterprise frameworks out there that can easily be mapped to TOGAF. Most of these focus mainly on the layering (business, information, application, technology), processes (requirement management and the like) and viewpoints (how to visualize certain insights) and, if you're fluent in TOGAF, you can easily understand these other frameworks as well. I will not be going through those in detail, but I also do not want to insinuate that they are not valid anymore if you compare them with TOGAF: TOGAF is very extensive and has a huge market adoption, but sometimes an extensive and exhaustive framework isn't what a company needs...
TOGAF Technical Reference Model / Integrated Information Infrastructure Reference Model
As TOGAF is extremely extensive, it has parts that can be used to reference or visualize infrastructure a bit better. In TOGAF 9.1, we had the TOGAF Technical Reference Model (TRM) and TOGAF Integrated Information Infrastructure Reference Model (III-RM) where you might feel that this is closer to what I am seeking (for instance, III-RM).
Focus of the III-RM, taken from The Open Group, TOGAF 9.1, Chapter 44
While it does become a bit more tangible, TOGAF does not expand much on this reference model. Instead, it is more meant as a starting point for organizations to develop their own reference models.
Information Technology Infrastructure Library (ITIL)
ITIL 4 is another very common framework, this time owned by AXELOS Limited. The focus of ITIL is on process support, with many processes (sorry, 'practices' as they are called now) being very much close to what I consider to be part of the infrastructure domain. The practices give a good overview of 'what things to think about' when dealing with the infrastructure domain. Now, ITIL is not exclusive to the infrastructure domain, and the company that I work for currently considers many of these practices as processes that need to be tackled across all domains.
ITIL 4 Practices, taken from Value Insights, The ITIL 4 Practices Overview
Still, I do want to see some of the ITIL practices reflected in the generic infrastructure view as they are often influencing the infrastructure domain and the projects within. The ITIL practices make it possible to explain that it isn't just about downloading and installing software or quickly buying an appliance.
Reference Model of Open Distributed Processing (RM-ODP)
The RM-ODP standard has a strong focus on distributed processing (hence the name), which is a big part of what the infrastructure domain is about. If we ignore the workplace environment for a bit, and focus on hosting of applications, the majority of today's hosting initiatives are on distributed platforms.
Five viewpoints of RM-ODP, taken from MDG Technology for ODP - UML for ODP, SparxSystems
Within RM-ODP guidance is given on how to handle requirement management, how to document the processing semantics, how to identify the components, integrations and limitations of the systems, and how to select the most appropriate technology. The intention of RM-ODP is to be as precise and formal as possible, and leave no room for interpretation. To accomplish that, RM-ODP uses an object model approach.
Unlike the more business and information system oriented frameworks, RM-ODP has a strong focus on infrastructure. Its viewpoints include engineering, computational and technology for instance. The challenge that rises here however is that it sticks to the more engineering oriented abstractions, which make perfect sense for people and stakeholders involved in the infrastructure domain, but is often Chinese for others.
Personally, I consider RM-ODP to be a domain-specific standard strongly associated with the infrastructure domain.
Department of Defense Architecture Framework (DoDAF)
DoDAF is an architecture framework that has a strong focus on the definition and visualization of the different viewpoints. It is less tangible than RM-ODP, instead focusing on view definitions: what and how should something be presented to the stakeholders. The intention of DoDAF is that organizations develop and use an enterprise architecture that supports and uses the viewpoints that DoDAF prescribes.
DoDAF viewpoints, taken from "What is DoDAF Framework", Visual Paradigm
Unlike broad scale architecture frameworks that look at an enterprise in its entirety, my impression is that DoDAF is more towards product architecture. That makes DoDAF more interesting for solution architectures, which often require to be more detailed and thus hit closer to home when looking at the infrastructure domain. However, it is not something I can 'borrow' from to easily explain what infrastructure is about.
NATO's Architecture Framework (NAF) seems to play witin the same realm.
Sherwood Applied Business Security Architecture (SABSA)
The SABSA framework and methodology has a strong security focus, but covers the requirements from full enterprise view up to the solutions themselves. One of the benefits of SABSA is inherent to this security-orientation: you really need to know and understand how things work before you can show that they are secure. Hence, SABSA is a quite complete framework and methodology.
SABSA metamodel, taken from "A Brief History of SABSA: Part 1", sabsa.org
An important focus area in SABSA is the integration between services, which is something I am frequently confronted with at work. Yet unlike the more solution driven frameworks, SABSA retains its business-oriented top-down approach, which places it alongside the TOGAF one in my opinion. Moreover, we can apply TOGAF's development method while using SABSA to receive more direct requirements and design focus.
Its risk and enabler orientation offers a help to not only explain how things are set up, but also why. Especially in the sector I am currently active in (financial sector) having a risk-based, security-conscious approach is a good fit. The supporting list of attributes, metrics, security services, etc. allow for defining more complete architectures.
Control Objectives for IT (CObIT)
In a similar area as ITIL, the CObIT framework focuses less on a complete enterprise architecture framework and more on processes, process maturity, and alignment of the processes within the organization. I am personally a fan of CObIT as it is a more tangible framework, with more clear deliverables and requirements, compared to others. But like with most frameworks, it has received numerous updates to fit in continuously growing environments and cultures which makes it heavy to use.
The CObIT 2019 Core Model, taken from "Using CObIT 2019 to plan and execute an organization transformation strategy, ISACA.org"
The framework is less about the content of infrastructure and technology, and more about how to assess, develop, build, maintain, operate and control whatever service is taken up. However, there are references to infrastructure (especially when dealing with non-functionals) or controls that are actively situated in infrastructure (such as backup/restore, disaster recovery, etc.)
IT for IT (IT4IT)
The Open Group has a similar framework like CObIT, called IT4IT. It does have a reference architecture view that attempts to group certain deliverables/services together to create a holistic view on what IT should offer. But unlike the larger enterprise frameworks it focuses strongly on service delivery and its dependencies.
IT4IT Reference Architecture, taken from The Open Group IT4IT Forum
Within the IT4IT reference architecture, a grouping is attempted that maps on a value stream, starting from a strategy over the deployment up to the detection and correction facilities. This value stream orientation is common across frameworks, but often feels like the value is always to "add more", "deliver more". In my opinion, rationalization exercises, decommissioning and custodianship is too much hidden. Sure, it is part of the change management processes and operational maintenance, but those are extremely valuable areas that are not expressively visible in these frameworks. Compare that to the attention that risk and security receives: while security consciousness should be included at all phases of the value stream, security is always explicitly mentioned.
Several vendors have their own visualization methodology that represents more specific requirements from the domain(s) in which those vendors are active. These are generally domain-specific visualizations, even with a vendor-specific view. Such methodologies are nice to use when dealing with specific viewpoints, but I do not believe these should be considered "architecture" frameworks. They don't deal with requirement management, strategy alignment, and often lack functional and non-functional insights. Still, they are a must to know in the infrastructure areas.
If you are active in Amazon AWS for instance, then you've undoubtedly come across drawings like the one visible in "Wordpress: Best Practices on AWS". These drawings provide a deployment viewpoint that lists the main interactions between AWS services.
When you are more network oriented, then you've been immersed in Cisco's network diagrams, like the one visible in "Verizon Business Assessment for: Cisco PCI Solution for Retail". These network diagrams again focus on the deployment viewpoint of the network devices and their main interactions.
There are probably plenty more of these specific visualizations, but the two mentioned above are most visible to me currently.
There are plenty of frameworks out there to learn from, and some of these can be used to find ways of explaining what the infrastructure domain is about. However, they are often all very complete and require an architectural mindset to start from, which is not obvious when trying to convey something to outside or indirect stakeholders.
Few frameworks have a reference that is directly consumable by non-architect stakeholders. The most tangible ones seem to be related to the IT processes, but those still require an IT mindset to interpret.
As I mentioned in An IT services overview I try to keep track of the architecture and designs of the IT services and solutions in a way that I feel helps me keep in touch with all the various services and solutions out there. Similar to how system administrators try to find a balance while working on documentation (which is often considered a chore) and using a structure that is sufficiently simple and standard for the organization to benefit from, architects should try to keep track of architecturally relevant information as well.
So in this post, I'm going to explain a bit more on how I approach documenting service and solution insights for architectural relevance.
TOSCA is an OASIS open standard, and is an abbreviation for Topology and Orchestration Specification for Cloud Applications. It provides a domain-specific language to describe how an application should be deployed in the cloud (the topology), which and how many resources it needs, as well as tasks to run when certain events occur (the orchestration). When I initially came across this standard, I was (and still am) interested in how far this goes. The promise of declaring an application (and even bundling the necessary application artefacts) within a single asset and then using this asset to deploy on whatever cloud is very appealing to an architect. Especially in organizations that have a multi-cloud strategy.
Software as a Service (SaaS) solutions are often a quick way to get new capabilities into an organization’s portfolio. Smaller SaaS solutions are simple, web-based solutions which barely integrate with the organization’s other solutions, besides the identity and access management (which is often handled by federated authentication).
More complex or intermediate solutions require more integration focus, and a whole new market of Integration Platform as a Service (iPaaS) solutions came up to facilitate cross-cloud integrations. But even without the iPaaS offerings, integrations are often a mandatory part to leverage the benefits of the newly activated SaaS solution.
In this post I want to bring some thoughts on the integrations that might be needed to support customizing a SaaS solution.
My current role within the company I work for is “domain architect”, part of the enterprise architects teams. The domain I am accountable for is “infrastructure”, which can be seen as a very broad one. Now, I’ve been maintaining an overview of our IT services before I reached that role, mainly from an elaborate interest in the subject, as well as to optimize my efficiency further.
Becoming a domain architect allows me to use the insights I’ve since gathered to try and give appropriate advice, but also now requires me to maintain a domain architecture. This structure is going to be the starting point of it, although it is not the true all and end all of what I would consider a domain architecture.
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.