Episode 31 - Architecture Content Frameworks

Hey, what's up everybody, you're listening to the enterprise architecture radio, if you're thinking about organizational complexity and agility, if you're concerned about operational efficiencies and thinking of taking it to the next level, if managing innovation is one of your priorities, you've come to the right place. On this podcast, we talk about all of that, and more. It's a jungle out there. And we'll attempt to navigate this jungle of frameworks, methods, and most importantly, Enterprise Architecture in practice.

​

Yesterday was International Women's Day, I'd like to start this episode by sending my wishes to all my women listeners, I wish you a very Happy International Women's Day. May you continue to break barriers, people deserve options and the boundaries of your capabilities continue to be as amazing as you are inspiring everyone around you. Yesterday was also holy, incidentally, the Festival of Colors in India, I'd like to wish all my listeners a very Happy Holi. While you may or may not have celebrated the festival, the way we celebrate in most parts of India, it continues to be a day when people wish happiness and colors in everyone's life. And I would like to do the same for you.

​

It's been a while since I talked about TOGAF and Enterprise Architecture. Well, I did talk about EA In my last episode. But I haven't specifically talked about TOGAF for a while.

And I bring this topic up today, because recently I was having a conversation with someone I know. And this person also happens to be a TOGAF trainer. And he has had many years of experience doing what he does, which is trainings and TOGAF. And he's worked with many training organizations, and he's worked with international organizations doing his trainings, corporate trainings, online trainings, and what have you. And I, during my conversation with him came to realize that his concepts are not very clear,

​

specifically around content framework. So I thought I'd dedicate this episode to the enterprise architecture content framework, what it is, and see if I can explain the concept a little bit.

​

Now, within TOGAF, the Enterprise Architecture content framework is a part of the overall framework, there are five parts of TOGAF. One of them is the content framework. But majority of the Enterprise Architecture frameworks are called Enterprise Architecture frameworks, but they're really not Enterprise Architecture frameworks, they're more of a content framework. And there used to be a long period of time when these two could be used interchangeably. Because there was a time when people used to think that an Enterprise Architecture Framework is really a framework around all the information that you need to collect about the enterprise. So so it's a comprehensive list of all the architectural artifacts that you'd have to work to collect information about the enterprise. And so it was used interchangeably. But then what happened is, over a period of time, some of the Enterprise Architecture frameworks started getting more and more mature, specifically TOGAF. Now, I did come across another Enterprise Architecture Framework recently, that seems to have more than just the content framework. And I need to study that a little bit deeper before I can talk about it in detail. So I'm going to defer that topic for a while.

​

But barring that particular framework, most of the Enterprise Architecture frameworks that exist today, are primarily content framework. So let's talk about the content framework. A little bit more. I already told you that it is a comprehensive list of all the architectural artifacts that you're going to work on, while doing enterprise architecture work. So when you're collecting information about the enterprise, different aspects of the enterprise, different parts of the enterprise, you will work on architectural artifacts. So the content framework provides you with a comprehensive list of all the artifacts that will help you collect information about your enterprise. Now, different frameworks have different ways of collecting that information.

​

It's only fair that I start with the Zachman framework that was the first Enterprise Architecture Framework ever. In fact, John Zachman is the father of enterprise architecture and is the man who originally coined the term enterprise architecture. So let's start with the Zachman framework. What Zachman framework essentially does is it has a six by five matrix. On the y axis you have six questions

​

So what, how, where, who, when, and why. And on the x axis, at the highest level, you have the executive perspective.

​

Under that you've got the business management perspective, under that you have the architect perspective, under that you have the engineer perspective. And then we have the technician perspective. And then the combination of these, basically, from different point of views of how you look at the enterprise. Now, let's take the combination of what, and the executive perspective, executive perspective is the x axis, what is the question? So we find a, a sort of intersection of what an executive perspective, this will have a list of all the inventory types, right? What would an executive want to see? When he asks the question? What, right? Similarly, how, when an executive, or a senior business professional asks the question, How is this done within my enterprise, you'd like to see processes, right, different processes within the organization. So we have a list of all the different process types.

​

What would a senior business person want to see when he asks the question? Where is this? And this could be anything within his enterprise, or business? or what have you. So where is this? So all the different distribution identification, so different asset types and where they are located? Really, it's basically a list of that. And then we come down to the business perspective. And then we come down to the architects perspective. And we, we provide a list of architectural artifacts essentially, that a particular stakeholder would like to see, when they ask the question, what how, where, who, when, and why. Right. That is an example of a contract. Now, obviously, there's quite a lot of more to Zachman framework than just just this much. And I can only cover I'm just giving you a very high level view. And there is a five, four or five day program that John Zachman himself conducts, that you would have to attend to be able to truly understand Zachman framework.

​

But this is a high level perspective. And, and I'm going to talk about other frameworks as well. Let's take a look at the TOGAF framework.

​

Now, the TOGAF framework has five different parts. And the content framework is just one of those five different parts. So TOGAF framework really identifies the content framework as the content framework. And then it specifies that there is more to an Enterprise Architecture Framework than just the content framework, there is an architecture development method, there is a architecture repository, there is a number of things now, let's focus on the content framework. So to understand the current framework in TOGAF, you need to have a brief understanding of what the architecture development method is.

​

It's a method to develop architecture, it's split into a number of phases. Well, the first few phases are preparatory phases in which we try to understand how we are going to do enterprise architecture, we pick a good framework, we build an architecture body, we select a tool that will essentially help us in collecting information about the enterprise, etc, etc. And then we go into the requirement gathering, it's not very different from software development lifecycle, we just do it at a much more higher scale, we try to understand the vision of the organization, the strategy and

also the immediate next transformation that we would like to do at the enterprise level. And then we get into the design phase, where we build all the architectural artifacts that we need to build to collect information about the enterprise and then there is a planning phase and there is an execution and a governance phase. And then finally, there is a change management phase. And there are phases within each of these. So you know,

not going to get too much into it. The content framework is linked directly to the architecture development method. What that means is,

well, there are three types of architectural work products within TOGAF content framework, we have deliverables, artifacts, and building blocks and and deliverables are large contractual documents that we need to prepare to start any project. It could be a Statement of Work document or contract, some kind of a large document accurate a deliverable document, and so on. And then we have artifacts which are there are three types of artifacts there is catalogs, matrices, and diagrams, catalogs are lists of things. So if you're building a stakeholder catalog, what that means is you're making a list of all the stakeholders that are involved as a part of this large transformation. Our matrix is basically data in a tabular format and add a diagram Everybody knows what a diagram is. Now, these three types of artifacts, catalogs, matrices, and diagrams are either lists of things, tables of things, and diagrams of things. Now, these things that we're talking about, are really architectural building blocks. So when you say, I'm building a list of stakeholders, each stakeholder is a building block, when I'm saying I'm building a list of databases, or a catalog, or a matrix of databases, and which applications are accessing which database, so each application and each database is really an architectural building block.

​

Now, I just mentioned three different types of building blocks. I said, stakeholders, databases, and applications, how many more types of architectural building blocks are there? This is defined by the architecture content metamodel. The architecture content metamodel is essentially a really long list of all the different types of architectural building blocks that exist within the TOGAF framework. And what are the possible relationships between them. So a stakeholder accessing a database is a relationship, for example, or a stakeholder using an application is another relationship and so on and so forth. So the architecture content metamodel, to repeat, is a list of all the different types of building blocks that can exist within the content framework. And their relationships within

a artifact is either a catalog or a matrix or a diagram, which is essentially showing the relationships between all the different types of building blocks within the given context, right? Again, the content metamodel also has relationships between building blocks, but it shows all the possible relationships that can exist.

​

But do they exist in the real world, that is shown either by a catalog, a matrix or a diagram, a diagram will exactly show you which stakeholder is accessing which application, etc, etc, right? It's the relationship between different building blocks in the given context of this particular transformation.

​

And then we have architectural deliverables that contains all the different artifacts that we are going to be building within it. So a deliverable contains within it, different diagrams, and lists and matrices, and so on and so forth. That essentially represents the architecture of our current context that we can show to our stakeholders.

​

Now, I have told you earlier that the architecture content framework is connected to the architecture development method. Let me try to explain the connection between the architecture content framework and architecture development method. I explained to you the different phases of the architecture development method. Now, depending upon which part of the architecture development method you are in, the list of what you are going to work on will change. So for example, let's say that you're in the design phase. Now within the design phase, there are four types of design as explained in the architecture development method. Within TOGAF. There are business architecture, there's data architecture, there's application architecture, and there is technology architecture.

​

Now, if you're within the business architecture phase, the content framework specifies the exact deliverables that you can work on the exact catalogs matrices and diagrams that you can work on, that will primarily focus on business stakeholders, so it will focus on people, it'll focus on different business processes that exist within the organization, the organizational structure, etc. All the catalogs, matrices and diagrams that you're going to be working on, will collect information about the organization. From that perspective, from a business perspective, if you're in the data architecture phase, then you will collect information about how the data exists within the organization. And it will primarily be related around the concerns of data, which is data analysis, data gathering, data processing, data transformation, etc. When you're doing application architecture, all the catalogs matrices and diagrams will be around applications. So how are the applications integrated with each other which business processes are actually accessing which application or need which application which application has, what kind of data etc, etc. Of course, it has integrations a data architecture and business architecture as well, but primarily the focus area is application architecture. So the content framework, when I say is linked with the architecture development method, what I mean is the list stuff called architectural artifacts are primarily focused around which phase of the architecture development method you are in. So for an architect, the architecture contract framework being linked to the architecture development method makes visualizing the enterprise much easier when I'm working on a particular phase of EDM.

I will only focus on concerns which are related to that particular phase. So when I'm doing business architecture, I focus on the business when I'm doing data architecture focusing on the data, I bring in the specialists that I need to gather that kind of information.

​

And I build my designs. So that is the architecture content metamodel. And the architecture content framework within the TOGAF framework.

 

So all the different Enterprise Architecture frameworks like DoorDash, and PDF, and all that are really architecture content frameworks, they're not really full fledged Enterprise Architecture frameworks, but because they do not contain within them. More than just what we are supposed to be building the content framework within TOGAF also contains the same thing. It contains a list of all the different artifacts that we can build, to collect information about the enterprise for people who are new to the enterprise architecture world, and the TOGAF world. I hope that clarifies the meaning of architecture content framework. Now, I understand this is the theoretical subject a little bit. And I'm sure you have questions. And that's exactly why this podcast exists. Please feel free to reach out to me all my contact details are there in the show notes. If you have any questions or any suggestions about topics that I can cover as a part of the podcast, I'm always looking for that kind of feedback.

​

If you consider yourself somewhat of an expert in any areas related to it, or enterprise architecture, please feel free to reach out to me and we can work on an episode. I'm really looking forward to inviting guests to my podcast.

​

That's all I have for you today, folks, I hope you enjoy the show more about organizational agility, innovation and enterprise architecture in the practical world, in the business writer on the show. But before I end the show, I want you to help me out with this one little thing. Pause the show and share this podcast via WhatsApp or text message with at least one person who might be interested in the show. It could be anyone, your colleague, your boss, someone in your team. That's all I ask just one share with one message via text or WhatsApp, or any social media of your choice. And it would go a long way in supporting this podcast and growing this listener base. Also, please don't forget to follow the podcast that way. You'll get notified when we publish a new episode. If you want to find out more about us. You can find us at Enterprise Architecture radio.com. If you have ideas, thoughts, disagreements, please feel free to write to me directly. We also have a telegram group if you would like to contribute to the discussions or what have you. Just search for Enterprise Architecture radio on telegram or the URL to join the group is https colon slash slash t.me/enterprise architecture radio.

​

While our contact details are there, the show notes were very easy to find. Just search for Enterprise Architecture radio anywhere Twitter, LinkedIn, Facebook, Instagram, YouTube, even discord once again. I hope you had fun and I'll see you in the next one.

Transcribed by https://otter.ai