How to develop a complete picture of an organization's baseline architecture for TOGAF

Objective: To capture a view of the current state of an organization's existing IT architecture, as a baseline for comparing with the defined target state, identifying gaps that must be addressed and planning a programme of work for the migration.

Tool: Current state architecture modelling and documenting

Pre-requisite reading: Business Architecture (TOGAF phase B)

A fundamental activity during phases B, C and D of the TOGAF methodology involves developing complete views of an organization’s current state (baseline) and future state (target) processing capabilities. It is by comparing these two views, in the context of the IT vision and principles, which you developed during TOGAF phase A, that you can start to identify the gaps that must be addressed and the migration plan for achieving it.


This blog concentrates on the technique I have used successfully, to develop a baseline view that can develop a practical and useable understanding of an organization’s current state.

I will use other blogs to explain:

• How to build a complete picture of an organization’s targetstate. This will include the organization’s goals and objectives.
  
• How to conduct TOGAF phase E. This is where you’ll identify the gaps between the baseline and the target state.
  
• How to develop a migration roadmap. This plan will comprise a set of investment projects aimed at delivering new capabilities, and a set of reengineering projects aimed at transforming the existing cost structure.
  

FIRST PRINCIPLES: Before you start developing your baseline view, there are a few principles you should bear in mind:

1. Structure: You must organize the information you capture in a way that makes it accessible to the people who need to understand it and, more important, the people who will rely on the information to rapidly specify and execute the programme of migration projects you will identify during TOGAF phase E.
   
   The primary elements of structure you need are:
   
   
   
   • the ability to capture lists or catalogues,
     
   • the ability to cross-reference one catalogue against another, and
     
   • the ability to print, export and share the information.
     
   
   Packaged Enterprise Architecture tools provide this structure and are functionally rich. However, spreadsheets provide an adequate tool for capturing information on the baseline view, since they deliver ease of use as well as the structure you require. This blog assumes that you are using a spreadsheet to capture your current-state information.
   
   I will refer to this spreadsheet as the Enterprise Architecture Workbook or EAW. You will constantly build up workbook until you reach phase E in the TOGAF methodology (Opportunity and Solutions Management) that represents the pivot point in your Enterprise Architecture project, where the focus switches from data collection to planning. Phase E is where you start to analyse the current and target state information you've captured, identifying gaps and seeking solutions to those gaps.


2. Outcome: Keep in mind that the information you collect must provide the justification, scope and objectives for the various migration projects. Be thorough but focus your effort on the areas where the organization will benefit from most. My blogs on business architecture and the value chain should help you in this regard.


3. Artefacts: The information regarding the baseline architecture, which you capture in your Enterprise Architecture Workbook (EAW), will comprise the following elements:
   
   
   
   1. Catalogues: These are essentially separate lists (worksheets) of things that you wish to describe, including organizations, stakeholders, processes, applications, etc. Picture each list as a set of rows in a worksheet, with columns for each of the attributes you wish to record.
      
   2. Cross references: These are essentially worksheets where you map one catalogue against another so that you can record additional information in the intersecting cell. For example: if you cross reference organizational units against applications, you could record which departments use which applications (perhaps using colour) and the release level currently implemented (perhaps as text).
      

DEVELOPING YOUR CATALOGUES: Which may include the following:

1. Catalogue of business scenarios: A catalogue of the organization's value chain functions
   
   Use the value chain concept to develop an understanding of the organization's primary and secondary activities. Refer to my blog on the value chain model for some ideas [click here].
   
   
   
   1. Add a new worksheet to your EAW, to catalogue the value-chain functions.
      
   2. Name this worksheet Catalog Business Processes.
      
      
   3. Start with these columns:
      
      
      
      1. Column A = Identity: Every business activity must have a unique number (e.g., BS-sss (where sss is the value chain activity or scenario number).
         
      2. Column B = Name: Every business activity must have a unique name conforming to the convention “Action” “Object” (e.g., “Manage Relationships”, “Manage Sales & Orders”).
         
      3. Column C = Description: Every business activity must be clearly described so that you and others can start to have meaningful discussion.
         
      
      
   4. Add a separate row to describe each business scenario you identify in the value-chain analysis. You should expect to have a catalogue of between 10 and 20 business activities for a typical small-to-medium sized enterprise or a division of a larger organization.
      
   
   
2. Catalogue of business processes: A catalogue of the organization's business processes by value chain function (scenario)
   
   Use your model of the organization’s value chain(s) as a skeleton for developing a view of its business processes. Build upon that understanding by reading any available material and by conducting interviews with key business and technology decision makers and subject-matter experts. Review my blog on business architecture interviews, to get some ideas on how this can be done effectively [click here].
   
   
   
   
   1. Reuse the same worksheet you just added to your EAW and named Catalog Business Processes.
      
   2. Insert rows for 10 or more business processes, under each of the scenarios (activities) you identified during your value-chain analysis. Expect this number to grow over time, as you learn more about each part of the business. Focus on the value chain activities that fall within the scope of your project, although that may have to comprise processes that are effectively interfaces (that hand off work) into other competencies.
      
   3. Reuse the same columns:
      
      
      
      1. Column A = Identity: Every business process must have a unique number in the form BS-sss-ppp (where ppp is the number for the business process).
         
      2. Column B = Name: Every business process must have a unique name conforming to the convention “Action” “Object” (e.g., “Administer Leads”, “Administer Contract”). Note: I used the term "administer" for processes that are a collection of use-cases that include create/read/update/delete/list/view/etc.
         
      3. Column C = Description: Every business process must be clearly described so that you and others can start to have meaningful discussion.
         
      
      
   
   
3. Catalogue of stakeholders and/or organizational units: A catalogue of entities linked to value chain activities
   
   The breadth of detail you need about organizational units will relate to the scope of your Enterprise Architecture project and may focus on strategic business units and their main departments, or may focus on the teams in one department or business unit, or some other scope. Defining this scope is an important part of the framework phase in TOGAF.
   
   Validate your list of stakeholders (or organizational units) against your list of value chain functions. Make sure that you understand which stakeholders fulfil each function and the various provider/consumer relationships between them.
   
   
   
   1. Add a new worksheet to your EAW.
      
   2. Name this worksheet Catalog Stakeholders.
      
   3. Choose suitable columns (for example):
      
      
      
      1. Column A = Business Unit: Every business unit must have a unique number (e.g., BU-uuu).
         
      2. Column B = Name: Every business unit (and stakeholder) must have a name.
         
      3. Column C = Description: Document what the business unit or stakeholder does.
         
      4. Insert rows for every business unit and/or department within the scope of your project.
         
      5. Additional rows for individual stakeholders may be added under each business unit (e.g., BU-uuu-sss).
         
      
      
   
   
4. Catalogue of current-state applications: A structured list of all the applications being used across the organization
   
   There are many ways to develop a complete inventory of existing applications so I will use a separate blog to describe the approach I prefer to use. For the purposes of this blog, let’s assume that you’ll simply capture a list of applications as you become aware of them, perhaps organized hierarchically within either the business unit or the value chain where they are used.
   
   
   
   1. Add a new worksheet to your EAW.
      
   2. Name this worksheet Catalog CS applications.
      
   3. Choose suitable columns (for example):
      
      
      
      1. Column A = Identity: Every application must have a unique number and a row in the worksheet (e.g., CS-sss-aaa where sss is the value-chain identifier and aaa is the application number).
         
      2. Column B = Name: Every application must have a name.
         
      3. Column C = Description: Document what the application does.
         
      4. Column D = Vendor: Record the name and details of the supplier.
         
      5. Column E = Asset: For companies that manage or monitor applications using a specific mechanism, then you’ll find it useful to include that tag as a cross-reference (e.g., the application’s number in the asset register or the Enterprise Management tool like OpenView).
         
      6. Add any other columns that are appropriate to your project. I often include columns for the platform type (e.g., Linux, Windows, ...), the container type (Tomcat, JBoss, .Net, ...) the database type (e.g., Oracle, Open Source, Sql Server, ...) and various attributes such as “Stores sensitive data”.
         

The various catalogues you have developed above represent raw facts. In order to build an understanding of the baseline architecture you now need to use these facts as the dimensions of a matrix, in which you can start to add details that will enable you to analyse the information and justify decisions you make later in the TOGAF process. So, let’s talk about a few matrices you might find useful.

DEVELOPING CROSS-REFERENCES BETWEEN CATALOGUES: Which may include the following:

1. Processes versus Stakeholders: A mapping of business scenarios and business processes against organizational units and/or stakeholders.
   
   This cross-reference worksheet is used to understand the link between value chain activities (described using your process catalogue) and the various business units, departments or user communities (described using your stakeholder catalogue).
   
   
   
   1. Add a new worksheet to your EAW.
      
   2. Name this worksheet Map Process-to-Stakeholder.
      
   3. Link the rows to the “Catalog Business Processes” so that columns A (identity) and B (name) get replicated automatically.
      
   4. Link the columns (starting at column E) to the “Catalog Stakeholders” so that rows 1 (identity) and 2 (name) get replicated automatically.
      
   5. Fill in the content of the intersecting cells with any information that is appropriate to the goals of your enterprise architecture project. This might typically include an indication of which stakeholders are responsible for (i.e., own) the process, which provide input (i.e., supply) to the process, and which care about the output (i.e., demand) from the process. This knowledge will prove very useful when you want to interview people about the process, to understand it in greater detail.
      
   
   
   
2. Processes versus Applications: A mapping of business scenarios and business processes against applications that currently exist and are performing that function.
   
   This cross-reference worksheet is used to understand the link between value chain activities (described using your process catalogue) and the various applications that are being used around the organization (described using your current-state application catalogue).
   
   Two significant points to mention here:
   
   
   
   • First, your catalogue of business processes must be defined at a consistent level of detail. Therefore, it is quite normal that many applications will be performing more than one process. It is also quite possible that one application is not performing all of the processes you’ve specified for a scenario, because people buy tools that meet their needs rather than all their wants.
     
   • Second, you should expect that more than one application (and possibly several) will be performing the very same set of processes, since process redundancy is a common curse in enterprises everywhere.
     
   
   
   
   
   1. Add a new worksheet to your EAW.
      
   2. Name this worksheet Map Process-to-Application.
      
   3. Link the rows to the “Catalog Business Processes” so that columns A (identity) and B (name) get replicated automatically.
      
   4. Link the columns (starting at column E) to the “Catalog CS applications” so that rows 1 (identity) and 2 (name) get replicated automatically.
      
   5. Fill in the content of the intersecting cells with any information that is appropriate to the goals of your enterprise architecture project. This might typically include a simple indication of which applications are performing that function and any details you wish to record about how the application operates (e.g., limitations in functionality, where manual intervention is required, where interfaces are available). This knowledge will prove very useful when making decisions over which of the existing (baseline) applications are good candidates for migration to the future state.
      
   
   
   
3. Applications versus Organizations: A mapping of existing applications against the organizations that currently use them.
   
   This cross-reference worksheet is used to understand the link between the various applications that are being used around the organization (described using your current-state application catalogue) and the business units or departments within the scope of your project (described using your organization catalogue).
   
   
   
   
   1. Add a new worksheet to your EAW.
      
   2. Name this worksheet Map Application-to-Organization.
      
   3. Link the rows to the “Catalog CS applications” so that columns A (identity) and B (name) get replicated automatically.
      
   4. Link the columns (starting at column E) to the “Catalog Stakeholders” so that rows 1 (identity) and 2 (name) get replicated automatically.
      
   5. Fill in the content of the intersecting cells with any information that is appropriate to the goals of your enterprise architecture project. This might typically include a simple indication of which applications are being used by which part of the organization. This knowledge will prove to be useful when you need to understand which parts of the organization will be affected by the transformation plans you develop later.
      
   
   

Blogger: