Services Oriented Architecture (SOA) should dramatically improve the relationship between people, processes, and IT. Yet the potential for SOA remains clouded due to a gulf between worker knowledge and the new services automation benefits, which remain focused on structured data and existing applications.
New advances in documents-based technology, management, and dynamic content enrichment offer a promising lifeline to help solve SOA’s tenuous relationship to people and task-oriented knowledge. For example, the Darwin Information Typing Architecture (DITA) Maturity Model, co-authored between JustSystems and IBM, offers a standardized approach for technical document authoring and publishing.
[UPDATE: JustSystems is providing a webinar on DITA best practices on April 10, registration here.]
We're seeing these two areas -- SOA and newly dynamic documents -- come together. Structured documents and the lifecycle around structured authoring tools provide an end-point for the assets and resources managed through an SOA. But we're also providing a two-way street, where the information and data that comes in through end-users can be reused back in the SOA to combine with other assets for business process benefits.
Our friends at ZapThink recently developed a report and webinar on many of these trends and benefits, as well as best practices.
To help us understand this interesting intersection and the somewhat complex relationship between structured documents and SOA, I recently interviewed Jake Sorofman, senior vice president of marketing and business development, for JustSystems North America. The sponsored podcast describes the tactical benefits of recognizing the dynamic nature of documents, while identifying the strategic value of exposing documents and making them accessible through applications and composite services via SOA.
Here are some excerpts:
A lot of companies will take on this notion of XML authoring from a tactical perspective. They are looking for new and improved ways to accelerate the creation, maintenance, quality, and consistency of the content that they produce. So they embrace XML authoring tools as the basis for creating valid XML, to manage the lifecycle of those documents and deliverables.
What they realize in the process of doing so is that there is a strategic byproduct to creating XML content. Now, it’s more accessible by various line-of-business applications and composite applications that can consume it much more readily.
If you take the documents that users thrive on and make those available to the SOA, and the composite business processes that that architecture is supporting, then you are able to bridge this gap between the people, the process, and the systems.
We’ve been talking about the notion of unstructured content as a target source to SOA-based applications, but you can also think about this from the perspective of the end application itself -- the document as the endpoint, providing a framework for bringing together structured data, transactional data, relational data, as well as unstructured content, into a single document that comes to life.
We provide the ability to embed this application logic within the document format. The document becomes very attuned to its environment, so it can render information dynamically, based on who you are, what your role is, and where the document is within a process. It can even interact with its environment.
This notion of the dynamic documents ensures that what you’re presenting is always an authoritative reflection of the latest version of the truth within the enterprise. You never run the risk of introducing inaccurate, out of date, or stale information to field base personnel.
You start seeing some blurring some between all these categories of technology around information, search and retrieval, semantics, and document management and data integration. It’s all resulting in a much a richer way of working with and utilizing information.
I don’t think that SOA architects have given a great deal of thought to date to unstructured content and how it plays into SOA architectures. So, there certainly needs to be consideration paid to how you get the information in, in a way that makes it rich to describe, reusable, more akin to relational data than documents themselves.