CCIE or Null!

In my last post we briefly looked at the TOGAF ADM. We won’t be able to fit it all into a single blog post but we will start to explore the ADM from a high level. ADM stands for Architecture Development Method and it organized in 10x different phases. These different phases are designed to assist organizations with keeping their business objectives & goals aligned the associated IT organization. IT departments have grown to be an important part of everyday business and even though we are in 2019 some companies still struggle with the relationship of aligning the business goals and their IT acronym jargon. The ADM works in a scalable phased approach allowing the left hand (the business) and the right hand (the IT department) to collaboratively work through meeting the desired objectives. Without further ado let’s jump in!

Preliminary Phase: The Preliminary Phase is an odd one, because it is outside of the phased ADM cycle however it is an important phase because this is when the architects get together and begin defining how the ADM will be interoperate within the company.

The following are outlined during the preliminary phase:

• Architecture principles – Principles that align with the business and IT principles which will provide high level guidance on how the architecture team operate.
• The scope of the enterprise – This how the architects determine how much of the enterprise they want to interact with and govern. The scope of the enterprise can also be broken apart by architecture partitions depending on the size and/or business goals of the Enterprise, or the different business units).
• Creating the architecture team.
• Identifying other processes that the TOGAF may need to interoperate with. (ITIL, change management, PMO, etc)
• Governance methods.

Phase A: Architecture Vision: This is essentially the beginning of the architecture work and is kicked off by a Request for Architecture Work where a member of the enterprise wants to accomplish a goal and requires the architecture board to oversee the task. One of the big key points is to ensure the architecture work is sponsored by a high level member of the enterprise to ensure the architecture team has the authority and political backing to manage the project.

In Phase A, we our primary focus is to gather as much information as we can about the request. This where we ask the important questions:

• What are the business goals.
• Who are the stakeholders, what are their concerns or constraints, and creating a communication plan for keeping the stakeholders informed as the architecture work progresses throughout the ADM. Let’s also keep in mind the stakeholders might not be only on the business side, you will likely have stakeholders on the IT/IS side depending on the scope of the project.
• Define the target architecture and identify risks that may concern the stakeholders during the journey of getting too that target architecture.
• Develop / define the architecture vision and secure approval for the Request for Architecture Work document.

Phase B: Business Architecture: In Phase B, we continue to build off the information we gathered in Phase A. We continue our conversation with the stakeholders and determine each of their concerns. These concerns can be referred to as a view this ensures we know what each stakeholder is looking for allowing us to meet each of their requirements of the project. If the stakeholders do not feel their deliverables have been met they might not consider the project a successful.

We also need to consider what business processes are existing today (baselines) and what the target business architecture is. Once we know where we want to be, some type of gap analysis will be performed to identify what deliverables need to be implemented in order for today’s baselines architecture to meet tomorrow’s target architecture. Once we have gathered all the information we should have a complete business architecture document.

Phase C: Information Systems Architecture:  Phase C is really broken down into two separate domains, both of the domains follow a similar pattern and can be carried out simultaneously. TOGAF understands the importance of focusing in both the data & system/applications separately:

Data Architecture – Here we are talking about the data. TOGAF places emphasis and importance of the actual data, an important element that has not been brought up yet is the concept of building blocks and re-usability, if we can re-use this same data in another application or project that can minimize effort down the road making further project easier and potential cost loss. That is just one (or two) reasons why the data architecture is important.

Understanding that data architecture comes from knowing:

• What data the stakeholders need.
• What data do we have today (Baseline architecture), can any existing data models be re-used?
• What data do we need to compile or collect to accomplish the desired architecture (target architecture).
• This will lead you to perform some type of gap analysis, and then create potential roadmaps to get to your target architecture.

System/Applications Architecture – This sub-phase is conducted similar to the data architecture section, replace the the word data with application and add in any specific application or software flow diagrams.

• What software/applications do we have today (Baseline architecture), can any existing applications models be re-used?
• Define your application or functionality matrixes/diagrams. We are still very early in the ADM so most deliverables are still high level but having an understanding of what business process is linked to which application feature & what data each feature may need to interact with. We also may start considering user roles and permissions.
• This will lead you to perform some type of gap analysis, and then create potential roadmaps to get to your target architecture.

Phase D: Technology Systems Architecture: The is where we starting to consider the communications and compute requirements for accessing the data and applications. Since my experience is on the networking side of the world this is typically where I would really getting involved in some discussions. Hopefully though I would already be aware of this, as I should have been identified as a stakeholder in Phase A.

Phase D, follows a similar path as to what we did in Phase C, however it will be specific to the system/network concept.

• Are their existing technologies standards or implementations that can be used.
• Understand your baselines and target architectures.
• This will lead you to perform some type of gap analysis, and then create potential roadmaps to get to your target architecture
• Gather the requirements from the stakeholders, some key points you want to understand are the desired performance, availability requirements, latency, etc.
• What kind of diagrams or models will need to understand and convey the architecture deliverables.

From a quick high level, Phase B, C, & D following a similar routine however they each focus are their specific knowledge domains. Now, to keep this post from running away, I am going to be stopping here. The ADM is a powerful and detailed methodology, my goal here was to give a simple overview, we will continue exploring the TOGAF ADM in my next blog post.

Random Note: I created all the images in this post using a mind mapping application for note taking during my TOGAF studies. Sometimes mind maps can get a little out of control but I hope this format worked out well for presenting the ADM and the high level steps of each phase.