One of the key requests from our operational focus groups during the early design phase of BLAM-3 was the ability to prioritise workflows, particularly delivery workflows. Words to the effect “As an operational supervisor I would like the ability to place assets in a fast lane for delivery” were frequently heard. This became one of the key requirements of the BLAM Workflow Engine and has been developed into a sophisticated and highly configurable capability which enables operators to build Service Level Agreement (SLA) ‘aware’ workflows.
BLAM Workflows
The BLAM Workflow Engine is the business process orchestration component of BLAM which manages all operations within the system as well as the user-definable workflows. Workflows are constructed by linking functional blocks called BLidgets (Blue Lucy widgets) in sequence, to deliver a specific capability. Each BLidget performs a particular function such as creating a checksum, watermarking an image or controlling 3rd party systems such as a cloud-based Quality Control service.
Workflows are built by connecting the individual BLidgets together to produce a sequence of operational steps which, when triggered, will be executed and managed by the engine. Workflows are easily built by simply dragging, configuring and connecting BLidgets on a visual canvas.
Workflows are built from BLidgets: drag, configure and connect.
A mid-level system administrator or business analyst is able build workflows without needing to create or understand the underlying code. The workflow builder has been designed to be entirely operator self-service, allowing media businesses to build their own workflows with ease. And crucially without the need to refer back to Blue Lucy or our integration partners.
Safety features are built in at the BLidget level to ensure that incorrectly configured workflows can do no harm to existing workflows or the wider platform. This encourages experimentation and a trial-and-error approach which enables media operators to respond quickly to new business needs – essential in the increasingly dynamic, ever evolving consumer market.
Such is the versatility of BLAM that the number of workflows on any one system tends to grow rapidly, particularly for multi-tenant systems. At a certain point the question of workflow prioritisation is often considered.
Do Cloud Workflows Need Prioritisation?
The elastic nature of ‘the cloud’ affords significant opportunity for scaling in the provision of the key functions of a content supply chain such as media format conversion (transcode), render, QC and delivery (transfer). In the context of the infinite scalability of the cloud is prioritisation even a requirement?
In reality there will be some queues and, although a properly configured management platform such as BLAM can all but eliminate these, some contention is inevitable – particularly in the case of bulk migration projects. In addition, manual operations that require human resource, such as ‘eyes on’ QC, cannot be scaled so readily and on prem’ deployments have physical constraints that need to be managed. With pressure to deliver ever more rapidly to an ever-increasing number of delivery channels, workflow prioritisation has probably never been more important.
Prioritisation in BLAM
BLAM maintains individual queues for each functional service under management. For example, if an on prem’ deployed BLAM is managing three connections to external cloud-based storage such as AWS S3, BLAM will manage a single queue for the ‘upload to S3’ function. If five asset files (named A – E) are running through different workflows at around the same time and all need be uploaded to S3, each will join the single upload to S3 queue. Without prioritisation the first three asset files, A – C, will be distributed as jobs to each of the available connections in the order in which they arrived on the queue. Asset file D will remain on the queue and is posted only when a connection becomes available – i.e. when the process for any of the files A – C completes. Asset E will follow D in the same manner. If asset file E is required urgently then joining the back of queue in this example is not ideal and makes the case for prioritisation.
There are three dimensions to prioritisation in BLAM, although all directly relate to the job queues – i.e. the order in which jobs are ordered on a queue.
Need By
The classic TX workflow. A ‘need by’ date and time stamp is applied to an asset by an operator or, more usually, a scheduling system. As jobs are added to a queue for a specific function (QC or compliance for example) the queue is updated based on the ‘need by’ date-time. The queue is ordered by nearest date-time, if that is not set the queue reverts to the first-in-first-out model unless another priority value is set.
Workflow Configured Priority
Every BLidget allows a priority value to be set when it is added to a workflow. The priority is a number, positive or negative and is applied to any asset or task as it is added to the BLidget queue. The larger the number the higher the priority. The priority number is set on a per BLidget basis although it is typically used workflow-by-workflow. This means that two workflows which are functionally identical may be set with different priorities so that assets passing through workflow X will always have priority over workflow Y for example.
Priority is set within the BLidget configuration.
Material Value
The third, and possibly the most powerful, variable by which an asset’s priority is set in a queue is ‘value’. Value is used to set a monetary worth to an asset with higher value assets taking priority in queues. The Value may be set for an asset by a BLidget from manually keyed or a system set data. Value based prioritisation allows operators to build workflows that ensure their highest value assets always take priority in a workflow. In the context of a service provider the value may relate not to the specific retail value of the media itself but the worth of the customer SLA the workflow is supporting.
Functionality Mapped to Benefits
We have, in the realisation of BLAM-3, built in the capability for operators to create a ‘fast lane’ for urgent content delivery. This has been achieved by providing the ability to set priorities based on a workflow, a ‘need by’ time or to meet an SLA. As such specific ‘fast lane’ workflows should not be necessary; operators can build this intelligence (information) directly into the workflows.