SOA, BPM and Documents

Matching the types and tiers of applications between SOA, BPM and Document Services might make me guilty of “marketecture” – the clever but generally obfuscating, vague and confusing PPT version of a real application architecture – but I have found the following to provide the basis for a very useful tool employed in explaining how to build a better mousetrap with LiveCycle and PDF-centric applications.

According to the AMR Research Market Analytix Report “Service-Oriented Architecture: Survey Findings on Deployment and Plans for the Future,” the dominant reason (48%) for people to embrace SOA technologies is the ability to configure business processes more quickly and flexibly. A growing number of developers are moving toward SOAs (intentionally in most cases) in order to meet challenges of both intra-application behaviors and the need for truly functional interactivity. This approach can automate the result of processes in a faster, securer, and more cost-effective way. While SOA is often used in many differing domains with different semantics, I like to use the definition of SOA as an architectural paradigm, or simply stated, a model for architecture.

Reinventing people’s processes by integrating documents or forms into SOAs involves some discussion on three technical topics: SOAs, BPM workflows, and document services. If we use 3 tiers to describe the SOA overlay on the core applications and we assume that each tier has three elements, then each element in a tier interacts with its corresponding counterpart in another tier. Now I wave the magic technology marketing wand and the three tiers apply to other technology trends like BPM, workflows, and document services. Then I spin the three ideas to align around the necessary application components and “abracadabra, ala-shazam” I have provided a method to describe an open architecture and standards-based approach to developing applications that utilize documents as the interface and enable IT developers to add or eliminate services to meet changing technical requirements or business needs.

The SOA afficionado builds applications as services. SOA can be defined using three different views or elements that are required:

1) Applications: The developer breaks down underlying artifacts and improves the aspect orientation of discreet units of application or business logic.

2) External interfaces: This developer exposes both configuration interfaces and activity interfaces.

3) Transport: The developer enables SOA by providing transports to the collection of services within composite applications.

The BPM or workflow architecture gets applications oriented around workflows so that services can be integrated into BPM applications. Three types of workflows can be persisted from your SOA up to the document layer:

1) Intra-application workflows: Developers combine the services interfaces of different applications, essentially exposing and serializing APIs to create new functionality or new transaction types that persist across several applications or infrastructure layers.

2) External workflows: Developers can externalize business processes and workflows to interface to a set of pre-existing applications. What is needed is a way to represent expose services or represent transactions and data to the various business stakeholders.

3) Human-centric workflows: Developers can provide interfaces for people to access the various functions. This access can be granted based on the roles of the different actors that need to request, submit, review, or approve the things that cannot be automated through technology alone. Even if these transactions can be automated, they often still require some type of intervention in order to provide approval or input..

Documents services can be used to link security services to a specific document, create and bind policies to documents, and expose enterprise data as documents with read and write permissions for authenticated users. The following three elements comprise the baseline of document services:

1) Document services: Developers can deploy document services on the same layer as other services and therefore can be easily combined with other applications that require access to the API. Not only can we process requests using these services, but we can also impact the way in which applications process information contained in the specific document functions. Further, these transactions can now be handled as secure communications inside and outside a firewall.

2) Document templates: Developers can dynamically assemble intelligent documents at runtime using data and logic constraints in the XML or code. Intelligent documents are actually secure, dynamic digital containers for delivering and executing document services. The documents integrate XML content and high-fidelity presentation in PDF with powerful business logic that drives form or document design behavior. Built-in capabilities include calculations, routing instructions, error checking, digital signatures, and data validation. Data in XML can be imported and extracted automatically.

3) Document clients: Users interact with the documents through universal clients. Examples of universal clients include standard web browsers or free software to enable people to view and engage with interactive, quality digital documents anywhere at any time. Adopting accepted standards like web interfaces and PDF is critical because it offers users uninterrupted access to materials now and in the future.

Given the similiarity and the dependencies in each of the three tiers, a simplistic comparison can be applied to show how the approach we are taking to manifest documents as the end-user interface for large applications is therefore an instantiation of an SOA.

1) There are both application logic and a message bus required to instantiate application interactions. In this layer we can consider the folowing:
Application = Intra-application workflow = Document services

2) There needs to be an application interface or some technology provision for external interaction that is schema-driven. Given that:
Application interface = External workflows = Dynamic templates

3) A useful container generally requires a client that provides the usability to these interfaces, and unlocks the workflows, data and interaction required to carry out the application functions
Transport = Human-centric workflow = Interactive forms and documents

In each of the examples above, the dependencies roll back into the previous. For example, an interactive form assumes the existence of and represents human-centric workflow and has a dependency on a mechanism for transport. Simply put, email me the form and I will submit the data from here. It’s not about redundant technology, it’s more about abundant technology and, IMHO, this is a logical extension of where you might already going. If you clicked to this blog from the Macromedia MXNA, then this blog is a document that went through a workflow and exists in a services oriented architecture.

No actual developers, code or architectures were used or harmed in the creation of this entry, yet. The almost entirely fictional representations herein are meant to provoke thought, not debate, and any resemblance to marketing or technical literature is purely coincidental.

One Response to SOA, BPM and Documents

  1. Jim Williamson says:

    BenI like the approach; I recently tried to convince colleagues that the technology also needs a system modelling approach that describes the interaction of human and computer actions before you get into the detail of architecture.Is IDEF0 the answer ?