Heading Off Misunderstandings at the Gap

Any time people from different domains of expertise need to collaborate, things go better with a common understanding of the terms used to describe the components and facets of the projects they’re engaged in. Coming from different professions, environments, and perspectives, project participants can find themselves unfamiliar with the language being spoken. Words, phrases, or acronyms may be used in a sense outside our experience or be entirely new. Being that misunderstandings have a cost in time (read: $$), quality of results, and quality of relationships, making an investment in clarity up front has rewards. That brings us to my purpose here which is to elaborate on some (not all) vocabulary related to software development and systems integration projects for those becoming involved with them. My hope is that when you find yourself engaged with a team of technical service providers—be it to integrate a digital asset management system, create a website, a mobile app, or any other kind of software—your level of understanding, comfort, and participation is raised by knowing these terms, and your end result improved. Along the way I may lob out some other tips for good communication and outcomes but that’s just some beer in the stew. (It’s good. Try it.)

Caveat: While I have been engaged for many technical projects supporting dictionaries I am not a lexicographer! Take what you like, leave the rest. Or better yet cover errors and omissions in a comment and I may update accordingly.

I’ve categorized what follows into groups of terms related to People, Hardware, Software, Information (Data), and Project Management. (Sing with me: It’s my article, I can class how I want to!)


  • User. Anyone who consumes a function provided by your software. Most frequently used to refer to End Users, but can be used following other terms that further define a user Role.
  • User Group. A collection of Users classified by a given characteristic, such as their Role, location, or affiliation.
  • Role. A group of actions or activities undertaken by a specific type of User. Examples of Roles: Administrator, Collections Manager, Subscriber, Editorial Staff.
  • Permissions. Access granted to content or functionality for a given User, User Group, or Role.
  • Stakeholder. See under Project Management.


  • Infrastructure. The basic foundation of a software system, most commonly referring to the hardware and network architecture it is deployed on.
  • Platform. The combination of Infrastructure and Application Framework (see under Software).
  • Server. A computer—physical or virtual—providing shared resources via network to Client devices. Many applications and their supporting environments employ multiple servers and you may hear them referred to by their roles, e.g. database server, backup server, staging server, production server.
  • Client. An application or device accessing resources from a Server.
  • Device. A catch all for desktop, notebook, tablet, mobile, or other type of computer.
  • Hosting. Provision of resources and infrastructure—space, redundant power and bandwidth, rackspace, monitoring, support—required to run Servers and the applications they provide access to.
  • Instance. Used to refer to a single deployment of a virtual server, software framework, or application.


  • UI/UX. Acronyms for User Interface and User Experience that are often used together.
  • Application. A software program that provides a specific set of functions to Users.
  • Framework. A group of software applications working together in an integrated fashion to provide a suite of functionality.
  • Component. A part of an Application or Framework that handles a specific set of functions. For example, an image viewing component.
  • SaaS. Software as a Service refers to hosted applications that—freely or not—are available to be consumed without installation of client software on a device, most frequently via web browsers.
  • Front End. Software or framework components providing Users access to functions.
  • Back End. Software or Framework components that provide functions for managing information served through the Front End: storage, access, monitoring, reporting, administration.
  • API. An Application Programming Interface provides a set of software functions that aren’t dependent on their implementation. For example: A Dictionary API might provide functions for searching and retrieving content that can be used by developers to create new apps.
  • Proprietary Software. Software that may have one or all of the following characteristics: Requires purchase; has restrictions on use; does not allow access to the source code for modification or reuse.
  • Open Source Software. Software providing a free license (not nec. without restriction) and access to the source code for modification or reuse.


  • Data. individual pieces of factual information in digital form. Examples: textual data, image data, statistical data, geospatial data.
  • Database. A specialized software for storing and organizing related Data, providing search, retrieval, creation, update, and deletion functions.
  • Data Store. A repository containing Data. These words can refer to a Database but being a conceptual term can also refer to simpler things such as a collection of files.
  • Legacy Data. Data from prior stages in a project lifecycle to be ingested or migrated into a new or updated Data Store. This often requires Data Conversion (see below) to change the structure or format of the information. Example: Our legacy data was in old typesetting files that had to be migrated to structured information for our new content management system.
  • Metadata. Information that describes information, for example: a library record consists of metadata for a publication: author, date of publication, publisher, subjects, identifiers, etc.
  • Content. A general term for textual, graphic, media, or other type of information to be served by an application.
  • Format. The underlying file format of a given piece of information. Examples for images: TIFF, JPEG, GIF, SVG, PNG; for texts: PDF, Word Processing files, Desktop Publishing files, etc. Some file formats are proprietary, some are open source.
  • Standards. A term used to refer to established and/or widely followed regulations or guidelines for information Formats, Metadata, storage, transmission, or software implementation. Following Standards appropriate for your Data and its designed use is good practice. (Warning: Here’s where the acronyms fly.)
  • Controlled Vocabulary. A standardized list of terms used as values for a particular metadata facet, for example: The Library of Congress Subject Headings is a controlled vocabulary for classifying records by subject.
  • Data Processing. Specific procedures by which Data may be extracted, analyzed, reorganized, distributed, or ingested. Depending on the context of the process you may hear variants like preprocessing or postprocessing. Examples of data processing: validation processes, reporting processes, publishing processes.
  • Data Conversion. A Data Process by which information is transformed from one state to another, the target state generally being one that is improved, and perhaps required to use the information for a particular purpose.

Project Management

  • Stakeholder. Any party that has an interest in a project. Examples: funders, end users, internal users, client staff, service provider staff.
  • PM. Project Manager.
  • Artifact. Planning and execution of a project will involve creating and maintaining documents, visualizations, and plans, all of which may be called Artifacts.
  • Project Plan. A set of Artifacts that comprise everything needed to plan, execute, monitor, control, and close a project.
  • Scale. A metric or set of metrics determining the size of a project in some way, e.g. storage capacity, number of supported users, etc. May be used in the noun sense to describe the scale, or a verb sense to indicate a target size, for example: The initial design will support 5,000 users and later we will scale the system to 50,000. (See also Requirements, specifically non-functional requirements.)
  • Scope. Everything required to complete and deliver your project in a state that meets the Requirements. Used in a a noun sense as such and in a verb sense to describe the process of defining a project’s Scope. Bonus points: Scope Creep refers to a gradual increase in Scope that occurs as new business or functional requirements arise once a project has been started. It happens.
  • Resource. A person, service, or (sometimes) material required for completion of a project. Examples of resources: Software Developer, Hosting Provider, Test Lab.
  • SME. (pronounced Smee) Subject Matter Expert
  • Standards. See in Software above.
  • Compliance. Project requirements or tasks that address adherence to applicable standards, particularly regulatory ones.
  • Requirement. A Functional, Non-functional, or Business need that your project must fulfill. Functional Requirements describe in detail the software functions and capabilities that must be provided to users. Non-functional Requirements describe desired levels of availability, redundancy, performance, scale, or other characteristics or constraints. Business Requirements state the objectives of the sponsoring organization, such as the problem they are addressing or opportunity they want to capitalize on.
  • Use Case. A set of steps a User of a given Role may perform with a software, and the expected results. These are often a part of Requirements documentation, and may be expressed graphically, verbally, or both.
  • User Stories. Some development methodologies (Agile, but that’s a whole other article) express User objectives in everyday terms is used to facilitate the requirements process. Using concise template, such as “As a [Role here], I want [desire/goal here]  so that [benefit here]”. Bonus: Stories are grouped by functional realm into Epics.
  • Phase. A grouping of a sequence of project tasks and/or events to achieve a Milestone. That’s a noun sense. Phase is used in the verb sense sometimes to describe the process of creating that grouping, e.g. We phased the project to deliver Milestones 1 and 2 simultaneously.
  • Milestone. A significant event in a project, such as a beta software release, or delivery of a specific set of functions.
  • Change Impact Statement. Any time you change the Requirements or Scope of your project it will likely affect the cost, timeline, resourcing, risk factors, or other facets. It’s the job of your PM to be sure they understand your change and report the potential effects to you in the form of a Change Impact Statement so knowledge based decisions can be made. (Yes, I left out a number of Artifacts in this list but I cannot turn away from any opportunity to cover this topic!)
  • MVP. Minimum Viable Product. A project deliverable consisting only of the core functions required for release.

Parting Shots

Understanding the language of software projects is good. Using it in clear communications is even better. Take steps to be sure all stakeholders come away with the same understanding of written and verbal interactions. Be explicit, thorough, ask questions, send confirmations . . . whatever is needed (or not—there are sins of excess to be committed).