Photography: Workflow

Workflow is a topic that professional photographers are well acquainted with. People like me discover the need after a while. Three things have prompted me to look at how I deal with my photographs (and movies):

1. Volume:
   I now have in excess of 10,000 pictures and my current software is being stressed; it’s slowing down.
2. Time to process:
   It takes too much time to process batches of photographs. If it were one or two at a time that would be fine, but a one-week vacation can easily produce one thousand pictures.
3. Consistency:
   Having a sequence of steps that is consistently followed is essential for ensuring the photographs are properly tagged and stored so at some later date they can be found.

So, as an architect, I recognize the above as “business drivers.” Hence there is motivation to do something and supporting rationale. My next step is to describe the broader nature of the solution; the principles that will govern its direction.

One of the issues I see with my current platform is its proprietary nature. Therefore my primary principle is that I will used industry standards based solutions. I will use, where possible: standard data formats, meta data, etc. From an execution perspective, my primary principle is to develop towards specific targets (capabilities) in small increments enabling the agility to shift direction as greater depth of understand or opportunities emerge.

As a work flow is essentially a sequence of steps, the next step is to express that as what is called a business process. I have identified several processes related to the processing of photographs. The first is importing items from the camera, tagging them and organizing them in a database.

The above depicts the logical sequence to be followed. With such a representation I am able to identify in advance potential issues and concerns.

For example, my three drivers will tend to push me to reduce the number of manual things I have to do so I may reduce processing time and improve consistency. The drivers don’t necessarily push me to reduce the number of steps: that number is determined by the nature of the problem; the functionality I intend to address. While it is possible to find a better way to do the task, which in turn might reduce the number of steps, the real issue will be the number of actual steps I will have to do manually not the sum total including automated steps (which I won’t see).

In the next phase, when I start to map the logical components against specific technologies I will apply the principle related to standards compliance. At this point I can identify areas that should be automated so that I can achieve my goals.