I’ve touched on this subject briefly before, but I wanted describe it more directly. The simplest definition of domain knowledge, for me, is: what you need to know to create and apply effective solutions in a specific situation. Acquisition, of course, is the process of gaining that knowledge.
If that seems vague it’s because we have to understand what “situation” we’re actually working in when crafting a solution. When I implemented FileNet-based document imaging solutions for business process re-engineering efforts I might have been working across several competencies at the same time, but what did I actually have to know to do the job?
- Process Mapping: This comes in two parts. The first involves understanding a process through discovery and data collection. You have to be thorough. You have to be pleasant and engaging to get people to tell you everything you need to know. You have to recognize the important information when you hear it. The second is creating the requisite documentation using some method, which these days more or less always involves knowing how to use one or more complicated software programs. You may or may not need to know how to do that yourself, but someone on your team does.
- Business Case Analysis: This could also be called Cost-Benefit Analysis. It involves calculating the difference between the benefits of a proposed change and the cost of implementing it. If you can do these calculations in terms of money it makes things easier, but other factors may be involved. If the costs and benefits are readily identifiable it takes less expertise to run the numbers, but more complex assessments may take additional experience and even entrepreneurial judgment.
- Document Analysis: For a process that involves many thousands of pieces of paper a day it’s important to be able to classify them and identify the relevant information on them. Our customer had developed an ingenious manual filing system that collated the arriving documents into custom-made folders that clasped the received documents in three easy-to-thumb-through collections so they were able to give us guidance on the sorting system they used. Without this guidance we would have had to do a lot more work to understand the documents and create our own sorting criteria.
- Document Imaging Systems: The FileNet system included hardware components for scanning documents and then storing the images (using a robotic system of removable optical disk cartridges that automatically optimized the storage locations of the cartridges to minimize the travel time of the robotic mechanism based on the frequency of access of the items stored on them), and a WorkForce software component that ran on a network of PCs connected to a central server that contained the database information on each perspective customer and each employee, as well as links to the related documents.
- Computer Programming: General: Implementers had to come to this work already knowing how to program computers. The FileNet WorkFlow language was obscure enough that it was never the first language anyone learned.
- Computer Programming: FileNet WorkFlow language: When I used it the WorkFlow language was a loose combination of Pascal and BASIC with special functions to interface with the dedicated scanning and storage hardware, document and item queues, and mainframe access terminals. FileNet was in the process of creating a version called Visual WorkFlow that allowed the programmers to graphically define parts of the flow of documents, information, and work items within the system, but I never saw that in action.
- User Interface Design: This is a whole field on its own, with a lot of specialized knowledge. By the time I worked on this I had been programming user interfaces graphically and in text for a number of years. I had even written my own text-based, mouse-driven windowing framework several years before. The basics aren’t that difficult to learn and can be picked up in a couple of weeks of initial training.
- Database Schema Design: This is also a field that can get as complex as you’d like, but schemes for most applications are pretty simple; it’s what you do with the data that makes it work. The FileNet system used an Oracle back end, but the WorkFlow programmers didn’t need to know anything about Oracle per se to make use of its capabilities.
- Mainframe Data Interfacing: There are many ways to get computers to talk to each other but this one was unique–it used a process called screen scraping.
- Automated Microsoft Office Document Creation: Some Microsoft (and other) products included the ability to be manipulated by other programs using an interface protocol called Dynamic Data Exchange (DDE). Using this capability required an understanding of the controlled product, content management principles, and programming in general.
- Medical Records Processing: This is a potentially huge field by itself. It includes considerations like security, procedure coding, and the use of specific medical language. If something isn’t understood then intelligent questions have to be asked. Our customer had a process for this, where questions were written up for certain files and routed to specialists who would call the physicians for clarification. (Since the people making the calls were not trained doctors themselves the people they called would sometimes get highly annoyed.)
- Insurance: Disability: The insurance field covers many specific areas, and disability is just one type of insurable risk.
- Insurance: Underwriting: The decision to grant insurance coverage to a potential customer, and the rates to charge, are the result of a complex process of evaluation and calculation. The cost of underwriting and servicing a new pool includes the cost of evaluating whether to grant coverage to every pool whether they are accepted or not.
- Insurance: Actuarial Calculations: A major component of providing insurance is the ability to evaluate the occurrence rate of specified outcomes across large populations. The training required to do this work is extensive, and requires up to ten individual certification exams and a heavy mathematical background.
- Insurance: Investment Portfolio Management: Insurance companies must manage a lot of capital as it’s being held against the need to pay benefits over time. My father was a fixed income institutional investor for decades. That specialty has a lot of overlap with what I do and requires a similar personality type.
- Insurance: Claims Processing: This involves several components including communication, submission and reply processes, bank transfers, tax considerations, procedure and condition coding, and so on.
It should be clear that knowledge of some of these subject matter areas was required to automate the paper-handling aspects of the re-engineering process, especially as that project was handled in two phases. In the first phase we primarily used the skills of process mapping (with light data collection) and business case analysis and to a lesser extent our experience with document analysis and document imaging systems. Once we won the right to do the implementation the detailed computer skills came into play. It might have touched on supporting user processes (like the scoring of individual files and pools thereof) during the implementation phase, where screens had to be designed and calculations supported that allowed the underwriting department to perform its evaluations. In those cases the investigators and implementers can learn what they need to know from the subject matter experts they’re working with. The important thing to recognize is that for the most part the process mapping we did involved processes that anyone could analyze and understand. It required exactly zero special knowledge or training to understand how pieces of paper were received, collated, moved, and reviewed, so the real domain we were operating in wasn’t insurance, per se, it was document processing — which was our area of expertise..
This is relevant to me when recruiters and companies ask for specific domain knowledge. I think they often view the problem too narrowly in terms of industries. Some skills, like discovery, data collection, process mapping, and process improvement (in terms of the arrangement of steps) translate to any situation, as I believe I have more than demonstrated. Other skills, like actuary science, thermodynamics (and calculus), and specific elements of computing, are more specialized and are far more difficult to learn from subject matter experts on the fly. Many situations fall in the middle of this spectrum. For example, I knew nothing about border operations when I started analyzing and simulating them, but I had all the general skills I needed to understand and analyze them. Did I get better as I gained more experience and had seen dozens and dozens of ports? Sure, but that didn’t mean I couldn’t hit the ground running.
Domain knowledge is acquired in two major ways. One is through specific skills training and industry experience. The other is through being able to learn from subject matter experts on the ground. If the business or process analysts are sharp, communicate well, and can establish good rapport with such SMEs, they can implement solutions under the guidance of the SMEs with the proper feedback and direction. I discuss this feedback here. The effort is always cooperative, and learning how to learn from and engage with your customers is critical.