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
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
- How could they leverage OA.SYS' existing IT infrastructure of legacy applications and
- How could they integrate their suppliers' disparate systems, technologies,
- 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
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:
The build approach
- 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.
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
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
- 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.
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.
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)
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
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
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
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
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.
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.
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.
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.