Tag: process

Posted on

Factory Approach to Service Engineering – Preamble

Machine Keyboard Code

World of Perspectives

We all see the world from different perspectives, and the sum of perspectives help us to get a better/fuller understanding of our world.  In this article, we share a perspective on engineering services for business.  This perspective can be summarised as: Intelligent Laziness – strategies to achieve equal or better productivity with equal or less effort and minimal stress. To illustrate how we try to achieve this, we will use five metaphors:

  • Factory
  • Pattern
  • Framework
  • Process
  • Service

PowerPoint Summary: A Factory Approach to Service Engineering

The Factory – First Glance

When people think of factories, they imagine the primitive/simple product-focussed line that spews out large numbers of identical, low-value items.
http://www.verbolt.co.za/company-home.htm
But there is another perspective; the advanced/composite service-focussed systems that create a few bespoke high-value units to specific customers.
http://www.orangecountychoppers.com/
There are similarities, in that both are repetitive and they both transform inputs to outputs. But there are significant differences too.  The primitive factory involves lower risk, and less complexity whilst the advanced factory multiplies risk due to composition and customisation.  There is a direct relationship between value and complexity, and it is often the case that the advanced factory uses outputs from primitive factories.

But factories occur in software engineering too, and the underlying principles apply here too.  Whereas it is common to talk of dichotomy in software engineering: is it a science or an art?  Software factories do not suffer such ambiguity.  For every factory, whether hardware or software, two principles always apply:

  • The outcomes are predictable
  • The process is repetitive

Careful study of any system reveals re-occurring things/trends the production of which can be achieved with the factory principles.  This is equally true in a McDonalds restaurant as in a Rolls-Royce workshop. This is also true in software engineering, especially service engineering.

The Pattern

The re-occuring things/trends in a factory are patterns.  The predictability of the output of a factory and the fidelity of repetition depend on patterns.  Patterns are fundamental to factories.  In a factory, there is a need to understand what is to be produced and the patterns that are involved in its production.  Each pattern is a kind of template.  Given certain input and application of the template, a given output is guaranteed.  A factory is likely to involve mastery of one or more patterns, depending on the type of factory.  Fewer patterns generally reflect superior understanding of the problem domain.  However, some patterns go through special evolution (exaptation) and could become the focus of a factory in their own right.

The Framework

The collection of patterns required to create a given output can be described as a framework.  A good analogy is a box of Lego.  It is a composite of patterns, which can be put together to create the structure illustrated on the box/packaging.  The framework identifies all requisite patterns for a given output, and usually in a given technical/business context.  Each pattern in a framework form synergies and are known to be beneficial in the specified context; examples of frameworks include building regulations (hardware) or Oracle AIA (software).

The Process

Of course having all the pieces of a Lego is insufficient to construct the picture on the box.  The process elevates the framework from static to dynamic.  The process describes how the patterns in a framework are to be sequenced and aggregated in a way that delivers synergy and the best output.  The framework is a snapshot, whereas the process describes a flow from conception to completion.  For business services, the process is the first point where IT and business meet.  The process shows how value can be created while hiding (abstracting) the taxonomy/ontology of patterns and the framework(s) employed.

How does all of this come together, especially in our daily lives as software engineers serving businesses?  And how does this help our clients (the business) better compete?  Join me in the next instalment where I will be looking at the benefits, business connection, and potential future impact.

—
Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 793 920 3120

Posted on

Oracle BPEL Subprocess

There are quite a few new features in Oracle BPEL 12c and here is one that I really like; the BPEL subprocess – a task/algorithm that is an association (not composition) of an activity/process.

The concept has been around for decades and it has featured in process diagrams and BPMN notation for quite a while, but there was no equivalent in program code.  Oracle has finally addressed this lacuna by releasing a feature in BPEL that closely approximates the design concept.  Please note that it is close but not identical in semantics; but that again is to be pedantic – pardon the pun!

The subprocess allows a programmer to define a block of code or algorithm that will be reused as-is at various points within one or more BPEL processes.  I took the liberty of taking a few screenshots of active code from a recent client in order to illustrate a subprocess in action.  Before diving in though, it is useful to set the context.  The subprocess is being used in this scenario to wrap the invocation of operations on a service, and the task is named here as “QueryMaximoSP” – see highlighted item in the diagram below.

Call to the subprocess from the parent process

sub-process
sub-process icon
sub-process assignment

 

This subprocess wraps all the operations on the AWMaxAssetABCS service, and can determine which one is to be invoked by examining the inputs it receives from a main process.  In this simple example, the choice is implemented as if/else paths for “query” and “update” operations.  Once the operation has been determined invocation of the target service follows, using the input that was passed in by the main process.

Subprocess internal details

sub-process detail

There are three benefits that this concept brings to BPEL code:

  • Simplification of design view
  • Improved reusability
  • Improved modularisation

In the design view, hiving off some code into a subprocess frees up the screen from clutter and makes it much easier to see the big picture of what we are doing in the main process.  But what becomes of all this delegated code in production systems?  One fear may be that the subprocess will be displayed as a black-box.  This is not the case, all steps in the subprocess will be revealed at runtime, but only if they are executed.

Modularisation is improved because programmers can delegate as much logic to the subprocess as needed, including specialised error-handling and rollback, pre/post processing, and other conditional processing.  All of this functionality is thereafter available to all processes within a SOA composite, and each can invoke (reuse) the same subprocess multiple times with different inputs.

In the diagram below, input has been provided for the query operation while the update operation has been left blank, and so only the query operation will be acted upon in the subprocess.  Notice also that the “Copy By Value” checkbox of the output variable has been left unchecked.  This is important, as the invocation is likely to fail on the output variable if the checkbox is checked.

sub-process assignment

I have found it really useful to encapsulate the invocations to partner services in subprocesses, so that I can control all necessary pre and post processing in one place, as well as any necessary error handling and recovery that is specific to that partner system.  In future, it would be nice to have subprocesses that more closely resemble the concept in process models, i.e. a unit of functionality that can be reused across the domain, not just within one composite.  Now, some would argue that we should create a new composite to encapsulate the required functionality, but of course that would not be the same thing as in the model, and such a construct would also be significantly slower, not to mention that it would not fit nicely into a service portfolio.  Let’s wait and see if Oracle will be tweaking this feature in the next release of the JDeveloper and SOA Suite; for now though, there are already some great benefits realised in subprocesses.  I hope you find it useful too.

Regards and God bless.

—
Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 [0] 793 920 3120