You can’t move today without someone mentioning workflow and the latest whizzy tool being thrust under your nose with a massive “Buy Me” ticket strapped to it. You’ll also find that descriptions of these products are so different that it’s hard to figure out a sensible way to compare them. Well fear not! Here I’m providing you with 6 tips to help you navigate some of the vocabulary so that you can tell a well-engineered solution from a hyped up marketing campaign.

Tip #1: Service Oriented Architecture (SOA) is a way of thinking

If you read a press release that says, “We’ve implemented Service Oriented Architecture…” then it probably means that the writer didn’t understand the subject or they’re bluffing. The Wikipedia entry for SOA starts with “… SOA is a design pattern…” In other words, it is a way of designing. It’s not a technology and it’s not something you can buy in a shop. Specifically, SOA is a way of thinking about the problem that forces you to separate the service that is being delivered to you from how that service is performed. Take a simple, but slightly silly, example. As a builder, I need to make holes in walls so that I can hang beams, pictures and other items. If I went to the shops and asked for a hole delivery service, then the person behind the desk would probably laugh at me for a while and then sell me a drill. The reality is a bit strange. I don’t want to own a drill, I don’t really need a drill but I do need a service that delivers precision holes to the right wall in the right shape at the right time. Today, I choose to buy a drill as my hole delivery service. Tomorrow – who knows? Maybe a team of students with high-powered lasers and a disregard for personal safety might offer a better service. 

Tip #2: Your service boundaries might not line up with today’s functional boundaries

From the early days of TV we have been battling with physics. It’s been a miracle to get moving images on the screen at the right time. In the past 8-10 years things have moved very quickly, but old equipment still defines the workflow boundaries in many organisations. A recent example of this is the DPP workflow in the UK. Before the file based delivery specification, QC was performed both in the post house and in the broadcaster. By looking at the service being delivered by the post house, the broadcaster’s thinking goes: “I am paying for a trusted file delivery service.” Part of the trust element of the business relationship is to trust that the QC was done correctly upstream. As a result, a QC certificate now travels with the media from post house to broadcasters, making the overall supply chain more uniform and efficient. When designing with SOA principals, it’s always important to look at the service that is being delivered and figure out what has to flow across that service boundary for that service to be classed as successful. Sometimes it will be media, sometimes it’s metadata, sometimes it’s just performance metrics and sometimes it’s just everything! 

Tip #3: Business Process Management (BPM) is a methodology

If SOA is a way of thinking, then BPM is a way of doing. A process is simply a set of instructions or a method for accomplishing a task. If you are thinking in SOA terms, then a process will be delivering a service to you. For any given service (e.g., a transcode service), two different businesses might have completely different processes for achieving that service. This is because those processes will be designed to optimise something. In transcoding, you may want the maximum throughput or the minimum latency or the maximum quality or the minimum cost or some other optimisation. Each optimisation will define a process and the BPM engine will usually be able to decide which process is best for a given service, provided you give it enough metadata (e.g., cost, throughput, latency or other metrics). A BPM methodology can delivery an SOA design. 

Tip #4: BPM has standards and terminology – such as BPMN

There are quite a few formal standards, de-facto standards and commonly used tools in the BPM world. Learning some of the terminology helps conversations with vendors and technologists. One key word is the orchestrator. This is a component of a BPM system that controls the dispatching of tasks. Just like the conductor in the middle of the orchestra, the orchestrator is responsible for checking that everything is happening at the right time with the right dependencies, and that nothing is stuck and there are no errors. If errors or problems occur, then special tasks are executed to handle them. The orchestrator does that handling too. Another key piece of terminology is BPMN – Business Process Model & Notation. BMPN 2.0 is, in part, a graphical standard that allows you to draw your processes in a standardised way so that you can understand the diagrams in different systems. There are many systems out there today that use their own proprietary representations of workflows, and it’s challenging to relearn the meanings of visually similar symbols that in fact have quite different underlying effects. BPMN gives a standard look as well as a standard XML representation of those elements. This means that both humans and machines now stand a chance of exchanging interoperable models.

Tip #5: Web services can be good, bad and ugly

If BPM is a methodology then Web Services are the technologies that deliver the processes. There are three main Web Services technologies in use today: SOAP – Simple Object Access Protocol; RESTful – Representational State Transfer; and RPC – Remote Procedure Calls. Each of these technologies allows you to create a distributed system connect by IP (Internet Protocol) that behaves like a single system. There is not enough space here to describe the differences between all these systems (and the dozens of alternatives), but if you really want some training in this area then email acadamy@dalet.com and I’ll put a webinar together, provided enough people ask. Good web services tend to be stateless – in other words you shouldn’t have to remember previous results to interpret the current results. A simple example is this dialogue between two pretend servers:
 
Stateful conversation:   
Server A – Hello, what’s your name?
Server B – Mister
Server A – Hello, what’s your name?
Server B – John          
Server A – Hello, what’s your name?
Server B – Smith
Server A – Hello, what’s your name?
Server B – <End of Transmission> 

Stateless conversation: 
Server A – Hello, what’s your name? 
Server B – Mister John Smith 
Server A – Hello, what’s your name? 
Server B – Mister John Smith 
Server A – Hello, what’s your name? 
Server B – Mister John Smith 
Server A – Hello, what’s your name? 
 
Sometimes you can’t make communications stateless, but you can recognise a bad web service when statelessness is possible but has not been achieved. Designing good web services is difficult. Good ones are released and don’t have to be changed for many, many years because they just work. Bad web services probably don’t work at all, and ugly ones grow new features and versions in an inconsistent way and drive developers mad. I won’t name any products, but if you know any developers ask them to name their least favourite web service and then sit down and drink lot of teas as they tell you why.

Tip #6: Web services – it’s not religion

The various web service technologies can usually be interchanged to achieve the same overall results. By selecting different technologies you are usually optimising a different facet of the process that you are trying to implement. Very often products with which you integrate will come with a fixed web service interface that requires an adapter to convert the product’s web service technology to the web service technology used by the BPM system. This is just the way life is and needs to be factored into the overall project. I know many people who get upset by the fact that there are many incompatible web service technologies in circulation. This is one of the prices we pay for rapid development of internet technologies. You can optimise design speed or the number of people who adopt the design on day-one or the cost of the design. Choose any two.
 
For more on these topics, come and see us at NAB! As Ben said in a previous post, if this year’s NAB is a buzzword Bingo, we’re sure to fill the board.