Business Documents

In this application category, XML documents contain information about fundamental business entities such as customer, order, and invoice. The crucial benefit of XML is that it allows humans and software to use these documents in the same format. The need for Business Document applications usually stems from one of three requirements.

• Automate the workflow of document processing. Everyone agrees that moving paper documents around is an efficient means of executing business processes. However, prior to XML, automating workflow had two drawbacks: Businesspeople were tied to a particular workflow system, and the document data representations often violated business people's concepts of what a document looks like. With XML Business Documents, all workflow systems that use XML can interoperate , and businesspeople are free to view familiar documents, while the system is free to process the underlying data.

• Synthesize familiar documents from business software systems. Typically, business systems present business information in terms of its underlying data model. Often, this representation is not particularly convenient for businesspeople, especially when a logical business document encompasses information from multiple business systems. Software engineers who build these applications do not want to hand-create each type of document. Synthesizing XML business documents using an automated tool is an efficient solution for both users and developers.

• Automate document exchange. With the connectivity enable by the Internet, many businesses want to achieve operational efficiency by using the business document architecture discussed in Chapter 4. XML Business Documents such as Order and Invoice constitute the seed of an effective supply chain management system. Each business simply needs to accept an explicit set of Business Document definitions and then map them to data representations used by business software systems. Software engineers do not have to hand-code a translation bridge for every trading partner, and businesspeople can still view familiarly formatted documents if they wish.

The strength of Business Document applications is that people can view documents and software applications can process them, using the same underlying representation. Presentation concerns and compatibility with XML formats from other organizations are both significant, so XSLT can play a substantial role in these applications. Businesspeople definitely want to view the documents in a familiar layout, but the need for visual sophistication is less than that for Content Documents. On the other hand, software engineers need more sophisticated tools so they can efficiently map XML document definitions to the data models used by business software applications.

Development Process

In some sense, Business Document applications differ the most from traditional software development. Their general goals are to provide a means of universally defining common business concepts and provide the infrastructure for cooperatively manipulating these concepts. At the analysis level, some organizations have used information engineering or business object modeling to define common business concepts in a fashion analogous to XML schema design. But even then, they actually implement the information exchange described in these models on an ad hoc basis. XML provides a means of formalizing the implementation of information exchange services. As Figure 6-2 shows, the development process for Business Document applications has the following ten steps.

Figure 6-2. Development Process for Business Documents

1. Adopt schemas. Because Business Document applications concern the exchange of information related to fundamental business concepts, there are often existing schemas for these concepts. In some cases, industry groups may propose a set of schemas to cover common business concepts. In others, a partner may want to agree on common schemas. In yet others, a vendor of a third-party software package may provide schemas. In all these cases, application developers have three choices of how they adopt schemas. One, they may simply adopt them as is. Two, they may work with the other parties to help define them. Three, they may choose to use parts of them, with modifications to meet their particular needs.

2. Design schemas. In some cases, Business Document application developers may need to define fundamental business concepts that are unique to their organization or develop enhanced definitions that give their organization a competitive advantage.

   In these cases, application developers will design their own schemas.

3. Specify document processing. Because Business Document applications typically facilitate one or more business processes, they must include rules for document processing that reflect the business process rules. For example, in supply chain applications, these rules will reflect the allowable interactions between suppliers and customers. In workforce automation applications, these rules will reflect the processes employees should take in performing their job tasks .

4. Implement front-end processing. Business Document applications have human users. Developers must therefore implement the processing rules that apply to the documents produced and consumed by human users. These rules may include allowable actions such as "approving" or "rejecting." They may also include security restrictions. Developers must develop the code necessary to enforce such rules, or administrators must configure the off-the-shelf packages used.

5. Design stylesheets. Human users comprise one of the information consumers for Business Document applications. Therefore, once application developers have decided what information to present and the processing rules that apply to the information, the next step is to develop the layout for that information. In some Business Document applications, users will view documents within an XML-capable browser using stylesheets, so layout design implies stylesheet design. In some cases, users may require specialized client software for certain types of document manipulation. Applying digital signatures to a business document or visualizing document data using SVG are good examples. For such applications, layout design may imply more traditional graphical user interface design.

6. Integrate front-end. With the front-end processing rules and interface layouts in place, developers must integrate them with front-end clients. For XML-capable Web browsers, this integration may consist simply of providing a link to a starting page from a well-known Web location. For non-XML-capable Web browsers, this integration will require distributing updated versions of the browser or XML plug-ins. Sometimes, the sophistication of Business Document applications requires custom clients perhaps for such tasks as real time collaboration. In this case, developers may have to write code that connects the client graphical user interface to the front-end processing implementation.

7. Implement application processing. Software users comprise the other information consumer for Business Document applications. Developers must therefore implement the document processing rules that apply to the documents produced and consumed by software users. These may include required actions such as "create" or "update," as well as transaction restrictions. Developers must either write custom code necessary to enforce such rules or write scripts to drive an off-the-shelf application. Note that this step and the next two steps may occur in parallel with the previous three front-end steps. This step presents something of a challenge during the testing phase because the potential range of document data makes it difficult to achieve complete functional testing coverage.

8. Implement transforms. Business Document applications almost always involve information exchanges with other parties. Usually there is substantial variation in the data that comes from these parties. Most Business Document applications need XSLT transforms to handle this variation. This step is most important in the design phase because that's where the decisions about the expected variations occur. The availability of XSLT generation tools usually makes their implementation straightforward once the requirements are clear.

9. Integrate application. With the application processing rules and data transformations in place, developers must integrate them with other application components. Developers must define the interface to these components and implement the code necessary to propagate the processing rules through these interfaces. This step becomes quite important during the testing phase because quality of integration and its scalability greatly affect system acceptance.

10. Integrate storage. In most cases, an application requires persistent storage for business documents. Developers will have to integrate the application processing infrastructure with the persistent storage mechanism. Native XML stores and data servers include automated functions for the storage and retrieval of XML documents. Many traditional DBMSs include components for such storage and retrieval, although often some custom coding to map XML documents to the DBMS's native model is required. Note that storage integration can occur in parallel with front-end and back-end steps. As in Content Document applications, this step is prominent during load testing.

A principal characteristic of Business Document application development is that developers must address the needs of both human and software users. Therefore, after an initial set of steps necessary to agree on a set of information exchange formats, the development process really has two separate paths: one for the human users and one for the software users.

This situation contrasts with traditional software development, where there are constraints from either human or software users but not both. The existence of constraints from both sources can have negative effects on the schedule in a spiral development process. Although the two branches of development may occur in parallel, once one branch has feedback that requires changes in the schema or application processing phases, the feedback affects the other branch, potentially setting off another round of feedback. Achieving the benefits of parallel development therefore requires excellent up-front design to minimize midstream changes.

Required Staff

Because the goal of Business Document applications is to align information exchange with business process flow, implementing such applications requires a wide variety of staff types. Skills have to include business partnership management, business process analysis, and development of interfaces to the different components of the enterprise information architecture. Specific types of required staff include the following.

• Standards bearer. Because Business Document applications deal with the exchange of information about fundamental business entities, standards bodies are likely to take a strong role in defining schemas describing these entities. A standards body may be an accredited standards organization. It may also be an industry group or even an internal group within a large enterprise. In any case, the application development team needs a representative to the standards body. This standards bearer ensures that schemas describe business entities in a way that meets the needs of the team. The standards bearer needs a combination of both business and technical experience. The standards bearer will have experience in business management, business process design, and application design.

• Business analyst. The business analyst's role is to make sure that the schemas defining business entities and the document processing rules accurately reflect the organization's business processes. The analyst collaborates with the standards bearer to define the organization's goals for the standards body and collaborates with the architect to decide which schemas to adopt and how to design internal schemas. The business analyst will have experience in the line of business operation, business process design, and perhaps data modeling.

• Architect. Most Business Document applications span a large user population and a large number of back-end systems. Therefore, there is a need for a staff member to coordinate a large spectrum of technical design tasks. The architect works with the business analyst to specify schemas and document processing rules. He also works with application developers, user interface designers, and the different integrators to ensure that the application architecture operates within the constraints imposed by their respective components of the application. The architect will have a wide variety of technical skills, including requirements analysis, application design, and data modeling.

• Application developer. In most cases, a Business Document application requires the development of code to implement business logic. In workforce automation applications, there is the task processing engine to implement. In applications that use business data visualization, there is data processing code to write. In applications with special client capabilities, there is client code to write. This coding requires an application developer with experience in the appropriate programming languages and tools.

• User interface designer. For the parts of a Business Document application that interact with human users, there is a need for appropriate user interfaces. A user interface designer specializes in designing such interfaces based on how the presented information relates to the user's job task. This staff type has a number of options for the design, including the use of stylesheets, special browser plug-ins, and custom clients. Of course, these choices are constrained by the overall architecture of the application. The user interface designer will have experience in user requirements analysis, graphic design, Web page design, and user interface design.

• Client integrator. In some cases, the user interface needs integration with the existing client infrastructure. This integration may include the deployment of updated browsers, the deployment of special plug-ins, and the deployment of custom user interface clients. For plug-ins and custom clients, there may be issues of integration with client desktop management and configuration tools. These tasks are all the purview of the client integrator, who will have skills primarily in browser configuration and desktop management.

• Data integrator. Because a Business Document application must provide for the exchange of information with existing applications and data sources, there is the crucial problem of integrating the Business Document application with these existing systems. The data integrator translates the information format in the sources into the appropriate schema format. In some cases, this translation may simply require using a graphical tool. In others, it may require some scripting. The data integrator will have experience in database programming or administration and perhaps programming languages such as Java, C++, and Perl or the APIs of particular packaged applications.

• Administrator. A typical Business Document application has many pieces of server infrastructure. These pieces include Web servers, application servers, data servers, DBMSs, and packaged solutions. Each requires its own administrator to install and configure the server as well as collaborate with the architect and application developers to integrate them into a single functioning system. The administrator will have experience as a Webmaster, system administrator, network administrator, or database administrator, as appropriate for the particular type of server.

Largely, all the staff types required to deploy Business Document applications already exist within enterprises and vendors . The problem is that they rarely have to coordinate their actions to the extent necessary with XML. Of course, much of this lack of coordination stems from the fact that standards bearers , business analysts, application developers, interface designers, and data integrators do not have a common basis for communication. A unique benefit of XML is that it can provide this common basis. However, project managers still have to address the problem of coordinating and facilitating communication among these separate types of staff.