African Development Bank SANKOFA Program

Description: This presentation discusses the metadata strategy of SANKOFA, the African Development Bank’s new document and records management platform for development project activities. The design and definition of metadata, and the strategies for automating its generation are briefly described. Best practices for file plan and metadata design, validation, implementation, and maintenance in a multilateral financial institution setting are discussed. The African Development Bank is a leader in documentation of development project activities and promotes best practices for the provision of disclosure and access to information. Presented by Joseph Busch, Taxonomy Strategies’ principal analyst at the DCMI 2023 Best Practices Session in Daegu, South Korea on November 9, 2023

Venue: DCMI

Date: November 9, 2023

Broad Topic: Metadata

Watch Presentation

Video Script

[Slide 1] African Development Bank SANKOFA Program

DCMI 2023 Best Practices Presentation, Daegu, South Korea, November 9, 2023

Abstract: This presentation discusses the metadata strategy of SANKOFA, the African Development Bank’s new document and records management platform for development project activities. The design and definition of metadata, and the strategies for automating its generation are briefly described. Best practices for file plan and metadata design, validation, implementation, and maintenance in a multilateral financial institution setting are discussed. The African Development Bank is a leader in documentation of development project activities, and promotes best practices for the provision of disclosure and access to information.

[Slide 2] Project context

The African Development Bank (AfDB) is a multilateral development bank with the overall goal of sustainable economic development and social progress in African countries that contributes to poverty reduction. The Secretary General (PSEG) has the mandate to provide leadership and sponsorship of the implementation of Bank policy and enabling compliance with it. This includes implementation of records management (RM) and disclosure and access to information (DAI) policies. In practice this means the capture and storage of documents and metadata across activities, from drafts to the final version. The overall goals are to transform the current business practices where documents have been created and stored mostly on personal computers, reviewed and approved using email and hard copies, and shared as email attachments. The desired future state is to break down these silos, implement common business processes among and across business units, regions and country offices, build a shared online collaboration and document repository, and to ultimately achieve the Banks top priorities—The High Fives: Light up and power Africa, Feed Africa, Industrialize Africa, Integrate Affrica, and Improve the quality of life for the people of Africa.

[Slide 3] Metadata enablement goals

One of the key bottlenecks in international development is the appraisal and approval of projects. This involves a significant amount of documentation of project development activities prior to implementation. In developing countries, the size of projects varies widely, but the project budget is often smaller scale than in developed countries and the needs are greater. This adds up to more projects with smaller budgets that need to be on-boarded and managed. This is a major documentation challenge and potential project implementation bottleneck. SANKOFA is the African Development Bank’s (AfDB) new document and records management platform. SANKOFA aims to facilitate a digital transformation of the Bank’s documentation facility to address the project implementation challenge and to unify access to documents across all the Bank’s business activities, as well as to enable the disposition of the Bank’s records and their disclosure as appropriate.

[Slide 4] Development project phases and key document types

One method to facilitate collaboration in document production is templates and metadata, especially for key document types such as the reports that are generated in conjunction with each phase of the development project lifecycle illustrated in this slide [Table 1]. Templates enable standardization of the form, structure, and metadata of key document types. A template related to a specific type of report can be associated with the specific phase in the project lifecycle when that type of report is generated, and specific metadata and metadata values can automatically be filled in based on this context.

Project PhaseKey Record Types
ProgrammingCountry Strategy Paper
IdentificationProject Brief
PreparationEnvironmental & Social Impact Assessment
Appraisal and ApprovalProject Appraisal Report
Implementation/SupervisionImplementation Progress Report
Completion/CancellationProject Completion report

Table 1-AfDB development project phases and key reports.

It is important to classify documents with their correct business activity, project phase, and record type, and to tag them with a project code or other identifier such as an employee ID. This will enable the automatic population of important metadata associated with the record type, as well as metadata associated with the project or other enterprise entity. The business activity and record type are used to retrieve metadata from the records management file plan (plan de classement). The project code (or other identifier) is used to query and retrieve related metadata from the enterprise data applications. 

[Slide 5] Business classification scheme

A file plan is the documentation of a standard method for organizing documents so they will be filed and named in a systematic way. A file plan may be thought of as business classification categories, for example, by business function and activity, business activity phase, and record type as shown in this slide. [Figure 2] 

Figure 1-Sankofa File Plan Functions

Figure 2-SANKOFA File Plan Classification Levels (*Phase only applies to Development Projects)

[Slide 6] Function

To upload a document (or group of documents) to Sankofa, the first step is to select the function for which a document was created. In Sankofa, documents are organized based on the function or business purpose for which they were created. Functions are more stable than organizational structure which frequently changes. [Figure 1] This slide shows the 10 broad business functions at the Bank. These are common business functions that are applicable to any large organization.

[Slide 7] Activity

This slide shows the sub-functions or activities that are related to the Operations, Programs, Projects, and Initiatives function at the Bank. The Bank is particularly focused on the Project Lifecycle Management of sustainable development projects.

[Slide 8] Project phase

This slide shows the standard defined phases of the Project Lifecycle Management of sustainable development projects.

[Slide 9] Document type

This slide shows the start of the list of the document or record types that are related to the Identification phase of sustainable development projects.

[Slide 10] Business value and security metadata

Classifying documents with their correct function, activity, project phase (when appropriate), and record type enables effective record retention and disposition of the Bank’s records. In most cases, the business activity in the records management file plan identifies the business value of documents that are classified in that activity. 

[Slide 11] Retention and disclosure classification

Each business value has a set retention period associated with it as shown in this slide [Table 2]. The business value and retention period are the metadata parameters that are used to automate the appropriate disposition of items in the records management system as shown in this slide.

Business ValueRetention Period
Transitory2 Years
Essential10 Years
Important50 Years
VitalPermanent

Table 2-AfDB file plan business value classification.

Similarly, classifying documents with the correct record type enables the effective disclosure of and access to Bank information. It automates the identification of a document’s disclosure and access to information (DAI) class and level. The DAI class and level are the metadata parameters that identify the appropriate disclosure series in which the document belongs as shown in [Table 3]. The disclosure series in turn provides the triggers for automating the appropriate disclosure of and access to the items in the records management system.

ClassLevel
PublicPublic
RestrictedConfidential
Strictly Confidential

Table 3-AfDB file plan disclosure of information (DAI) classification.

[Slide 12] Record retention and disposition metadata

This slide shows the metadata (in bright yellow) that drives record retention and disposition. It’s fetched from the file plan and determines the appropriate record series to be used to calculate the triggers for record disposition events, for example, 10 years after the contract completion date.

[Slide 13] Disclosure and access to information metadata

This slide shows the metadata (in bright yellow) that drives disclosure and access to information (DAI). It’s fetched from the file plan and determines the appropriate disclosure series to be used to calculate the triggers for record disclosure events, for example, 10 years after the project completion date.

[Slide 14] Centralized file plan model

The master Sankofa file plan is updated using an iterative process as new business units are onboarded to the application. First, new business units identify which existing functions, activities, phases, and record types apply to their documents. Then any gaps are filled with new business classification categories, and any changes to existing categories are made. Finally, business value and DAI classifications are determined. Any conflicts with the master file plan are resolved, for example, harmonizing variant names for the same business activity or record type, and then any changes are made to the master. [Figure 3] This slide is diagram of the Sankofa file plan management model. The Sankofa application keeps track of which business units include which functions, business activities, project phases, and record types so that a specific business unit file plan view is displayed when that business unit uploads or searches for and retrieves documents for reference.

Figure 3-SANKOFA File Plan Management Model

[Slide 15] Editorial rules for activity and record type labels

Editorial guidelines and naming conventions are important for having a consistent file plan, records schedule, and for the disclosure and access to Bank information. The goals are to avoid duplicate categories, enable harmonization of similar categories, and provide predictable and reliable search results. [Table 4] This slide shows examples of the business classification scheme editorial rules. 

[Slide 16] Objective of naming conventions (editorial rules)

Standard naming conventions will improve predictability when staff are searching for an appropriate category when classifying new documents, or when they request a new category to be added to the business classification scheme, as well as when they are searching or browsing for documents in Sankofa. One of the biggest challenges in implementing an effective information retrieval application is confidence that you have found the specific document you are looking for, or confidence that the document truly does not exist in the system. 

RuleDescription
LabelUse the most common form of the label found in AfDB documents or other authoritative sources (called literary warrant). Prefer UK spelling and punctuation.
Plural vs. Singular Use the singular form for labels, e.g., “Agenda” or “Presentation”, except for collective nouns, e.g., “Minutes of Meeting” or “Regulations and Rules”.
Direct OrderDo not use inverted terms. Terms should be in direct order or qualified. E.g., “Annual Report” NOT “Report, Annual”, but “Correspondence (Internal and External)” is OK.
CapitalizationUse title capitalization. (Sometimes called camel case)
AbbreviationsSpell out abbreviations and acronyms unless the most common usage is the abbreviated form. Append the abbreviation, acronym, or spelled-out term to the label in parentheses. E.g., “Memorandum of Understanding (MoU)” or “Country Resilience and Fragility Assessment (CRFA)”
AmpersandDo not use ampersands. Instead, spell out the word “and” E.g., “Pictures and Videos” or “Quarterly Climate Change and Green Growth Report”. But the ampersand can be used in acronyms and abbreviations. E.g., “Operation and Maintenance (O&M) Contract”.
Special CharactersAvoid using special characters such as forward slash, m- and n-dash, etc. Note that m- and n-dashes may be separated from the noun phrases by spaces. E.g., “Protocol and Liaison Services (Executive Directors)” NOT “Protocol and Liaison Services – Executive Directors”
Compound NamesAvoid combining multiple activities or record types. Whenever possible make these two or more record types. E.g., “Activity Work Program” and “Action Plan”, NOT “Activity Work Program / Action Plan”.
Label LengthLabels should not exceed 255 characters.
HyphensFollow the most common UK usage. Generally, use a hyphen to link compound nouns and prefixes. Capitalize each noun in a hyphenated compound noun phrase. E.g., “Aide-Mémoire”.
Serial CommasIf a category name includes more than two items, separate the items with commas. The last item separated by “and” or “or” should NOT be preceded by a comma. 

Table 4-AfDB business classification scheme editorial rules.

[Slide 17] Project code metadata

Sankofa makes it very easy to add metadata labels and descriptions to documents when they are uploaded into it. Most project documents can be described by simply entering project codes, employee numbers, or other unique identifiers assigned in the Bank’s enterprise data management applications. Then those enterprise systems are queried using the entered identifier to automatically fill in the descriptive metadata for the new document(s). [Figure 4] This slide shows the descriptive metadata associated with “Annual Progress Reports”. By typing in the project code “G-Z1-GB0-TRN-003”, metadata values including the Activity Code, Description, and Manager; Trust Fund Description, Number, and Type; and Year, Region, Country, Sector, and Subsector are automatically filled-in. 

Figure 4-Sankofa document metadata 

[Slide 18] How metadata is used to filter documents

[Figure 5] This slide illustrates how metadata is used to filter document collections by country, division, phase, or sector in Sankofa.

Figure 5-Example of metadata filtering in Sankofa.

[Slide 19] Sankofa architecture

Document management supports the creation, collaboration, and use of operational documents. Some documents need to be managed more formally as records when they document organizational decision-making and policy. It is critical to separate these different types of information management into separate systems that are optimized for these different purposes. Sankofa is implemented on the Bank’s existing SharePoint and FileNet infrastructures. As illustrated in this slide Figure 6, SharePoint is used for document creation and management. Once a document “of record” is approved via an approval workflow, it is automatically archived as a non-editable PDF in FileNet, the Bank’s records management application. Further editing of the document in SharePoint renames it as a subsequent version of the approved record.

Figure 6-SANKOFA Application Architecture 

[Slide 20] Summary

The Bank’s practices to obtain complete and consistent metadata include: 

  • A core metadata standard for the Bank based on ISO 15836 – Dublin Core (creator, title, owner, and date; plus: function, activity, project phase, and document type​) that enables complete metadata​,
  • Editorial guidelines and naming conventions for controlled vocabularies, and 
  • The re-use of existing metadata from Bank applications and repositories (such as SAP and IBM FileNet) enables more consistent metadata. 

Practices focused on the right amount of ​metadata should result in:

  • Reduced errors, 
  • Relevant search results, and
  • Optimized staff time.​