AWD 10 – re-entering the BPM market, or just some lipstick on the old beast?

Posted on

I recently saw the review of AWD 10 from Bruce Silver (, where he was outlining the virtues of AWD 10. Now to be open I have been bitten by AWD in the past and have some painful memories. These were not necessarily all the fault of AWD, but partially that we were trying to use it outside of its main areas of strength. However, I still have the scars.

AWD has been around for a long time. Originally built by DST to manage its BPO operations I believe it started life in the 70’s / 80’s written in Cobol – and this heritage always remained in the constraints in the fixed length data models. Over its life it was ported to a combination of C and Java and a number of add-ons were bolted on to the side. During the last 5 – 10 years there seemed to be a significant lack of investment in the product itself, and it went from a position of being a market leader to a boundary player.

AWD is used extensively by DST systems for operations processing. This, in conjunction with the joint ventures with State Street and FDI was always the reason why the install base was so large. Used in this way, I have seen AWD being used very effectively for large volumes of transactions.

From first glance through the report, it appears that AWD 10 bolts together all of the components that were emerging as add-ons in previous incarnations – such as the form designer, service designer, and smart forms. These were previously always add-ons, developed separately, and licensed as add-ons.

In the past the challenges that we have encountered with AWD have been based around:

  • The complexity of the operating and development environments. The lack of version control and release management capabilities in particular – although this is an area that Lombardi 6 struggled, it has now put these largely to bed with 7.x. It was not clear from the report whether this has been addressed at all.
  • Integration into any other portal or technology – for example for presenting tasks lists through a partner portal.
  • The number of and integration between add-ons which were not seamless.
  • The data dictionary – especially around field name lengths and handling of collections.
On the positive side, its support for out-of-the-box QA sampling, review, and performance tracking has always been a strength and something that I have never understood why the rest of the BPMS / Workflow platforms have not got. I think this is a symptom of the fact that AWD is designed by a company that actually uses this stuff, and the innovation is driven by actual usage (especially through the FDI joint venture from what I have seen).
So my observations are:
The product homepage ( mentions that this is a complete re-architecture of the product. Although this doesn’t come through in Bruce Silvers report. 
It was good to see that there was finally a basic process modeler, as this was always a key let-down. It looks from the screen shots to be BPMN based, although very restricted. Maybe this is just the screen shot.
From what I can see, the key changes are the addition of the BPMN modeller, some improvements around the integration of the job designer and the ability to call external business logic (services), web browser based design tools, and some improvements to the dashboards.
So I am not convinced that this is such a big progression. AWD seems to be playing catch up, and is still a way behind. The key functions have remained the same and really there is nothing new in there. Yes it has been around for a long time and has some significant volumes. But it is still a fairly straight-forward workflow platform. There doesn’t appear to be any focus on supporting collaboration or continual improvement, especially in areas such as optimisation and simulation. In my mind these are key features I am looking for in a business focussed BPMS. And is it a BPMS without them?

2 thoughts on “AWD 10 – re-entering the BPM market, or just some lipstick on the old beast?

    TonyM said:
    November 16, 2010 at 12:14 pm

    The other comment I would make re AWD is migration pathways – which perhaps ties into your points. From memory there were a lot of older AWD implementations floating around at different sites – and effectively a product replacement step required rather than a defined upgrade path? This is going way back – so not sure if this criticism is still valid.

    Alex Bullen said:
    November 16, 2010 at 1:32 pm

    Yes good point Tony. We have seen that as well. The rearchitecture of any system that contains long running transactions requires a really sophisticated upgrade strategy, and this has often been lacking.

Leave a Reply

Your email address will not be published. Required fields are marked *