8 years, 1 month ago

On the use of the word ‘delivery’

Enterprise architects and consultants often enjoy building specific languages. This is both good and bad. Good jargon allows one to be very specific and concisely articulate observations about a particular specialised field of interest — for instance a domain architecture or a very specific business process, which only few people understand or carry out. Bad jargon distances ourselves from the topic at hand and annoys people because it becomes too hard for outsides to follow or understand. Through my work I often hear people using the word ‘delivery’ when talking about a particular service offered to an organisation — for instance:

  • “Architecture delivery.”
  • “Governance delivery.”
  • “I delivered X efficiencies to client A.”
  • “We must ensure higher quality in our delivery processes.”
  • Etc.

I often use this word myself. Whilst there is absolutely nothing wrong with using this word, delivery still reminds too many people of a postal service – i.e. the delivery of a package from one destination to another.

Source: Wikimedia (Creative Commons License) http://commons.wikimedia.org/wiki/File:The_Delivery_guy.jpg

One conception of what delivery really means (Source: Wikimedia/CC license).

According to the Free Dictionary, delivery (n) is defined as:

a. The act of conveying or delivering.
b. Something delivered, as a shipment or package.

Whilst some architecture practices can in some way or another be packaged into a well-defined solution, I still find it very hard to think of the complex act of architecture and systems improvement as a shrink-wrapped package delivered via mail or courier. Are we really ‘delivering’ architectures? In this case I think we can, within the discipline itself, be more cognisant of the words we chose and how they affect how other people see us.

Maybe we are more so facilitating, establishing, or building trust through architecture? Ultimately architecture is the conjunction of multiple, often intertwined layers of complexity involving the absolute highest number of moving parts compared to other business and enterprise management functions. As an example, in their day-to-day jobs architects must consider:

  1. People, cultures, and organisational aspects;
  2. Processes and business efficiencies;
  3. Data, information, and knowledge;
  4. Systems, technologies, applications, and integration, etc.

Architecture sits at the foremost inflection point of technical efficiencies, intellectual property, and human work and thought processes. Therefore I think we need to change our architecture jargon of what we do from something shrink-wrapped delivered via courier to something more specialised, tailored, and facilitated. Maybe we should rather see ourselves as facilitators and communicators as opposed to postmen?