Tag: AWD12

AWD Design Studio: Services And Automation with @smsj76

Simon James of DST gave what will be my last presentation of AWD Advance (in fact, I have to leave before the end to catch my taxi to the airport), looking at how services and automation are done in the Design Studio in AWD 10. This is a code-free (or code-light) environment for composite application development for process-centric applications. [Note to vendors: just because it’s done in a graphical environment doesn’t mean that it’s not code. Just sayin’.]

He walked through a number of examples of what could be done with their library of available services, and showed a bit of the environment used for this; this ranged from automatically adding comments to work items to performing various sorts of calculations, which sounded as if they were things that have caused headaches (and custom coding) for their customers in the past.

As I’ve pointed out in my posts about the other sessions, this is not cutting-edge technology, but it’s ahead of where most of DST’s customers are in their technology journey. Existing AWD customers can be upgraded to AWD 10 without changing their existing applications, but that won’t allow them to take advantage of the new features that we’ve been seeing this week: to do that, they need to redevelop their applications using AWD 10. Design Studio definitely makes that easier, but that may not be a popular idea with customers who are happy with their existing legacy applications built on older versions of AWD that run just fine on the AWD 10 infrastructure.

Consider the different types of AWD customers:

  • Customers for whom DST outsources at least part of their process and infrastructure, including “friends and family” (companies that are connected to DST through corporate ownership) as well as arms-length customers. These have, I believe, already been upgraded to the AWD 10 infrastructure, but for the most part are still running legacy AWD applications. These are likely to have their applications updated to AWD 10 on an ongoing basis, since DST has some degree of control over the application development and deployment.
  • Customers who use other DST transactional systems such as TA2000, tightly integrated with AWD. These will undoubtedly be convinced to upgrade the infrastructure, but may decide to stick with their legacy AWD applications unless they can see clear reasons why they need to take advantage of the new functionality. Rewriting their applications will take time and holds some degree of operational risk, so they may stay on the legacy apps (although on the new infrastructure in order to remain supported) for some time.
  • Customers who do not have tight integration between their transactional systems and AWD may also stick with their legacy applications; at the point that they are forced to upgrade (either because of support issues in the future, or because they need newer functionality), they may choose to evaluate other BPMS along with AWD. For DST, this represents a risk that they may lose a customer, or at least the BPMS part of their business, although the existing customer relationship may allow them to combat this.
  • Customers with no other DST products besides AWD. This is a big risk for DST, since there is little reason for them not to evaluate other BPMS at the point that they need to rewrite their applications. This is also true for new DST customers where they are only looking for BPM/ACM, not the other transactional systems, as they are more likely to find outside North America where the DST transaction processing systems are less commonly used.

DST has a lot of low-hanging fruit in the first two of these categories, and the existing relationship will probably see them through a lot of the third. However, the BPMS-only customers are going to be the challenge, since they will be selling AWD against other BPMS that are further along the technology curve. They do have some strengths, but their biggest strength by far is their existing customer base and the close relationships that they have with those customers.

That’s it for me and AWD Advance; this has been a really interesting view into a very different sort of BPM vendor, and I look forward to seeing how their technology matures and the path of their customers in the future.

AWD Monitoring Technical Deep-Dive

Great keynote at AWD Advance this morning by Captain Michael Abrashoff, author of It’s Our Ship, a book on leadership; I confess to tearing up a bit when he described how he supported and encouraged the young people who worked for him, and hope that I did a fraction as well when I ran a company.

Back to business, however, I’m in the technical session on AWD monitoring and business intelligence, following on from Kim Smyly’s introduction to the new monitoring yesterday, where Dirk Luttrell and Bob Kuesterteffan are giving us a peek under the covers for their new monitoring offering. They are implementing dimensional data modeling in their new offering – which, as I pointed out yesterday, is based on Oracle’s BI – in order to provide better business-based metrics and analytics. We got a brief tutorial on dimensional data models (star schemas in relational databases, or cubes in multidimensional databases), making me wish I was paying a bit more attention when my other half was talking about how he was implementing one of these in his data warehouse. In short, relational data models are organized around transactions, whereas dimensional data models are organized around business entities and information. Business entities are represented in fact tables, and dimensions are key to selecting, sorting, filtering and summarizing the data contained in fact tables.

The core AWD data is based on relational models, since it is a transactional system, but both the process and line-of-business data in AWD can be published to the dimensional (star) model for easier reporting and monitoring. If you’ve ever written a report or dashboard based directly on the process transactional data in a BPMS (which I have), you know that it’s not pretty: BI tools are optimized for dimensional data models, not relational transaction models. In the past AWD has allowed for reporting directly against relational models, but it was (is) not very flexible and could be prone to performance and scalability problems, requiring either extremely complex (and compute-intensive) queries, or denormalization and data duplication. Furthermore, it requires that report writers know and understand the underlying relational data model since they’re writing directly against that physical schema, which further locks in the core AWD product to that schema rather than being able to mask it behind a logical data schema.

In the new dimensional data model, they represent business entities directly: work items, queues, users and various other attributes of work including time dimensions. They also include a single line-of-business data dimension for all LOB fields (this seems like they are relational-izing their dimensional model, but I can understand the administrative and design complexity if they didn’t do it this way), so that fields such as account number can be used to cross-reference to other systems or for filtering, searching and sorting within the BI context.

They are creating the following fact tables:

  • Assigned work fact, with dimensions regarding when and to whom a work item was assigned and unassigned, and the current state regarding assignment and work selection. This is used, for example, to report on assigned work by user.
  • Completed work fact, which tracks work steps as they are completed, including duration, user experience level and other information about how the work was completed. This is used for reporting on work that was completed.
  • Locked work fact, tracking items when they are locked by users: who, when and how. As with assigned work fact, this is used for reporting on work locked by a particular user.
  • Login status fact, tracking when users log in and out, and whether they are currently logged in.
  • Queue fact, tracking work as it moves from queue to queue, and the status that each work item is in.
  • Suspended work fact, including when items are suspended and unsuspended, and who did it.
  • Work fact, which including historical information on work but includes a “current” flag to filter for just work that is in flight.

[This is probably way more detail about their dimensional data than you’re interested in, but I blog because I have no memory, and this is my only record of what I see here. That’s right, it’s really all about me.]

Given that the same underlying relational model will still be there in AWD, customers can continue to use the existing AWD BI (which would hit against those tables), but I’m guessing that a lot are going to want to move over in order to take advantage of the ease of use, performance and scalability of the new BI environment. They’re also planning on some future features such as scheduled report delivery; I’m not sure which of the new and upcoming features are based purely on the underlying Oracle technology, and how much that they’re building themselves, but if they’re smart, they’ll leverage as much of the Oracle BI package as possible. They also need to figure out how to integrate/publish to enterprise data warehouses, and work up full replacement functionality for the current BI product so that it can be retired.

Managing People And Work In AWD (with @amv0920 and @Arti_Acharya)

Management of users, roles and groups in AWD is fully featured, but has its roots in functionality that was created decades ago. There are currently 15 different screens used to manage users, roles and groups in AWD today, and in many cases, they need to be visited in a very particular order to make something happen.

DST is in the process of rewriting the user management functions, and Angela Veach and Arti Acharya (the experience designer) presented the wireframe designs in progress. This is greatly simplified in terms of the number of screens and in terms of the language used on those screens, such as:

  • Create a new user, specifying general attributes such as name, user ID, security level and work group. This can be done using another user or a model user as a template, such that privileges, experience levels and resources are inherited from the model.
  • Manage what they can work on, by assigning one or more roles, assigning individual privileges such as specific business areas or work types that are beyond the capabilities of the assigned roles, and assigning experience level.
  • Manage what they can see in AWD, by assigning security group, and additional individual resource access control grouped by product/capability.
  • Specify resource-specific attributes, which are the additional parameters required for the different capabilities to which they have access, e.g., the signature that will be used for correspondence generation if they have access to the correspondence capabilities.

They’re still working out the details on this, and are actively soliciting ideas from their customers in the audience. There are a lot of options here, such as whether selecting a model user should replace or augment the existing privileges on a user account.

This appears to be a new interface on the existing structure of users, roles, skills and permissions, rather than a new underlying structure, meaning that it doesn’t impact much in terms of operational functions (except a new dialog to select their primary workspace if they have been assigned to multiple), mostly just these administration screens. There is a still a very complex structure that needs to be well-understood by an administrator, but at least the administration screens will make it easier to implement. Lots of happy sysadmins in the audience.

As with case management, this is unreleased functionality still under development, likely to be released in 2013.

This was the last session of this first day of AWD Advance 2012; we’re off to the reception and conference dinners tonight, and will resume tomorrow. I have been assured that dinner will not involved Lipizzan stallions or palaces, although I might see a cow sometime before I leave tomorrow.

Case Management In AWD 10

Judith Morley presented on their new case management capability; she started from some pretty basic principles explaining knowledge work, so likely a fairly novel capability for most of the audience.

She described case management as a new application or user interface, meaning that the AWD 10 BPM capabilities are there as part of it, but it has additional capabilities such as collaboration, content, ad hoc processes and deadlines. This circles back around the ongoing discussions in the industry about the relationship between BPM and ACM; certainly, process is a part of ACM (even structured process), but it’s more than that. They did research with their own BPO companies and some of their customers spanning retirement, mutual funds, insurance and healthcare industries, and came up with four design imperatives for a case management solution:

  • A humane way of working with files
  • Reorienting yourself to a case: making it easy to pick up where you left off after some time away from the case
  • Immediate responsibility versus ultimate responsibility: understanding ownership and responsibility for meeting milestones
  • A system that suggests rather than dictates: supporting the knowledge worker rather than enforcing a specific process

The primary workspace now for knowledge workers (as defined in their profile) is a dashboard listing their top 10 tasks – as defined by what they own and due date – and a task forecast for the next three weeks, then their top 10 cases and the case workload of all members of the worker’s team. There are two other tabs for cases and tasks; on each of those are interactive filtered views of the cases and tasks in progress. Both cases and tasks are types of AWD work items (with a predefined process model, even if just a single-step user task), with tasks being children of cases; opening a case or a task takes you to a view of that work item with the related data, content and activity. Tasks can be added to a case by the worker, using a template, and content can be added at the case or task level. Messages get passed around between cases and their tasks to allow for processes to be started, paused and rendezvoused appropriately. Cases can be created from templates as well, where a case template contains one or more tasks of any degree of complexity. Both task and case templates are, in fact, templates: if they are changed, work that is already instantiated is not impacted. Furthermore, cases can be organized into folders as a collection mechanism, although folders are not routes as cases and tasks are.

This is not yet a released product: it’s scheduled for the end of 2012 or the beginning of 2013, and they are currently researching different representations that they might create of manager and team views, as well as reporting on knowledge work. This latter issue is one that I’ve been talking about a bit lately, and proposed it as one of the “unanswered questions” in my presentation on the nature of work at last year’s academic BPM conference.

Monitoring Dashboards And Reports In AWD

Kim Smyly presented on some of the new monitoring and analytics capabilities in AWD. They now have interactive dashboards, charts and reports that link directly to the underlying transactions, and can include line of business data in the reports. Writing reports in the custom AWD BI engine has been replaced with an OEM version of the Oracle Business Intelligence Enterprise Edition, allowing for a more flexible representation and visualization of the information, with actionable links to the processes. With interactive filtering capabilities, this also provides a search interface, such as searching for all active transactions for a specific account number.

This is pretty standard BI in terms of report and dashboard definition: quite a bit of flexibility for visualization and computation in a drag-and-drop interface, no more difficult to use than Excel tables and charts. It includes pivot tables (which you may know from Excel), which are great interactive analytical tools. I’m not sure what the legacy AWD BI looks like, but if it’s like that in most older systems (usually some ancient version of Crystal Reports), this is bound to be a huge improvement.

Line of business data can be included directly as fields in the dashboards and reports; I’m not sure of the underlying data architecture, but it appears that LOB data dimensions are defined in AWD and somehow replicated from other systems (or they are a view on those other systems); because they’re in the AWD data schema, they’re exposed for monitoring and reporting.

A number of questions from the audience on this; DST is porting over from the old to a new schema, and although they will support both for the foreseeable future, I expect that this will eventually force a migration from the old report mechanisms. It seems like the first implementation of this is not as powerful as the old custom BI (although probably significantly easier to use), so they will need to bring the functionality up to match before they can expect a mass migration.

Mutual Fund Processing With AWD 10 And DST Vision

My history with DST started in 1994, when a mutual fund customer in Toronto hired me to conduct an evaluation of imaging and workflow systems. They were certain that they wanted DST, but we went on to evaluate and select FileNet (now IBM). In the course of that evaluation, I spent about a week each with DST and FileNet building an application, with my DST time spent here in Kansas City including a tour of their massive mutual fund transaction processing outsourcing operation. I hadn’t had a lot of interaction with DST again until recently, and obviously things have changed a lot in their technology (as well as in Kansas City).

A big chunk of DST’s core business is still with mutual fund processing companies, since they provide both the TA2000 transfer agency system (for transaction processing and shareholder recordkeeping) and AWD for the imaging, workflow, correspondence generation and other related capabilities. For those companies using TA2000, which is really a mutual fund industry standard in the US, the natural fit has been to use AWD as well since there is some deep integration between them, and DST is pushing hard to ensure that AWD 10 continues that tradition.

Their consistent message at their user conference this week is transforming business (through, of course, the implementation of AWD 10). Part of this is to treat transactions not just as independent transactions any more: many transactions represent life events such as births, deaths, marriages and divorces. How you handle the transactions related to a life event – which usually required initiating and managing transactions and tasks that the customer didn’t think of – can make or break that customer relationship, and that viewpoint can be transformational for how you run your business. This requires a case management approach to that life event, where directed dialogs (wizard interfaces) collect information that can be used to spawn additional tasks required for case completion.

They’re also enabling additional transparency by allowing financial advisors – those people and companies who actually sell the mutual funds – to participate directly in an existing AWD workflow through the DST Vision portal application. For mutual fund transactions, this is primarily to report on transactions that are not in good order (NIGO) so that the advisor can provide additional information in order to complete the transaction, usually related to transfer of assets. This presents a filtered view of the back office information, since advisors are not permitted to see all information about shareholders and transactions, and may include images of the original documents provided.

It’s difficult to tell how well the transformation message is going over with the customers, but based on the audience questions, the functionality provided by DST Vision is much more relevant to them right now. Although all of the DST full-service clients (that is, those where DST or one of their related companies are doing some or all of the processing) are operating on the AWD 10 infrastructure, that doesn’t mean that they’re using the emerging capabilities, and the self-serve mutual fund clients in the room may be slow to follow.

Introduction to AWD 10

I’ve had a bit of a remote demo of AWD prior to the conference, but wanted to see how DST presents AWD at a basic level to their customers. They highlighted a number of features:

  • Inbound scanned documents, faxes, emails, tweets and other sources
  • Forms builder for data capture user interface
  • Process design (apparently with BPMN), including service calls and subprocesses
  • Work assignment
  • Audit and quality review history
  • Correspondence generation, based on templates for standard parts of the letter, and allowing for ad hoc text
  • Integration with customer database and business rules
  • Monitoring dashboards for individuals and teams

I’m not seeing any unusually innovative BPM capabilities in AWD 10 compared to other BPMS, but this reminds me a lot of how BPM is presented at SAP conferences, for much the same reasons: these customers are using DST products that run their current business effectively, and the agile process-centric BPM environment is new (and likely a bit scary) to them. However, by focusing on things that really matter to these BPM newbies – transaction processing, ability to quickly change process models, quality, work monitoring – they’re showing the inherent value in a more flexible environment over their older AWD code-driven environment.

The challenge for DST will be whether these customers will make the jump to AWD 10, or decide to evaluate other BPM systems if this is a complete application rewrite from existing AWD platform versions. If there is a great deal of customer loyalty, or the customers are bound to other DST systems that will integrate more easily with AWD 10, this may not be a case of offering the best BPMS on the market, just the best BPMS for existing DST customers.

AWD Advance Opening Keynote

AWD from DST Technologies is one of those well-kept secrets in BPM: I know about them because I’ve done a lot of implementations with mutual fund companies, which is one of their primary markets due to DST Systems’ transfer agency solution and their involvement in business process outsourcing (do not ask me to explain the web of companies that make up DST and its parents/children/siblings). When you mention DST and AWD to most people in the BPM space, however, you’ll get a faintly puzzled look. And when I mentioned that I was going to be attending their conference in Kansas City this week, I got a few raised eyebrows, because it appears that analysts aren’t usually invited along. It’s like a secret society or something. I’m still waiting for the initiation ritual.

John Vaughn, VP of business process solutions, gave the opening keynote about business process and customer experience as competitive differentiators: if you do it better, and make your customer while you’re doing it, you have a killer combination. If you read about my experience with Zipcar, you’ll know that this is true. Competitors in the future aren’t necessarily going to be who you think they are now; they’re going to come from places that you don’t expect, in terms of geography, company size and current industry focus. DST’s customers here today, many of them financial services and business process outsourcers, aren’t going to just be competing with other current financial services and BPO companies: at some point, Walmart is going to start selling mutual funds, free agents are going to develop financial planning software, and China’s going to ramp up their outsourcing capabilities. All of this is going to be seriously disruptive for companies that aren’t expecting to compete outside their current base of competition.

AWD as a product has been around for 20 years, and I expect that many of the customers in this room are still on older versions, wondering why they should convert from the old system that runs their business perfectly well to something new and potentially risky. This disruptive business and economic environment is exactly why you can’t just upgrade your server and keep doing business as usual.

Lisa Williams, officer of product management for AWD business process solutions, followed on from that to talk about where they’re taking AWD in the future: empowering knowledge workers, customer engagement through mobile and social, and generally enabling business transformation. AWD 10, which we’ll be hearing more about later today, provides a lot of capabilities to move this forward, but you also need to consider reinventing the customer journey rather than just incremental improvement. Then, you can use the AWD 10 capabilities that you already have to implement that platform to engage your customers.

Mike Lovell, director of product management, finished up the opening keynote with a focus on supporting knowledge workers by getting the technology out of the way and allowing them to engage with the customers. Productivity, throughput and quality are table stakes with AWD, and will never be compromised; rather, you need to up the ante with case management for a more flexible yet powerful environment to support those workers with prioritized task lists, activity feeds and team collaboration. There are also new monitoring and analytics capabilities for better visibility and more intelligent processing.

Good kickoff to the conference, and lots of interesting things to come.