In-Depth

Components Crucial for E-business Development - Book Excerpt

• By Peter Fingar, Harsha Kumar , Tarun Sharma
• March 1, 2000

Developing e-Commerce applications is no trivial endeavor. Just as with all enterprise computing efforts, the task requires solid planning, systems architecture and project management. This [article] provides an overview of the development process from the requirements analysis stage to implementation.

The entire process is discussed against the backdrop of a fictitious company, OA.SYS Technologies, that requires the inter-enterprise integration of business processes. This approach is the way forward to sustainable development for the multitude of e-Commerce initiatives corporations must embrace as they build bridges to the emerging digital economy. Although a comprehensive treatment of this subject would require a book, this [article] walks the developer through the major steps of a full enterprise-scale development cycle while providing snippets of analysis, design and implementation artifacts along the way.

OA.SYS Technologies is a $900 million maker of computer systems for the business market. OA.SYS has one focused vision: To build custom computer systems tailored to individual business needs. OA.SYS has gained recognition as the provider of choice for business customers and government agencies and has established itself as a brand name recognized by purchasing agents across North America.

Headquartered in Flat Rock, Texas with 2,800 employees, OA.SYS' computers are manufactured to individual order specifications at facilities in Tampa, Florida; Wilton, Connecticut; and Phoenix, Arizona. The components that go into OA.SYS systems are provided by a network of suppliers located in Stamford, Connecticut; Austin, Texas; Limerick, Ireland; Penang, Malaysia; and Xiamen, China.

To accommodate its rapid growth, OA.SYS invested heavily in an enterprise resource planning (ERP) system to supplement and integrate the many legacy systems it had developed in-house during its start up years. Its inventory control system was developed on a mainframe and serves as the heart of the order entry and procurement systems. This workhorse has been revamped to a client/server architecture to streamline the operations of remote departments and facilities.

OA.SYS has been so successful on Wall Street that it has caught the attention of competitors, a number of whom are in hot pursuit in the business and government market sectors. Facing shrinking margins and increasing competition, executive management has conducted a series of intensive strategic planning sessions. Not wanting to rest on its past laurels, the focus of these sessions was corporate renewal, and the planning team included managers from customer and supplier organizations in addition to OA.SYS' CIO and executive management.

A careful analysis of OA.SYS' strengths, weaknesses, opportunities and threats produced a number of business initiatives. Common to all of the initiatives was the radical redesign of key, outward-facing business processes that could be enabled by the Internet. Of the 16 Internet-enabled initiatives the team identified, two were prioritized for implementation. Procurement and establishing a Virtual I-Market thus became OA.SYS' first forays into e-Commerce with the goals of cutting costs and increasing revenues through a new market channel.

Using her combined business and technology expertise, OA.SYS' CIO, Jini Martin, had to translate these business goals into requirements and constraints. A foremost requirement was quick time-to-market - a month earlier, a competitor with significant financial backing had announced intentions of entering the market with Internet-based offerings. Moreover, Jini knew that the company's unique business philosophy, policy, and processes were embedded in its legacy systems. She recognized the wisdom of leveraging, not obliterating, these corporate assets, as they embodied OA.SYS' competitive advantage.

Jini worked through the requirements and constraints with John Dorfman, the Systems Architect who would begin the process of designing the information and technology architectures for OA.SYS' current and future e-Commerce initiatives. Because they were moving the company into uncharted territory, their initial risk assessment caused them to select procurement as the first application to be developed. The rationale was that any mistakes made along the way toward their first e-Commerce application would be tolerated among suppliers, but absolutely not tolerated by customers. Moreover, Jini and John realized that they were not just developing a single application. Instead, they knew that they must develop an overall application architecture able to sustain multiple e-Commerce development projects and integrate with OA.SYS' existing systems as well as those of their suppliers and customers.

OA.SYS' e-Commerce strategy formulation

Once the strategic e-Commerce initiatives were established for OA.SYS Technologies, the procurement system was confirmed as the top development priority. The goal of the system was to streamline the trading processes between the company and its suppliers. OA.SYS was to host the procurement application and integrate it with some of the critical systems at suppliers' sites. Even though several points of integration between OA.SYS and its suppliers could have been tackled, the initial goal was to integrate the suppliers' inventory systems to provide up-to-the-minute data for the procurement system catalogs, and integrate the order entry processes to automatically handle purchase orders.

After a thorough analysis of the overall systems requirements, John and his team uncovered several issues they must address:

• Should they buy a pre-packaged procurement application or build the application from scratch?

• How could they leverage OA.SYS' existing IT infrastructure of legacy applications and ERP systems?

• How could they integrate their suppliers' disparate systems, technologies, and applications?

• How could they build a framework that would both support the development of the procurement application and accommodate future e-Commerce applications?

• How could they accommodate changing business rules and models within the new e-Commerce applications in order to maintain OA.SYS' unique competitive advantage?

To address the first issue, the architecture team decided to examine the "build versus buy" dilemma, and then create a deployment strategy that was in line with OA.SYS' strategic business initiatives.

The buy approach

John and his team evaluated several pre-packaged procurement solutions for the Internet. Most of the solutions were fairly complete in terms of the functionality required for a procurement application, but did not address the other issues the team had identified. Some of the problems they found with the pre-packaged solutions included:

• They did not integrate with OA.SYS' legacy or ERP systems that contained OA.SYS' unique business processes. Some packages offered data integration, but not process integration. Some pre-packaged solutions required eliminating or duplicating legacy systems while others were tightly integrated with a specific ERP solution (not the one that was deployed at OA.SYS).

• While pre-packaged solutions modeled industry standard practices and processes, the business rules were hard coded into the systems. As a result, they would be very difficult to change in order to accommodate the unique business processes that embodied OA.SYS' competitive advantage.

• Customization of pre-packaged applications would be tedious and expensive. Although pre-packaged solutions were perceived by management to be quick and easy to deploy, John's experience in customizing them rapidly dispelled such notions.

• After the initial customization, every update to the pre-packaged solutions or changes in business processes or rules would require rewriting the "wrapper programs" used to link to legacy systems. This would be a maintenance nightmare.

• The software modules of the pre-packaged procurement systems could not be reused in OA.SYS' other e-Commerce initiatives. Each of these e-Commerce packages would exhibit the same slew of problems and would not integrate with packages from other vendors, including the procurement application.

• Every instance of integration with a supplier's systems would be a customization effort that would have to be funded by OA.SYS.

The build approach

After considering all of the issues brought about by pre-packaged apps, John's team decided to analyze the "build from scratch" approach. After considerable review, the team found that despite the flexibility that in-house development could deliver, several issues would have to be addressed:

• Building a solution completely in-house would be very time consuming and expensive.

• Even though they were technically competent and talented, John's team lacked experience with Internet development and was new to e-Commerce application environments. Compounding their Web expertise lag was the tidal wave of new technologies and buzzwords: EJB, XML, DNA, XQL, Servlets, JTS, DOM, RDF, OTM, IIOP, et al.

• In order to reuse common functionality across the other e-Commerce applications, John's team would have to spend considerable time building an infrastructure of reusable functional components. Designing and building such an infrastructure would have to be accomplished before even starting the first application. Without this preparation, however, major development time (and cost) as well as integration and maintenance costs would be associated with every application.

• Due to the complexity of the Internet as a computing platform, OA.SYS' application developers would end up focusing more on technology issues and less on business issues.

After assessing the tradeoffs of both these development models, John's team searched for a way they could combine the benefits of both the approaches while avoiding the pitfalls of each. If they could buy a framework of application components that gave them the core business functionality they needed and yet was open enough for the team to custom code their unique business processes, most of the critical issues would be addressed, and they could simply "assemble" feature-rich and yet flexible e-Commerce solutions.

The component assembly approach

During their search for a sustainable e-Commerce development strategy, John's team evaluated an emerging approach to applications development: component-based development. Component-based development is an architectural approach where each layer in the architecture offers services to higher layers while hiding the details of how those services are implemented. Although software components have been embraced since the beginnings of computing, traditionally they have been used to provide low-level technology services such as system calls and window APIs. Application components, on the other hand, offer services that address business semantics such as user profiling and workflow routing. In order to build e-Commerce applications using component-based development, John's team realized that the architecture would have to:

• Consist of reusable software modules rich in business functionality. The software modules would have to be loosely coupled and based on open standards so that they could integrate with each other without being dependent on each other.

• Provide uncomplicated integration with legacy and ERP systems of both OA.SYS and its suppliers.

• Provide ease-of-use and flexible support for custom application logic, user interface design, configuration and postdeployment maintenance.

• Be scalable to support more users and transactions as the business grows. Scalability must be achieved via distributed computing platforms currently under evaluation by OA.SYS, including Microsoft's DCOM with its Microsoft Transaction Server (MTS) for component coordination, and CORBA Object Transaction Monitors (OTM), including IBM's Component Broker, BEA System's M3, IONA's OrbixOTM, and others supporting Enterprise Java- Beans (server-side components).

• Be extensible to permit additional functionality over time. As development software for the Enterprise JavaBeans specification becomes available, the architecture would have to support drag-and-drop rapid application development (RAD) to give OA.SYS and its partners the agility they would require to support business changes.

A closer look across the many e-Commerce applications that were to be developed revealed distinct patterns of functionality. If these distinct patterns were implemented and available as software components, John's team could assemble their new applications quickly and inexpensively by reusing these modules. Using their Java Integrated Development Environment (IDE) they could assemble the components into applications with "glue code" that would incorporate OA.SYS' unique business processes.

[An earlier chapter] discussed the framework of the core business functionality common to most e-Commerce applications and essential to inter-enterprise process integration. Some common e-Commerce application functions include profile management, collaboration and mediation, application security, workflow and process management, event notification, data and object management, and transaction processing. When implemented in software as components, these functions appear to application developers as a set of services. These services are part of a layered software architecture. Within each component, services are implemented by a collection of business objects. A service is simply a request protocol for a logical unit of work-for example, update employee's address, move the task to next person in queue, send the purchase order to the supplier via EDI and so on. Services can be invoked without the requester needing to know the implementation details of the software that delivers them. The process is very much like driving a car without needing to know how the engine works. It is extremely important, however, that component services are provided through a standard, published interface to ensure inter-operability, ease of use and loose coupling. To summarize, an application component is a collection of code that provides one or more services based upon a clearly-defined, standard interface as illustrated in Fig. 1.

Business rules and unique business processes are embedded in the e-Commerce applications' glue code that plugs in the services provided by the components as required. The services provided by the components are very business-centric and hide the technical details of the objects they encapsulate. Application developers, therefore, can focus more on the business rather than technology issues.

Based on their domain, e-Commerce application components can be classified into three main categories: cross-application components, application-specific components and industry-specific components. Cross-application components provide a set of services that can be used across several different applications. They have a higher granularity when compared to other technology components such as a JDBC driver, but a lower level of granularity when compared to a specific application. Application-specific components, on the other hand, provide a higher level of granularity and may use cross-application components configured to provide application-specific functionality. An industry-specific component is unique to a given industry. To illustrate, a cross-application workflow component allows any kind of workflow to be modeled. An application-specific procurement component uses the cross-application workflow component to model a typical requisition workflow. An example of an industry-specific component is a "stock price analyzer" for the financial services industry. Any one or a combination of these e-Commerce application components mentioned above could be used to assemble customized applications as shown in Fig. 2. The figure also shows where application components fit within a modern distributed computing infrastructure.

Having evaluated all three approaches to e-Commerce application development, John's team summarized their findings in Table 1 and presented them to management. Overwhelmingly, the component assembly approach stood out as the right choice for OA.SYS.

Component-based development - Putting it all together

Once John's team determined that components were the right way to build e-Commerce applications, they moved on to the work at hand - to execute the development and deployment strategy, beginning with the procurement application. John assigned his business analysts to start gathering requirements from the intended users of the system within OA.SYS and the suppliers. The focus of the requirements gathering team was on the inter-enterprise business processes. The team used their existing business process engineering tools, but the actors they modeled were external as well as internal. In other words, their domain modeling was aimed at Inter-enterprise Process Engineering (IPE). Their goal was to identify and eliminate duplicate processes and ineffective hand-offs across enterprise boundaries. These new inter-enterprise processes would then be jointly designed and owned.

Simultaneously, John asked his technical lead to start evaluating the components that they would need to buy that would give them the core functionality to assemble their e-Commerce applications. One of the critical features required of these application components was the ability to provide their services to not only OA.SYS, but also to their multiple trading partners. After a thorough analysis, OA.SYS acquired its initial set of application components and incorporated them into its software development repository.

Figure 3 shows the application development life cycle they adopted to create an overall architectural framework while building the procurement application. For some time, OA.SYS had been using object-oriented analysis and design methods to develop their enterprise systems. The technology team was well versed in the Unified Modeling Language (UML) and had adopted use cases as their requirements gathering and analysis technique. They were evaluating Fusion, the Unified Process and others for adoption as their overall systems development method, and were pleased that these methods had support for component modeling. In addition, they were delighted to learn that the shift to component-based development methods could accelerate the software development life cycle as pre-fabricated components shifted the focus from implementation to integration.

During all phases of development, the repository of modeling artifacts and pre-tested components was available for reuse. The transition to component-based development did, however, affect their development culture and training was needed to refocus on architecture rather than building code. The architecture provided an infrastructure for coordination, and standards that defined what components could be plugged into it. Training extended the team's expertise from building software to component assembly.

Requirements gathering

During the requirements gathering phase, John's business analysts met several intended users of the proposed system, both throughout OA.SYS and within the trading partner network. They had to identify the roles that each of these entities would play, the inter-enterprise access privileges they needed, and how they would like to see their systems interface. One of the essential tasks assigned to the analysts was to engineer and streamline processes across OA.SYS and its vendors so that they could eradicate duplicate processes, eliminate inefficient hand-offs, and create new real-time interconnections.

The requirements team needed to identify points of integration between OA.SYS' new e-Commerce procurement system, their existing ERP/MRP and legacy systems, and their suppliers' ERP/MRP and legacy systems. The work involved identifying new workflows within the organization and across trading partners. Although there were several applications that needed to be integrated, the business analysts decided to use an iterative approach. The first iteration would integrate only two supplier applications: the inventory systems (for getting up-to-date catalog and pricing information) and the order entry systems (for sending orders electronically to the suppliers' order entry systems). This level of integration proved to be a challenge because the suppliers used different technologies in their inventory and order entry systems. Some larger suppliers utilized electronic data interchange (EDI) to send catalog information and receive purchase orders. Others published paper catalogs and received purchase orders via fax. To accommodate such disparate systems and business data formats, the integration simply had to be part of an overall, consistent framework.

The team used their existing business process engineering tools for gathering requirements and mapping the new inter-enterprise business processes. In addition, they developed the context level use case diagram for the system shown in Fig. 4.

OA.SYS requisitioners were to be able to browse or search for the items they wished to procure, and create requisitions. Based on workflow rules, OA.SYS' requisitions would be routed to the appropriate managers for approval. The managers would receive notifications for approval based upon their preference: fax or e-mail. Once approved, requisitions were to be routed to the Purchasing Manager to be dispatched as a Purchase Order using the supplier's preferred method of delivery (EDI, e-mail, or fax). Preferences throughout the system for both OA.SYS and suppliers were to be maintained by a profiling component. In the case of EDI, data was to flow into suppliers' order management application electronically, thus streamlining the whole procurement process from catalog maintenance to purchase order processing. Where possible, OA.SYS and its suppliers were to share their new inter-enterprise business processes in real-time.

The team's requirements gathering work was maintained in a repository that permitted reuse of their requirement artifacts as the project moved forward into the analysis phase. The use cases in the repository would bind further steps in the development life cycle and were essential to quality assurance and systems testing.

Analysis

Once the business analysts gathered the requirements, they released the functional requirements to the technical team to begin the analysis phase. During the analysis phase, the technical team elaborated upon the context level use cases to prepare a detailed specification of the requirements of the system and to develop a logical application architecture. They also developed the initial analysis object models. The analysis artifacts they produced included a high level architecture, detailed use case diagrams, test cases, class relationship and object interaction diagrams, and sequence diagrams. Architectural decisions were critical because the many artifacts created at this stage would be held in a repository for later inspection and reuse.

Figure 5 shows a detailed use case diagram of the OA.SYS procurement system. It models the system's intended functions, its surroundings and the relationships among the actors involved in the system. Actors are not part of the system, but are either users who interact with the system or are external systems or resources that have to integrate with the system.

Each module, illustrated in [Fig. 5] represents a major piece of functionality that delivers value to the participants. For example, the Approve Request module provides the following functionality:

• Authenticate and authorize the user

• Display the list of requests awaiting disposition

• Allow the user to approve the request, depending upon privileges

• Route the request to the next participant in the work flow

• Notify the appropriate participant(s)

Design

Once the use cases and other analysis artifacts were finalized, the design team moved on to refine the logical design and transitioned from the problem space to the solution space. This entailed designing the flow of operations within each functional module of the system from the detailed requirements gathered during the analysis phase and mapping analysis models to the target platform. They packaged their deployment models so that they could be implemented in a distributed computing environment (e.g. CORBA or DCOM). Reusable components accelerated the design phase dramatically.

Figure 6 shows a sample design artifact, a sequence diagram of the Approve Re-quisition module discussed earlier.

Laying out the sequence diagram and depicting the sequential flow of events allowed the design team to identify the interaction between objects of various functional modules in a time sequence. This activity allowed the design team to identify auxiliary objects and the messages exchanged between these objects (e.g., Approve is a message sent by the Approver object to the Requisition object). Then they structured the methods within the objects to support the desired functionality (e.g. An Approver object should have a public method called canApprove() and the Requisition object should have a public method called approve()). With preexisting components available, the design team inspected the components for services that could be reused to accelerate the process.

The next step within the design phase consisted of two parts:

• The Business Object Design

• The User Interface Design

The business object design step consisted of the initial layout of the objects and their organization within a categorized hierarchy of similar packages. In this phase, the objects were modeled to encapsulate the data and provide methods (APIs or messages) for objects to communicate with each other. At this stage, the cardinality relationships were defined between the objects (e.g., one Approver object can approve many Requisition objects).

Figure 7 shows a sample object model for the Requisition Approval functionality within the procurement application.

The User Interface design addressed the effect of user task requirements on the application flow, as well as the screen design from the user's view. In this phase, the project manager worked with the graphics team and the usability group to build prototypes of the application, keeping the user-experience in mind. Some of the key design issues were the look-and-feel of the application, the ease of finding information and acting on it, the ease of initiating and tracking transactions, and user profile related functionality. In addition to authentication and access management, the user profiles needed to support digital signatures for nonrepudiation. Dynamic profiling was needed because purchasing agents are time constrained and want the system to bring to bear all the resources for the task at hand in a convenient manner that allows them to do their work efficiently. Often a task cannot be completed in one work session, and the user will want work in progress to continue where it left off on successive sessions.

Once the object model and design were finalized, the design team searched the component repository to see which of the existing objects could be reused. They found that most of the objects they required for building the procurement system either existed as part of the component framework, or could be derived from the ones that did exist. For example, an Approver object could easily be modeled with a User object from the profiling component. The basic attributes like Username, Password, and Role were available directly, whereas those attributes that were application specific (e.g. purchasing limit) could be easily associated through the Extended Attribute object provided by the component. Similarly, objects required for defining and managing workflows, user notifications and data integration of the legacy and ERP systems were available out of the box with these components.

Table 2 shows a sample mapping from application-specific objects to objects available in the application components.

The next step of the design phase was the configuration of the components to model the objects according to the design documents. The technical lead used the component's administrative tools to configure these objects. He defined the workflows, events, user profiles and resource access privileges, and data integration templates that would be used in the new procurement application. Figure 8 shows a sample component administration tool that was used for configuring the user profile objects while Fig. 9 shows the configuration of the workflow component.

Once the objects were defined and the templates laid out, the system design document was updated with screen shots from the prototype, the functional description of the modules, the specifications for the implementation, and the scenarios for the regression tests. These specifications were then distributed to the entire development team and tracked using a project management tool.

Development

The developers used their existing Integrated Development Environment (IDE) to assemble the application. Figure 10 illustrates a sample IDE used for component assembly.

During the development phase, each developer was responsible for the unit and integration testing aspects of the glue code they built to assemble the application components. Once the coding effort was completed, the application came to life. Figure 11 is a snapshot of one of the screens in the procurement application.

Testing

Although the quality assurance (QA) team had been involved from the inception of the project, they returned to the use cases from the requirements gathering phase and went into overdrive. Their intention was to break the application at every step. They worked against a formal test plan and the functional requirements documents to ensure that the functionality in the application met the requirements specifications. In addition, the QA team tested transactions that were "not expected" by the system to see how the application would respond. All bugs and system change requests were tracked using an integrated project and configuration management system. Once the integration testing was complete, OA.SYS was ready to begin running pilot programs with some of their most strategic suppliers.

Pilot

One of OA.SYS' close trading partners, Keyboards International, was eager to participate in the initial pilot of the new system. The technical leads shipped out the integration templates for the inventory system so that they could pull the catalogs directly out of Keyboards International's inventory system in real-time. The purchase orders were handled electronically using the traditional EDI mechanism. All that Keyboards International's MIS team was required to do was to map their existing data schema elements to those specified in the template that OA.SYS shipped to them, and have the catalog administrator initiate the transfer of item data, with contracted prices, to OA.SYS. All the items were available immediately for the requisitioners at OA.SYS.

OA.SYS requisitioners were able to browse or search for the items they wished to procure and create requisitions. Based on workflow rules, OA.SYS' requisitions were routed to the appropriate managers for approval. The managers received notifications for approvals based upon their preference: fax or e-mail. Once approved, requisitions were routed to the Purchasing Manager to be dispatched as a Purchase Order via EDI to Keyboards International. Once an EDI document was received by Keyboards International, the data flowed electronically into their order management application, thus streamlining the whole procurement process from catalog maintenance to purchase order processing. The two companies shared their new inter-enterprise business processes in real-time.

The launch of the procurement application

After a successful pilot, OA.SYS extended the new procurement application to all its suppliers. OA.SYS' new infrastructure allowed them to roll out follow-on e-Commerce applications in record time. The component-based architecture could scale as new suppliers were added as well as integrate the disparate technologies deployed throughout OA.SYS' supplier network. In addition, the new e-Commerce framework set the stage to expand their e-Commerce applications portfolio.

After their meeting with senior management to brief them on the new procurement system, Jini and John were confident and looked forward to taking on the I-Market initiative. Although they knew that the I-Market project would not be a trivial undertaking, they now had a solid architecture on which to build.

The history of business computing is demarcated by major shifts in the use of the computer for competitive advan-tage. Early mainframe systems brought productivity to the back office while personal computers brought productivity to the front office. With the advent of the Internet, business computing moves to the front lobby giving customers, suppliers and trading partners direct access to a company’s business processes and systems. Each new era of business computing brought not only a new realm of possibility for competitive advantage, but also increased complexity and a corresponding paradigm shift in the software development processes needed to accommodate the complexity.

To tame the complexity of large-scale distributed applications and develop agile inter-enterprise systems, it is necessary to undertake the shift from a conventional development methodology to a component-based development paradigm. As we explored in this brief treatment of the subject, component-based development is not a replacement for existing development methods, it is a next step in the evolution of modern software development methods and techniques such as those found in the UML. With these needs clearly recognized, researchers, standards bodies such as the Object Management Group, and software development corporations are currently formalizing the methods and tools of component-based development. Companies wanting to remain competitive in the digital economy should act now to incorporate e-Commerce components and component-based development as strategic business weapons.