text:
|Publication number
|Publication type
|Application number
|Publication date
|Jun 27, 2006
|Filing date
|Dec 22, 1999
|Priority date
|Dec 22, 1999
|Fee status
|Publication number
|Richard D. Cornelius, Andreas Stepniczka, Kevin Chu
|Original Assignee
|Accenture Llp
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (53), Non-Patent Citations (8), Referenced by (605), Classifications (21), Legal Events (6)
|External Links: USPTO, USPTO Assignment, Espacenet
The present invention relates to networked interfaces and more particularly to conducting trade finance business operations including the initiation of agreements.
In international sales of goods, the buyer and seller may not know each other, or may not be familiar with the other's legal system. Thus, one of the major difficulties in international trade is to assure payment, particularly when the buyer or the seller is a small or medium sized business which expects difficulties in obtaining payment should a problem arise. Conventionally, a letter of credit is used in international trade to shift transaction risks to parties better able to manage these risks, specifically, to shift payment risks from unknown entities, such as a distant buyer, to known entities, such as a local bank.
A letter of credit (L/C) is usually an irrevocable undertaking by a bank to pay the beneficiary of the letter, for example, a seller of goods, specified sums of money when certain conditions are fulfilled, to be charged to the account of the person, for example, the buyer of the goods, who causes the bank to issue the letter of credit.
Generally, after a buyer and seller have made an agreement for the sale of goods, the buyer instructs its bank to open an L/C in favor of the seller. The buyer's bank advises the seller's bank that an L/C has been opened in favor of the seller, and the seller's bank accepts the buyer's bank's guarantee to pay. The seller's bank advises the seller that an L/C has been opened in its favor, and the conditions which must be fulfilled for payment to occur. Usually, the seller's bank makes an irrevocable promise to pay the seller upon presentation of appropriate documents. The L/C document is considered an asset of the seller, and can be sold or assigned by the seller.
Documentation which the seller usually must present to obtain payment includes a bill of lading from its shipper, an invoice identifying the purchase, an appropriate insurance certificate, a certificate of inspection from an inspection firm confirming that the required goods are being shipped, export licenses and/or health inspection certificates, and certificates of origin used by customs personnel. After the correct documents are presented, the seller's bank pays the seller, then collects payment from the buyer's bank and delivers the presented documents to the buyer's bank. In turn, the buyer's bank obtains payment from the buyer.
Meanwhile, the shipper, via a carrier, transports the goods to the buyer's location. The carrier requires presentation of the bill of lading, which was delivered to the seller, before transferring possession of the goods to the buyer.
The buyer obtains the bill of lading from its bank after payment, and then the buyer and its broker arrange for presentation of the bill of lading to the carrier and delivery of the goods to the buyer's location. Often, the carrier delivers the goods to the buyer's broker at the customs entry point of the buyer's country.
During an international trade using a conventional letter of credit, the buyer and seller are assumed to be located in countries B and S, respectively. The issuing bank is a bank in country B which has agreed with the buyer to issue a letter of credit in favor of the seller. The paying bank is a bank in country S known to the seller which has guaranteed the letter of credit to the seller. The intermediary bank, which may be in country B, country S or a third country, is a bank trusted by both the issuing bank and the paying bank.
To begin, the buyer issues a purchase order based on an agreement previously concluded between the buyer and the seller. Then, the buyer approaches its chosen issuing bank and instructs the issuing bank to open a letter of credit in favor of the seller confirmed on its chosen paying bank. The letter of credit may be confirmed, unconfirmed or standby. In a standby letter of credit, if the transaction proceeds properly, the standby L/C expires, but if the transaction does not proceed properly, the damaged party draws on the standby L/C.
The issuing bank is assumed in this example to have no direct relationship with the paying bank, so the issuing bank approaches an intermediary bank which accepts the guarantee to pay of the issuing bank. The intermediary bank then approaches the paying bank, which accepts the guarantee to pay of the intermediary bank.
The paying bank then advises the seller that an L/C has been opened in its favor and that upon presentation of appropriate confirming documentation, including the Bill of Lading from a Shipper, the paying bank will pay the seller. In this scenario, that is, assuming a confirmed L/C, the paying bank must pay without recourse upon presentation of appropriate documentation. In other cases, the paying bank has recourse, that is, the paying bank passes the documentation to the issuing bank and obtains payment therefrom before paying the seller.
The seller finishes producing the goods and arranges for shipment with a shipper. Goods are passed to the shipper. The shipper transports the goods to a port of entry in the buyer's country.
Upon receipt of goods, the shipper provides the seller with a bill of lading. The seller presents the bill of lading and other confirming documentation to its paying bank in order to collect against the L/C. After verifying that the documentation is in order, the paying bank pays the seller.
The paying bank presents the documentation and its proof of payment to the intermediary bank, which pays the paying bank. The intermediary bank in turn presents the documentation and its proof of payment to the issuing bank, which pays the intermediary bank. The issuing bank then obtains payment from the buyer and gives the buyer the confirming documentation including the bill of lading.
The buyer gives its agent, such as a broker, the bill of lading and other necessary documentation. The buyer's agent obtains the goods from the shipper, clears the goods through customs in country B and arranges for delivery of the goods to the buyer. The international trade is now completed.
An L/C shields the seller from the risk of non-payment by the buyer and reduces the risk to the buyer that the buyer will pay for goods not received. With the L/C, the risk of non-payment is assumed substantially by the buyer's bank, which is assumed to be able to evaluate the risk of non-payment by the buyer. The seller's bank assumes the risk of non-payment by the buyer's bank, which the seller's bank is assumed to be able to evaluate. The banks require fees to compensate them for their risks and the expenses they incur in connection with the L/C. Typically the buyer's bank also requires that the buyer pledge collateral such as cash or marketable securities against the L/C or otherwise reduces its exposure in the event of non-payment by the buyer. These bank fees and requirements are a burden on trade, particularly on the buyer. Also, the delay involved in establishing an L/C for each transaction is a burden on trade.
Problems multiply because the L/C mechanism separates the transaction into substantially independent contracts, namely, the contract for the sale of goods from buyer to seller, the bill of lading, and the letter of credit.
One fertile source of difficulties for the seller is that its bank usually requires that all the documents called for in the L/C exactly correspond with the terms of the L/C, and withholds payment to the seller even due to typographical errors and minor misspellings. This has caused an enormous amount of frustration to sellers seeking payment.
Another problem is that the L/C holder can obtain payment with the correct documents, even if shipment has not actually occurred.
Yet another problem is that the L/C document itself has value, so there are expenses associated with its custody and in assuring that it is genuine.
A bank incurs roughly the same expenses in connection with an L/C, independent of the value of the goods to which the L/C pertains. The bank's fee is sometimes expressed as a percentage of the amount of the L/C, such as 1%. Assuming, for example, that the bank's expenses are $10,000, it will be appreciated that the bank is reluctant to open an L/C for transactions involving less than $1,000,000 of goods, as this business is not profitable for the bank. Thus, it is difficult for parties wishing to participate in international trade to use the L/C mechanism when the value of the goods involved in a transaction is small enough that the expense of an L/C becomes significant.
The present disclosure provides for initiation of an agreement utilizing a network. First, a buyer and a seller are allowed to negotiate terms of trade utilizing a network. A form is received from the buyer indicating the terms of trade utilizing the network. Also received utilizing the network is an identifier of the buyer. Thereafter, the form is sent to a bank for assessing the credit of the buyer utilizing the network. The bank to which the credit application is sent is based on the identifier. Next, the form is forwarded to a seller along with the assessment of the credit of the buyer. At such time, the seller is permitted to digitally sign the form utilizing the network. The digitally signed form is then received from the seller utilizing the network after which a notice is sent to the buyer indicating that the digitally signed form has been received from the seller, thus initiating the agreement.
In one embodiment of the present invention, an identity of the buyer is authenticated prior to sending the form to the bank. Such identity may be authenticated by requiring the submission of an identifier and a password.
In another embodiment of the present invention, the credit of the seller may be verified. As an option, the form may include a combined purchase order proforma invoice.
The invention will be better understood when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein:
igure 21 depicts a process for account settlement and/or financing for a buyer (importer) in the VTrade system;
Virtual Trading (VTrade) is a "method" of conducting the trade finance business that achieves the same results as traditional trade finance through a new value proposition and a rethought process. In the VTrade operating model, physical documents are reduced. The number of parties involved are kept to the minimum. Three key components of VTrade model are:—VTrade Enterprise, Payment Network and a Bank. It should be noted that though "Bank" is used throughout this document, it is intended that the term include any type of credit provider.
VTrade Enterprise provides a one-stop trade finance service via the Internet. It is a highly efficient process excellence factory with full automation in handling credit application, payment, trade document submission and other critical processes. The Bank extends trade credit to the buyers and provides funding for the trade transaction.
The following are some of the features and benefits provided by the VTrade system.
VTrade deals in the underlying goods that are financed while traditional Trade Finance deals with the documents associated with the goods which are financed. VTrade eliminates documents usually associated with international trade. It supports international trade in a similar fashion to the way credit card supports retail commercial transactions. VTrade is to international trade finance transactions as what ATMs are to the retail banking transactions. VTrade allows "Trade Finance" transactions to be carried out at substantially lower cost than traditional Trade Finance transactions.
VTrade removes the inefficiencies in traditional Trade Finance business by eliminating the handling of documents which acted as surrogate to the actual goods traded. In traditional Trade Finance, documents were used as surrogate to facilitate the proximity of payment of a trade transaction to the event of taking delivery of goods. In VTrade, the process of processing the documents which are required under traditional Trade Finance is eliminated. Hence, VTrade is able to deliver the same results as traditional Trade Finance at a much lower cost. The following table contrasts traditional trade finance and the VTrade environment.
Trade Finance (Letters of Credit)
Buyer and seller trade settlement
through multiple intermediating
Heavily centered around documentary
checking by multiple banks which
slows down payment turnaround. 80%
of trade documents are 'discrepant"
and average order to payment is
around 9 months
Processes are cumbersome because
letters of credit are more sophisticated
More expensive due to more parties
involved (more than 2 banks) and
cumbersome processes
Payment is through SWIFT and other
more expensive payment network
Buyer and seller trade settlement
through buyer's bank only
Document checking performed by
buyer, payment will be faster using
VTrade Rules. Discrepancies will be
greatly reduced with trade facilitation
methods like electronic POPI and
Document Checklist
Process more streamlined because
POPI terms are simpler
Cheaper because of disintermediation
and streamlined processes
Payment through Visanet, which is
Some of the benefits that the VTrade system offers an exporter include:
Some of the benefits that the VTrade system offers an importer include:
The general steps to set up the VTrade system are as follows:
The general steps of a transaction in the VTrade system are:
Table 2 illustrates the general roles of the parties in the VTrade system.
Credit Provider
Market VTrade to organisation which large
Provide credit financing
Guarantee importer's credit worthiness
Syndicate credit requirements
Negotiate exporters' receivables
Provide FX services
Syndicate VTrade to insurance and shipping
Syndicate VTrade to other banks
VTrade Enterprise
Establish the VTrade Processing HUB and
business capability
Provide a secured environment for
Operate the VTrade Processing HUB
Develop the necessary infrastructure to
support the VTrade Processing
Market solution to Credit Provider
Assist Credit Provider in the marketing
process to importer, exporter, insurance
companies, shipping companies and etc
Provide Support parties in VTrade
Subscribe to VTrade and transact all
intermediated trade transaction through
Subscribe to VTrade and transact all
intermediated trade transaction through
A preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative hardware environment is depicted in
A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided.
OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.
In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.
OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.
OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.
When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.
With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, one's logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows:
With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.
If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects.
This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development.
Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.
The benefits of object classes can be summarized, as follows:
Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.
Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.
The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system.
Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.
Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).
A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.
Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.
There are three main differences between frameworks and class libraries:
Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language —2.0" (November 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. Mogul, "Hypertext Transfer Protocol—HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).
To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:
Sun Microsystem's Java language solves many of the client-side problems by:
With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.
Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution."
Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.
In one embodiment of the present invention, the secondary documents are received via a facsimile transmission. Further, the initiation and payment documents may include a combined purchase order proforma invoice. As an option, the secondary documents may be stored, indexed and matched.
In another embodiment of the present invention, the secondary documents include an insurance certificate, inspection certificate, certificate of origin, invoice/declaration, counselor's invoice, sanction and boycott declaration, packing list, weight list, lab test report, and beneficiary certificate.
In one embodiment of the present invention, an identity of the buyers is authenticated prior to submitting the form thereto. The identity is authenticated by requiring the submission of an identifier and a password. As an option, the step of categorizing the bids may include ranking or segmenting the bids.
In another embodiment of the present invention, the criteria may include a geography and/or product category. Further, the bids and offers may be displayed on a site on the network.
In one embodiment, the agreement between the buyer and the seller may include payment terms. Further, an identity of the buyer may be authenticated prior to receiving the form. As an option, the identity may be authenticated by requiring the submission of an identifier and a password.
In another embodiment, the seller may be requested to become a registered member of the framework. As an option, the agreement may be finalized after forwarding the response of the seller to the buyer.
In one embodiment, the amendments include changing terms of the form. Further, the form may include a combined purchase order proforma invoice. As an option, the form may include a first section indicating a plurality of terms, a second section indicating requirements of the buyers with respect to the terms, and a third section indicating requirements of the sellers with respect to the terms.
In another embodiment of the present invention, the form is automatically sent to a database utilizing a network in response to the buyer and seller signing the form. As an option, commercial shipping documents may be created utilizing input from the seller.
If the seller cannot fulfill the buyer's requirement, the buyer and seller will amend the POPI until agreeable terms are achieved. The buyer and seller can submit each amendment on POPI via the submit pushbutton 2402, 2404. Each amendment by trading parties on POPI will be reflected as a new version. The VTrade Web allows old versions of amendments to be stored and viewed. Once the POPI is finalized, the buyer and seller signs agreement on overall terms and conditions of POPI which automatically triggers POPI to be sent to VTrade. The seller then proceeds to prepare commercial/trade documents for payment.
If the seller cannot fulfill the buyer's requirement, the buyer and seller will amend the Combined Purchase Order Proforma Invoice until agreeable terms are achieved. Each amendment by the trading parties on Combined Purchase Order Proforma Invoice will be reflected as a new version. VTrade Web allows old versions of amendments to be viewed. Once agreement is reached on the Combined Purchase Order Proforma Invoice, the buyer and seller sign the agreement on overall terms and conditions of the Purchase Order Proforma Invoice which automatically triggers a purchase order to be sent to VTrade. The seller then proceeds to prepare commercial shipping documents (option of using VTrade Electronic Document Creator).
In one embodiment of the present invention, the form may include a first section indicating the terms, a second section for allowing the buyer to sign off on the terms, and a third section for allowing the buyer to sign off on the terms. As an option, the form may be displayed after the negotiation of the terms in response to the selection of an icon.
In another embodiment, the documents supporting the form may be displayed. As an option, the form may be automatically sent to a database utilizing a network in response to the buyer and seller finishing the signing of the form. Further, the payment may be completed only after checking the form and the receipt of payment authorization from the buyer.
In one embodiment of the present invention, the trade terms may include shipping related terms. As an option, the terms of the form may be filtered, so that the form may be outputted with only the terms included after filtering for various purposes. As an option, standard documents associated with the form may be generated to be used with the form during the transaction.
In another embodiment, the form may include a first section indicating a plurality of shipping terms, a second section indicating requirements of the buyers with respect to the terms, and a third section indicating fulfillment of the terms by the seller.
An automatic check is triggered once Seller and Buyer signs off digitally on Main Menu of Document Creator for overall agreement (all terms of documents required by Buyer is agreed, including physical documents checked outside of VTrade). Two types of automated compliance check are performed simultaneously:
The compliance checking is performed through data validation on defined parameters of structured formats for text. Once the compliance engine finds all structured fields/tag are in compliance (clean), an automatic signal is sent to the bank/buyer for payment authorization. When payment authorization is received, the signal will prompt Visanet to credit the seller's account. Anytime the value of the data falls outside the parameter of the structured field, it is rejected as 'discrepant.' The rejection will be automatically sent and highlighted to both buyer and seller electronically. Only upon the completion of all checks of structured fields will discrepancy signal be sent to buyer and seller, who will renegotiate on the highlighted discrepancies on VTrade Web's electronic platform
A VTrade system should provide the following security features:
VTrade should operate under some group of recognized rules, preferably rules that are enforceable in foreign countries.
VTrade may provide a forum for buyers and sellers to settle unresolved disputes through VTrade Rules. The handling of disputes under Traditional Trade Finance can be governed by rules in UCP 500 and URC 522 issued by the International Chamber of Commerce (ICC). Both UCP 500 and URC 522 contain a complex set of rules relating the documents in International Trade.
VTrade, may have its own set of rules which govern the underlying goods similar to how credit card rules for retail transactions. In traditional trade finance, disputes can be settled bringing the case to the ICC International Court of Arbitration or to the courts under the normal law of contracts. Similarly, VTrade can provide a similar avenue of resolving disputes under VTrade rules.
Under traditional Trade Finance, the process of refusal of acceptance occurs when the importer refuses acceptance of the document giving him rights to the title of the goods. This can happen under two different situations:
As such, the embodiments set forth above allow business-to-business commerce and eMarkets. Several factors that are driving the adoption of business to business commerce are:
Increasing Competition and Globalization
eMarketplaces offer buyers and sellers a new way to locate, engage, and transact online as traditional trading practices give way to new business models. Comparing eMarketplaces to traditional methods:
eMarketplacesRestrictive vendor/supplier relationships
As shown in
The three emerging online marketplaces serve the basic functions of bringing buyers and sellers together online to easily exchange value, provide content, and form a community. As shown in
eMarketplaces can target either vertical market segments or horizontal market needs.
The present invention is preferably practiced in the context of a vertical market. Players with common needs will naturally look to deep vertical eMarketplaces that cater to their specific needs. Therefore, horizontal hubs will be challenged to directly provide members with targeted industry knowledge and focused offerings. Further, fast movers will lock up key suppliers early making room in many market segments for only one player.
Characteristics of a dynamic eMarketplace include:
As shown in
In addition to having attractive forums of exchange, electronic exchanges must also provide content and support the creation of communities. Content includes developing information which allows users to develop a strong understanding of what they're trading and with whom. Examples include historical price/volume data, product/service information, and buyer/seller credit ratings.
Community includes providing information about related subject areas to members and allow them to exchange experiences. Examples include chat room, industry news, how-to's, and community contacts.
Commerce includes creating a regulated forum for trade. Examples include open/closed trading rooms, multi-dimensional tradeoffs (price/time), and real-time order matching or auction.
Electronic exchanges must also provide support services to facilitate trading. These are preferably part of the infrastructure.
Several needs should be addressed in order to offer a complete eMarketplace.
One embodiment of the present invention offers an integrated package of eEnabled financial services products in one or more of the five categories shown in
TradeDirect should offer products in one or more of the areas of
TradeDirect will allow corporate customers to gain comfort regarding the quality of their counterparties before engaging in online business to business trades.
In one embodiment of the present invention, the history may be supplemented with information on the buyers and sellers received from third parties. As an option, the history of the buyers and the sellers may include ratings received from other buyers and sellers. Further, the history of the buyers and the sellers may incorporate records of problems occurring during the delivery of the services.
Optional credit rating and reporting services which may be offered include:
Some of the benefits these services will provide for buyers, sellers, and for transacting, include:
Pre-approved lines of credit and online decisioning will streamline financing and guarantee payment.
In one embodiment of the present invention, the sellers are provided with the credit assessment when the terms of the transactions are being negotiated by the buyer and the seller. As an option, during the negotiation of the terms of the transactions, request may be received from the buyers for an increase in credit utilizing the network. The credit of the buyers may be again assessed by interfacing banks associated therewith in response to the requests. Further, an increased predetermined amount of credit may be granted to the buyers. The sellers are then provided with a guarantee on the payment up to the increased predetermined amount of credit.
In another embodiment of the present invention, forms indicating the negotiated terms may be exchanged utilizing the network. Further, the buyers may be optionally allowed to negotiate terms of the transactions with the sellers utilizing a site on the network.
Optional trade finance services which may be offered include:
Some of the benefits these services will provide for buyers, sellers, and for transacting, include:
TradeDirect may provide products with which buyers and sellers can minimize the risk of trading. Optional risk management services which may be offered include:
Some of the benefits these services will provide for buyers, sellers, and for markets, include:
TradeDirect may automate most elements of payments and trade settlement.
In one embodiment, evidence of the periodically executed payments is stored for later verification. Further, the seller may be sent electronic notices via the network upon each execution of a payment. As an option, risk associated with the transaction may be reduced by offering insurance.
Optional settlement services which may be offered include:
Some of the benefits these services will provide for buyers, sellers, and for exchanges, include:
One embodiment of the present invention makes information available online to help buyers and sellers make informed decisions, negotiate contracts, and structure these in accordance with relevant negotiations. According to this embodiment,
In one embodiment of the present invention, information may be displayed on procedures involving the goods utilizing the network. Information may also be displayed on current events involving the goods utilizing the network. As an option, risk associated with the transaction may be reduced by offering insurance.
In another embodiment of the present invention, the buyer and the seller may be allowed to negotiate other terms of the transaction such as the volume of goods, delivery window, delivery location, and delivery mode.
Optional information services which may be offered include:
Some of the benefits these services will provide for buyers, sellers, and for exchanges, include:
Further, in operation 6712, funds may be released to the seller upon the form and the documents being successfully checked.
In one embodiment of the present invention, the form is a combined purchase order proforma invoice. As an option, a freight shipper and/or an insurer may be contracted to become involved in the transaction.
In another embodiment of the present invention, authorization may be received from the buyer before the funds are released. Further, a consolidated statement may be sent to the buyer.
In one embodiment, the card is delivered to the buyer by courier. A notice is then sent to the bank upon receipt of the card by the buyer. As an option, the credit application may include financial statements of the buyer. Further, the step of assessing the credit of the buyer may include approving a credit limit, and setting up a line of credit.
In one embodiment of the present invention, an identity of the buyer is authenticated prior to sending the form to the bank. Such identity may be authenticated by requiring the submission of an identifier and a password.
In another embodiment of the present invention, the credit of the seller may be verified. As an option, the form may include a combined purchase order proforma invoice.
In one embodiment, a plurality of documents which support the transaction are received from the buyer. As an option, at least a portion of the documents may be forwarded to the bank for payment authorization purposes. Further, it may be confirmed that the documents are received within a predetermined time period. Still yet, the documents may be forwarded to the bank for facilitating the finalization of the payment. Optionally, the documents may be scanned and forwarded to the bank utilizing the network.
In one embodiment, the payment information may include an identifier for the bank and an associated account identifier. As an option, the direct fund transfer may be carried out by a party separate from the bank, the buyer, and the seller.
In another embodiment, the buyer and the seller are allowed to negotiate payment terms of a transaction using a chatroom. Further, the identity of the buyer may be authenticated using a password.
In one embodiment of the present invention, ownership of goods may be released to the buyer by transferring title thereto if the selected option includes either settling a minimum balance or partially settling. As an option, a consolidated card statement may be sent to the buyer utilizing the network.
In another embodiment of the present invention, a third party who reconciles the account may be engaged if the selected option includes settling a full balance.
Development Framework (IDEA)
The development environment is a production environment for one or several systems development projects as well as for maintenance efforts. It requires the same attention as a similarly sized end-user execution environment.
The purpose of the development environment is to support the tasks involved in the analysis, design, construction, and maintenance of business systems, as well as the associated management processes. The environment should adequately support all of the development tasks, not just the code/compile/test/debug cycle. Given this, a comprehensive framework for understanding the requirements of the development environment can be used.
Another reason for the comprehensive framework is that it is important to get the development environment right the first time. Changing the development environment when construction is fully staffed entails serious disruptions and expensive loss of productivity.
Experience has shown that within the same medium- to large-size project, with the same people, moving from a poor to a good development environment, productivity is improved by a factor of ten for many tasks. The improvements come in two categories:
While it seems intuitive that most tasks can be streamlined, the following list gives a few examples of redundant tasks that must be eliminated:
On a smaller project, these problems can be solved using a brute force approach. This becomes very expensive as the project grows, and finally impossible. A well-designed development environment becomes important as the project team reaches 20–30 people and is absolutely critical with a project size of more than 50 people.
The investment required to design, set up, and tune a comprehensive, good development and maintenance environment is typically several hundred development days. Numbers between 400 and 800 days are commonly seen, depending on the platforms, target environment complexity, amount of reuse, and size of the system being developed and maintained.
Development Organization Framework
In the same way, when a new business capability is introduced, it is crucial to keep in mind the needs for training and organizational change that which may accompany the technical change. This is also true of the development environment. When a new development environment is put in place, the developers need to learn not only how each individual tool works (for example, how to use the compiler), but also how the tools work together to support the organization as it performs well defined processes.
The Business Integration Methodology (BIM) provides valuable information on organizational issues.
Relying on the Business Integration Methodology and its project organization guidelines (0940—Organize Project Resource Task Package), the following should be prepared:
The RAA profiles deliverable consists of statements about the responsibilities, accountability, and authority of each of the positions in the development organization. These statements define the role of each position in terms of:
In accordance with the IDEA Model, the following management teams with responsibilities for the key management functions are defined as:
Together, these teams support the efforts of the System Building team, which is charged with the analysis, design, build, and test of the system to be developed. These teams represent real roles, and on a given program the same people may play different roles.
Security Management
The evolution of new technologies and expanded access to a virtual world has increased the security risk of conducting business. It is therefore essential to recognize the need for a new unit in the organization, specifically dedicated to ensuring that security is handled appropriately. At the Program level, the Security Management unit needs to:
More details about the Security Management team, and other security aspects can be found in the Security in eComerce Executive Planning and Implementation Guides to be published by Global TIS Security.
Information Management
The Information Management team is responsible for ensuring that the project's knowledge capital and information resources are managed effectively. This includes:
Information Management encompasses Repository management, but generally has a broader scope than merely the repository contents, because most repositories are not capable of holding all the information resources of a project. It is, for example, common to have key project information reside in a combination of repositories, teamware databases, flat files, and paper documents. It is the Information Management team's responsibility to ensure consistency across all these formats.
The responsibilities of the Information Management team therefore cover:
In addition to managing the information for the System Building team, the Information Management team must also manage the information resources of the other management processes—quality management, environment management, and project management.
In order to delineate the responsibilities of the Information Management team, it is useful to state those areas that are out of scope. The following are not included:
The Information Management team is ultimately responsible for the contents of the repository. They need to have an intimate understanding of the repository structure and the rules that govern how different objects should be stored in the repository. Although most of the input to the repository are entered by designers, the Repository Management team must manage this population process. Rather than taking a policing role on the project, they should work as facilitators—helping the designers do things correctly the first time, thereby maintaining the integrity of the repository. Without strong repository management, the benefits of using a repository quickly diminish.
In many situations the Information Management team must make decisions that affect functional areas. To empower the Information Management team, the Application teams should include the Information Management team in relevant design discussions. This facilitates the validation of design outputs.
Folder Management
Folders (or directories) can be very useful in gaining control over the overwhelming amount of information produced on a large project. Their utility greatly increases if they are managed appropriately. This management is based on easy-to-follow, easy-to-enforce standards.
Object Management
The responsibilities involved with object management are very similar to those involved with repository management. However, in order to facilitate and promote reuse, it is recommended to have a librarian whose responsibilities include:
The methods of handling media content are somewhat different from those surrounding more traditional development content such as code or documentation; for this reason, a role should be defined that is responsible for the management of all media content.
Quality Management
The Quality team is responsible for defining and implementing the Quality Management Approach, which means defining what Quality means for the Program Leadership, and then implementing the procedures, standards, and tools required to ensure the delivery of a quality program. The Quality Management Approach addresses concepts such as expectation management, quality verification, process management, metrics, and continuous improvement.
Since quality is the result of the interaction of many teams working on multiple processes, the Quality team is responsible for ensuring effective cooperation between teams and good integration of the development processes. The Quality team must therefore forge strong links with all the other project teams.
It is important to note that the Quality team is not only responsible for ensuring the quality of the system building process. The Quality team is also directly involved in ensuring the quality of the other IDEA management processes.
Program & Project Management
The Program Management team is responsible for delivering business capability. In this respect, it is responsible for the System Building and other management teams. In addition, other management responsibilities that do not have a specific team or role defined within IDEA also belong to the Program Management team. These include:
The Project Management team is responsible for producing a deliverable or set of deliverables. As such, it is responsible for:
The Configuration Management team is responsible for defining the approach the program takes to deal with scope, change control, version control, and migration control, and for putting in place the policies, processes, and procedures required to implement this approach.
In other words, the team is responsible for maintaining the integrity of software and critical documents as they evolve through the delivery life cycle from analysis through deployment.
Release Management
Delivering a system on a release-based approach means delivering the system in a series of consecutive releases, increasing or refining functionality progressively. Some of the main drivers to such an approach include:
The Release Management team is responsible for:
As with many other management responsibilities described in IDEA, Release Management is more a role than a function. It is good practice to have as many areas as possible represented in the Release Management team; for example, Design, Construction, Configuration, and Environment Management team members would make up a typical Release Management team, each providing input based on their own perspective.
Environment Management
Just as a business application requires support and system users require service, the development environment requires system operations daily, and developers require ongoing support in order to use the environment effectively. (In fact, the complexity and frequency of these operations is often greater than that of the execution environment).
To ensure that this area receives the necessary attention, an Environment Management team 8400 should be assigned these tasks.
The Service Group 8402 serves as a single point of contact for developers. It interfaces with the Architecture team to provide answers to questions from developers. To avoid adding overhead to the issue resolution process, the support group must be staffed adequately to ensure that all questions are answered. For example, the support group should recruit people from the Technology Infrastructure team at the completion of Technology Infrastructure development.
Problem Management
Problem Management is concerned with the discrepancies that result from the testing process and the management of design problems detected during verification or validation steps throughout the development process.
The Problem Management team is responsible for defining the problem tracking and solution process, and for providing tools and procedures to support the solution process.
System Building
The Business Integration Methodology (BIM) describes System Building under the following activities:
For this reason, the System Building teams are organized into application and technology Infrastructure.
Application Team
The Application team 8500 consists of three separate subteams: Application Architecture 8502, Application Development 8504, and System Test 8506.
The structure of the Application team evolves as the development process continues —as the development of the application architecture components is completed, the Application Architecture team's roles may change. While the team continues maintaining the application architecture components, some team members may be deployed to the Application Development team. Here their roles can include helping application developers to correctly use the architecture components, providing development support, and performing code reviews, and so forth.
As systems become more user-facing, important new roles are emerging that must be integrated into the Application Development teams:
a) Media Content Design
For any system with a user-facing component, it is extremely important that media and design specialists are involved as team members at an early stage in the design of the system. In systems with simple user interfaces, this helps to ensure usability and consistency. As user interfaces become more complex, the early involvement of design experts not only leads to more creative and attractive user interfaces, but also reduces the risk of further alteration to work at a later stage.
b) Usability
Often coupled with Media Content Design, it is vital that a role for usability is defined within the Application Development teams. This will ensure the usability of the system from the perspective of target user groups.
Technology Infrastructure Team
The technology infrastructure evolves throughout the project and responsibility for managing and evolving the infrastructure must be clearly defined. Therefore, rather than having a single amorphous 'technical team' (responsible for operations, support, architecture evolution, and more), it is important to define a dedicated technology infrastructure team. By allowing the technology infrastructure team to focus on the technology infrastructure, rather than the day to day running of the environment, the project increases the chances that the technology infrastructure will provide good support for the business applications.
In practice, the Technology Infrastructure team is the team that will implement the IDEA framework.
The Technology Infrastructure team is responsible for:
Note: The responsibilities of the Technology Infrastructure team may overlap with those of the Application Architecture team, and on some projects the two teams are often combined.
Development Processes Framework
A thorough understanding of the development processes is a prerequisite for ensuring that the tools effectively support the organization and the processes they are intended to support.
The Development Process Model
The Development Process Model is a framework that facilitates the analysis of the many concurrent processes of systems development. This analysis helps understand process interaction, which, in turn, affects organizational interaction and defines a need for tools integration.
The Process model is simple—at its core is the system building process, which is surrounded by eight key management processes.
The core activity—systems building, depends strongly on support from the surrounding management processes, which all affect each other:
For a given project, each of the processes must be defined at a greater level of detail than that which any methodology can achieve. This additional specification consists of a set of procedures and standards that specify how to perform the work and what to produce at each step.
Standards specify what the results should look like. They may include industry standards and more formal (de jure) standards, such as POSIX compliance, but most standards are project specific and determine, for example, how to structure and name system components and where to place system components. Standards make it possible for a large team to exchange information effectively and to work productively together.
Standards should focus on what must be common, and should not become a goal in themselves. Erring on the side of over-standardization stifles productivity. It is, however, often the case that unforeseen events (such as platform demise, tool evolution) will be easier to tackle the more unified the development approach has been. Unfortunately, there is no substitute for experience when making the detailed decisions on exactly what should be standardized. Factors to take into account must at least include:
Procedures specify how to perform a task. They are generally guided by the methodology but provide information at a lower level of detail. They are highly environment-specific, and take into account the organization, the standards, and the tools in the environment. Procedures often specify the techniques to be used. They may specify which tools to use and how to use the tools that support these techniques.
Many processes require individual judgment, and the way to perform these processes cannot be specified in detail. In such cases, it may be valuable to provide guidelines that do not have the mandatory flavor of procedures but rather that of valuable advice.
While it is easy to generate zeal to set up standards and procedures at the beginning of a project, it can sometimes be more difficult to ensure that these are enforced throughout the project. Two considerations are useful. Firstly, standards must be easy to follow. It should be easier to follow the standard than doing things any other way. This is generally achieved by supplying the training, tools, and support needed to facilitate a given work style. For example, developing and distributing application program shells, which respect the architecture and standards, facilitates programming and contributes to ensuring broad standards compliance. Secondly, the responsibility for enforcing standards must be clearly identified and assigned. Standards enforcement must take place as a natural part of the process and at well-defined check points before work flows to the next task, or (even more importantly) to the next group or team.
A very useful way of complementing the specification of procedures is to provide samples. Samples can sometimes convey a message much faster than pages of explanatory prose. Sample programs are generally very useful. Other samples may include logs, which demonstrate interaction with tools, a sample change request, or a sample request for technical support. Samples can sometimes be created efficiently by taking screen dumps. This can be much faster than specifying what the screen should look like in theory.
Samples and standards must be high quality—any quality breach will be multiplied when developers start using them. It is therefore imperative that samples and 1 standards not be created in a vacuum but be based on concrete experience with the project's development environment. Some pilot development work often proves extremely useful when fine tuning the standards.
When documenting the process, it is useful to develop an approach and process description for each project segment and for each high-level process. This document summarizes the support available for that segment or process. It refers to all the standards, procedures, guidelines, and examples relevant to a collection of tasks. Such a summary document makes it easier for developers to navigate the standards and hence to follow them.
Process Integration
To ensure that the project team works effectively together, numerous processes must be integrated. A simple example is provided by the required integration between design and construction. A more subtle one is the integration of product quality inspection and the continuous improvement process.
As process integration frequently involves several teams, it is crucial to understand the interfaces between processes and teams to ensure good hand-offs. This understanding must have a direct impact on tools integration, so that integrated processes are supported by integrated tools. Tools that support multiple processes performed by the same individual must, at a minimum, be integrated at the user interface level and should ideally be integrated at the process level. Tools that support processes performed by different individuals may only have to be integrated at the data level.
Security Management
Processes must be put into place in order to ensure security is properly designed and built into the system that is being developed, including:
Security requirements are the outcome of the security Risk Assessment. This is the process of identifying business risks, identifying system vulnerabilities or weaknesses that can impact those risks, and recommending mechanisms to control the vulnerabilities. Specific confidentiality, integrity and availability requirements for the new system and the development environment are defined through this process.
Security Standards, Guidelines and Procedures
Security standards, guidelines and procedures provide security direction to the implementation. They will help define how the security requirements developed through the Risk Assessment must be addressed in all areas of the development environment. They will include security standards for the development environment infrastructure, procedures for the development processes, standards for the design of the security architecture and security guidelines for programming. It is especially important to ensure the security of the development environment because if these systems are broken into and back doors are introduced, it may lead to later compromise of the production system. It will be the responsibility of all developers that these security controls are implemented and adhered to throughout the development process.
Security Validation
In order to ensure the security of the system, periodical security audits should be arranged, in order to verify that the processes and architecture and application components that are being developed conform to security proven practices. This may be done by an external body specializing in security (such as Global TIS-Security) in the form of interviews, architecture and code reviews, and automated tool assessment.
Information Management (202)
A vast amount of information is generated within the development environment, which needs to be carefully managed (for example, design documentation, application code, media content, test plans and test data). Information Management generally involves Repository Management, Folder Management and, where applicable, Object Management and Media Content Management.
Since a number of teams rely on the service provided by the information management team, it is important that the level of service to be provided be chosen carefully, documented, and communicated. The arrangement should take the form of a Service Level Agreement (SLA). Such an SLA typically defines how quickly a new data element is created and how repository changes are communicated. More generally it defines the division of responsibilities between the information management team and the other project teams at a detailed level.
Repository Management (8102)
Repository Management includes activities such as:
As many repositories do not provide sufficient versioning functionality, it is common to have more than one repository on large projects. Typically, there may be one repository for development, one for system test, and one for production. This allows better control, but also requires significant resources to move repository objects from the development environment to the system test environment. By merging the development and system test repositories, the medium-sized project has a potential for productivity gains. If these gains are to be realized, great care must be taken when making corrections during system test. As a common repository is shared, any error analysis involving repository objects must take into account the possibility that these objects could have changed since the previous migration to system test. This situation can be managed by meticulously maintaining a comprehensive change log.
Another reason for maintaining several copies of the repository is the existence of concurrent projects focusing on different releases. If this is the case, it may be beneficial to maintain delta repositories, which document those components that have been modified. This requires strict repository management but the reward can be significant. It allows the merging of several releases, which have implemented complementary functionality, but which have modified a few shared components.
A single development environment may have to deal with multiple repositories:
Repository Management can be divided into the following areas:
Restricted access to various repository object types is necessary to ensure high quality repository content, because developers sometimes take shortcuts and make unauthorized changes to meet their deadlines. When standards have been set, a good way to enforce them is to restrict personnel through the use of locking mechanisms. Access to repository object types will change throughout the project.
The data elements should usually be controlled by the Repository Management team, because they are the basic building blocks of the system and have broad reuse. Poorly defined data elements can cause inconsistency, redundancy, and generation errors. Data elements should therefore be locked at least by the time construction starts, and possibly earlier, depending on the discipline of the team. Project members must be allowed to browse the data elements, but only the Repository Management team should be allowed to modify or unlock data elements. In some repositories, it is difficult to restrict the creation of repository objects. If this is the case, it may be acceptable to let designers create data elements if these are reviewed and locked at the end of each day. Increased control can be obtained by having designers submit requests for new data elements to the repository administrator. This allows the repository manager to evaluate whether the new data element is justified, or whether an existing one should be used.
Repository Maintenance
a) Creating and Maintaining Data Elements
Requests for data element changes can be forwarded using a database or paper-based system. Based on functional and technical knowledge, the repository administrator evaluates the requests and may involve other teams to make appropriate decisions.
The database used to request data element changes during design and programming should be separate from the project's change request database. This will simplify and speed up the change process. When data elements have to be changed during system test, however, the impact can be much greater, and the regular change request database should be used.
Whenever a data element is changed, impact analysis must be performed to understand the side-effects. Where-used reports are useful to determine these side-effects. The repository manager must be able to obtain the list of direct references and the list of all components affected indirectly (transitive closure). In the latter case, a message based on a record containing a group, which makes reference to a changed data element is considered to be indirectly affected by the change.
When adding a data element, no functional equivalent must exist, because redundancy creates difficulties for impact analysis and future maintenance.
b) Creating and Maintaining Other Repository Objects
The objects related to dialog definitions, reports, messages, and so forth, are usually maintained by the designers and programmers. When the dialogs and report programs are tested, approved, and ready to be promoted to the system test environment, the related objects must be locked. This is the responsibility of the Repository Management team.
Repository Validation and Mass Changes
Keeping thousands of data elements consistent and in compliance with project standards requires a sustained effort. This daily effort is crucial to avoid a massive clean-up, which would be necessary if the repository manager ever lost control of the repository.
Detailed, project-specific standards should exist for defining repository objects. These standards can form the basis for a repository validation program, which can run through the entire repository and report on detected deviations from standards. In some cases, this program can also enforce the standard.
Mass changes to the repository can be performed when the validation reports show the occurrence of many standards violations that follow a common pattern. This may occur in cases where:
Certain reports should be run daily, such as the list of new data elements or modified data elements. These reports can serve as an audit trail of changes and can be used to communicate changes to the entire team. Procedures should specify which reports are run daily and what their distribution should be.
The Repository Management team performs certain analyses repeatedly. Standard analyses such as impact analyses should be specified in detail to facilitate staffing flexibility.
When supporting specific kinds of repository analysis, the Repository Management team can provide custom reports or ad hoc queries that satisfy particular needs.
Folder Management (8104)
It is important to set up and communicate a detailed folder structure with specified access rights from the beginning. Contents of folders must be checked regularly to ensure that folders contain what they are supposed to.
Two main strategies exist.
Choosing the strategy depends on how components are named, on the number of components, and on the tools used. If naming standards make it easy to identify the component type (for example, by using suffixes), organizing them by functional area is generally useful and straightforward to administer. Some tools assume that closely linked files (for example, source and object modules) reside in the same folder.
Another important distinction is the one between work in progress and completed documents that have been approved. This distinction can be supported by a folder structure with carefully chosen access rights.
This distinction makes it easy to retrieve a consistent copy of project documentation for someone who is new to the project.
While scratch folders may be useful in certain contexts, the proliferation of miscellaneous folders with cryptic names can make it very difficult to navigate the information. Some useful guidelines include:
The unique nature of media content means that it cannot be treated in the same way as 'standard' formats, such as source code or design documentation. The major differentiating factors are its sheer volume (media files can range from a Kilobyte to multiple Gigabytes), and the complexity of its associated formats (i.e. it is not easy to 'look into' a media file and understand its contents). For this reason, some of the processes that support multimedia content management must be handled differently.
The three major processes that are required to support media content management are:
Storage management concerns the methods of storing and retrieving media content. The cost of data storage may be decreasing, but it is still the case that for large volumes of media it is often uneconomical to store everything on-line. For this reason, processes must be implemented to manage where data should be stored, and how it may be transitioned from one location to another. There are three ways to store data:
When deciding on where media content should be stored, there is always a trade-off between accessibility and cost (on-line storage being the most accessible and most expensive, and off-line the cheapest but least accessible). The decision of which method to use for which data may depend on a combination of its type, volume, version (i.e. latest or historic) and accessibility requirements.
Metadata Management
Data about the media that is being stored is an important commodity that must be managed. As the volume of media content grows, it is vital to be able to understand characteristics of the media, in order to be able to manage it correctly. Examples of metadata include:
As with standard development code, when media content is created and edited, a revision history of changes should be retained. This way, if it is necessary to revert to an original piece of media content, it is not necessary to go all the way back to the original source (which in the case of finding an image in a CD-ROM library containing 10,000 images, for example, could be a difficult task). In practice, this may mean storing the original and final copies of media (especially where volume is an issue). For this reason, a process for managing multiple versions of media content must be put into place.
The more advanced media content management tools may provide much of the functionality required to support these processes, but where this is not the case, the processes must be implemented manually.
c) Legal Issue Management
When dealing with media, it is often the case that content may be subject to copyright laws. It is important that the legal implications surrounding all content in the system is understood, and where necessary, royalties paid to the appropriate parties.
Object Management (8108)
Object Management processes are very similar to those involved with Repository Management. However, they should promote reuse through specific processes:
Quality Management is described at length in the Business Integration Methodology (BIM).
The Quality Management processes are covered by the following tasks:
The objective of these tasks is to ensure that, early in the life of a program, program leadership explicitly defines what quality means for the program. This results in the production of the quality plan. Then the infrastructure and processes are put in place to ensure delivery of a quality program.
The Quality Management Approach defines the following processes:
Focus here is on those processes that have a direct impact on IDEA and its components (that is, Systems Building and the management processes).
Expectation Management Process
Expectations can be thought of as quality objectives expressed in measurable terms such as:
The targets for quality verification should be defined. Processes and deliverables are key candidates.
In development terms, the V-model is the preferred method by which the quality verification process is managed. The V-model ensures that deliverables are verified, validated, and tested. It is based on the concept of stage containment (enforcing for a given deliverable the identification of the problems before it goes to the next stage) and entry and exit criteria (describes conditions in which a deliverable passes from one stage to another).
The quality verification process owner may not be responsible for executing the V-model, but is responsible for making sure that the V-model is in place and complied with.
Metrics Process (8110)
To fine-tune the development process, the important quality attributes must be measured. Sample metrics include:
Once the key metrics are agreed upon, procedures must be put in place to:
The first stage of the Continuous Improvement Process (CIP) is to capture continuous improvement opportunities. These may include:
The CIP then plans and manages improvement related activities such as:
While maintaining quality at a program level, the Quality Management team must liaise with each of the organizational units within the development environment in order to monitor the quality management processes within these units.
Standards and Procedures
The Capability Maturity Model (CMM) for Software describes the software engineering and management practices that characterize organizations as they mature their processes for developing and maintaining software.
The CMM provides a software organization with guidance on how to gain control over their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. The model defines five levels of software process maturity as well as how to move from one level to the level above.
For more details, refer to Consistently Delivering Value: The CMM—How to Help Your Project Measure Up.
The V-model is a framework that promotes stage containment by organizing the verification, validation, and testing in and across all the methodology elements throughout the delivery phase of the Business Integration Methodology.
For more details, please refer to the V-model overview job-aid in the Business Integration Methodology.
The IMPROVE Job Aid (provided with the BIM Guide) describes the process for solving problems or improving a process. In this Job Aid, you will find an introduction to the five step process your team can use to solve both simple and complex problems. The Quality Action Team (QAT) is responsible for applying IMPROVE to improve a process or solve a problem.
Program and Project Management (8214)
Program Management
Program Management focuses on the continuous oversight needed to support the delivery of business capability through multiple projects and releases. Appropriate disciplines, techniques, and tools are used to plan and organize the work, and to manage the incremental delivery of the new business capability.
Program Management consists of three major activities, each split into a number of task packages.
a) Plan Program
*The Team Work environment, in the domain of the development environment, includes those parts of the development environment which are consistent across the entire program (e.g. Collaborative tools).
Project Management
Project Management focuses on providing specific deliverables through balanced management of scope, quality, effort, risk, and schedule. Project Management processes follow a cycle of planning the project's execution, organizing its resources, and controlling its work. The Project Management team oversees all other teams within the development environment.
Project Management comprises a single activity containing a number of task packages.
a) Plan and Manage Project
Configuration Management is not only the management of the components in a given environment to ensure that they collectively satisfy given requirements, but it is the management of the environment itself. The environment consists not only of system components, but also of the maintenance of these components and the hardware, software, processes, procedures, standards, and policies that govern the environment.
Configuration Management in systems building consists of four major interdependencies:
Packaging is the combination of systems software and application component configurations (source code, executable modules, DDL and scripts, HTML) together with their respective documentation. It may also include the test-data, test scripts, and other components that must be aligned with a given version of the configuration. Packaging allows the grouping of components into deliverable packets of application software that can be developed, tested, and eventually delivered to the production environment. Packaging defines the underlying architecture that drives version, change, and migration control. Each of these control processes defines how changes to configuration packages are versioned and migrated to the various development and test phases in the systems development life cycle.
A sample packaging strategy would take into consideration some of the following factors in determining a unique method to handle a given configuration packet in terms of version, change, and migration control:
Given these three basic package definitions, a configuration management cube can be defined, which uniquely identifies version, change, and migration control characteristics of a given package. The cube can be used to implement a table-driven configuration management control system for all software developed on the program. The configuration control system consists of version and migration control. Therefore, the cube defines all processes associated with version control and migration of a package.
b) Version Control (8114)
Version control and compatibility are key considerations when managing these packages. Note that version control not only applies to software components, but also to all components of a given package, including test scripts, test data, and design documentation. It is also of great importance to keep track of which version is in which environment. If incompatibilities are discovered, it must always be possible to "roll back" to a previous consistent state, that is, to revert to an earlier version of one or more components. It must be possible to define releases of a configuration—a list of version numbers, one for each component of the package which together form a consistent configuration. The smallest unit that can be version controlled should be the package as defined in the packaging plan. This ensures that the lowest common denominator in all version control activities is managed at the package level.
c) Migration Control (8116)
A systems building environment can have many development and test stages. On a large project these may include:
Migration of packages or consistent configurations from one stage to another is a central part of Configuration Management. The key to successful migration is the knowledge of what constitutes each stage. Examples of migration include:
Stages and their constituents exist as a result of certain user and technical requirements. The technical requirements are derived from the user requirements. It is crucial to develop a migration plan that maps out the progression on configuration packages throughout the systems development life cycle.
The version control plan must align with the migration control plan. The version control plan defines the points where version control activities will take place. In the above example, version control will take place at the development stages, architecture development and unit test, and application development and unit test.
Migration control defines how these version control configuration packages will be migrated successfully from one stage to the next until the package is eventually released to the production environment.
D) Change Control (8118)
Change requests as a consequence of changing requirements and changes requested due to nonconformities (or defects), either in the application software, or in the system software must be analyzed, authorized, scheduled, staffed, and tracked in a defined way. What, why, when, and who made a change must be tracked from the point of analysis to the reintroduction of the defective or changed component at the appropriate stage. Change control therefore governs what software component is changed, version controlled, and when it is remigrated to a given development stage.
It is important to link the general change request with the requests produced during formal testing phases. This makes the processes clearer.
Configuration Management becomes more complex in a component-based development environment as the system is broken down to a greater level of granularity.
Release Management (8208)
Release Management involves coordinating activities that contribute to a release (for example, cross-project management) and the coordination of products that contribute to a release (such as architecture, integration, and packaging). It is concerned with managing a single release rather than cross-release management.
The Release Management approach documents critical decisions regarding the management, tracking, and integrity of all components and configurations within a given release. The Release Management approach must be closely coordinated with the definition of the Configuration Management approach and the Problem Management approach. Release Management involves two main components:
The coordination of products that contribute to a release is the maintenance of a bill of materials for a release. It is an inventory of all software and hardware components that are related to a given release. The development environment is directly affected by the Release Management strategy. The way a program decides to plan releases affects the complexity of the development environment.
It should be noted that delivering a system in a series of releases significantly increases the effort.
Standards and Procedures
If the release plan dictates that there will be parallel development of two releases of software, the development environment and configuration management must be able to support the release plan. In the most general development case, a program can have a single release capability mechanism 8700 but must simultaneously perform maintenance activities 8702 for components that are in production 8704. There must be an ability for the program to design, build, and test the applications for production.
The ability to perform all development stages for a given release can be defined as a development pipeline. The pipeline consists of all development and testing stages necessary to release the software to production.
The pipeline strategy of a program depends directly on the release strategy. A program is potentially developed on three different timelines:
To support this release plan, the development environment must be separated into pipelines that are replicas of a single migration path to production 8704. A pipeline consists of all the necessary development and testing stages required to deliver a piece of software to production. Therefore, because of simultaneous development and testing of three code bases, there needs to be three development and testing pipelines that deliver software to production.
The pipelines must be capable of allowing the developer to design, build, and test applications as well as architecture components.
As can be derived from the above illustrations, the more flexible a release plan, the more complex the development environment. As the number of development pipelines increase, the complexity of working in the development environment also increases. All development environment tools must support the pipelining strategy and so must the configuration management and problem management processes.
The pipeline strategy for a program must incorporate code base synchronization. Code base synchronization must occur among the three pipelines to ensure that the three code bases eventually result in one version in production.
Environment Management (8206)
Since the development environment is a production environment, it follows that environment management must be planned, organized, and executed to ensure a predictable and productive environment. Andersen Consulting has a comprehensive framework for the Management Of Distributed Environments (MODE). It describes four central functions:
MODE provides an excellent framework for specifying the management responsibilities that apply to the development environment. These responsibilities are often assigned to the technical group, but as discussed above, there are benefits associated with establishing a dedicated environment management team.
The Environment Management component described here uses MODE as a framework, adopts MODE terminology, and focuses on those management tasks, which are particularly important in the development environment.
Adopting a structured approach to environment management, which applies the same principles to development as it does to production, has several advantages:
In some respects, the development environment is simpler than the production environment. It is, for example, generally smaller in terms of the number of hardware components and the number of locations. In other respects, however, the development environment is more complex. For example, the amount of change in this environment is generally higher than in the production environment. In fact, the environment can be so fluid that extreme care must be taken to maintain control. On a large engagement, one dedicated technical support person per ten designers and programmers is recommended. The greatest need for technical support is generally during detailed design and programming. It is, however, necessary to start building the technical support function before detailed design.
All processes that are performed by the Environment management team must be documented in a centralized database that allows quick and easy reference.
Service Management (8122)
Service Management provides the interface between the Environment Management team, the Development teams, and external vendors or service providers. It manages the level of service that is provided to the developers. In order to maintain this service, three areas must be managed:
In order to plan and organize the development work appropriately, a Service Level Agreement (SLA) must be in place between the Service Management group (typically part of the Environment Management team) and the developers. As with all other components of the development environment, this agreement should be kept simple. It should specify the following:
Specifications of service levels should be precise and the service must be measurable. The SLA should also specify how to measure this service (for example, system response times, request service times, backup frequencies). In addition, the SLA must be managed. It may have to be modified as the environment changes, and it must be reviewed with developers on a regular basis to see if the service level is adequate.
a) Operations Level Agreement Management
The Environment Management team is responsible for providing the specified level of service, but frequently relies on external vendors and suppliers to perform certain tasks. For example, hardware service is typically provided by the hardware vendor. To provide the agreed level of service to the developers, the Environment Management team must ensure that external vendors provide their services as required. This generally means establishing a contract with the vendor and following up that the contract is respected.
As the relationship between the Environment Management team and external vendors becomes less formalized (for example, Internet Service Providers, mass market software vendors), it becomes more difficult to provide guarantees on the level of service that will be delivered.
b) Help Desk
The Help Desk function is an important part of the interface between the Service Management group and the developers. The Help Desk makes sure that questions are answered and requests serviced in a timely manner by the right people. In a complex, leading-edge environment, the Help Desk is crucial to maintaining productivity. The Help Desk needs particular focus when:
While supervisors and coordinators who work with the developers may alleviate the impact of these factors, the more difficult questions must be resolved by the Environment Management group. As some of these will be repeat questions, the ability to log the question, the analysis, and the result in a structured way provides the basis for performing smart searches and answering the question quickly. Repeat questions may also trigger:
Efficient searches in the Help Desk database can, in some cases, be greatly facilitated by extending the basic functionality of the Help Desk tool. This can be achieved, for example, by adding a smart word search capability on top of the Help Desk history database.
Comprehensive training must be given to Help Desk personnel in order to ensure the best possible level of service to the developers.
In addition to serving internal project needs, the Help Desk must be prepared to coordinate the activities of external suppliers to solve problems. This occurs when several new versions of hardware and system software are introduced, and compatibility issues arise. Part of the coordination is the tracking of request IDs, which refer to the same question but which are assigned differently by each supplier.
To manage communication with external vendors, a contacts database with the following information is useful:
Based on this information, it is useful to log the exchanges with the external company, indicating:
Defining the SLA, with its specific, measurable criteria, is the basis for continuous improvement. The continuous improvement effort may focus on providing the same level of service with fewer resources, or on providing better service. An important part of quality management is ensuring that the Environment Management team understands the key performance indicators for service delivery, that these indicators are monitored, and that all personnel are adequately equipped with the tools and training to fill their responsibilities. While the entire team is responsible for delivering quality, the responsibility for Quality management should be assigned to a specific individual on the Environment Management team.
Systems Management (8126)
MODE divides Systems Management into:
In the development environment, a number of activities must be performed according to schedule, including:
Many of these activities can be scheduled and performed automatically, but must have some level of manual control to ensure that they are executed correctly. Control tasks may include checking and archiving activity logs. Standards and procedures that describe the control function must be established.
The Environment Management team must systematically monitor the development environment to ensure that it is stable, provides adequate response times, and satisfies the needs of the developers. This monitoring involves looking at trends and extrapolating them to anticipate problems with disk capacity, system performance, network traffic, and so forth.
Failure Control
Failures must often be corrected quickly to restore service. The time needed to restore service is affected by the time it takes to isolate and repair the fault. In many cases, elapsed time can be shortened by allowing remote administration of system components.
Security Management
Security management involves:
Although direct sabotage is rare, inexperienced developers, perhaps new to the project, can wreak havoc to the system under development by inadvertently deleting or modifying system components. Focus must be on defining access rights so that developers have the right level of access (read/write) to all the information that is useful and relevant to their work.
With the opportunity to connect development environments to the internet comes new risks. There is a potential for security breaches or the transfer of viruses and other malicious programs. In extreme situations, where security is of great importance, it may be prudent to isolate the development environment, and allow Internet access only via a dial-up connection on stand-alone machines. The overlap of responsibility for Security Management between the Environment Management team and the Security Management team will need to be defined at the program level.
Outsourcing Considerations
In the development environment, it may be possible to outsource certain Systems Management tasks. For example, the LAN supplier may be willing to take responsibility for LAN support, upgrades, and so on. Similarly, an existing data processing center may be willing to take responsibility for host operations. Such agreements are very beneficial and make it possible to use project team members more effectively. However, outsourcing the development environment carries a risk, which can be mitigated by defining a Service Level Agreement with the provider. This will generally be very similar to the SLA established between the Environment Management team and the developers. One important difference is that punitive measures (to be applied if the SLA is not respected) must be specified to ensure that outside suppliers are strongly motivated to abide by the agreement.
Service Planning (8124)
MODE divides Service Planning into:
All these planning stages apply in the development environment and are analogous to the kind of planning that must occur in the business application's production environment. One of the most important success factors when providing technical support is being proactive and anticipating the need for intervention.
Service Management Planning
Once the SLA is defined, the resources required for delivering the service can be specified. Questions to address include the staffing of these resources and training to ensure that they are equipped to deliver service as agreed.
Systems Management Planning
Daily tasks must be specified, assigned, and followed up. Systems management planning determines who is responsible and how follow-up is performed.
Managing Change Planning
Managing change planning is of great importance in the development environment. During a large project, several very significant changes to the development environment must be accommodated. They include:
The release of these components into the environment requires very careful planning to ensure minimal disruption for developers. Techniques commonly used include:
Planning for change includes choosing options based on a thorough understanding of the positive and negative impacts of change to the environment. Changes to the development environments should be analyzed and planned for as orderly releases rather than a stream of small modifications. Changes should be packaged into releases, and each new release of the development environment should be tested by developing a small, but representative part of the system using the new environment. Ideally, this test should be performed by real developers rather than by the Environment Management team. This may be very helpful in order to obtain better buy-in.
Strategic Planning
Strategic planning is traditionally regarded as being less important in a development environment than in the production environment, mainly because the development environment is often viewed as a temporary entity that does not warrant serious strategic considerations. This may be changing however, with the concept of the enterprise-wide development environment—a single, generic development environment architecture that is tailored to each specific project. In this case, strategic planning for the development environment is vitally important if the environment is to evolve, and allow the organization to remain competitive. Strategic planning of the environment management function may, for example, include such questions as support for multisite development and coordination of multisourced systems management.
Managing Change (8120)
The development environment is subject to constant change (for example, the addition of new tools, or changes to code libraries), which needs to be managed carefully. The Managing Change component comprises three sub-components: Controlling Change, Testing Change, and Implementing Change.
Controlling Change
After planning for and scheduling change, it must be controlled. This ties in closely with Configuration Management.
Testing Change
Thorough testing is required to reduce the risk of productivity loss due to environment changes. Techniques commonly used include:
In addition to reducing risk, testing should also verify that the expected positive benefits of the change are indeed obtained.
Implementing Change
After planning and testing the change to be introduced, it must be implemented. The most common kinds of change in the development environment are the introduction of additional hardware, new releases of databases, subroutines and infrastructure, and upgrades to tools. Each change implementation should be viewed as continuous improvement so that any difficulties or inefficiencies are analyzed and resulting improvements are planned and implemented. To be effective over time, this requires that procedures be documented and regularly reviewed and enhanced.
When the database is changed, new versions of test-data must be developed and distributed. When infrastructure components are modified, they may have to be distributed across platforms, and the ripple-effects (for example, the need for recompilation or code changes in affected components) must be understood and coordinated. Some projects have experimented with incentives to ensure that the infrastructure components do not change too frequently. One such strong incentive is to make the Architecture team responsible for all ripple effects and have them implement all the application level changes that result from an architecture modification.
Problem Management (8212)
Problem Management is generally associated with the discrepancies that result from the testing process, though it may also be applied to the management of design problems detected during verification or validation steps. Problem Management is a crucial process in the system development life cycle. It ensures that quality software is designed, developed, and tested so that initial benefits defined in the business case are in fact realized. A development environment must have a formally defined problem management process to ensure that this objective is met.
Formal problem tracking helps to control the analysis and design process by maintaining documentation of all problems and their solutions. Problem tracking improves communication between developers and business representatives, which is particularly helpful in minimizing misunderstandings at later stages of the development cycle.
Such formal problem tracking also helps to facilitate the solution process by formalizing a procedure for reviewing, acting on, and solving problems in a timely manner. By circulating problem documentation to all affected parties, management can minimize the risk of misunderstandings at a later date. In addition, the documentation serves as an audit trail to justify design and implementation decisions.
It is, however, important to note that not only the software that is developed for business case benefits realization must have a formal problem tracking mechanism, but the development environment architecture must also have a formal problem tracking mechanism. The development environment tools and processes support the design, development, testing, and delivery of quality software. Therefore, the foundations of design, build, and test must be stable and problem free. All problems identified in the development environment architecture must be tracked formally and solved as the development environment is also a production environment for developers.
System Building (8218)
Understanding the systems building process is important since well defined development tasks and workflows form the basis for achieving high productivity and consistent process quality. Tools to support these processes may be found in Tools-System Building.
The development environment varies by segment of a systems development project. The following model is used when discussing different components of the development environment.
The development process is iterative and can be entered at different stages depending on the complexity of the changes. Small corrections may not require explicit design, and small enhancements may not require any high-level design. The shaded, elliptical labels in the above figure indicate how the development process can be entered depending on the magnitude of the change.
The iterative nature of the development process is important since it implies that components of the development environment, which are put in place for design (for example), must be maintained, since they will continue to be used until the end of system test and beyond. Multiple releases of the business application may also be under concurrent development at different stages. This may lead to very active use of design, construction, and testing tools at the same time.
Analysis & Design (8128)
Analysis and design in this context, refer to the two Business Integration Methodology activities:
The most critical and perhaps the most difficult work occurs up front. The success of the entire design effort depends on the quality of the work performed to gather, document, communicate, and analyze requirements in the early stages. Standards for how to document these requirements are very important. They facilitate communication, which, in turn, ensures a common view of the problem to be solved. Communication must be ensured within the analysis team but also with the (possibly future) designers and programmers.
Tool support may help enforce standards, and such tools are discussed under Tools-System Building-Analysis &Design.
The design process includes numerous activities, which range from high-level general considerations to low-level detailed issues. The overall objective of design is to transform functional and technical specifications into a blueprint of the system, one that will effectively guide construction and testing. While requirements analysis and specification deals with what the system must do, design addresses how the system will be constructed. Validating that the design actually meets the requirements for functionality, performance, reliability, and usability is essential.
The quality of the design process directly affects the magnitude of the efforts required to construct and test the system, as well as the maintenance effort. Investments in defining high-quality design standards and procedures and integrating tools is therefore particularly important. It may, for example, have a direct impact on the degree of reuse achieved. In addition, adequate training must be provided to ensure that the designers make optimal use of the environment provided.
Information on how to approach system design can be found in the following Andersen Consulting sources:
New tools and processes link detailed design and construction more closely than before. To realize the expected benefits from repositories and code generation, the output from detailed design must be exact and correct, leaving little room for interpretation. This requires careful quality control and very specific exit criteria associated with the completion of detailed design.
It is important that the development environment accommodates concurrent effort in different areas. For example, parts of design may occur after system test starts, as in the case of an urgent change request, or when a significant inconsistency is detected in system test. Some reverse engineering work may also occur before design or during construction.
When standards, procedures, and tools are developed for a task, it is important to consider where the task belongs in the sequence of tasks that contribute to the development. For example, the use of a repository early in the development process reduces the need for re-entering information while enhancing consistency and facilitating standards compliance.
Usability and User Interface Design
Usability is an important (and often overlooked) consideration in system design. Usability is more than a well-designed user interface—the way in which business processes are modeled, how they are implemented within the system, and how they are presented to the user all contribute to the overall usability of the system. Usability is an iterative process of refinement that results in systems that are easy to learn, efficient, and enjoyable. In the very broadest sense, usability is the thoughtful, deliberate design approach that considers users throughout the solutions-building process, from start to finish. For this reason, usability guidelines should be defined and followed at every stage of system design. This, along with regular usability reviews and tests both internally, and by target user groups (by using prototypes), helps to reduce the risk of a poorly received system.
The User Interface has become increasingly important as systems become more and more user-facing. As multimedia technologies evolve allowing the development of richer user interfaces, so the design processes must adapt to reflect these new technologies. The processes that surround the design of media content are similar to that of regular system design, and many of the same issues that apply to designing traditional user interfaces also apply to the design of media content. The major change is the involvement of media content designers—a group of people not traditionally associated with system design and development. As their presence is relatively new to the scene of systems development, it is often the case that media content designers are not fully integrated into the development team—a potentially costly mistake. It is important to ensure that media content designers are involved in the design process at a very early stage, and that they are fully integrated into the application design and construction teams.
The approach to Interface design is evolving as media technologies become more advanced. Modern media creation tools allow the development of not only media-rich interfaces, but also the functionality that lies behind them. This means that the role of the media content designer may now range from that of designing the look and feel of a user interface, to developing the entire presentation layer of an application. In this situation, the role division between media designer and application developer becomes a difficult one to define, reinforcing the argument for fully integrating media designers into the application development team.
Standards and Procedures
Well documented, comprehensive standards make designers more independent and enable them to produce more consistent, high quality designs. Common standards include:
While the standards focus on what to do during design, procedures focus on how to do it. Procedures must be in place to specify:
Guidelines give assistance in areas where judgment is important and where standards are not easy to define. Valuable guidelines may include:
Designers must understand standards and procedures other than the ones listed above. For example, repository related standards are very important to designers. These standards are discussed in Processes-Information Management.
Implementation Considerations
a) Multi-Site Development
In the case of systems being developed by multiple parties or across multiple locations, it is vital that a process of regular communication is implemented. This communication should involve all the parties involved in the design of the system, and is usually conducted in the form of an audio conference. Through this process, it must be ensured that all parties are approaching problems from the same direction, and that they are thinking about the design in the same way. If this is not achieved, there is great potential for misunderstanding across teams, which generally leads to a badly integrated system. In this type of situation, where parties are not working together on a day to day basis, it is also important that any definition (requirements or design) is completely free of ambiguity (if anything is left open to interpretation, there is a high risk that it will be misinterpreted). Practically, this means that quality controls on documentation need to be more stringent than on a traditional single-site project.
Reverse Engineering (8130)
Reverse Engineering is a set of techniques used to assist in reusing existing system components. Most of the time, this work is performed manually: one person studies thick listings to understand data layouts and processing rules. The person gradually builds a higher-level understanding of how the components work and interact, effectively reverse engineering the system into a conceptual model. It may be necessary to study certain pieces of code to understand how they work, but reverse engineering is not limited to code. For example, these techniques might help understand the data-model of a legacy application, in order to better design the new applications that will coexist with it.
The process can be very time-consuming and is notoriously difficult to estimate. Tools to support the effort do exist, and have been used successfully to streamline the process. The main problem with such tools, however, is the hasty (and erroneous) conclusion that tools automate everything. They do not, just as design tools do not automate the design process. Human intelligence is still required to drive the effort.
The supporting tools can, however, reduce the amount of manual effort needed and significantly lessen the amount of non value-added activities, such as "find all the places in a program that affect the value of a given variable".
The goal of a specific reverse engineering effort generally falls into one of the following categories:
In component-based development, a concept known as "round-trip reengineering" provides the developer with a way of modifying a component model and generating the code, then at a later date modifying the code at predefined locations in the source code and regenerating, thus enabling the model to maintain a 2-way-synchronization.
Note that components to be reverse engineered can be both part of a custom-built system, or part of a software package.
Projects dealing with the Year 2000 issues have had much experience in reengineering.
Standards and Procedures
The following reverse engineering guidelines should be used as input when developing standards and procedures for a particular context.
Packaged Component Integration applies to the use of any third party (or previously developed) technical components that may be integrated into the target system. This can range from simple components offering limited functionality (worksheet or charting GUI components), to components handling a significant portion of the application architecture (data access components and firewalls). The process involves a number of stages:
A proven practice in the component-based development world, when dealing with purchased components, is to "wrap" them, i.e. encapsulate them so that the visible piece of any component remains fully controlled. This way, when a component is replaced (either for an update or because it has proved to be defective), no other system components that refer to that component will need to be altered.
Construction (8134)
Construction covers both generation of source code and other components as well as programming and unit test. It may also involve help text creation and string test.
As construction is a large part of system building, the benefits of streamlining this process are significant. Since several aspects of construction are rather mechanical, it is often fairly easy to simplify this process and to automate parts of it, particularly if the design holds high quality.
The arrival of Integrated Development Environments (IDEs), has further simplified the automation of construction processes to the degree that a single tool can manage the majority of the process.
As with Analysis and Design, usability must not be ignored in the construction of a system. Especially in the case of an iterative development approach, it is vital that those responsible for usability and target user groups are involved in regular reviews as the system is being developed.
Standards and Procedures
Important standards include:
Important procedures include:
Important guidelines include:
System test is performed to validate that the gathering and transformation of information is complete and correct.
As automation progresses and an increasing number of business processes are supported by computer systems, system test is changing in nature. Firstly, the testing of interfaces to other systems is becoming an ever larger part of systems test. Secondly, system test increasingly applies to a new release of an existing system. In addition, it is worth noting that as design and construction is increasingly automated, system test is becoming a larger part of the total development effort.
Both of these factors increase the value of automated testing tools, given that the work associated with checking that system changes do not have unintended side-effects, is becoming an ever larger part of system test. Another trend affecting system test is the demand for traceability. Increasingly, users and management wish to know the purpose of a given test condition. This is answered by referring back to the design and to user requirements.
System test is a very large part of any systems development effort and can, especially when requirements are changing, exceed one third of the entire effort. A streamlined environment, which enables high productivity is therefore of utmost importance.
IMPORTANT: When planning system test, it is vital that the testing of all target platforms is included in the test plan. For each platform that is supported by the system, there must be a separate set of tests.
The necessity of impact of volume and stress testing early in the development process is becoming more common, due to the proliferation of new technologies and tools which have little or no performance track record. It is important that the performance and reliability of such tools and technologies are established as early as possible in the project to avoid possible problems further down the line.
Component-based development may have an impact on the way in which testing should be performed.
Standards and Procedures
System test relies heavily on configuration management, repository management, and quality management.
Each of the following system test activities needs well-documented standards and procedures and should be supported by tools:
The following is an overview of the firm's testing methodology as documented by RTP. It describes the framework for the testing process, or the V-model of verification, validation, and testing.
b) Are Program Specifications being Tested?
The following is an overview of the component test as documented by RTP. It describes the testing methods used to validate the detailed design stage where program specifications are tested.
The following is an overview of the assembly test as documented by RTP. It describes the testing methods used to validate the technical design stage where system designs are tested.
By the completion of assembly testing, the system should be technically sound, and data flow throughout the system should be correct. Component and assembly testing ensures that all transactions, database updates, and conversation flows function accurately. Testing in later stages will concentrate on user requirements and business processes, including work flow.
d) Are benefits being tested?
e) Are costs being tested?
f) Are intangibles being tested?
The following is an overview of the benefits realization test as documented by RTP. It describes the testing methods used to validate the business case stage where benefits, costs, and other intangibles are tested.
Ideally, benefits realization test occurs prior to complete deployment of the system and utilizes the same environment that was used for the service-level test piece of operational readiness test. Tools are put in place to collect data to prove the business case (e.g., count customer calls). A team of people to monitor the reports from the tools and prove that the business case is achieved is still needed. The size of the team depends upon the number of users and the degree to which tools can collect and report the data. The benefits realization test tests that the business case for the system will be met. The emphasis here is on measuring the benefits of the new system, for example: increased productivity, decreased lead times, or lower error rates. If the business case is not testable, the benefits realization test becomes more of a buyer signoff.
g) Are quality requirements being tested?
h) Are technical requirements being tested?
i) Are functional/user requirements being tested?
The following is an overview of the product and operational readiness test as documented by the RTP. It describes the testing methods used to validate the requirement/definition stage where quality, technical and functional/user requirements are tested.
The product test tests the actual functionality of the solution as it supports the user requirements: the various cycles of transactions, the resolution of suspense items, the work flow within organizational units and among these units. The specification against which the product test is run includes all functional and quality requirements. The testing is organized by business function.
The operational readiness test assumes a completely stable application and architecture in order for it to be successful, and therefore, is heavily reliant on the previous testing stages.
The operational readiness test is the point in the development process where all the application development, architecture development, and preparation tasks come together. The operational readiness test ensures that the application and architecture can be installed and operated in order to meet the SLA.
Development Tools Framework
In addition, three other components are required to fully support development:
An efficient development environment requires good tools. For general issues regarding tool selection, please refer to the general Product Selection Considerations.
Productivity (9002)
While many tools are developed in order to support a specific task (for example, source code editor), there is a family of tools that are generally required across the board, often known as productivity tools or office automation tools. These tools, typically packaged as integrated suites of software, provide the basic functionality required to create documents, spreadsheets, and simple graphics or diagrams. More recently, the ability to access the Internet and browse electronic documentation has been added to the suite of productivity tools.
Specifically, productivity tools include:
These tools are generally versatile enough to take the place of specialized tools (such as planning tools) in certain circumstances.
Implementation Considerations
a) How Secure does the Development Environment Need to Be?
In environments where security is a factor, the way in which team members gain access to the Internet must be carefully considered. For example, on high security projects, it is often the case that isolated machines with a single dial-up connection provide the only way to access the Internet, thus ensuring that the development environment remains completely isolated.
b) Are People Using the Internet for its Intended Use?
Studies have shown that employees spend a lot of time using their Internet access for purposes unrelated to work. Therefore, the benefits and damages of providing Internet access must be assessed.
Collaboration (9004)
It is well understood that both good communication and knowledge sharing are vital for the success of any team. As development projects get bigger and teams more distributed, it becomes increasingly difficult to maintain communication between project team members. Collaborative tools have been developed with this very purpose in mind—to enable groups of people to communicate and to share information, helping them work together effectively, regardless of location.
More information on collaboration may be found in the Collaboration Extensions Framework in the database, and the Collaboration Architecture Framework in the Technology Library.
Implementation Considerations
a) How Distributed are the Project Teams?
On projects with development sites that are geographically distributed, it is usually the case that communication by e-mail alone is not a sufficient substitute for meetings when attempting to coordinate the teams involved. In order to keep all teams updated and moving in the same direction, regular (for example, weekly) conference calls between all parties—chaired by project management—is much more efficient. It is important that these conference calls are closely monitored, well prepared, and that the agenda is closely followed. Action points and commitments made during these calls must also be documented. Where issues arise that cannot be resolved using an audio conference (usually because the subject is based on a visual concept), video conferencing may be necessary.
E-Mail (8138)
E-mail provides the capability of sending and receiving messages electronically. In addition to the ability to send simple ASCII text, e-mail systems usually provide the capability to attach binary files to messages. E-mail is a convenient tool for distributing information to a group of people, as it has the advantage of delivering content directly to the 'mailbox' of each individual, rather than relying on individuals to access a central data repository in order to retrieve the information.
Implementation Considerations
b) Is E-Mail Likely to Contain Sensitive Information?
When setting up an e-mail system, it is important to consider the content that will be transferred using the system and to apply the appropriate security controls accordingly.
If so, a gateway will be required to manage communication beyond the local environment. This will bring with it security implications, as the local environment will no longer be isolated.
c) Do E-Mail Capabilities Already Exist at the Development Site?
If adequate capabilities are already present at the development site, it may well be prudent to take advantage of these capabilities.
Product Considerations
a) Is E-Mail to be Supported on Multiple Platforms?
The choice of which product to use may depend on the platforms upon which the system must run.
b) How Many People Should the System Support?
Low-end e-mail solutions may be perfectly adequate for small development teams.
Teamware (8140)
In a creative environment, it is vitally important that people are able to easily share ideas and information. Teamware provides the ability to capture and share information across a project through the use of common-access, structured databases. A good example of teamware is the Knowledge Xchange.
Teamware may be used to share many different types of information, for example:
In order to guarantee the value of a teamware environment, it is vital that:
To ensure that information is consistent across different formats, it is useful to view the management of all these information sources as part of a more general information management process. Effective information management beyond repository management is required to ensure that the anticipated benefits of electronic mail and teamware materialize.
For example, certain teamware databases require continuous maintenance in order to remain relevant. The management of the database contents may require significantly more work than either the initial installation of the tools or the technical support for the tools. This effort is frequently underestimated.
In addition to setting guidelines for general usage, the project must designate mail administrators and knowledge managers who are responsible for:
Teamware will generally only be effective when used within large groups of people. Unless a critical mass of people is achieved and content is regularly added to the system, interest will soon dwindle, and the system will no longer be of any value.
Group Scheduling (8142)
Group scheduling tools help to centrally manage the personal schedules of a group of people. This offers the advantage of being able to coordinate events that require the participation of a number of people automatically by checking 'group availability' rather than checking with each person individually. These tools may also be used to schedule other resources such as meeting rooms and equipment.
For the use of group scheduling tools to be successful, the personal schedules of each member of the group must always be current. This is the responsibility not only of the group scheduler, but also of the individuals involved.
Audio/Video Conference (8144)
In an ideal world, all meetings would be conducted face to face. In reality, however, it is often the case that not all the individuals who are required to take part in a meeting are on the same site. To overcome this problem, audio and video conferencing tools allow many individuals in different locations to communicate simultaneously. Audio conferencing is not a new concept, but remains a valuable tool for conducting meetings where the issues being discussed do not require the support of visual aids. Video conferencing takes this one step further, allowing people to interact both aurally and visually, making for a much richer method of communication.
Implementation Considerations
a) Is there Enough Bandwidth to Support a Video Conferencing System?
Adding bandwidth intensive applications such as audio, video, and data conferencing could have severe effects on the network infrastructure and this must be anticipated. This type of implementation is also based on a number of different, emerging standards. The video conferencing system should be designed with that fact in mind and provide for some degree of interoperability between dissimilar systems. For example, being able to connect a desktop-based video conference user with a room-based video conference user.
b) Is Video Conferencing the Right Medium for the Desired Purpose?
Video conferencing is an advantage when one person needs to see the other person's face, his or her reactions, read body-language, build relationships, and so on. On the other hand, when communication is more technical, for example, fixing a bug, collaborative design, document writing, or presenting a demonstration, it is more critical to be able to see what the other person is seeing, or to be able to show information at hand. In this case, application sharing assumes greater importance. It is a common misconception that video conferencing replaces working in the same place. The logistics involved in setting up a group video conference for different time zones, and the complexity of sharing a common whiteboard, limit the value of the solution to occasional situations. In a development environment, the real value of synchronous communication is not in being able to see someone else at the other end, it is in being able to share a working session on a work object.
Shared Workspace (8146)
Shared workspace systems may be categorized as follows:
An electronic whiteboard provides a large, clear screen that can be viewed close up and at a wide angle, upon which participants may 'write' with an infrared pen or a mouse. Images may also be pasted onto the whiteboard.
Regular workstations on a network may also be used for electronic whiteboarding, providing the appropriate software is installed. Electronic whiteboarding often works in conjunction with video conferencing applications.
Application Sharing
Application sharing allows participants to see and control the same application running on multiple PCs. In this way they can simultaneously create and edit a single, common file. Application sharing may be combined with audio conference.
Process Management (9006)
Process Management may be categorized into two areas:
In either situation, the aim of the process management tools is to enforce the correct sequencing of tasks and tools. Task integration must be provided in accordance with the methodology and should provide direct support for the methodology. Effective task integration therefore reduces the need to consult the methodology.
Simple Process Integration (8148)
Simple Process Integration concerns the integration of a limited sequence of tasks, for an individual, according to a prescribed development methodology. For example, the construction process can be supported within an integrated development environment tool by a menu with the following choices:
The sequencing of the menu items help to remind the programmer of the steps needed to complete the construction of the program.
Going beyond mere sequential use of tools, real-time integration of tools enables real-time data interchange. The most common example is perhaps the edit/compile/debug cycle. Here it can be very helpful to work in an integrated environment that uses the editor and places the cursor at the position corresponding to a syntax error or to a given break-point defined to the debugger. This integration is generally offered as a standard feature of an integrated development environment.
Task integration for the individual can be achieved using scripting tools or a desk top manager.
Real-time tools integration is most commonly provided by vendors who deliver integrated environments.
Workflow Management (8150)
When processes become complex and require the participation of multiple groups, simple integration techniques are not adequate for managing the process flow.
Workflow Management tools address this problem by providing the ability to define, manage, and execute automated business processes through an electronic representation of the process, both in terms of what has to be done, and by whom.
For any process where multiple groups are involved, well-defined procedures must be in place to ensure that work flows from one task to another. Each participant must have access to the information required to perform the task, including the information from previous steps in the flow. This can be handled manually or supported by tools. If handled manually, it requires dedication, attention to detail, and significant training.
Workflow Management can be applied to many processes within the development environment, such as quality assurance, migration, design/construction, system test, and standards development.
Implementation Considerations
Efficient tools support for Workflow Management requires standards and procedures that specify:
Workflow Management tools must at a minimum provide support for
Tools to assist Workflow Management should support the following:
Security Management tools provide the components that make up the security layer of the final system, and may provide required security controls to the development environment. While some of these tools may be considered as nothing more than security-specific Packaged Components, many are an integral part of the development environment toolset.
Security Management tools include:
These tools will be discussed in detail in the Security Product Evaluation Framework to be published by Global TIS Security as part of the Security in eCommerce project.
Product Considerations
a) Does the Tool Use Role-Based Access Control?
Role-based access control establishes access rights and profiles based on job functions within the environment. If different access rights are required for security administrators vs. code developers vs. code reviewers vs. testers, then the correct access can be established based on these functions.
b) Does the Tool Have Flexible Auditing Capabilities?
The security administrator should be able to granularly configure what is being audited by the tool. The audit logs should be able to optionally record User ID, time-of-day, location of access, successful and unsuccessful access or change attempts, etc.
c) What are the Performance Implications of the Tool?
Some security services, such as content scanning or auditing, may add noticeable processing time and requirements to the system. Tools should be architectured in such a way that performance impacts are or can be configured to be minimal.
d) Does the Tool Comply with Industry Accepted Standards?
Many standards are emerging in the security technology marketplace. These include standards for cryptographic services, directory services, IP security, etc. In order to enhance future integration possibilities, choose vendors who are developing open solutions which comply with standards.
Information Management (8202)
Information Management of the development architecture is provided through an integrated development repository. At this level of integration, tools share a common repository of development objects, design documents, source code, test plans and data. Ideally, the repository would be a single database with an all-encompassing information model. Realistically, the repository must be built by integrating the repositories of the different development tools through interfaces. Tool vendors may also build part of the integrated repository by integrating specific products.
Implementation Considerations
a) Is There a Desire to Enforce Consistency in the Development Effort?
Engagement teams should consider the use of a repository to enforce consistency across development efforts. A repository can store standard data, process, design, and development objects for use during application development activities. Developers then use these standard objects during implementation. As objects are defined once in the repository and reused throughout the implementation process, applications display a consistent look, feel, and flow while enforcing the standards inherent in the repository objects.
b) Will Analysis and Design Objects be Reused?
Based upon engagement experiences, an engagement team should consider using a repository when the development team reuses analysis and design objects and deliverables during later phases of the development process. A repository houses many application development components including data definitions, process models, page designs, window designs, common GUI widgets, message layouts, and copybooks.
These components can be reused across large development projects to increase developer productivity and decrease the risks associated with coding and testing the same components multiple times.
c) How Large is the Development Team?
Large development teams require more standardization and control in order to ensure that the team remains productive and maximizes reuse of analysis and design components. A repository provides the development teams with the ability to reuse objects defined in the repository in a controlled manner. Most engagements consider using a repository once the number of developers exceeds ten.
d) Is the Development Team Geographically Dispersed?
An Information Management repository is crucial when teams whose designs must integrate are in different places. The repository becomes a means of communication that is formal and enforces the agreed interfaces.
e) Do a Number of Tools Need to Be Integrated?
A repository management tool may be required to provide an integration platform for existing and future tools, providing communication among all tools where appropriate.
Product Considerations
a) Is Support for User Defined Objects Required?
The repository may need to be extended by the Engagement team to support custom objects defined by the Application Development team. Some repositories support user-defined objects as part of the base functionality. Others allow customization of the repository by the user while some are not designed for customization at all. If the repository requires extensive customization, a buy versus build decision may be required.
b) Is a Logical or Physical Repository More Beneficial?
The Engagement team must consider the costs and benefits of a physical repository versus a logical repository. A physical repository is implemented as a single product. Many CASE tools employ this type of repository by housing all application development objects in a single source. Application development tools are then tightly integrated with the repository.
A logical repository integrates multiple tools to form an application development repository. The various tools employed in the development environment are bridged together by custom architecture components. This approach is commonly used when the Engagement team takes a best of breed approach to tool selection.
c) What are the Current and Proposed Future Platforms?
The Engagement team should determine whether the repository must support multiple platforms. The selected tool should not only support current platforms but also support the future platform direction of the project.
d) Does the Product Support Multiple Versions of Objects?
The repository should support multiple versions of objects. By doing this, the repository can support applications in multiple phases of development. The repository tool should control access to the versions of objects by providing check-in and check-out functionality. This allows multiple developers in various phases of development to work from the same repository while allowing only one developer update access to a particular object at a time.
e) Are There Existing Tools that Influence the Selection of the Information Management Tool?
Engagement teams have found that tools used in other parts of the client organization influence the selection of a repository tool. Clients may have experience and existing skills with certain Information Management tools that drive the decision to use those tools corporate-wide on other initiatives. The KX may also provide input to the tool selection process based on previous experience and skills of team members.
f) What Are the other Capabilities of the Tool?
Engagement teams often chose a tool that can be used in other areas of the development environment. Many Engagement teams select data modeling tools that can double as Information Management tools. Using one tool for multiple purposes results in fewer integration points in the architecture and less time and cost training personnel on multiple tools.
g) Should the Information Management Tool Support Multiple Repositories?
As many repositories do not provide sufficient versioning functionality, it is common to have more than one repository on large projects. Typically there would be one repository for development, one for system test, and one for production. This improves overall control. Another reason could be that there is concurrent development of different releases, each requiring its own repository. Hence, on a large project, a tool that supports multiple repositories is often a requirement.
The repository contents are effectively the building blocks of the system and have broad reuse. A facility for security is required to prevent unauthorized changes to the repository elements and hence to ensure high quality and consistent repository content. For example, restrictions are often placed on making changes to data elements because ad-hoc changes by a single designer could have devastating impacts on other parts of the design.
Repository access control is important where developers in the development environment need to be assigned different rights to the repository. Typically, the developers will be placed in groups with diminishing access rights such as repository administrator, technical support, designer, or programmer. These access rights may relate to read/write/modify/delete authority. This method of access control is far more flexible than simple object locking.
h) Does the Tool Provide Repository Reporting Facilities?
Repository reports serve as an audit trail for changes to objects within a repository and can be used to communicate these changes to the entire team. The Repository Management tool should provide this utility.
Reports for impact analysis are extremely useful in the change control process. As the repository maintains relationships between repository objects, 'where-used' and 'contains' report facilities can be very useful when dealing with change requests.
i) Is the Tool an Active or Passive Information Management Tool?
Active Information Management tools can be used to generate components, whereas passive tools are used to hold information about the tool but are not used to build the system. The use of an active Information Management tool increases productivity because of the facility to generate components.
If the repository needs to be customized in order to integrate with all the required tools, then it is important that the Repository tool has a published interface and underlying data model. Using such a repository makes interfacing other tools with the repository considerably easier and less time consuming.
All key characteristics of repository objects (for example, data elements) and their inter-relationships should be validated. Taking data elements as an example, these characteristics may include:
At a minimum, naming standards must be validated to allow better navigation of the repository and easier reuse of elements.
The integrity of references to entities that exist outside the repository but within the folder management system must be maintained. If the tool does not directly support this, procedures will have to be put in place to ensure the consistency of references to these entities.
Repository Management (8102)
Repository Management is the key information management tool. The repository should be:
A development repository results in three important benefits for a development organization and for the business units they support:
The challenge is to create such a repository. Most of the available tools on the market do not explicitly support this comprehensive concept of a repository.
The alternative is to:
In many instances, content may not be stored directly in the repository and must be placed in storage. In this case, only a reference is stored in the repository.
When complete integration is achieved, the repository can serve as a communication enabler for a large collection of development tools.
This can be achieved either by using an integrated CASE tool, or by integrating point tools around a common repository.
In addition to the repository, which plays a key role, other important tool categories include the following.
k) Security
Repository access can sometimes be controlled using an access control function, which comes with the repository. A common technique is to group users and assign different access rights to the different groups. Each of these groups is also assigned specific read/write/delete/modify authority. For example, the following groups may be defined as having increasing rights:
A less flexible alternative is to lock objects. A locked object cannot be changed until the repository administrator unlocks it. This is a less flexible approach but may be used when flexible access control functionality is not part of the repository.
A tricky, and somewhat risky, approach to compensate for lacking access control functionality is to use information about the repository's internal storage mechanism to design an access control scheme. For example, if data elements are stored in a particular directory, tools from the network operating system can be used to limit access to that directory. If data elements are stored in a particular table, tools from the DBMS can be used to limit rights to that table. How well this works depends on how gracefully the repository handles error messages from the network operating system or the DBMS. This approach should be tested before it is implemented.
l) Repository Maintenance
An alternative approach to maintaining history in cases where the repository does not offer good versioning capabilities, is to maintain a shadow repository where previous versions of repository objects are stored. This only works for those repository objects whose maintenance is strictly controlled.
This, however, is not always the case. In some instances, the tools for populating extensions of the repository are not provided, and in other cases, a stand-alone repository is used. In these cases, the integration between the design tools and the repository must be performed by the Technology Infrastructure team. This was achieved on a number of projects that chose a "best-of-breed point tool" approach where they integrated these point tools around a repository. The integration may require some challenging work writing parsers, which analyze the output from the individual point tool, and use this to populate the repository. These technical complexities should be hidden from designers and programmers by providing friendly interfaces to the parsers, or by having the repository administrator trigger the parsing at regular intervals.
Similar validation can be performed on other repository objects depending on project standards. At a minimum, naming standards must be validated. This helps designers navigate the repository and thereby encourages reuse.
Import and export utilities, which provide exchanges between the repository and flat files, can be useful in several ways. They make it easy to take a snapshot of the repository for archiving, and they allow for reuse of the contents of other repositories.
m) Analysis, Reports, and Queries
Reports for impact analysis are extremely useful in the change control process. As the repository maintains relationships between repository objects, where-used and contains reports are usually provided with the repository. Storing the names of affected repository objects in an area-affected table can be useful when grouping change requests during assignment, or when defining a release. The area-affected table is also a valuable tool that can be used to facilitate migration from development to system test.
The ability to easily create various repository reports is important to leverage the information in the repository. A scripting language, a simple report builder, or a query tool provides this capability. Having a query tool with an intuitive user interface and good report formatting features is a necessity on a large project. The query tool can be used to provide standard reports for designers and programmers, printed design information for external reviews, and ad hoc requests for the repository administrator.
Folder Management (8104)
It is not always practical to store all information in the same repository. One reason for this is the repository's physical implementation. For example, if the repository is implemented on top of a relational DBMS, this supporting structure does not provide good support for storing flat files. It may therefore often be most practical to populate the repository with place-holders for entities which reside outside the repository. With this scheme, the place-holder serves as a logical pointer. This scheme obviously requires some work to ensure integrity, but in practice it can work quite well. It works better if the objects outside can be organized in a structured way. This is where folders come in. They can be used to impose a structure on flat files; a structure, which can correspond to the structure of the repository. Folders should provide:
Methods for storing and managing media content range from simple folder management techniques to multimedia digital asset management systems, capable of indexing and manipulating numerous multimedia data types. There are a number of key requirements for Media Content Management—in particular, a Media Content Management system should have the ability to:
Whether the functionality described above is handled as an integral part of the system, or by manual processes implemented by the Information Management team depends on the richness of functionality provided by the tools chosen.
Additional functionality provided by advanced Media Content Management tools may include:
The method of Media Content Management depends heavily on what media is to be stored. Ensure that the target media formats are understood before implementing the Media Content Management approach.
b) Where Should Media Content be Stored?
Where to store media content greatly depends on the volume of media to be stored, and the performance requirements for retrieving that data. One thing is certain however; when dealing with large quantities of media, it is necessary to employ a dedicated media server, thus avoiding volume and performance hits with the rest of the development environment, while allowing the possibility of tuning the media server for optimal performance.
The cost of data storage is not insignificant, especially when considering the total cost (not just that of the hardware and software, but also the effort required to support it). This means that much thought must be put into a media storage strategy. This includes a strategy for deciding which media should be on-line (instantly accessible), near-line (accessible with short delay, for example, CD juke box), or even possibly off-line (manual intervention required).
Object Management (8108)
Object Management tools provide capabilities for viewing objects, their methods and attributes, and the dependencies between these objects.
Object Management tools also provide specific analysis tools, in order to understand interdependencies between the core classes and the components. When classes and components are modified, impact analysis tools are required to see where the modified entity is being used, allowing them to understand what is the overall impact of the change. This is more complex than with traditional systems as a veritable spider's web of dependencies between classes, components, and applications may ensue. In addition, OO features such as inheritance and polymorphism make tracking down dependencies with simple text search tools much more difficult.
Note: At the time of writing, none of the object management tools currently available on the market provide component management capabilities.
Quality Management (8204)
Quality Management is a management discipline that promotes a customer satisfaction focus and continuous improvement. Quality Management tools support the definition and implementation of quality.
A number of integrated Quality Management tools are available that may combine the functionality of all the required quality subcomponents into a single product. Many quality processes however, (such as Expectation Management) do not require specialized tools, and are therefore supported by standard productivity tools.
Metrics (8110)
Metrics are an important part of quality management in that they provide a method of measuring (for example, sampling, testing, and determining) whether a process or product meets a given criterion. With Metrics, different stakeholders can agree that a product objectively meets an expectation, or that a process has been improved by a measurable amount. Without Metrics, stakeholders can only have subjective opinions that may or may not agree.
Measurement tools are used to measure process quality and product quality. Process quality may include Metrics such as the time it takes to process a change request. Product quality should be measured for all the product expectations the project has set. This measurement process is the inspection part of quality management.
Statistical Process Control (8152)
Statistical Process Control tools are used to analyze the results obtained with the measurement tools. These display trends that can be used as the basis for process improvement or, in other cases, product rework.
Continuous Improvement (8112)
Continuous Improvement tools are used to analyze and improve the development processes.
Continuous Improvement is a process management technique by which action is taken to modify a process when the measurement or outcomes of that process are unsatisfactory. Process improvement is required whenever the number of defects exceeds the desired level, productivity falls below a desired threshold, or client expectations fail to be met. Once the process has been modified, it is remeasured to see whether the expected gain was actually achieved.
Training (8154)
Training tools provide methods to apply a standardized training approach to a large group of people. Training tools can complement or take the place of traditional instructor-led training depending on the type of information that must be communicated. Computer-Based Training (CBT) tools offer the advantage of being able to train personnel directly on the target environment.
At the more basic level, training tools can also include online or paper-based training materials—not offering all the advantages of CBTs, but still providing the flexibility and convenience because they can be conducted as and when the trainee requires, and in any location. This removes the need to organize classes.
The decision of whether to use CBT, online, paper-based or instructor-led training is affected by the number of people that have to be trained, the complexity of the subject, and the availability and distribution of the people to be trained.
Program & Project Management (8214)
Program and Project Management tools assist the management teams in their daily work. These tools, typically packaged as integrated suites of software, provide the basic functionality required for planning, scheduling, tracking, and reporting at both the program and project level.
Planning tools are used to assist in program and project planning including the development of the Program Resource Plan, the Work Breakdown Structure (WBS), the Organization Breakdown Structure, Cost Accounting, milestones, and deliverables.
Scheduling Tools are used to allocate resources against the WBS, to determine the timeline for a specific project, and to schedule the allocation of resources at the program level.
Project tracking tools enable the project manager to track the actual project status against the original plan and schedule. Integration with the time reporting system and techniques such as Estimates to Complete (ETCs) are valuable in tracking project status.
Reporting Tools are used to summarize status and metrics to program and project management.
Configuration Management (8210)
Configuration Management tools ensure that consistency between components and a given environment is maintained over time as components are changed.
Implementation Considerations
a) Does the Testing Effort Involve Numerous Applications with Common Components?
Engagement teams frequently require Configuration Management tools to support the testing process. Large development efforts may have multiple releases of an application in the development pipeline (development, unit test, integration test, user acceptance test, and production). Additionally, some environments have multiple applications that share common components. Multiple versions of common components may be required depending upon the application being tested.
Configuration Management tools assist in migrating code between these environments. These tools can also be used to manage different versions of test scripts for various releases of an application.
b) Where is the Development Team Located?
Configuration Management tools are essential when development teams are not centralized at one location. These tools provide services, such as version control, when geographically distributed teams need to access common modules or data, such as code tables. Configuration Management tools may still be necessary even if the development team is centralized, depending upon other criteria such as development team size.
c) How Large is the Application or Development Team?
Large applications, as well as large development teams, require Configuration Management tools to help control versioning of code, changes to code, and migration of code (and accompanying design and test documentation) through the development and testing environments.
As the size of the team increases, the communication between team members becomes more cumbersome. The Configuration Management tools provide a structure for communication between team members regarding version control, change control, and migration control.
As the size of the application increases so does the number of objects, files, or components. The management of these items becomes increasingly difficult to manage and track during the development process. The Configuration Management tool provides structure for managing the objects, files, and components and reduces the risk of lost information caused by version problems, or by items not being migrated properly.
d) Is the Development Effort to be Sustained Over a Prolonged Period?
Over time, a large number of configurations will evolve and Configuration Management tools can be used to control the evolution and to document these configurations.
e) Is there a Large Number of Components?
It may be necessary to keep track of and control configurations consisting of objects such as training materials, documentation, hardware components, system software and even building characteristics. The existence of a large number of such components makes the task of managing their configurations complex, and a dedicated Configuration Management tool becomes crucial to the process.
j) Are Multiple Organizations Contributing?
Configuration Management tools are particularly important when there are multiple vendors and subcontractors involved and there is a need to align what is assembled in preparation for the integration test.
g) Does the System Exceed 100 Modules?
Configuration Management tools are needed once the system becomes large and many modules (which may include programs, header files, copybooks, shared components, subroutines, and so on) have to be managed. There is a significant cost involved in formal configuration management. If the system has a little over 100 modules, the Configuration Management component may consist merely of a whiteboard or Excel spreadsheet. As the number of modules grows to about 1000, a dedicated tool is required.
h) Do the Generations or Versions of Components Change Frequently?
A Configuration Management tool is important if many generations or versions are to be managed. This will generally be the case if the project involves a large development team. There may be external factors that the project team has no control over such as hardware vendors who change their configurations frequently. The internal components, for example, software modules must be configured to match external components such as operating systems and hardware components.
Product Considerations
a) Should the Engagement Team Build a Custom Configuration Management Tool or Purchase an Existing One?
An engagement team must determine whether to purchase a Configuration Management tool or build one. The build decision should consider the cost of designing and developing the functions required by the engagement team. Additionally, the project must consider the resources and development time required to build the tool and when the tool is needed in the application development schedule.
The buy decision can still be expensive and requires additional investments for training project personnel. These tools also provide many features that may not be required by the engagement team.
b) Does the Engagement Team Have More Experience with Certain Tools?
Engagement teams found that tools used in other parts of the client organization influence the selection process. Clients may have experience and existing skills with certain Configuration Management tools that drive the decision to use those tools on other initiatives corporate-wide. Andersen Consulting may also provide input to the tool selection process based upon previous experience and skills of team members. Using tools that the engagement team already has experience with provides several advantages, especially a reduction in training costs.
c) Does an Existing Component Satisfy this Requirement?
Engagement teams sometimes choose tools that provide multiple development functions, including Configuration Management tools. The decision to choose between available Configuration Management tools may already have been decided as a result of using certain other tools within the development environment.
d) Does the Product Integrate with the Existing or Proposed Architecture?
The engagement team should select tools that integrate with other tools in the development environment and operate on the same platform. Project teams should select tools where vendors provide support for the integration between the Application Development tool and the Configuration Management tool. Such integration helps to easily and effectively manage the objects or files created by the Application Development tool.
How does the project define a configuration?
Does the tool handle all types of components in the configuration?
The components involved in Configuration Management typically involve hardware, system software, and application components together with their documentation. The tools should be able to manage and keep track of all the component types that make up a configuration.
e) Does the Tool Provide Capabilities for Exception Reports?
If for some reason a repository component is not at the correct promotion level, the tool should be able to report on this when required.
f) Will a Source Control System Suffice as a Configuration Management Tool?
Generally, source control systems must be enhanced to provide a basic Configuration Management tool. The functional enhancements are typically:
The tools should automate the storage and retrieval of all dependent software components indicated by an impact analysis report.
Version Control (8114)
Version Control tools control access to source code as it is developed and tested and allow multiple versions to be created, maintained, or retrieved. For example, a source code comparator can be used to identify changes between different versions of programs.
The component-based development raises a new challenge: when a single component is used by several applications, versioning becomes significantly more complex and therefore, advanced versioning software, including system support for versioning, is required.
Implementation Considerations
a) Should the Evolution of the System be Tracked in Terms of Who Makes Changes or Why Certain Decisions are Made Along the Way?
Version Control tools allow systematic storage of information about who makes changes in what order so that the evolution of the system can be tracked.
The tools usually provide a facility to report on differences in versions so the version that existed when a critical change was made can be identified and recreated or retrieved. The tools can also provide a means of documenting why decisions are made during the evolution of the system. These decisions would have been made based on the version of the documentation for the system that existed at that time.
Version Control tools allow the state of the system at a particular time to be recorded. Hence improved auditability for decisions can be achieved.
b) Is there a Large Development Team?
Version Control tools allow developers to work semi-independently and to choose the degree of integration they need at any given time. They can shield themselves from the tentative development performed on shared components and test a portion of the system with a stable environment around them. This prevents the development team from having to develop one full sequence at a time and increases the ability of a large number of people to work productively together, thus compressing the time required to develop a system.
c) Is there Concurrent Development of Multiple Versions of the System?
A comprehensive Version Control tool set is critical if there is concurrent development of multiple versions of the system. This is often the case when system development is to be sustained over an extended period.
Special provisions must be made to ensure that the library and repository structures are rich enough to be able to support the necessary versions. In this environment, a log of changes also becomes very important as fixes applied to earlier versions generally have to be applied to later versions as well.
d) Is it Likely that the System Will Need to be Rolled Back to a Previous Version at Some Stage in the Development?
This is typically the case when the project is breaking ground, using new techniques or untried architectures.
Version Control tools provide a means of taking snapshots of the system in time. If there are changes in the environment that force the system to be rolled back to a previous stage in the development, Version Control tools allow access to previous versions and mechanisms for reverting to an earlier version.
e) When Should I Set Up Version Control?
Version Control should be set up from the beginning. By delaying version control, manual Version Control must be used. This result can be an increased cost in disk space in the development environment (because of the number of versions of each module that must be kept) and can lead to some human versioning errors.
f) What Kind of Information Should I Add to Version Control?
There are different approaches: Everything (hand-made code, generated files, documentation, even compiled exec file or DLLs), some of the above etc. In general, documentation should be added if no additional design repository exists, otherwise, use the repository, which usually has a versioning capability. Adding binary files will usually have to be considered during the initial setup phase, as this requires significantly more memory and not all tools can handle binary files in a correct manner.
g) Which Stages to Add?
The stages in the version control (Dev, Assembly test, system test, etc.) should be added according to the development approach. Strong relationship to migration control. Should also be automated and is usually supported by the tools.
Product Considerations
a) Does the Tool Provide Capabilities to Cater for a System Running on Multiple Platforms or a Distributed System?
Ideally, the Version Control tool must be able to operate on all the platforms in use, whilst at the same time performing Version Control for all components across the entire system.
b) Does the Tool Provide Support for Actions Like Mass Builds?
Usually, custom tools are put on top of the vendors tools to support actions like mass builds etc. Some tools (or add-ons) support this already. This is vital for the project, as it allows huge productivity gains in later phases of the project.
c) How Easy is it to Implement Batch Solutions?
It should be considered if a batch/API interface exists for implementing batch solutions.
Change Control (8118)
The Change Control system should provide the following features:
Ideally, the Change Control system should also be integrated with workflow support, the repository, and the source code control system. This ensures rapid processing of the change, accurate analysis of the area affected, and correct locking and unlocking of repository objects and source modules.
Implementation Considerations
a) Does the Project Require Strict Scope Control?
Specifications and scope may be changed at any time if Change Control tools and standards are not implemented. This can result in the project running over budget, or being delivered late with inconsistent quality because requirements change continuously.
b) Is the System Complex?
Change control has broader applicability than to just application source code. It may also affect the look and feel, training materials, documentation, and so forth. Change Control must be formalized if the system is complex with many components.
c) Do Changes Need to be Authorized by Specific Personnel?
Change control tools provide a vehicle for ensuring that only authorized changes are made and signed off. This ensures conceptual, proper ownership of the total look and feel of the application. Change requests may also be rejected or deferred by an authorized person.
d) Is Coordination of Changes Required?
Facilities to track interdependencies between change requests (for example, change request A must be completed before change request B can start) are provided by Change Control tools. This can be used to encourage efficient scheduling and to ensure that work is not duplicated.
e) Should a Record be Kept of Changes that Fall Beyond the Capacity of the Project at that Time?
Change Control tools can provide a vehicle for capturing good ideas. If the project does not have the capacity to implement those ideas at present, the Change Control tool can be used to capture those ideas. These ideas can be reinvestigated when a future release is planned.
f) Are Conflicting Change Requests Likely to Occur?
Change request tools can be used to identify changes that conflict, for example, one user wants a green background and another wants a blue background. The changes must be resolved through some kind of dialog or discussion and Change Control can be used to initiate this process.
g) Is it Likely that the System Will Need to be Rolled Back to a Certain State?
This is typically the case when the project is breaking ground by using new techniques or untried architectures.
Change control tools provide a means of identifying at what point in time a critical change was implemented and that information can be used to find out what version existed at that time.
h) Is there a Need to Evaluate the Impact of Implementing a Change on the Project?
Change control tools typically support some kind of impact analysis and may be integrated with an impact analysis tool set. Impact analysis is important in order to group changes so that they can be implemented effectively.
Multiple changes may affect the same component and it would be wasteful to open that component many times over and implement the changes one at a time. Impact analysis can be used to ensure that all relevant changes to that component are implemented together. Hence impact analysis is important for scheduling purposes and for estimating cost.
Product Considerations
a) Does the Tool Provide a Capability to Classify Change Requests?
Change requests may occur as a consequence of changing requirements, or as a result of nonconformities (or defects) in the system. The tool should be able to classify change requests into categories such as incidents, faults, or enhancements. The tool should also have the ability to update these categories if required.
Classification of different change requests in several different ways such as area affected, priority, estimated cost or authorization is important to ensure correct scheduling of the implementation of changes. Flexible, customized sorting and reporting based on this classification is required to ensure that change is handled in a timely manner.
b) Should an Impact Analysis Tool be Purchased or Developed?
Impact analysis tools are typically required to provide analysis of a wide range of types of documents such as Word, Excel, or PowerPoint.
If an impact analysis tool cannot be found that supports the entire environment, it is critical to develop procedures or utilities that will report on where items are used. The first step is to identify the items to be searched, and to build procedures around searching them (for example, databases, files, workspaces, programs, screens/forms, reports). It is also important to identify who will be responsible for the impact analysis (DBA, analysts, programmers, team leaders, and so on) to avoid this work falling between the cracks.
c) Does the Tool Provide Free Format Description of Changes?
Free format descriptions are important because this allows better and more understandable documentation of change requests and associated decisions.
d) Are there Going to be Multiple Releases of the Software?
The tool should allocate change requests to different releases based on priority and resource availability. It should also provide a means of attaching a deadline to a change request.
Does the tool provide a means of indicating which development team member is best suited to perform the implementation of that change request?
This functionality should be available as part of the scheduling capability. An added feature would be the capability to balance workload across the team.
e) How does the Tool Handle Exceptions?
The tool should provide a capability to generate exception reports that highlight issues such as change requests that are in danger of not meeting the release to which it was allocated.
f) What is the Prediction for Volume of Change Requests for the Project?
The tool should be able to cope with the expected volume of change.
g) Is Validation Of Data Entered into the Change Re Quest Form a Consideration?
It may be necessary to ensure that the data entered on a change request form is valid. This is particularly important if the development team is inexperienced or if the project is particularly complex. An example of data validation would be to ensure that the change is assigned to a valid team to prevent a change request from falling through the cracks.
h) Is Recording of Resolution Details and Root Causes Required?
This capability provides useful tracking across the complete life cycle of a change request.
i) What Reporting Capabilities are Needed on the Project?
Some Change Control tools can report on status of change requests at the individual, team, and project level. Such reports can provide information about work done to date and Estimate to Complete (ETC) values.
j) How Many Users Will Simultaneously be Accessing the System?
The tool should cater to the size of the project. Maintaining consistency of information may otherwise become a problem with simultaneous access. The tool should provide some kind of protection of change requests if simultaneous access is likely to occur.
k) Does the Tool Provide a Means Of Prioritizing Change Requests?
The tool should provide capabilities for prioritizing change requests based on business impact and the impact of implementing the change.
Does the tool provide capabilities for predicting the cost, risk, and instabilities created as a result of implementing a change request?
These capabilities need not provide completely automated prediction but should work in conjunction with an analyst.
l) Does the Tool Identify Component Dependencies?
This is an important aspect of impact analysis that is required to ensure that all components impacted by a change request are identified.
Migration Control (8116)
Migration Control tools control multiple versions of source code, data, and other items as they are changed, tested, and moved from one development environment into another, for example, from development to test and from test to production. Data migration control tools manage multiple versions of the database and its data to ensure that accurate data and structure are maintained in the environment, and to ensure that versions of application code and database are deployed consistently. Types of data that would be migrated include base codes data and converted data.
Other Migration Control tools manage other types of objects to ensure that complete versions of all components reside in the production environment (for example, test definitions and scripts).
Implementation Considerations
a) Are there Multiple Environments Running in Parallel?
Multiple environments are typically required when the project is faced with serious time constraints. Typically the project team performs integration or systems testing on one portion of the system, while developing the next portion. The team corrects errors based on one test while at the same time, the next test cycle or testing of the next part of the system is performed. This means that multiple environments exist that are configured differently and use a different version of the system components. The migration of these different versions and configurations between environments must be carefully controlled using Migration Control tools. For successful migration there must be consistent migration of all components and their dependents.
b) Are Multiple Releases being Developed in Parallel?
If multiple releases are being developed in parallel, it is vital to provide a consistent means of migrating configurations and versions from one environment to the next. This ensures that there is no confusion of components in each release as the move is made from, for example, a unit test environment to a system test environment.
c) Is the Development Effort to be Sustained Over a Prolonged Period?
Migration control tools keep a log of what is migrated. It may be required to review what has happened over time, in order to gain an understanding of the current status of the system.
d) Is there a Need to Control Who Activates Migration from One Environment to the Next?
Migration control tools ensure that only authorized personnel can trigger the migration of components from one environment to the next.
e) Is the System Complex (Consisting of More than 1000 Components)?
The task of promoting components and locking these components to prevent concurrent or unauthorized updates to them or their dependents becomes very intricate as the number of components reaches 1000. Migration control tools can be used to improve productivity by facilitating and controlling the migration from one environment to another and by automating the process. It is possible to bring a large project to a complete halt if Migration Control is not properly enforced.
Product Considerations
a) Does the Tool Support the Migration of all the Components that Make Up a Migration Object?
The Migration Control tool should be able to manage and control the migration of all the components (for example, source code, database access, make files, run-time data, environment variables, code libraries, code tables, third-party software, and so forth) which make up the object to be migrated. The complexity of the Netcentric world with so many integrated vendor solutions dramatically increases the number and variations of object types.
b) Does the Tool Facilitate the Migration of Many Components Together as Well as Migrating Components Individually?
Migration from a development environment to a system test environment either involves a large number of components (migration of all the components belonging to a test cycle) or single components (after code fixing in a program). Either way the Migration Control tool should lock the migrated component to control changes and allow better coordination with the system test team.
c) Does the Tool Support all the Required Platforms?
In a development environment where there may be different platforms, it is important that the Migration Control tools be able to synchronize source migration across platforms. Unit and system tests are normally performed on every platform so the migration tool should be able to promote the components across platforms as well as from environment to environment.
d) What is the Migration Strategy?
A push strategy should be facilitated by the migration tool if it is decided that modules should be tested when those modules are ready for testing. This is normally the case for unit testing. A pull strategy is needed if the order of component testing is important as is normally the case for system testing.
In implementing a push strategy it is usual for the individual programmer to be responsible for migrating the module. If this is the case then the tool should be easy to learn and use. Using a pull strategy may decrease the number of people required to know how to use the tool.
Release Management
Release Management tools should provide:
Ideally, the Release Management system should also be integrated with workflow support, the repository, and the project/program management system.
Environment Management (8206)
The modern development environment is both complex and sophisticated. It supports many different functional and technical requirements (illustrated by the execution architecture), many different development teams, tools from many different product vendors, and often must support projects at different stages of the development life cycle. As such, it is a mission-critical production environment and must be managed based upon an operations architecture. The extent to which the areas of the operations architecture are implemented must also be a factor of project size and duration.
The environment management requirements in this section are based upon the MODE (Management of Distributed Environments) conceptual framework. This section uses MODE as a framework, adopts MODE terminology, and focuses on those management tasks from MODE which are particularly important in the development architecture.
MODE identifies four main areas:
The subcomponents of Environment management reflect these four MODE areas.
Service Management (8122)
Service Management tools support the various aspects of supporting and managing the interface with developers.
As defined in MODE, these include the following:
Systems Management Tools support and manage the operation of the distributed system. Many specific monitoring and analysis tools are covered in detail in the Network Performance Management practice aid and the Technology Products and Vendors database, both available on the Knowledge Xchange.
Startup & Shutdown
A comprehensive development environment rapidly becomes sufficiently complex that the startup and shutdown of the environment must be managed carefully, and preferably automated. This is key to ensuring the integrity of the environment. Startup may involve the carefully sequenced initialization of networking software, databases, web servers and more. Similarly, shutdown involves saving configuration changes as needed and gracefully taking down running software in the correct sequence.
Backup & Restore
The incremental value of the daily work performed on the development project is high. This investment must be protected from problems arising from hardware and software failure, and from erroneous user actions and catastrophes such as fires or floods. The repositories and other development information must therefore be backed up regularly. Backup and restore procedures and tools must be tested to ensure that system components can be recovered as anticipated. The large volumes of complex data generally require automation of backups and restores.
The advent of Netcentric technologies has introduced an increase in media content that requires storage. The environment may support a high volume of media files, which must be considered in the backup/restore plans. Storage capacity planning should allow for the typically increased size of these file types.
As the amount of storage will grow significantly over time on a large project, the hardware requirements will increase. Sufficient room for growth should be planned when selecting the tools and hardware. Switching tools and hardware can be problematic due to lack of upward compatibility (DDS-DLT, various tools etc.).
The time required for backups must also be considered. Usually the number of hours without development per day decreases over time and if backups can only be performed when no user is logged in, this might become a problem. It is generally the case that the project will benefit from buying the fastest and largest backup hardware/software it can afford.
Archiving can be particularly useful to safeguard information from previous versions or releases. More generally, it is used to create a copy of information that is less time-critical than the current environment at a given time. Archiving may be performed to a medium, which is different from the backup medium, and may involve other tools which, for example, provide a higher compression ratio.
Security tools are required in the development environment to ensure against unauthorized access by individuals and system processes, to limit damages caused by such unauthorized access, and to audit access the environment services. At the security management level, it may be valuable to have tools which help manage security profiles, security groups, and access rights.
Product Considerations
a) Does the Tool Use Role-Based Access Control?
Role-based access control establishes access rights and profiles based on job functions within the environment. If different access rights are required for security administrators vs. code developers vs. code reviewers vs. testers, then the correct access can be established based on these functions.
b) Does the Tool Have Flexible Auditing Capabilities?
The security administrator should be able to granularly configure what is being audited by the tool. The audit logs should be able to optionally record User ID, time-of-day, location of access, successful and unsuccessful access or change attempts, etc.
c) What are the Performance Implications of the Tool?
Some security services, such as content scanning or auditing, may add noticeable processing time and requirements to the system. Tools should be architectured in such a way that performance impacts are or can be configured to be minimal.
Performance Monitoring
Performance Monitoring tools help ensure that the available resources are sufficient to meet the developers' performance requirements. These tools can be used to assess end-to-end performance of both batch processes such as backups, and interactive processes such as repository-based file retrieval.
Service Planning (8124)
Service Planning is the planning required to anticipate and implement changes to the following areas:
All these areas relate to the development environment and are analogous to the kind of planning that must occur in the business application's production environment. Key types of tools for development environments include Performance Modeling and Capacity Planning tools.
Performance Modeling
Performance modeling tools in this category support the analysis of the development environment's performance, as opposed to that of the client/server application being developed. A simple spreadsheet may be suitable in some well-known and understood environments, but dedicated performance modeling tools should be considered on any project with high transaction volumes or complex environments involving multiple platforms.
Capacity Modeling
Capacity modeling tools support the maintenance of adequate processing capacity for the development environment (for example, workstations, servers, storage devices, and network capacity). These tools range from spreadsheets to dedicated capacity modeling and simulation tools.
Managing Change (8120)
Managing Change tools support the various aspects of identifying and managing change in the development environment. Specific tools are discussed in detail in the MODE Products Database on the Knowledge Xchange.
Data and Software Distribution is a key tool in this category for development environments that have several developers. These tools enable automated distribution of data and software to the workstations and servers in the development environment.
Problem Management (8212)
Problem Management tools help track each system investigation request—from detection and documentation to resolution (for example, Problem Tracking, Impact Analysis, Statistical Analysis).
Problem Management tools log information about problems detected, classify them, and generate reports. This is essential for capturing metrics information.
The major functions of Problem Management are:
It is important to select an automated Problem Management system that is integrated with the program's testing and Configuration Management tools. Therefore, the Problem Management system must be able to support the testing model selected, for example, the V-model, and have tight integration with the Migration and Version Control tools associated with Configuration Management.
An automated test script tool can be integrated to allow users to reference scripts that were being used when the error or defect was found. A data repository can be integrated into the Problem Management application that will allow the users to build relationships between problems and design and test documentation and application components.
An ability to associate problems with affected work packages and a mechanism for version control changes for the work package is necessary so the package can be migrated back into the testing environment.
When considering an automated tool, also consider what type of security is required for the Problem Management application. This is closely tied with the Configuration Management tools. Only one person should have the rights to review and approve problem analysis tasks as well as problem migration activities.
Implementation Considerations
a) How are problems handled at each stage?
b) How do I plan for trapping problems?
c) Do I retest problems at different stages?
The following is an overview stage containment as documented by the Reinventing Testing Project (RTP).
Stage containment is an approach to identify problems in the system before they pass to the next stage. It is a measure that helps build quality into the system. The goal of stage containment is to minimize the number of errors being passed to the next stage. For the purpose of stage containment, problems are sorted into categories. Errors are defined as problems found in the stage where they were created. Defects are problems found in a stage successive to the stage where they were created. Faults are problems found in production. The longer a defect remains undiscovered, the more difficult and expensive it will be to correct. Because each stage relies on the decisions made during the creation of the specification in the previous stage, detecting an error in a stage after it was made may invalidate some or all of the work done between the time the issue was created and the time it was discovered.
The V-model specifies that testing in one stage must be completed before moving on to the next stage of testing. Before moving up to the next stage, it is key that the exit criteria defined for that stage have been met. A part of the exit criteria for each stage is that the test has been successfully executed, therefore ensuring the test objectives (or primary focus of the test) are accomplished before moving on to the next stage.
Once the objectives of one test stage are met, there is no need to repeat the same testing at the next stage. This is a key concept of the V-model and one that proves difficult to accept and use in practice. There is often a desire to retest just to "make sure everything is OK." Doing so, inevitably leads to time-consuming testing. In addition, it leaves less time to do the testing required for the current stage of testing, ultimately resulting in minimal, if any, time for the last stage of testing. In other words, minimize gaps and overlaps between the testing stages while ensuring quality of delivery.
It is possible, however, that testing at one stage may, and should, use test scripts from previous stages. Two stages of testing may be executed together, using the same scripts, but both sets of test conditions must be covered (that is, both sets of objectives must be met). All stages of testing are required. For example, a thorough assembly test cannot make up for inadequate component testing, as the objectives of each test stage are different.
d) What Other Components does the Problem Management System Interface with?
RTP has identified the following components as interfaces with the Problem Management system.
The Problem Management system can keep track of the migration date obtained from the Migration Control system.
Typically, the design repository represents the basis of the application development. It is mainly involved during the construction phase of the application and is used to centralize the application definition data. The design repository can be complex, providing impact analysis and application generation features.
In a testing environment, the design repository is a safe means of analyzing the impact of a problem on the whole application.
Having two separated systems, one for Problem Management and one for application design, duplicates the information and introduces errors. Therefore, the interaction between the design repository and the Problem Management, Test Planning, and Configuration Management components significantly increases productivity and reduces the risk of errors.
Product Considerations
a) Are there any Problem Management Tools Identified?
Problem Management tools log error information, generate error reports (such as System Investigation Reports or SIRs), classify problems, and record information on the source of the error. Problem Management tools are essential for the capture of stage containment metric information.
b) What Engagement Factors Affect the Use of Problem Management Tools?
Similarly, the larger the testing team, the more benefits will be derived from using a Test Data Management tool (easier control over the test data for the various testers), a Configuration Management tool (easier control over all system configurations and component versions) and a Test Plan Management tool (easier control over all test cycles, subcycles, their execution statuses, and so on).
System Building (8218)
System Building tools comprise the core of the development architecture and are used to design, build, and test the system. All the system building tools must be integrated and share development objects appropriately.
Analysis & Design (8128)
Analysis tools are used to specify the requirements for the system being developed. They are typically modeling and diagramming tools, which provide the ability to diagram system requirements and specify "what" a system must do.
Design tools are used to specify "how" a system will implement these system requirements. They are typically diagramming tools, which graphically depict how the system will be built in terms of its key components. This differs between classical client/server systems and component-based systems:
The standard client/server model comprises application logic, presentation, and communication components, which together support the business processes. For a client/server system, each of these components must be individually defined.
The component-based systems, however, have the data model and process models encapsulated within the object model. In addition, the design of the component model is directly affected by the business processes which govern the way these objects interact. Therefore, with component-based systems, the object and component models encapsulate the data and process models.
Data Modeling
Data Modeling tools provide a graphical depiction of the logical data requirements for the system. These tools usually support diagramming entities, relationships, and attributes of the business being modeled on an Entity-Relationship Diagram (ERD). Several techniques have evolved to support different methodologies (e.g., Chen, Gane & Sarson, and IDEF).
As systems are often built on top of legacy databases, some data modeling tools allow generation of an object model from the legacy database data model (DDL). By understanding the E-R diagram represented by the database, it is easier to create an efficient persistence framework which isolates business components from a direct access to relational databases. Caution is required, however, as the resulting model is at best only partial, as an object model has dynamic aspects to it as well as static relationships, and may not correctly reflect the analysis performed in the problem domain.
When a component or object-based approach is used, data modeling is not performed. Rather, the object model contains both the data and the behavior associated with an object. In most systems relational databases are used and the object model must be mapped to the data model. Standard mechanisms for mapping objects exist. Tools such as Persistence (Persistence Corp.) and DBTools (Rogue Wave) can generate the code necessary to map objects to a database.
Implementation Considerations
a) Can the Development Process Benefit from a DDL Generation Tool?
Data modeling tools allow DDL to be generated from the data model. The tools should support DDL generation for the chosen RDBMs (Sybase, Oracle, DB2). In addition, the DDL generator should take advantage of the specific advanced features supported by each of the RDBMs.
b) Can Developers Benefit by a Graphical Depiction of the Logical and Physical Data Requirements?
Data modeling tools help to graphically develop the logical and physical data requirements for an application. These tools depict logical constructs such as entities, attributes, and relationships between entities, along with physical constructs such as database definitions and table indices.
It is useful for developers to have read-only access to either a hard or soft copy of the data model during development. This document rapidly becomes a key discussion document in design discussions. It is useful to show tables, columns, primary keys, and foreign keys (if all of this will fit on a diagram at the same time!) in the document.
Graphical depiction is not only useful but essential to data architects, DBAs and also to application developers (the latter group is often omitted). As in most cases, a picture speaks a thousand words.
c) Is There a Need for Consistency in Data Across Applications?
Data modeling tools promote consistency in application development by defining standard names and attribute characteristics for the application data. Application developers then use the standard entity and attribute definitions across various application development initiatives. This results in a consistent definition and usage of data. For example, all applications that require customer number will use the standard name and attribute length defined in the data model. Database administrators will also use the data model to generate physical database definitions that are consistent with the application under development. Thus, the data model acts as a single source for data definition.
All applications should have data consistency that is linked back to a set of business data standards. Failure to achieve an agreed set of definitions will jeopardize the ability of the separate applications to perform as a business unit, for example, applications will not be able to share data if they are in different formats or use different code lookups. Data consistency must be agreed FUNCTIONALLY during analysis and design. Data modeling tools will help to document data definitions but they will not automatically enforce data consistency.
d) Are There More than 100 Entities in the Data Model?
At this level of complexity a dedicated data modeling tool is necessary.
Does the system incorporate object oriented methods?
Is a relational database being used to store persistent objects?
Fully normalized data models are a different view of the corresponding object models. On the one hand, the data model does not show behaviors (methods). On the other hand it does show resolving entities that are normally modeled as container objects and may be internal to an object. A data modeling tool is useful for showing how the persistent objects map to the relational database.
e) Is there a Need to Communicate the Business Data Requirements without Regard to the DBMS or Platform?
A data model is a technology-independent model of an organization's data requirements consisting of diagrams and descriptions of entity types, attribute types, relationship types, and integrity constraints. It is a flexible, non-redundant, non-constraining model. As a simplified representation of reality, it has no regard for such physical matters as how data is to be retrieved or how long it will take. The data model presents a concept of the business data in an idealized structure. It is a useful tool to communicate the scope of the project.
f) Is the System Complex and Changing?
Good data modeling requires a full understanding of the business data involved. Data modeling becomes more important as systems become more complex and sophisticated. The data structures which support such systems must be flexible and be able to accommodate change. The data model is the best means of identifying and representing these changes.
g) Is Database Design going to be Performed?
The finalized data model is used as a basis for the logical database design. The logical database design converts the finalized Project Data Model to one of four basic structures, according to which DBMS is used:
Although entity-relationship diagrams are independent of specific DBMSs or access methods, a logical database design is not. This design is highly dependent on the platform components and may need to be repeated for each location type and platform type. This process is simplified if a data model is used.
h) Does the System Interface with External Systems Having Their Own Data Definitions?
Data modeling tools allow documentation of the data in so far as it appears in the data model (and ultimately in the database). However, there is usually a significant number of other data definitions which will never appear in the database, and whose definition is different to the data model attributes. For example, most systems have interfaces to external systems, and inherit a legacy of interface files whose data definitions may differ to those on the data model, but which do logically correspond to fields on the model. These data definitions must also be documented and stored but are effectively outside the data model. The data modeling component should be used to implement procedures to address all the data definitions that affect the system.
Product Considerations
a) What is the Intended Use of the Tool?
The features required in the data modeling tool will depend on the intended use of the tool. If the tool is to be used to develop logical data models, it should support logical constructs such as entity definition, attribute definition, subtyping, and supertyping. If the tool is to be used for physical data design, it should support the physical constructs required for the targeted RDBMs, such as transforming a logical model into a physical model, database definition, index definition, and DDL generation.
b) Does an Existing Component Satisfy this Requirement?
The development architecture may already have tools that support data modeling. For example, many information management tools (repository) provide data modeling capabilities. Using a single tool for multiple functions reduces the developer learning curve and provides integration between the components of the development architecture.
c) What Other Utilities are Available with the Data Modeling Tool?
It is important to consider the various utilities available with the data modeling tools. Two such utilities include impact analysis and reporting.
Impact analysis capabilities allow the user to understand the impact of a change to the data model. Impact analysis functionality is one of the key tools used by engagement teams to assist with change management and change control activities.
Some products will also include report generators which are useful for generating data and attribute definition reports as well as ad hoc reports.
d) Does the Development Team Have any Prior Experience with Data Modeling Tools?
A data modeling tool may be chosen based upon prior experience with the tool by the client or members of the engagement team. This reduces the learning curve associated with integrating a new tool into the development environment.
e) How Well does the Data Modeling Tool Integrate with Other Development Tools?
Data modeling tools commonly integrate with the repository and with system building tools such as window painters and Application Logic Design tools. If the tool does not provide seamless integration with other components of the development environment, the engagement team can build bridges between components, or develop manual procedures in order to share information.
It is important to consider how the data modeling tool integrates with the design repository. It is important to maintain a cross-reference of the attributes on the model, with the definition of data elements in the design repository. Such data element definitions will also address non-database data definitions (e.g. external i/face files).
f) What Level of Data Modeling is Required?
During the early conceptual design, data modeling need not be very detailed. It should be a participative, team activity, and is usually very unstable. In this case, a tool such as a white board or PowerPoint will suffice.
As the design becomes more detailed, more sophisticated tools are needed. At the lowest level of detail consistency is vital and a repository-based tool can be used to ensure consistency across the data model.
g) Should the Data Modeling Tool Provide Database Design Facilities?
There are some tools which do not incorporate this feature, such as ARIS, which is strictly a data modeling tool. This may be helpful to guard against moving too far into the design during the analysis phase.
Most data modeling tools allow you to develop the database design at the same time. This has the advantage of keeping costs down as two separate tools need not be purchased, and of ensuring consistency by providing a direct interface between the two phases.
h) Does the Data Modeling Tool Support Submodeling?
Submodeling enables complex models to be broken down into smaller more manageable and understandable models while still maintaining unique object definition. This is particularly important for large teams where data modeling is divided among several teams.
i) Does the Data Modeling Tool Provide Support for a Multi-Designer Environment?
The information management component may provide the security needed in a multi-designer environment. If this is not the case then a multi-designer data modeling tool should be used. The tool may provide a central dictionary which allows design data to be shared between several designers and includes security checks to monitor any conflicts in overlapping access rights between designers.
j) Does the Tool Provide Facilities to Add Color to the Data Model?
The facility to add color to the data model is useful for communicating additional dimensions such as data ownership.
k) Is Entity Life History Required to be Documented?
The data modeling tools must support a facility for ELH modeling for entities that have their status changed by a wide range of events. Any entity which has an attribute containing the word status is a likely candidate.
l) At What Point Should Inconsistencies in the Design be Controlled?
Designs should be consistent. However, enforcing internal consistency at all times can lead to design gridlock which prevents innovation or progress. The tool should support the project decisions regarding consistency.
Process Modeling
Process modeling tools provide a graphical depiction of the business functions and processes being supported by a system. The tool(s) selected must support the modeling techniques being used in the development methodology. These include process decomposition, data flow, and process dependency.
Implementation Considerations
a) Are the Processes that the System is to Support Ill-Understood or is There Little Consensus on what These Processes Are?
Process modeling is a method for clarifying and communicating the business design of the system. The process model can provide an effective means of bringing people together, creating a shared vision of how the business is to function.
b) Do the Processes Vary from Region to Region and Need to be Standardized?
A process model provides a means of standardizing a set of similar processes which exist, for example, at different branches of the business.
c) Does the Project Include Process Re-Engineering or Process-Streamlining?
The re-engineered processes in the process model may form a basis for the systems design which is to come afterwards. Requirements and constraints for the system design can be well represented and communicated in a process model.
d) Is Process Simulation Required?
Advanced process modeling tools provide process simulation capabilities. Process simulation ensures that the process design is adequate as a basis of the functionality of the software that is to be developed.
Product Considerations
a) What Approach is to be Used for Process Modeling?
The tool may need to support the creation of business function decompositions or data flow diagrams depending on the approach used.
Data flow diagramming is used when the application has a complex or innovative workflow or if the analysis and design teams have little experience with the application.
Business function decomposition is used when the application is fairly routine and the team has extensive experience with similar applications.
b) Does Another Component Support Procedure Diagramming?
A business function decomposition diagram can be produced using a procedure diagramer.
c) Are Common Process Symbols to be Reused?
The tool should provide a facility to create custom symbols for the process flow and these should be reusable.
d) Does the Tool Support the Expected Size of the Process Model?
The process model may include hundreds or even thousands of processes. The tool should be able to support the expected size of the process model.
e) Does the Dataflow Diagramer Support Leveling of Diagrams?
Some tools allow leveling of the diagram in which a process box on a high level diagram is decomposed into multiple processes on a lower-level diagram. To ensure that the diagrams are easy to understand and that they easily convey information, it is useful to keep the diagram size to one window or one printed page. The facility to level a large diagram can help to achieve this.
j) How does the Data Flow Diagramer Support Data Stores that are Used by More than One Process?
It is often the case that processes that share a data store cannot be placed near each other on the diagram. To avoid complicating the diagram, some tools allow data stores to be depicted more than once on the diagram. The tools may provide facilities to differentiate these stores from stores that have not been duplicated in this manner.
g) Can Control Flows be Represented by the Data Flow Diagramer?
It may be necessary to depict control flows. The tool may represent these as data flows without any data elements, such as, for example, a signal from a timer function.
h) Does the Tool Support Validation of the Diagram?
To ensure that a data flow diagram is complete, each process should have at least one input and one output. Unless data stores are shared with other systems, each attribute of each data store must have at least one input flow associated with it. The tool should facilitate the identification of exceptions to these general rules.
i) Is a Detailed Process Model with Complex Processes to be Documented?
At the lowest level of a data flow diagram or a business function decomposition, there may be processes that are still too complex to be explained by a label or even a short paragraph. For example, this may be the case if complex interest rate calculations are to be performed by the process. An elementary process description may be required for each such process. The process modeling component should include tools that enable the description to be documented. The description may be formatted as plain English, structured English (resembling pseudo-code), decision tables, or as action diagrams.
Event Modeling
Event modeling tools provide graphical depiction of the events and associated responses for the system. A variety of tools and techniques can be used for event modeling, for example, word processors to develop simple textual lists of events and data flow diagramming to show events and responses.
For component-based development, event modeling or interaction sequence modeling may be performed through interaction diagrams, both at the object and component level. The event model is often used as input for test scripting.
Implementation Considerations
a) Is there a Need to Capture the Essence of how the Business Functions without becoming tangled in the current sequence of Processes?
Event modeling does not fix the sequence of processes. A process starts when a specified event occurs, and may generate other events when it has finished. Event modeling notation allows focus on what steps the process must do as opposed to "how" it sequences the steps. This form of representation is especially useful for processes that will be re-engineered, since it allows steps to be re-arranged easily.
b) Is there Some Uncertainty about the Functional Requirements or Scope of the System?
An event model represents external actions which the system must recognize and responses which the system must produce. Events express the system's perception of external activities. Therefore, event modeling allows the external environment to influence the requirements definition, rather than basing the environment on the applications structure. This approach supports the applications consistency with the workflow and other business activities and thus clearly defines the scope of the system.
c) Are the Business Requirements of the System to be Communicated to a Large Team or to the Users?
An event model represents the user requirements in concise business terms. When used in conjunction with the process model, this provides an effective means of communicating the system requirements from the business design team to the systems design team or to the users.
d) Does the Architecture Have Several Disjoint Systems that Need to Respond to the Same Business Event?
By using event modeling and a central event router architecture, interfaces to several systems can be easily and flexibly provided. Each system registers itself with the event router and indicates which business events it is interested in. Whenever an event is triggered, the router is notified. It then triggers all the applications that registered themselves as being interested in that event.
Applications can generate events as required to ensure that appropriate next steps in the process are performed after they have completed their part.
e) Is a Real-Time System to be Developed?
Real-time systems require very strict responses to events within specified time frames. Event modeling is critical to ensure that real-time systems meet this requirement.
f) Is the Extent of Change to the Business Particularly Large Such that a Detailed Requirements Model is Needed?
The requirements model (event, process, and data models) provides a clear means of depicting the system. The requirements model summarizes the relationship between events, data, and processes. It consists of the event model, the process model, and the data model. The event model is important because it details the business transactions and events enough to understand the process and data models. Event modeling tools must be provided to complete the requirements model.
Product Considerations
a) Do Other Tools Provide the Required Functionality?
Event modeling and process modeling go hand in hand and are typically provided by the same tool.
b) Are Events Triggered by Time Easy to Represent?
The modeling tools chosen should provide a means of clearly depicting events that are triggered by time e.g. the year end event.
c) Does an Existing Component Provide all the Necessary Facilities?
A flow charter is generally required to graphically depict the events. There is also a text description of the events which can be documented using a tool such as MS Word or MS PowerPoint. Entity life cycle diagrams, Event-Stimulus-Response diagrams or matrices, or Context diagrams may be required to complete the model.
d) Is the System Complex?
As the number of events increases, the complexity of the event model increases and the diagrams may need to support certain facilities such as intelligent connectors. Simple graphics packages may not suffice at this level.
Performance Modeling
The performance of a system must be analyzed as early as possible in the development process. Performance modeling tools support the analysis of performance over the network. A simple spreadsheet may be suitable in some well-known and understood environments, but dedicated performance modeling tools should be considered on any project with high transaction volumes or complex distributed architectures involving several platforms.
In the case of Internet-based applications, as the Internet is not a controlled environment, performance modeling is limited to those components within the domain of the controlled environment (i.e. up to the Internet Service Provider). However, In the case of intranet-based systems, where the environment is controlled from end-to-end, performance modeling may be performed across the entire system.
Performance modeling for components involves the analysis of the projected level of interaction between components and the level of network traffic generated by this interaction. It is important for performance reasons that communication between components is minimized, especially if these components are distributed.
Implementation Considerations
a) Is the System Complex or Heterogeneous?
A performance model ensures that performance requirements are met in a complex or heterogeneous environment. Performance is usually a critical quality requirement in such environments.
b) Does the System Involve Extensive Communication Over a Wide Area Network?
The complexity involved in designing systems over a WAN makes performance modeling tools critical to success for such systems.
c) Are There Hundreds of Users? Are There Tens of Servers?
Due to the complexity of such systems, performance modeling tools are important in ensuring performance requirements are met.
d) Do Experience and Benchmarks Indicate that There May be Difficulties in Meeting the Performance Requirements as Stated for the System?
In this case performance modeling tools are critical, since penalties may be incurred if the system does not meet the performance requirements. A performance model provides a means of deciding early on whether the system is feasible or not.
e) Is what if analysis required for future growth?
f) Is what if analysis required for alternative hardware configurations?
g) Is what if analysis required for hardware loading?
Performance modeling tools provide a means of analyzing how much future growth or what alternative hardware configurations can be sustained before the system breaks down. This component may be needed even though it is obvious that the system will meet the current performance requirements.
h) Are High Transaction Volumes or Complex Architectures Expected for the System?
Dedicated performance modeling tools should be considered for any project that involves high transaction volumes or a complex architecture with several platforms. Performance is critical for such systems and a performance model is required in order to predict and optimize that performance.
Product Considerations
a) Does a Generic Tool Such as a Spreadsheet Package Suffice as a Performance Modeling Tool?
A specialized performance modeling tool should be used when the system is complex and involves high volumes of data, or is heterogeneous.
As design progresses from high level conceptual design to detailed design, to technical design, there is a corresponding sequence of activities involved in performance modeling. As the design becomes more detailed, so does the performance model. The model may start as a simple spreadsheet and evolve into a collection of spreadsheets with many sheets in each book. As the structure and parameters become overwhelmingly complex, a dedicated modeling tool with its own data model, user interface etc. is a good investment.
A performance modeling tool should not be purchased due to a lack of understanding or inexperience of performance modeling, since the tool will not clarify the issues any more than a spreadsheet model.
b) Does the Tool Allow Empirical Data to be Fed Back into the Performance Model?
Performance modeling must be backed up with empirical data at the earliest possible stage. Initially, this will be through performance benchmarking usually using a small equivalent of the production system. The results should be fed back into the performance models to improve their accuracy. There should be a means of differentiating empirical data from estimates in the model.
Object Modeling
An object model usually contains the following deliverables:
Guidelines for creating object models can be found in the ODM MKB database.
Tools such as MS Word, MS PowerPoint, ABC Flowchart (Micrografix), may be used to produce these deliverables. Specific modeling tools do exist, however, and provide advantages such as cross referencing (for example, are all the methods used in the Interaction diagrams described in the class definitions?), automatic propagation of changes to other diagrams, generation of reports, and generation of skeleton code. However, some tools have problems with:
As well as providing the usual editing and graphical functionalities, a good modeling tool should:
The use of UML notation to represent the object model is becoming more and more common. In this case other diagrams such as Use Cases (from Ivar Jacobson) and Collaborations Diagrams complement the model.
Component Modeling
Component modeling can mean either designing components from scratch, or customizing and integrating packaged software. No specific component modeling tools exist, and current object modeling tools only offer limited support for components (e.g. for packaging related classes together). Class packages can be used to separate the object models for different components, with a separate class package(s) for the component model. This approach, however, is not enforced by current modeling tools, and requires project naming and structuring standards.
When component modeling is being performed using existing packaged software, some form of reverse engineering or importing is required from the modeling tool to capture the existing design.
During component design the partitioned component model is designed, which defines physical interfaces and locations for components. It is important for performance reasons that communication between components is minimized, especially if they are distributed.
Reuse Support
It is during analysis and design that really large savings can be obtained by reusing existing solutions. At this stage, reuse is often at the subsystem level but can extend down to the service and module level. Asset navigation tools, which permit the retrieval of reusable components, can therefore be of great value.
For a component-based or object-based solution, reuse is usually with a specific aim. It occurs at different levels and requires different types of support.
At the analysis and design stage, common classes and components are used across applications. Repository management is required that allows easy browsing and sharing of pieces of design.
During the construction phase, there may be strong interdependencies between the core classes and the components. This must be taken into account when planning the work. When classes and components are being fixed or modified, impact analysis tools are needed to see where the modified entity is being used. This is more complex than traditional systems as a veritable spider's web of dependencies between classes, components, and applications may ensue. In addition, OO features such as inheritance and polymorphism make tracking down dependencies with simple text search tools much more difficult.
In terms of tools, a class or library browser is required, which allows easy navigation and identification of candidate components and classes.
In many cases, there can be a mismatch between design and build, especially if no detailed design phase exists. This may result in the existence of two repositories. The object or component model produced in the design phase is at a higher level and gives a good introduction or overview. The actual code, however, is where developers tend to go to find out how an application really works. When this is the case, the source code can be used as the detailed design. There are tools that extract documentation (from comments in a given format) and generate HTML pages. Examples of such tools include:
The ideal situation is a single repository for analysis, design, and code, allowing developers to move from design to code and vice versa. However, most tools have proprietary repositories and their import/export facilities are not sophisticated enough to merge the two. For the moment, source code and design documentation remain two separate repositories.
It is frequently difficult to obtain specific, reliable, and complete requirements that truly express what users need. This may stem from users being unavailable or inexperienced with computer systems, or it may arise from the nature of the system under design. For example, if the system incorporates very new technology, it may be difficult for users to visualize the possibilities.
Prototyping can address this problem by simulating key user interface components, thus enabling the development team to measure the usability of the proposed system at a very early stage. The most important quality of a prototyping tool is its development speed. If prototyping can be performed in hours or days rather than weeks or months, it becomes possible to perform more iterations, which explore different options. This may lead to a much better system, given that the user's perception matures with each iteration. This, in turn, improves the quality of user input.
Very rapid, lo-fidelity prototypes (for example, paper-based) play an important role in early prototyping. Hi-fidelity prototypes, used later on in the design process, should be as close to the target system as possible, and highly detailed—even down to the characteristics of a button click (e.g. click-down image, click sound, length of click etc.). This way, everyone (including the design teams) can determine exactly what the final system should look like.
User involvement at the prototype stage is of the utmost importance—regular user reviews as the prototype evolves will ensure buy-in from the users, and avoid unpleasant surprises at later stages of development.
Caution must be taken not to raise the expectations of the users in terms of the length of time it will take for the final product to be delivered. Prototyping will deliver something that looks like it "works" very quickly. It should be clear that what is delivered is a model and not an application. Clients may expect real application functionality to be developed and delivered quickly due to the fast turnaround of the prototyping process, which will invariably not be the case.
Prototypes may also be used to prove architecture concepts (for example, to verify the flow of messages from the client to the host), to ensure that the system is not based on an architecture that is fundamentally flawed.
It is important to determine whether to carry forward and extend the prototype, or throw it away after requirements have been determined and perform technical design from scratch. Some prototyping tools offer the possibility of reusing code from the prototype. Although this is a valuable option, it is often available at the cost of slower prototype development. An interesting compromise may be to keep portions of the prototype (for example, user interface components) and rebuild other components from scratch.
In component based development, prototyping may be a valuable way of checking that component boundaries are well defined. However, this implies that the architecture must be defined at the time of prototyping.
Specific multi-platform prototyping facilities may be required when developing and deploying applications across multiple platforms.
Prototyping functionality is usually included in Integrated Development Environments (IDE).
WARNING: If the prototyping tool used is not part of the execution environment, the use of features that are difficult to implement in the target environment should be avoided. Prototypes will set user expectations, which may be difficult to meet once construction starts. Specifically, it is important to ensure that the performance of the prototype does not exceed the projected performance of the target system. If user expectations are built upon a highly-performant prototype, there is the potential of considerable disappointment when the final system is rolled out.
Implementation Considerations
a) Will the Target System Run on Multiple Platforms?
If so, it may be important to ensure that the prototype also runs on multiple platforms (particularly if the prototype is a technical prototype as well as a functional one).
b) Is Application Performance an Important Consideration?
Prototyping tools can be used to identify potential performance problems in an application. A development team can use a prototyping tool to implement a portion of an application to identify performance problems. The team can then use this information to improve designs and provide guidelines and standards for designs. Thus, prototyping leads to a better designed and more consistent end product.
c) Do the Users Have Experience with GUIs?
Prototyping tools allow engagement teams to demonstrate the look and feel of an application to the end user. The tool should be capable of providing a realistic understanding of the final application without requiring an extensive construction effort.
Prototypes can be used to interactively gather business requirements and design the application with the end user. If the tool supports interactive prototyping, changes can be quickly incorporated into the prototype and demonstrated back to the user. This is important when users are inexperienced with GUI. Prototyping the look and feel of the application and interactively gathering business requirements assist in gaining user acceptance of the system.
d) Are the System Requirements Ill Defined, Vague and Poorly Understood?
A prototype provides a means of communicating what the system is intended to do and can clarify system requirements. The prototype may become a throw-away if it becomes clear that the development style of the prototype is not conducive to a quality product. It is often more cost effective to start afresh incorporating the added understanding which was developed during the prototyping stage.
e) Are the User Requirements Vague?
It is frequently difficult to obtain specific, reliable, and complete requirements that truly express what users need. Prototyping can solve this problem by simulating key user interfacing components. User interface issues which are detected later are generally costly to change.
f) Is this a High Usage and Dedicated System, Where Throughput Matters?
If the system is to be used by dedicated people where the measure of productivity is solely the number of transactions they can get through per second, then user interface prototyping tools are important. Prototyping tools provide a means of getting to the easiest and most efficient interface. Prototyping tools facilitate selection between alternative styles of interaction and provide a means of addressing performance issues.
g) Do the Users Have a Choice of Whether or not to Use the System?
User interface prototyping tools are important since they allow developers to obtain user input early on in the GUI design process. This induces user ownership and acceptance of the system.
h) Is User Input a Criterion for Getting the System Adopted, Such as Might be the Case when a Union or Organized Labor is Involved?
By using prototyping tools to get user input, ownership and acceptance of the system is facilitated. Adoption of the system by users and ensuring that their expectations are reasonable can make the system less expensive to deploy.
i) Does the Technical Architectural Design Use New or Unfamiliar Components or does it Use a Proven System?
Prototyping the technical architecture provides an ideal way to quickly determine if the design is feasible before a major commitment is made to a design that cannot work.
j) Are Selected Parts of the System to be Piloted on the Project?
Portions of the application could be selected for design and coding in advance of the full-scale design/code effort. This will help iron out architecture issues, user design preferences, standards, designer/development training requirements, and produce quick wins for the project which can build morale for the team and client. A prototype can serve as a means of identifying the portions to be piloted.
k) Are New Team Members Likely to Join Throughout the Project?
A prototype can serve to quickly familiarize new team members with the user requirements, reducing the ramp-up time for new team members. Project team members should be familiar with the goals and use of a system in order to effectively develop an application.
l) Is the Project Management Team Unfamiliar with the Development Team they will be Working With?
Prototyping allows the project management team to judge the capabilities of a development team with whom they are unfamiliar. The prototyping effort allows some preliminary assessment of skill sets.
m) Is There Some Uncertainty about the Product to be Used in Construction?
Prototyping can allow the project team to validate the capabilities and characteristics of products which will later be used for development. Many products (PowerBuilder, Visual Basic, etc.) are marketed as being the best, but may fall short of project requirements. Use of such tools during prototyping allows some "qualification" of a product's true capabilities. Performance, compatibility with existing client infrastructure, etc., can be tested.
Use of a product during prototyping (that is early purchasing) also allows a development team to determine the quality of the technical support within the company providing the product. It also allows time to work through some of the business models of those companies (their willingness to negotiate on issues, pricing, etc.).
n) Is System Performance an Important Factor?
Prototyping and benchmarking the performance of a technical environment enables possible performance problems to be identified as early on as possible.
o) Do the Users Have Little or No Experience with the Interface Technology?
Prototyping serves as a means of introducing the users to the interface. Problems the users may have in working with the interface can be identified early on, and can be accounted for in training materials that are developed.
p) Is There a High Degree of Innovation in the Work Flow?
Prototyping allows the developers to experiment and, with input from users, come up with the best solution to a new and unproven workflow.
q) Do the Project Team and Client Fully Understand the Review and Sign-Off Process?
Prototyping allows the project team and the client to work through the issues and mechanics of the review and sign-off process prior to the intensive development phase.
Product Considerations
a) What is the purpose of the prototype deliverable?
b) Is the deliverable used to document the design of the application or provide an accurate depiction of the look and feel of the application?
An engagement team should select a prototyping tool to support the level of detail for the prototype deliverable. Initial application prototypes may use low-fidelity prototyping techniques (prototypes built using MS PowerPoint or pencil and paper, etc.) in order to document initial window designs and determine dialog flow (navigation). Some advantages of low-fidelity prototyping include little or no learning curve, lack of standardization which increases designer creativity, and ease of modification. However, this type of prototyping can not provide the user with the look and feel of the final application. High fidelity prototypes require more sophisticated tools which can provide a more realistic depiction of the application.
c) Is the prototype demonstrating the application behavior to the users?
d) Is the depiction of application behavior used in development decisions?
A prototyping tool should deliver an accurate depiction of the application including window flow and business functions. The prototyping tool should allow the display of data in a window with the look and feel of the navigation.
e) Is reusability of prototype deliverables a requirement?
i) What is the objective of the prototype?
Depending on the objectives and timing of the prototype, all or part of the prototype deliverable can be reusable during later stages of the application development process. Some projects create prototypes in the very early stages of design to demonstrate the capability of the tool and obtain user acceptance, rather than gathering business requirements and documenting design based on the requirements.
If the objective of the prototype is to document designs based upon business requirements, then prototyping tools should be chosen with reuse in mind.
g) Is the prototype used to gather business requirements?
h) Is the prototype developed during Joint Application Design (JAD) sessions with users?
The prototyping tool should be easy to use so the application designer can quickly incorporate changes to the prototype. User input should be incorporated as quickly as possible into the prototype and demonstrated back to the user. This helps to acquire user sign off on the application design and to gain acceptance of the application.
i) Does the Prototyping Tool Support Reuse?
Prototypes often represent a large investment, and in situations where a prototype is successful it should be possible to reuse the prototype in the remaining construction process.
Although prototyping tools may have the facility to provide reusable code for the system development, it is often available at the cost of having a slower prototyping tool. The reuse of code may not be a good idea since some of the design methods used for prototype development may not be suitable or desirable for application development.
Another option which is supported by some tools is that certain prototyping components can be reused e.g. window definitions. The tool selected for prototyping should allow easy transfer of the required components into the development environment.
j) Can the Prototyping Tool be Used to Design and Build the Front End?
The prototyping tool could also be the tool that will be used to design and build the front end. Using the same tool eliminates double entry of repository information and reduces the chance of errors when prototype information is transferred to the application design phase of the project.
k) Does the Prototyping Tool Support Functionality not Provided by the Construction Tool of Choice?
If the prototyping tool provides functionality not available in the construction tool then standards need to be put in place to ensure that the development team only produce the prototypes using features that can be implemented in the development environment. The amount of additional effort required to develop features that are easy to implement with the prototyping tool but which require work-arounds in the construction tool should be a consideration. Prototyping features which cannot be delivered will result in failure to meet user expectations.
Application Logic Design
Application Logic Design tools are used to graphically depict an application. These tools include application structure, module descriptions, and distribution of functions across client/server nodes.
A variety of tools and techniques can be used for Application Logic Design. Examples are structure charts, procedure diagrams (module action diagrams), and graphics packages to illustrate distribution of functions across client and server.
Application Logic Design functionality is also provided by a number of Integrated Development Environments (IDEs).
With component-based development, Application Logic Design is performed through object and component modeling. The functionality is captured in use cases, scenarios, workflows and/or operations diagrams along with interaction diagrams/sequence diagrams. These are usually produced using MS Word, MS PowerPoint, ABC Flowcharter (Micrografix), or an object modeling tool.
Implementation Considerations
a) Is There a Need for Logic Representation?
Use Application Logic Design tools to graphically depict the logic of an application. This is a common requirement on most engagements.
b) Is there Some Uncertainty about the Validity of the Business Case?
The Application Logic Design tools provide a means of confirming the complexity estimates and hence facilitate a revision of estimates before going into construction.
By confirming the validity of the complexity estimates, the business case is also confirmed. It is at this stage that the decision is made whether or not to continue with construction.
c) Is Performance Modeling Required?
Application Logic Design tools can provide a basis for performance modeling, based on the processing ability of the CPU, parallelism, and pipelining. The tools can be used to graphically depict system complexity, from which a performance model can be derived.
d) Is the Programming Team Inexperienced?
Application Logic Design tools provide a vehicle for communication from designer to programmer. This is particularly important when programmers are relatively inexperienced and need detailed guidance, which comes from the detailed design that is documented using these tools.
e) Is System Maintenance Part of the Project Definition?
Application Logic Design tools, and the designs that they contain, provide documentation of the system which will support maintenance in the long run.
If the maintenance team is very experienced, or if the system is a throw-away prototype, which will not be reused or maintained in the future, then Application Logic Design tools may not be required.
Product Considerations
a) Should the Engagement Team Build a Custom Application Logic Design Tool or Purchase an Existing One?
Engagement teams must determine whether standard design templates provided by vendors meet project needs, or if the architecture must provide custom solutions. CASE tools tend to provide standard Application Design documentation. Most custom solutions utilize word processing tools to build Application Logic Design shells for use by development teams.
b) Are Several Tools to be Used to Provide Application Logic Design Facilities?
A single tool may not provide all the facilities required. The different tools must interface with one another in order to promote consistency of the Application Logic Designs.
c) Does an Existing Tool Provide the Required Functionality?
The development team may require facilities to produce procedure diagrams, flowcharts, or pseudocode. These facilities may already be provided by existing tools, for example, pseudocode can generally be produced by an application development tool.
d) Does the Application Logic Design Tool Reflect the Close Relationship Between Application Logic and the User Interface?
In a good GUI program design, the application logic is often closely linked to the user interface. A single design document capable of capturing this relationship could serve as a key input into the programming process. Traditional tools only provide separate presentation design and application processing module design documents.
Database Design
Database design tools provide a graphical depiction of the database design for the system. They enable the developer to illustrate the tables, file structures, etc., that will be physically implemented from the logical data requirements. The tools also represent data elements, indexing, and foreign keys.
Many data design tools integrate data modeling, database design, and database construction. An integrated tool will typically generate the first-cut database design from the data model, and will generate the database definition from the database design.
With an object-based or component-based solution the data modeling task changes. In most cases, relational databases are still used, even where there are no dependencies on legacy systems. As there is an 'impedance mis-match' between an object model and a data model, a mapping activity must be undertaken. There are standard mechanisms for doing this. There are also tools on the market which allow the mapping of classes to relational tables, and which generate any necessary code to perform the database operations (e.g. Persistence, DBTools, . . . ).
There is a tendency (especially when dealing with legacy systems) to treat data models and object models the same. It is important to recognize that at best, the data model represents only the static part of the object model and does not contain any of the transient or dynamic aspects. The physical data model may also change significantly (for DB optimization), further confusing the issue.
There can be performance problems with objects mapped to a relational database. In a worst case scenario, an object can be spread across many tables, with a single select/insert for each table, and as each object is loaded one by one, the performance becomes very poor. Some tools provide lazy initialization (only loading the parts as they are needed) and caching (minimizing DB hits).
The current trend seems to be for object-relational databases, with vendors such as Oracle adding object features to their core products. Although the support provided at the moment is limited, it is likely that in future versions Java or C++ classes will be able to interface directly.
Implementation Considerations
a) Do the Design Ideas Need to be Communicated to a Large Team of Developers?
Database design tools are important where design ideas must be communicated to the development team. Where the development team exceeds ten people, this design must be formalized. Database design tools provide a graphic depiction of the database design for a system, whilst at the same time enabling the developer to illustrate tables and other structures that will be implemented physically.
b) Is System Performance a Major Consideration?
Database design tools become especially important if performance is critical, since database design contributes substantially to the overall performance of the system. Database design tools provide quantifiable performance data which is a crucial component of the overall performance model.
Database Design tools also provide a means to model I/O on devices such as hard disks, optical drives, and tapes etc. This information can be used in a performance model.
c) Does the Project Have Multiple Teams Working on Multiple Functional Domains?
The database design component is important in the case where multiple teams are working on different functional domains, since they often model different parts of the database separately and then incorporate these models at the end into one large database model. Database design tools can be used to enforce consistency of the different database designs.
d) Does the Database Include a Very Large Number of Tables and Elements?
Navigation through a large number of tables is complicated and can be simplified significantly if dedicated database design tools are used.
e) Are there Likely to be Conflicting System Requirements?
Different teams or users may have different requirements which conflict. These requirements may have to be rationally traded-off against each other. Where these requirements are performance related, the trade-off can only be rationalized on the basis of a good database model.
Product Considerations
f) Does the Product Provide the Following Features?
Many database design tools allow for database construction. Such tools may help translate a logical database design into a physical design, or they may generate Data Definition Language (DDL) code or Data Manipulation Language (DML) code. The advantage of using a tool that provides this facility is that it simplifies the transfer of design information into a physical representation and can be used to ensure consistency from design into construction of the database.
Presentation Design
Presentation design tools provide a graphical depiction of the presentation layer of the application, such as windows, dialogs, pages, navigation and reports. Tools in this category include window editors, report editors, and dialog flow (navigation) editors. Window editors enable the developer to design the windows for the application using standard GUI components. Report editors enable the developer to design the report layout interactively, placing literals and application data on the layout without specifying implementation details such as page breaks. The majority of these tools generate the associated application code required to display these components in the target system.
Dialog flow (navigation) editors enable the developer to graphically depict the flow of the windows or screens.
The Control-Action-Response (CAR) diagram is a commonly used technique for specifying the design of GUI windows. It is typically developed using a matrix or spreadsheet tool such as Microsoft Excel.
In the case of systems published on the Internet, defining the target audience is less straightforward than in traditional systems, but equally important. Having a good understanding of the intended audience will be a big advantage when thinking about user interaction with the system, and therefore, the presentation layer of the system.
Implementation Considerations
a) Does the Project want to Use a Single Tool for Prototyping and GUI Design?
Presentation design tools provide the ability to use a single tool for both prototyping and GUI design. This decreases the learning curve during design and permits components of the prototype to be reused.
b) Are user requirements clearly defined?
c) Are numerous iterations of design anticipated?
These tools make application development easier and faster through point-and-click capabilities and built-in functions. Reduction in the overall presentation layer design/development effort allows for more design iterations, and thus more chances for user feedback.
d) Has a Specific Construction Tool Been Selected for the Project?
If the tool to be used for construction is not known at design time then specific tools for presentation design are needed.
e) Is the design complex?
f) Does the design have to be presented to multiple users?
g) Do the users have conflicting interests?
h) Does the design have to be signed off?
i) Does the design have to be maintained over time?
In these cases a dedicated presentation design tool can be used to provide maintainable documentation of the presentation design which can be used to clarify and communicate issues.
Product Considerations
a) How Much does the Tool Cost?
Product components, maintenance agreements, upgrades, run-time licenses, and add-on packages should be considered.
b) Will the Design Tool be Used for Programming of Client Applications? What Programming Language is Supported?
If the design tool is used for programming, there are several features of a tool that must be considered. These features can have an impact on the productivity of programmers, performance of the applications, skill sets required, and other tools required for development. These features include:
If the development team is more than 5 people, a tool should provide support for multiple developers. This support includes features such as object check-in/check-out, a central design repository for the storage of application objects and user interface definitions, and version control. Additionally, the development team should be able to cleanly divide the application(s) into pieces that can be worked on by multiple developers.
d) If the Tool is Also Going to be Used for Application Development, how Well does the Tool Perform During Production?
Computational, network, data retrieval, and display speeds differ for products. Factors to consider are whether the application will consist of heavy data entry, transaction processing, or a large user base.
Does the product integrate with other tools and/or support other tools in the development and execution environments?
It is important to determine how well the product integrates with other design and development tools, presentation services (graphics, multi-media, etc.), data access services (databases and database API libraries), distribution services (distributed TP monitor), transmission services (SNA, HLLAPI, etc.), data dictionary, desktop applications, and programming languages for call-out/call-in. Additional consideration should be given to add-on and third-party products/enhancements such as specialized widgets, report writers and case tools.
e) Is the Tool Scalable?
The tool should be scalable to support growth in application size, users, and developers.
f) What Functions are Required in the Control Set?
At the minimum, a tool should support basic widgets (push buttons, list boxes, etc.), window styles, (multi-window, multi-document, paned-window), and menu styles, along with validation and inter-application communication. Consideration should also be given as to the extensibility of the toolset via add-ons and third party products.
g) What databases are supported?
h) What protocols are used to communicate with the database?
Important considerations include the supported databases and protocols used to communicate with the databases. The tool must support the selected database. Additionally, if database selection may change, it is important that the tool have the ability to support other databases with minimal impact on the application development. Native database interfaces tend to have better performance than open standards such as ODBC.
i) What Level of Technical Support, Documentation, and Training is Required to Ensure the Productivity of Developers?
The extent of support (on-site, phone, bulletin board, world-wide, etc.), quality of documentation, and availability and location of education/training should be considered.
j) What Type of Learning Curve is Associated with the Tool?
Developers using the product should be able to become productive quickly. Factors which reduce the learning curve include an easy to learn and intuitive interface, thorough and clear documentation, and on-line help.
k) Can the Tool be Used for Both Prototyping and GUI Design?
The ability to use a single tool for both prototyping and GUI design will reduce the development learning curve. Tool integration with all other development tools should also be considered.
l) What Platform(s) are Supported?
The platform(s) that must be supported, i.e., MS-DOS, Windows, IBM OS/2, UNIX, or UNIX Motif, are an important consideration, as are any hardware restrictions.
m) Is there a Need for Consistency Across Multiple Screens or Windows?
Some presentation design tools provide the facility for reuse of elements. This can be used to enforce consistency across multiple screens and can accelerate development. This feature is not available in low-end presentation design tools, such as MS PowerPoint.
One means of ensuring reuse is for the tool to support a central library of predefined widgets or screen elements. This library should be extendible and customizable, allowing developers to create new widget/element definitions or to enhance existing ones.
n) Is Multi-Language Support a Consideration?
Special characters, differences in field lengths, and differences in number formats are some of the things that contribute to the complexity of a multi-language application. Window and report design are among the areas affected by differences in the language used for presentation.
Strategies on how windows are displayed are affected if multi-language support is a requirement. Are separate windows painted for each language or are window literals dynamically replaced? The former will produce windows that are more visually appealing but requires more significant effort to create and maintain.
The presentation design tools should facilitate documentation of these differences for design purposes and allow the design strategies to be implemented.
o) Is the Tool Integrated with the Repository of Choice?
The presentation design tools should be tightly integrated with the system components stored in the repository, such as windows, reports, screens, and other more abstract models to ensure consistency.
p) Is a Multi-Media Application to be Developed?
Touch screen hotspots, video clips, hypertext, pointer device hotspots and other similar design objects must be supported by the presentation design tool if the design is for a multimedia application.
Communication Design
An increasingly important aspect of system design is communication design. After the fundamental communication paradigms have been chosen, each exchange must be designed to allow for the detailed design of each module (clients, services, functions), and to lay the basis for more refined performance modeling. To ensure against interface problems, these tools should be tightly integrated with the design repository. One simple way to document communication interfaces is to define include files, which hold the interface definitions.
Implementation Considerations
a) Is Performance Simulation or Modeling Required?
Thorough performance simulation or modeling requires a communication model. A performance model is particularly important if the system is large, heterogeneous, and complex.
A valid performance model can only be created once a detailed communication design has been developed for the system. The performance model is derived from the detailed communication design. Communication design tools provide a means of documenting the physical design of the system, such as protocol stacks, message sizes, routers, bridges, gateways, LANs, WANs, MANs, etc. as well as the logical design, both of which are used to develop the performance model and to simulate performance.
b) Is the system migrating from a central to a distributed environment?
c) Is the system migrating from a LAN to a WAN environment?
d) Is the system migrating from a country wide WAN to a global network?
When development takes place in a mainframe environment, performance is relatively predictable. In a distributed environment, response time is dependent on the communication design.
Migrating from a LAN to a WAN, or from a WAN to a global network will drastically impact the performance of the system, and this type of migration requires the development of a complete communication design from which a performance model can be derived. Thus, tools to facilitate the communication design become a critical part of the development architecture when migration of this sort is involved.
e) Is High Network Performance Required?
Communication design tools are essential in developing systems where critical business operations have to have maximum availability and minimum down time. One of the primary contributing factors to high performance in client/server environments is a good network design. A good network design can only be achieved through a good communication design.
Product Considerations
a) Is the Tool Repository Based?
The best support for detailed communication design for a large development team is provided by a repository. Here the messages, calls, and queries can be modeled and designed as entities in their own right. These entities provide a necessary basis for performance and module design, which can be shared by all developers.
b) Is there a Need for a Graphical Depiction of the Communication Design?
A graphical depiction of the communication design may be required. For simple designs, tools such as PowerPoint are normally adequate. Data flow diagrams may be used to show how clients send messages to services. The tools used should help developers to ensure that objects in the diagrams are linked to the actual objects (Windows, Services, etc.) in the repository. This will maintain consistency of the design documentation with the actual objects used in development.
c) Do Existing Tools Provide the Necessary Functionality Required to Produce the Communication Design for the Project?
A simple and effective method of defining interfaces is by using include files to hold the interface definitions. The application development tools usually provide this facility.
A spreadsheet package such as Excel may also be used to design message layouts.
For simple graphical depictions of the communication design, a tool such as PowerPoint is adequate.
d) Does the Tool Encapsulate Knowledge of the Services Provided by the Middleware Layer?
The middleware layer provides the basic functions for applications in a heterogeneous environment to interface with operating systems, networks and communication protocols.
If the tools used encapsulate knowledge of the middleware services, low level design of communication (e.g. designing at the level of named pipes and sockets) need not be supported or investigated. The middleware component abstracts this level of detail so that the designers need not concern themselves with complex technical issues.
Usability Test
From a development perspective, systems that are designed and tested with usability in mind offer clear advantages. This is providing Usability Testing is executed from the user perspective, and from the very beginning of the development process.
Usability Testing can help developers:
Each system is designed to meet the unique requirements of its users, and therefore benefits from a different mix of testing techniques. In many cases, designers find that the best starting point is to build and test low-fidelity prototypes. These are paper-and-pencil versions of user interfaces that allow developers to demonstrate the behavior of systems very early in development. Before any code has been written, developers build prototypes on paper and test them with real users, simulating the human-computer interaction. Designs are adjusted and retested several times until a usable solution emerges. When it is time to begin coding, developers already have an excellent idea of how the system should work and what the users want.
Once the user interface has been coded, the high-fidelity prototype is ready for online usability testing. The test results are compared with previous tests and routed back to the developers. If lo-fi prototypes were used earlier, the major design issues have already been resolved. Refinements at the "hi-fi" stage should focus on perfecting the details.
In the later stages of development, usability laboratories can be extremely helpful for evaluating system design. Usability labs, which can be stationery or portable, rely on videotape and screen capture methods to record how users interact with prototype systems. Within a few hours of testing, lab administrators can create a highlights videotape of problems that users encountered. These tapes can be used immediately by developers and project managers to modify the hi-fi prototype as required. The average usability test results in 70 to 100 specific recommendations for improvement.
Remote testing, or telecasting, is an online variation of the usability lab. This still-emerging method relies on computer networks to conduct system evaluations. Remote testing enables developers to test a large number of users efficiently and without incurring travel expenses.
Reverse Engineering (8130)
Reverse engineering tools are used to capture specific, relevant functional and design information from a legacy system for use in a new, client/server system or to restructure the existing system for improved performance and maintenance.
Interactive Navigation
Developers use interactive navigation tools to identify requirements for a new system from the functionality and design of a legacy system. These tools enable the developer to interactively and graphically navigate the legacy system, determining the system's characteristics such as system structure, module flow, flow control, calling patterns, complexity, and data and variable usage. An alternate form of presentation is through reports. These provide cross-reference listings or graphical representations of control or data flows.
Graphical Representation
Graphical representation tools are used to display important system information in a form, which is easier to assimilate. These tools may, for example, produce structure charts, database schema diagrams, and data layouts. They can also print matrices that indicate relationships between modules and files or between jobs and programs.
An extraction tool, in conjunction with a repository population tool, enables the developer to reuse selected portions of a legacy system. The extraction tool can typically read and extract information from source code, screens, reports, and the database. The most common information extracted from a legacy system, however, is the data: record/table structure, indexes, and data element definitions.
In component-based architectures, as systems are often built on top of legacy databases, some extraction tools allow generation of an object model from the legacy database data model (DDL). By understanding the E-R diagram represented by the database, it is easier to create an efficient persistence framework which isolates business components from a direct access to relational databases. Caution is required, however, as the resulting model is at best only partial, as an object model has dynamic aspects to it as well as static relationships, and may not correctly reflect the analysis performed in the problem domain.
Repository Population
The repository population tool is used to load the information from the extraction tool into the development repository. These tools convert the information from the legacy system into the syntax of the development tools repository. The extent of the information loaded into the repository is a function of the Information Model of the development tool repository. Information that is not represented in the development tool repository cannot be loaded into the repository.
Restructuring tools are not analysis tools like the previous categories of reverse engineering tools, but design and construction tools. They enable the developer to rebuild a legacy system, rather than replace it. Examples of this type of process include restructuring spaghetti code with structured code, replacing GOTO's, streamlining the module calling structure, and identifying and eliminating dead code.
Data Name Rationalization
Data name rationalization tools extract information on variable usage and naming, and show relationships between variables. Based on these relationships and user input, these tools can then apply uniform naming standards throughout the system.
Packaged Component Integration (8132)
Packaged components are generally third party components that provide ready-made business logic that is customizable and reusable. These can range from simple components offering limited functionality (for example, worksheet or charting GUI components), to components that handle a significant portion of the application architecture (for example, data access components and firewalls). The advantage of using such components is that they have already been coded, tested, optimized, and documented.
The fact that these components come from third-party software houses does not always guarantee their quality. In order to minimize the dependency of the final system on these components (thus reducing the impact of possible changes within the libraries), it is recommended that wrappers are written to enclose any third-party components. This way, if any changes are made to the internals of the components, only the wrappers would be affected, allowing the application and architecture code to remain unchanged.
Frameworks may be found on the market which provide generic components for general business processes such as general ledger, sales order processing, inventory management or product distribution. For example, IBM San Francisco offers business components for the Java environment (see "ibm.com/Java/Sanfrancisco").
Product Considerations
a) Does the Component Require Significant Customization?
When selecting components, it is important to get as close a match as possible to the functionality that is required.
b) Will the Vendor Guarantee Required Functional Enhancements?
If functionality is missing from a component that cannot be added using the standard customization tools provided, it is vital to get a vendor guarantee that the enhancements will be made, and to agree on a deadline for these enhancements.
c) Will the Vendor Guarantee Consistency of all Interfaces Across Future Releases?
The biggest danger in using packaged components is that the vendor will make changes to the component interfaces. When selecting packaged components make sure the vendor guarantees backwards compatibility of all the existing interfaces provided by the component. If this is not the case, it will entail much reworking of the application code in order to be able to take advantage of (potentially important) upgrades to the component.
d) What are the Performance Implications of Using a Packaged Component?
Components are often developed with a preferred platform in mind. Components optimized for one platform may have severe performance problems on others. If performance is a factor (and it nearly always is) ensure that components are designed specifically for the platform of the target system.
e) Does the Component Provide Standard or Proprietary Interfaces?
When choosing between packaged components, always choose standard interfaces over proprietary ones. It will always be easier to customize and interface a component whose language is known to the development team, rather than one which requires developers to learn a new proprietary language.
Packaged components usually do not provide the exact functionality that is required of the target system because they are created by third parties. They may have to be configured in order to behave in the desired fashion. The majority of packaged components allow one of two methods of customization—either by using standard construction tools (such as an editor and a C compiler), or by using proprietary toolkits provided by the vendor.
Implementation Considerations
a) What Level of Support is Provided by the Component Vendor?
It is vital that the vendor provides an appropriate level of support for the component such as documentation, telephone support, remote support, training, and onsite support. It might also be necessary to include vendor developers on the Application team. This is especially important where component customization relies on proprietary toolkits.
Construction (8134)
Construction tools are used to program or build the application: client and server source code, windows, reports, and database. Along with the onset of Visual Programming, the more traditional form of construction tools have been superceded by Integrated Development Environments (IDEs) which take all the basic components required for construction, and integrate them into a single system. Although IDEs are now the preferred tools for most construction, the components that make up these tools remain the same—Source Code Editor, Compiler/Linker/Interpreter, Generation Tools and Debugging Tools.
Visual Programming tools, initially associated with the rapid development of the client-side of client/server applications, have now matured and expanded their domain to cover entire client/server development (e.g. Visual C++) and Netcentric development (e.g. visual Java IDEs).
IMPORTANT: While IDEs provide the basic components for construction, not all the functionality offered by the components listed here is provided (for example IDEs do not generally provide Help text generation or DDL generation). IDEs can usually be customized in a way that other tools (Version Control, Generation, Repository Access etc.) can be integrated. It is necessary to plan time for this upfront. It should not be left to the developers to do this individually.
In addition to the standard construction components, a new set of utilities exist which can help increase the quality of code generated by developers. QA Utilities verify the quality of constructed code, and its conformance to standards set down for the development environment.
It is important to ensure that developers use tools that are standard to the development environment. Now that Internet access is a standard facility for developers, there may be the tendency for people to download their own preferred tools, or upgrades to standard tools. This not only affects the management of the development environment, but could easily result in the generation of code that is incompatible with the rest of the code in the development system (for example, consider the effect of developers on the same team using tools which employ different version of the JDK).
Product Considerations
a) What Size is the Development Team?
When IDEs were first developed, they were targeted at individual developers. This means that support for team development is still not fully mature in the majority of IDEs, although some are closely integrated with third-party configuration management packages. When selecting an IDE it is important to ensure that team development is sufficiently catered for.
b) On what platform is the system expected to run?
c) Is the target system expected to run on multiple platforms?
The construction tools selected must be able to support the target platform(s) of the system to be developed.
Source Code Editor
A source code editor is used to enter and edit source code for the application. Complexity varies from simple ASCII text editors to fully integrated editors such as those provided by Integrated Development Environments. Typically however, they are linked with a debugger so that coding errors which are identified during compilation can be more easily corrected, since the error and the source code generating the error can be viewed simultaneously.
Other features include:
On the whole, these features will help ensure that code developed by the team is following project standards as opposed to individual programming styles.
Implementation Considerations
a) Web-Based Development
Product Considerations
a) How Well Integrated is the Editor with Other Tools in the Development Environment?
The level of integration with the rest of the environment is an important consideration when selecting a source code editor. Most editors now come as part of an IDE, and are therefore fully integrated.
b) Does the Editor Support Multiple Languages?
Some IDEs provide support for many languages using the same interface (for example, MS Developer Studio supports C, C++, Java, Fortran). This has the advantage of providing the user with a common approach to coding, regardless of the language being used.
c) What Features are Provided by the Editor?
As mentioned in the component description, many features may be provided by the editor, which can save time and improve code quality. A feature-rich editor is therefore often worth the investment.
d) Is the Product Easy to Learn and Use?
The source code editor should be easy to use with little or no training required.
e) Is an Acceptable Source Code Editor Already Provided by the Operating System or Other Tools in the Development Environment?
Most Development tools and operating systems already include a source code editor. These source code editors are usually just simple text editors.
f) What is the Amount of the Application Code?
Some source code editors may not have the ability to handle extremely large files while other tools are built specifically for that purpose.
This component is responsible for taking raw code (usually in ASCII format) and creating the necessary object, library, byte-code, or executable files that become components of the final system. The actual tools required depend on the development language, but always consist of one or a combination of the following components:
In the majority of Integrated Development Environments, the Compiler, Linker and/or Interpreter are included as an integral part of the system. In addition, the management of compilation and linking is automated using MAKE utilities which understand the dependencies between modules in the system. This allows the system to trigger all necessary re-compilation and re-linking when a module in the system is changed, thus avoiding the time consuming task of re-compiling and re-linking the entire system.
Product Considerations
a) Is the Tool Easy to Use?
The tool should be relatively easy to use in order to reduce the learning curve.
b) Does the Tool Support the Platform in the Development Environment?
The compiler/linker/interpreter tool must be compatible with all the platforms upon which the application is being developed. Besides compatibility, tool performance may be platform dependent.
Source Code Debugger
A source code debugger is a tool used to unit test a program. This tool provides information about the activity of programs and systems, enabling automatic analysis and diagramming, assisted code tracing, editing capabilities, and automatic documentation. The debugger allows the developer to enter program break points and step through a program, tracking the progress of execution and identifying errors interactively. It is typically used in conjunction with the source code editor so that coding errors identified can be more easily corrected, since the error and the source code generating the error can be viewed simultaneously.
Symbolic source code enables easier identification of where errors occur. Preferably, the debugger should be flexible enough to work with any combination of compiled modules and source modules. In addition, the debugger should be able to handle calls to the database and to other modules.
Product Considerations
a) What Testing Team Factors Should be Considered when Using a Source Code Debugging Tool?
Communication Between Development Team and Testing Team
A code analysis tool can help the testing team detect unreported changes in the application code, and therefore help alleviate possible bad communications between the development and testing teams. Thus, bad communications between teams will still influence positively the decision to use code analysis tools.
Generation tools include:
Shell generation is the process of generating a starting point for programming. Shell generation is typically repository-based but can also be based on interaction with the programmer, where the generation utility requests key information about the program, and generates a starting point as a result of this. Key information (whether obtained from the repository or through a dialog with the programmer) may include:
Based on this information, the generator selects the appropriate include files and creates skeleton code which may be used as a template for the programmer. This template may also include audit history for the module and standard code such as error handling.
Make File Generation is Integrated into the Majority of Ides
Window/page generation (which is an integral component of Visual programming tools) allows the developer to rapidly design windows and pages using a point and click graphical interface. The relevant source code is subsequently generated from these designs.
The generation of DDL and DML is often hidden from the developer by using data access functions or objects, provided by a large proportion of IDEs (e.g. MFC, JDK).
Help text and module description generation (not usually provided by IDEs) analyzes developer's raw code (including comments) and creates descriptions which may be used by developers to understand the contents of modules or objects. This is particularly useful for component-based development, where methods and attributes of objects may be automatically documented.
Trace code generation allows the insertion of traces into raw code in order to aid debugging.
Implementation Considerations
a) Does the project want to isolate developers from the technical environment as much as possible?
b) Are there a large number of developers which makes it difficult to enforce standards and consistency among developers?
Generators are typically used to enforce and maintain consistency throughout an application. The main benefit is a reduction in training. In addition, the code generated will automatically be checked for errors, shielding the developers from many complexities of the technical environment.
c) Are there a large number of developers or a large amount of code?
d) Can significant time be saved by creating generators to generate code for reuse and regenerated code to propagate changes?
Generators are used to leverage the powers of code reuse and code regeneration. The ability to reuse code reduces both the time and resources required on a project. Code regeneration eases maintenance issues by propagating changes throughout multiple sections of code.
Product Considerations
a) Can the Generation Tool Provide Code which Meets Performance Requirements?
The code/applications generated by the tools vary in performance. Optimized code usually results in faster run times. It is important to identify the high priority components that will benefit most from the tool.
b) Should the Engagement Team Build a Custom Generation Tool or Purchase an Existing One?
The decision to custom build or to buy available case tools must be determined by the development team. Most generators are usually custom built because often the technical environment and architecture have custom components that cannot be handled by a package generator. Associated with custom building are the issues of added cost and development time, but performance can be closely monitored and changes performed on the spot.
c) Does the Generation Tool Support the Development and Execution Platforms?
The tool must support the current or proposed platform.
QA Utilities
QA Utilities verify the quality of completed code, and that it conforms to project and international standards. These types of tools include the following:
Code and Object libraries provide the developer with ready-made components (such as GUI components or simple utilities), which may be integrated into architecture or application code. The advantage of using such components is that they have already been coded, tested, optimized, and documented.
Code and Object libraries may be differentiated from packaged components in two ways:
That these libraries come from third-party software houses does not always guarantee their quality. In order minimize the dependency of the final system on these components (thus reducing the impact of possible changes within the libraries), it is recommended that wrappers are written to enclose any third-party code. This way, if any changes are made to the libraries, only the wrappers would be impacted, allowing the application and architecture code to remain unchanged.
Implementation Considerations
a) Does the Object/Library Really Need to be Wrapped?
It may not always be prudent to wrap all third party objects/code that are to be used on a project. Sometimes the cost involved may outweigh the value of wrapping an object/code. As objects/code become more complex, with more functions/interfaces, then the value of wrapping them becomes more tangible.
Media Content Creation
As systems become increasingly user-facing, it is important to design user interfaces that are not only functional, but also engaging and informative. This is especially true of Internet and kiosk-based systems, where users have a notoriously short concentration span.
This requirement for more attractive user interfaces has triggered the evolution of media-rich applications, the development of which requires new tools and processes, and brings with it a whole new set of issues.
Media content can be broken down into three major media types, each with its own set of tools:
Tools to handle these images range from simple paint packages to highly complex multi-layered animation graphics packages. The images created by these tools may be pixel-based (bitmaps) or vector-based, each with their own advantages.
The high cost and complexity of video production equipment, along with the skills required to manage the process of video production mean that it is usually outsourced to a third party. It is important however that the personnel charged with creating video content are an integral part of the Application team.
The tools required for creating audio content depend on the quality required, and whether or not the content is original. For 'sound bites' or pre-recorded audio, simple desktop audio editing applications are adequate. For high-quality original content, a professional recording studio is recommended. Again, if third parties are involved, it is important that they are fully integrated into the team.
For both image and audio, it is possible to purchase re-usable content from agencies, usually delivered in the form of CD-ROMs.
NOTE: Tools required to store and manage media content (and storage formats) are discussed in Tools-Information Management-Media Content Management.
Test (8136)
Testing applications (client/server or Netcentric) remains a complex task because of the large number of integrated components involved (for example, multiplatform clients, multiplatform servers, multitiered applications, communications, distributed processing, and data), which, in turn, results in a large number and variety of Testing tools.
For any large scale testing effort, it is vital to have a repository that is capable of managing the data required by each of the test subcomponents. The repository should manage the following entities:
Within the repository, the following relationships between entities must also be managed:
These relationships make it possible to analyze efficiently the impacts of change and to document the state of system test. For example, the number of outstanding SIRs per cycle can easily be provided based on these relationships.
In some cases, the mentioned entities and relationships cannot be managed within the repository, and may have to be modeled outside the repository (for example, in a teamware database). In this case, the link between the repository and the external tools must be provided by a judiciously chosen set of procedures and custom integration tools.
Component-based development may have an impact on the way in which testing should be performed.
A number of firm initiatives have conducted considerable research into the field of testing:
Vendor tools are more appropriate when the requirements are totally dependent on the software development platform. Moreover, when the technology evolves too quickly, it requires a software organization to handle the changes.
Test Data Management
Test Data Management tools allow developers to create and maintain input data and expected results associated with a test plan. They include test data and archiving tools that assist in switching between cycles and repeating a cycle based on the original data created for that cycle.
Test Data Management functionality may be provided by the following tools:
To minimize testing errors when creating component and assembly test data, follow the guidelines provided by the AC Methods job aid for quality test data. Follow the doclink to view the Tester's View of the Methods.
Product Considerations
a) What Testing Team Factors Should be Considered when Using a Test Data Management Tool?
Size of the Testing Team
The larger the testing team, the more benefits will be derived from using a Test Data Management tool (easier control over the test data for the various testers), a configuration management tool (easier control over all system configurations and component versions), and a test plan management tool (easier control over all test cycles, subcycles, their execution statuses, and so on).
b) What Engagement Factors Affect the Use of Test Data Management Tools?
Risk Rating of the Engagement
In general, management and planning tools help better address the engagement risks. A high risk rating for the engagement will affect positively the decision to use tools such as test planning, Test Data Management, problem management, and configuration management.
Criticality of the Engagement
In general, management and planning tools help better manage the engagement and ensure the timely delivery of a quality system. Therefore, dealing with a highly critical engagement will most likely affect positively the decision to use tools such as test planning, Test Data Management, problem management, and configuration management.
Test Data Manipulation
Test Data Manipulation tools are used to create original test data and, sometimes, to modify existing test data. Such modifications may be needed to process a change in the database schema and to correct intermediate results in order to complete a test cycle. Some test data manipulation tools generate test data very effectively.
Test Planning
A Test Plan consists of several components:
Test Planning definition and maintenance tools define and maintain the relationship between components of a Test Plan.
Implementation Considerations
a) What Guidelines Should be Followed when Assembly Testing the Technology Architecture?
When deciding which areas of the technology architecture to test, follow the guidelines provided by the AC Methods job aid for technology architecture assembly testing. To view the guidelines, follow this doclink to the AC Methods job aid.
b) What Guidelines Should be Followed when Creating Test Scripts?
When preparing to test system components, scripts can be used to verify that the system design specifications are properly implemented. An AC Methods job aid provides guidelines for creating product test scripts.
c) What Guidelines Should be Followed when Creating Test Cases for the Component Test?
When preparing component test data, the AC Methods checklist helps ensure that all cases are thought up so that component testing is complete. To view the test case checklist follow the doclink.
d) What Components Interface with the Test Planning Component?
The following components interface with the Test Planning component:
The following is an overview of the repeatable test model as documented by the Reinventing Testing Project (RTP).
A repeatable test model consists of tests that can be easily executed by staff who have little or no experience of the application being tested. A repeatable test script provides the detailed steps necessary to test the functionality. In addition, the script provides the tester with detailed expected results to verify the operation of the test script.
In order to plan detailed script steps and expected results, it is necessary to know the test data. A large portion of the test data will typically be contained in test databases. These databases are called baseline databases, and are critical for a repeatable test model to exist. Baseline databases can be developed automatically (through execution of online activity in the system), manually (through test data manipulation tools), extracted from production databases, and so on. Once the baseline databases are selected and created, the repeatable test model can be developed. As the test model is based upon these databases, the impact on the test model of any changes to the baseline databases must be analyzed.
With a repeatable test model, most of the team members' knowledge is captured in the tests. Retention of team members is therefore far less critical than with a non-repeatable test model, and expected costs of training new team members are reduced.
If the application does not change, repeating the tests yields the same results every time, given the same baseline databases. To remain repeatable, a test model must be maintained to reflect changes made to the application (fixes, isolated enhancements, new releases, and so on).
To ensure the quality of the application as well as testing efficiency and effectiveness over time, the tests contained in the test model must be repeatable. Automation facilitates the engagement's ability to execute a repeatable test model. The decision to automate the test execution only affects whether the tests will be repeated manually or automatically.
Automating the execution of a non-repeatable test model is a waste of resources, as the test tool will not be able to re-execute the tests automatically or perform full regression tests with little effort. Little or no benefits will be achieved from automation.
Product Considerations
a) Has RTP (Reinventing Testing Project) developed a test plan management system?
b) What tools can be used for problem tracking?
The RTP Tools Development team has documented their evaluation summaries of the internal test plan management system. The following is a brief description of the product. To view more detailed information, follow this doclink to the RTP Tools Initiative document.
The Test Plan Management System is an online GUI application that is used to facilitate the creation and maintenance of test models and to support the planning and performing of each test stage. Each test model is stored in a central repository accessible by all team members.
Any test model data must be manually entered in the system or copied from a previously entered test model.
Multiple test models can be accessed or viewed at one time.
In addition, the TPMS provides the capability to research previously entered test elements through online queries.
A reporting option is planned to produce metrics and management type reports.
c) What Testing Team Factors Should be Considered when Using a Test Planning Tool?
Size of the Testing Team
The larger the testing team, the more benefits will be derived from using a Test Data Management tool (easier control over the test data for the various testers), a Configuration Management tool (easier control over all system configurations and component versions), and a Test Plan Management tool (easier control over all test cycles, subcycles, their operating statuses, and so on).
d) What Engagement Factors Affect the Use of Test Planning Tools?
Risk Rating of the Engagement
In general, management and planning tools help better address the engagement risks. A high risk rating for the engagement will affect positively the decision to use tools such as Test Planning, test data management, problem management, and configuration management.
Criticality of the Engagement
In general, management and planning tools help better manage the engagement and ensure the timely delivery of a quality system. Therefore, dealing with a highly critical engagement will most likely affect positively the decision to use tools such as Test Planning, test data management, problem management, and configuration management.
e) What Application Factors Should be Considered when Using a Test Planning Tool?
Starting Point of Automation in the Development Life Cycle
If the testing process is to include the use of a test plan management tool, test model components may be more easily reused across test stages resulting in time and cost savings during Test Planning and preparation. This obviously has a positive influence on the decision to use the test plan management tool.
Test Execution
Test Execution tools support and automate the conduct of system tests. Test Execution support includes the tools required to:
Such tools include dynamic analyzers and execution logs. The Test Execution platform may differ from the development platform if development is conducted in one environment (for example, Windows NT workstations) and deployed on a different environment (UNIX workstations).
A typical Test Execution tool supports test scripting and playback. These tools program or record the running of a test plan in an online environment by capturing key stroke sequences, mouse clicks, and other actions. They then record them in a script. Once the script is programmed or recorded, it can run repeatedly on the same application, effectively emulating the user. While defining the script takes some time, it saves tremendous effort when cycles must be re-run, particularly after relatively small changes (for example, the format of an output field is modified). When the application is modified, the script can be updated directly without re-entering long sequences of user input. This makes it easier to prepare for regression testing. Scripts may also be used for stress testing, where a single machine can run scripts simultaneously, emulating large numbers of users.
Implementation Considerations
a) What Development Approach Factors Should be Considered when Automating Test Execution ?
Reinventing Testing Project (RTP) has identified the following factors that either contribute to or take away from the successful implementation of an automated Test Execution tool. Further detail is available through RTP's Test Automation Strategy—Version 1.1: The type of system development approach to be considered is:
RTP has identified the following factors that will either contribute to or take away from the successful implementation of an automated Test Execution tool. Further detail is available through RTP's Test Automation Strategy—Version 1.1. Testing tool factors to be considered include:
RTP has identified the following factors that will either contribute to or take away from the successful implementation of an automated Test Execution tool. Further detail is available through RTP's Test Automation Strategy—Version 1.1. Engagement factors to be considered include:
RTP has identified the following factors that will either contribute to or take away from the successful implementation of an automated Test Execution tool. Further detail is available through RTP's Test Automation Strategy—Version 1.1. Application factors to be considered include:
RTP has identified the following factors that will either contribute to or take away from the successful implementation of an automated Test Execution tool. Further detail is available through RTP's Test Automation Strategy—Version 1.1. Testing team factors to be considered include:
Performance Management tools support application performance testing. Owing to the large number of components in modern systems, performance modeling can be a complex task and requires tools to effectively manage the process. These tools monitor the real-time execution and performance of software. They help to maximize transactions and response time to the end user. They are also useful in identifying potential bottlenecks or processing anomalies.
In the case of Internet-based applications, as the Internet is not a controlled environment, performance management tools can only measure performance within the domain of the controlled environment (up to the Internet Service Provider). However, in the case of intranet-based systems, where the environment is controlled from end-to-end, Performance Management may be performed across the entire system.
Emulation tools emulate components that are part of the target environment but are not in the development environment. These emulation tools include:
Test Result Comparison tools are utilities used to compare expected and actual results. These tools outline the differences between actual and expected results by comparing files and databases. Most of these tools offer functionality such as byte-by-byte comparison of files and the ability to mask certain fields such as date and time.
Test Coverage Measurement
Test Coverage Measurement tools are used to analyze which parts of each module are used during the test. Coverage analyzing tools are active during program operation and provide comprehensive information about how many times each logic path within the program is run. This Test Management and Quality Management tool ensures that all components of an application are tested, and its use is a vital and often overlooked component of the test process.
SIR Management
SIR Management Tools help track each system investigation request from problem detection through documentation resolution.
Operations Architecture Framework (9300)
Operations Architecture
The Operations Architecture is a combination of tools, support services, procedures, and controls required to keep a production system up and running efficiently. Unlike the Execution and Development Architectures, its primary users are the system administrators and the production support personnel.
The following databases provide information on the Operations Architecture and list requirements and current tools solutions for the managing of the various Operations Architecture areas. All areas of the Operations Architecture have the appropriate MODE sub-functions listed, along with requirements for management solutions and current tools that assist and automate management solutions.
Cautions and Caveats
Unlike the Application and Execution Architectures, every function of the Operations Architecture must be reviewed. All components of the Operations Architecture are integral to the successful management of a distributed environment. Any processes, procedures, or tools developed or chosen as an operational management solution for a specific operational area must be able to integrate with any existing or planned process, procedure, tool solutions for other Operations Architecture areas.
While the tools data and suite information was current and accurate at the time of publication of this document, there is no guarantee that that information is still accurate, or that the vendor is still in business. It is imperative that the following actions are taken when choosing a tool-based solution:
Some key design decisions are specific to the design of certain functions, while others apply more generically across every function. This section presents the generic key design questions. Key design decisions that relate specifically to a function are presented in each of the subsequent functional grouping chapters.
The following generic decisions impact need for specific components:
When and how Frequently, does the Function Need to be Performed?
The timing and frequency of each function may have an effect on its staffing, the tool(s) required, the capacity of systems and networks needed to support the tools.
Who Will be Performing the Function?
Responsibilities need to be defined for each function, as the set up tasks will differ dramatically depending on whether the function is to be performed in-house or outsourced. In addition, the individuals who will be performing the function should be involved in the design of how the function will be performed.
Will the Function be Centralized or Distributed?
Central control will mean a stronger focus on remote management, with skills focused in one place, whereas distributed control will mean skills will need to be more widely dispersed. Distributed functions may require less powerful tools due to their placement.
Will the Solution be Manual or Automated?
A number of functions could be managed manually, especially if the functions are not directly related to the systems, or are performed infrequently. Many of the functions, however, require an interface to the systems, or involve large volumes of data.
Is Integration with any Existing Systems Required?
If integration with existing systems is necessary, hooks may need to be built into both the existing and new systems.
What are the Data Sharing Requirements with Other Functions?
Integration between functions will either require a tool capable of supporting both functions, or hooks between tools.
What are the Expected Data/Transaction Volumes, and how Much Historical Data Will be Required?
Volumes of data, both real-time and historical, will have an impact on both system and network sizing.
What Platform/Protocol Constraints Exist?
Platforms and protocols are central both to the overall approach as well as the selection of tools to support the individual functions.
Is the Intention to Use Tools or to Custom Develop Some or all of the Functions?
The choice of tools in the marketplace is increasing, but custom development may still be required. This decision will impact how the function is established initially as well as its ongoing support and maintenance.
Will Existing Data/Databases be Used, or Will Data be Built from Scratch?
Many of the functions may already exist within the clients environment. As such, data which is necessary for supporting the system may already exist. If so, it must be determined whether or not the existing data can be used, either in its original or a converted state.
General Product Selection Considerations
It is important to note that there may be requirements which cannot be met by any tools. In this case, in-house development may be an alternative. This approach is likely to be more expensive, however, and more difficult to support the long term, and thus should usually be avoided if possible. Where possible, the tool with the closest match should be purchased, and customized to meet the necessary requirements.
Some additional considerations are outlined below:
Central vs. Distributed Control
The answer to this question may limit the selection of tools as not all tools are capable of controlling functions remotely. If control is centralized, technical expertise at distributed sites will not be necessary. This may, however, mean that a more complex, expensive tool is required.
If control is distributed, technical expertise will be needed at remote sites, and there is the potential for problems with the interfaces between tools.
Platform Constraints
Systems-based tools (e.g., for monitoring or control purposes) will clearly be platform dependent. Functional tools (e.g., to support Incident Management or Change Control), however, can run independently from the systems tools and may only need to run on a limited number of systems.
Integration with Other Functions
Integration between some of the functions is highly desirable. Integrated toolsets offer integrated functionality across a number of functions, thus simplifying the interfaces between them (e.g., data will automatically be consistent across functions). Purchase of such tools will help reduce costly customization or the development of add-ons.
It is important to understand the level of integration between products, however, before buying them. Integration varies from vendor to vendor and can mean anything from simply having an icon on a desktop to fully integrated applications and data. In addition, integrated toolsets are likely to be stronger in some functions than in others, and may preclude selection of the best possible tool for every function.
Anticipated Volume of Data & Transaction Throughput
Understanding the anticipated volumes will provide key input to sizing the system. Predicted business volumes stated in the SLA should be used to help determine the appropriate sizes for machines, databases, telecommunications lines, etc. Alternatively, experience from previous engagements can provide useful input.
Number of Users for the Tool
Users may not be limited to the number of support personnel accessing a tool alone.
Keep in mind that users of the tools may either be support personnel, vendors, users, senior managers, etc.
Some tools will only support a limited number of users, or may only support users within certain geographic boundaries. It is important to understand if there are any such limitations prior to purchasing a tool.
In addition, the number of users will affect the budgetary requirements for the purchase of a tool, particularly as they relate to hardware and communications requirements.
Level of Support Required
If third party software is to be purchased, suppliers must be assessed on their ability to ensure the availability, reliability, performance and user support for these tools will be sufficient to deliver the appropriate levels of service to the users of the system. It may even be necessary to visit reference sites for the vendors to determine whether these requirements are being met.
Presentation (9302)
The presentation component provides the interface between the manager(s) of the system and management data generated by the system. Data can be manipulated for various forms of output. By integrating the operational architecture it is possible to reduce the number of front-end interfaces required. Commonly, the presentation component uses a GUI front-end interface. This component is also responsible for real-time and historical report generation.
Event Processing (9304)
Event processing manipulates the raw data obtained in the event/data generation layer into a more workable form. This layer performs functions such as event filtering, alert generation, event correlation, event collection and logging, and automated trouble ticket generation. Event processing routes the processed information on to either the presentation or management applications layers. Again it is important to consider the interface of the event processing component with the other components of the operational architecture.
Help Desk (9306)
As with End User Services in the centralized model, the Help Desk is the single point of contact for all end users. This unit has end-to-end accountability for all user incidents and problems regardless of whether or not it has the resources to fix them (i.e., it must contact the necessary technical resources in either IS organizations to ensure the incidents and problems get resolved).
Incident Management (9308)
Incident Management provides the interface between the users of the system and those operating and maintaining the system when an incident arises. Incident Management is responsible for:
In addition, Incident Management is responsible for ensuring that outstanding incidents are resolved in a timely manner. As part of Incident Management, incidents are reviewed, analyzed, tracked, escalated as necessary, and resolved.
Failure Control (9310)
Involves the detection and correction of faults within the system whether they be minor (e.g., workstation is down) or major (i.e., a disaster) has occurred.
Fault Management (9312)
When a negative event has been brought to the attention of the system, actions are undertaken within Fault Management to define, diagnose, and correct the fault. Although it may be possible to automate this process, human intervention may be required to perform at least some of these management tasks.
Event/Data Generation (9314)
Event/data generation interacts with all the managed components in the execution and development environments in order to obtain the required management information. This component also interacts with the physical environment, managing hardware, and supporting infrastructure components of the operational architecture to obtain management information. It is important to consider these interfaces when choosing event/data generation components. Agents and proxies are two common types of event/data generation tools. Often these tools use broadcasting and trapping methods to capture information. Application generated events from vendor packages and user applications also fit into this component of the operational architecture.
Monitoring (9316)
Verifies that the system is continually functioning in accordance with whatever service levels are defined.
Event Management (9318)
An event is an electronic message generated by any component (e.g., application software, system software, hardware, etc.) in the system. Event Management receives, logs, classifies and presents event messages on a console(s) based on pre-established filters or thresholds.
Management Applications (9320)
Management applications are those tools which are used to manage the system. Most of the MODE functions tie directly into this component. The management applications component ties in directly with the integration platform component as the management applications tools must comply with the standards set by the integration platform. For example, if the integration platform is HP OpenView, then the management applications must be HP OpenView software (API, SNMPx) or hardware (card) compliant. Management applications receive data from the event/data generation, event processing, and repositories components and then send data to the presentation or repositories components. Management applications tools include capacity planning tools, performance management tools, license management tools, remote management tools, systems monitoring tools, scheduling tools, help desk tools, etc. Some Enterprise Management tools even poll the event/data generators for information but these options may impact network performance. Web Server management has been introduced as part of the management operations framework. As Corporate Internets and Extranets implement Web based software products to sell and advertise business services, corresponding administrative, security, event notification and performance requirements must be performed similarly for the companies web based system. The critical path issues for Web based server software is typically security and performance based levels of service.
Help Desk (9322)
As with End User Services in the centralized model, the Help Desk is the single point of contact for all end users. This unit has end-to-end accountability for all user incidents and problems regardless of whether or not it has the resources to fix them (i.e., it must contact the necessary technical resources in either IS organizations to ensure the incidents and problems get resolved).
Implementation Considerations
The following are functional requirements for Incident, Request and Problem Management.
Logging Incidents/Requests
Call logger should be presented with a unique incident/request identifier, and should be able to enter a free format description as well as the key data items specified in the data requirements section. Data and time stamps should be automatically registered and Incident and Request management staff should have access to display all open incidents and requests as well as the incident/request history for a specific user location.
Progress Incidents/Requests
Facilities should be given to provide a free format update of actions and investigations, to assign the incident/request to a support group, or to escalate the incident. Date and time stamps should be attached to each action and the full incident/request history should be available to the person performing the update.
Re-Assign Incidents/Requests
Possible for incidents and requests to be assigned to different support groups, if further investigation is required.
Close Incidents/Requests
Incidents and requests should be closed with a date and time stamp to help trend analysis and service level reporting.
Log Problems
Problems can be logged both as a result of one or more incidents, or through proactive monitoring of the system, before any incidents have been logged.
Support the Functions Either Centrally or on a Distributed Basis
If the Incident, Request and Problem management functions are to be centralized, these functions need to be able to control and monitor incidents and problems, but other functions should be able to gain access to input detailed technical information or progress updates. If Incident and Request management is distributed, it is recommended that remote locations are given access to the central system, rather than operating local systems. (Some problem areas are local sites operating on different time zones and standardizing escalation procedures from local sites.)
Facility for Auto-Logging Incidents
Event/alert based automatic logging of incidents to provide proactive management of incidents and problems by informing Incident management of issues before the user logs a call. This facility is conceptually desirable, but is only likely to be available if the Incident management functionality is part of the monitoring tool. The costs of building hooks between tools and applications are likely to prove prohibitive. In medium or large environments, this facility is extremely desirable, and must be built into the requirements.
Assess Incidents Automatically, Based on Previous Experience and Rules
Knowledge and case based incident management systems are becoming prevalent in the market place, and are built into Help Desk offerings. Use of these systems can help improve the responsiveness and reputation of the entire organization. (Case based tools will require building up over time.)
Incident Management
Incident Management provides the interface between the users of the system and those operating and maintaining the system when an incident arises. Incident Management is responsible for:
In addition, Incident Management is responsible for ensuring that outstanding incidents are resolved in a timely manner. As part of Incident Management, incidents are reviewed, analyzed, tracked, escalated as necessary, and resolved.
Implementation Considerations
Will Users be Given Access to the Incident Management System?
Users will benefit by gaining up to date information on the progress of incidents, and could be given the facility to log incidents directly, which would relieve some of the load of the Incident Management function. However, this adds complexity to the solution, and increases communications requirements/costs.
Which Support Personnel Will be Given Access to the Incident Management System?
Support personnel would be able to enter progress against incidents without contacting Incident Management. The ability to scan incidents may also aid the Problem Management function. However, this adds complexity to the solution, and may increase communications requirements/costs.
How Many Incident Support Levels Will be in Place, and how Expert Will the Incident Management Function Be?
This will depend on the knowledge and experience at the user locations. The level of technical expertise within the Incident Management function will drive the systems requirements.
Problem Management
Problem Management utilizes the skills of experts and support groups to fix and prevent recurring incidents by determining and fixing the underlying problems causing those incidents. Within Problem Management, related incidents are correlated to problems and ultimately to order or change requests. All problems are logged, tracked and archived. Where possible, work-around are determined and information regarding the work-around is distributed to the appropriate support personnel and user communities.
Implementation Considerations
Will Problems be Automatically Logged or Only by Manual Association with an Incident?
Automatic logging of problems will require interfaces to be built with the Event Management system, and perhaps the execution architecture for application errors.
Request Management
Request Management is responsible for coordinating and controlling all activities necessary to fulfill a request from either a user, vendor, or developer. Request Management determines if and when requests will be fulfilled through interaction with the particular function(s) impacted by the request. Following such interaction, accepted requests will be planned, executed, and tracked.
Implementation Considerations
Will Users be Given Access to the Request Management System?
Users will benefit by gaining up to date information on the progress of incidents, and could be given the facility to log incidents directly, which would relieve some of the load of the Incident Management function. However, this adds complexity to the solution, and increases communications requirements/costs.
Failure Control (9324)
Involves the detection and correction of faults within the system whether they be minor (e.g., workstation is down) or major (i.e., a disaster) has occurred.
Fault Management
When a negative event has been brought to the attention of the system, actions are undertaken within Fault Management to define, diagnose, and correct the fault. Although it may be possible to automate this process, human intervention may be required to perform at least some of these management tasks.
Disaster Recovery
In the event of a significant system failure, Disaster Recovery processes will be invoked to re-route the system resources to a secondary, stable configuration until the primary resources can be restored. Within a distributed environment, disaster recovery must account for differing levels of disaster whether at a central or distributed site(s).
Implementation Considerations
What is a Disaster?
The way in which a disaster is defined will be dependent upon which resources are critical to the business. For example, a data center failure may be critical for one client whereas a server failure for another is more critical.
How Quickly Will Disaster Recovery be Required for Each Service?
This will be defined in detail within the SLA, but high level service recovery targets must be understood, so that high level recovery plans can, in turn, be produced.
Recovery manages all of the actions needed to restore service delivery after a system failure. With critical business applications being rolled out on distributed technologies, the recovery of these systems must be easy, quick and efficient to guarantee availability of core business systems as expressed in the agreed service levels and operational levels.
Implementation Considerations
What are Some of the Limitations that are Encountered?
Recovery capabilities span the range from those required to bring up a device after it has failed to those required in the event of a major disaster. With critical business applications being rolled out on distributed technologies, the recovery of these systems must be easy, quick and efficient. Loss of the system for even a short period of time can result in significant financial losses to a client's business.
Hardware Maintenance
Hardware Maintenance maintains all of the components within a distributed system to protect the investment of the organization. Generally agreed upon in the SLAs, maintenance contracts are carried out, monitored and recorded for each asset as appropriate.
Administration (9326)
Billing and Accounting
Billing & Accounting gathers the necessary accounting information for calculating actual costs, determines chargeback costs based on pre-defined algorithms and bills users for service rendered.
Billing & Accounting also makes payments to service providers for services and equipment provided in accordance with agreed upon SLAs. As part of this payment process Billing & Accounting reconciles bills from service providers against monitored costs and SLA/OLA violations.
Systems Management Planning (9330)
Capacity Modeling and Planning
Capacity Modeling & Planning ensures that adequate resources will be in place to meet the SLA requirements, keeping in mind operational requirements which may require additional capacity. Resources can include such things as physical facilities, computers, memory/disk space, communications lines and personnel. Through this component, changes to the existing environment will be determined, modeled and planned according to the necessary requirements.
Production Control (9332)
Ensures that production activities are performed and controlled as required and as intended.
Production Scheduling
Production Scheduling determines the requirements for the execution of scheduled jobs across a distributed environment. A production schedule is then planned to meet these requirements, taking into consideration other processes occurring throughout the distributed environment (e.g., software and data distribution, remote backup/restoration of data.) It plans the production workload and then submits the tasks to the system in the proper sequence, stops processing upon detecting a failure, provides on-line task tracking and workload forecasting.
Implementation Considerations
In a Distributed Environment are Processes Across Entire or Multiple Platforms and Systems?
Processes may be taking place across the entire system on multiple platforms in either a parallel or a serial fashion. Batch dependencies may be required across platforms, and multiple time zones may be involved. In addition, many non-mainframe based products do not provide production scheduling capabilities with the platform. Therefore, one can see that scheduling processes across a distributed environment can be quite complex, requiring significant management effort to ensure that processes occur appropriately.
How Many Schedulers Will be Used to Control the Schedules?
The component plans for the production workload and then submits the tasks to the system in the proper sequence, stops processing upon detecting a failure, provides on-line task tracking and workload forecasting. In addition, requirements are determined for the execution of scheduled jobs across the environment.
Does and Existing Component Satisfy this Requirement?
Production Scheduling contains specific requirements that addresses a distributed environment's complexity of multiple platforms and system placed in either a parallel or serial fashion.
What Other Utilities are Available with the Tool?
The tool should provide control dependencies to schedule workloads such as: Task/job sequence enforcement, external/internal event driven. Graphically displays work flow from the scheduling criteria and includes such information as task/job name, task description, average run time and resource requirements. Allow clients to define user schedules that can be based on predecessor events in the production environment. Reporting capabilities for forecasting, simulation and analyzing scheduled workload. Monitoring capability of past, present and future workloads as well as tracking of current workload termination notification of normal or abnormal completion.
Does the Development Team Have any Prior Experience with the Tool?
The development should be able to identify the component linkages as well as the functional requirements critical for successful operational integration of the tool into the observed environment.
What Level of the Component is Required?
Due to the complexity of a distributed environment one must account for the processes taking place across the entire system on multiple platforms in either a parallel or a serial fashion. Therefore, production scheduling capabilities across platforms is critical as well as the ability to rerun/restart from single point of failure or provide checkpoint restart-ability.
Does the Tool Provide Facilities to Add Color to Mode Architecture Model?
Print Management monitors all of the printing done across a distributed environment and is responsible for managing the printers and printing at both central and remote locations. The purpose of a print architecture is to make formats applications independent, so that the only thing applications need to do is obtain the data.
Print Architecture offers:
The types of printers will be dictated by the business requirements. The types of printers, will in turn, determine what tools can be used to manage printing may or may not be required.
Where are the Printers Going to be Located?
The business will help determine where the printers need to be located based on where/when printing needs to take place. In some instances local printing may or may not be required.
What Spooling Facilities Will be Available?
If spooling is available, printing can be handled as a background task, freeing up system resources for use on-line.
Will Review Before Print Facilities be Provided?
If these facilities will be provided, all material will not need to be printed. If the material does need to be print; however, the location of the printing must be determined, and the system must be able to forward the printing on to the appropriate location.
Will Printing of Large Documents be Necessary?
Large print jobs may utilize system resources considerably (e.g., WAN, LAN, printer), and may tie up the printing queue for other individuals. This type of printing should be performed in off-hours or delayed to avoid contention for the printer during business hours.
What are Some Limitations that May be Encountered?
In a distributed environment the sizing and routing of print traffic is more complex. With new systems being installed, only educated guesses about how and when printing will take place can help determine print routing functionality. In most cases, some adjustments will be required to the print routing algorithms post-rollout to reflect the printing reality.
Product Considerations
What is the Intended Use of the Tool?
Controls report production and distribution form the moment the report is created to the time the printed report is dropped in the end-use s mailbox (electronic, paper, microfiche, etc.)
What Other Utilities are Available with the Tool?
Support multiple printer types as well as report delivery across them. This includes printer format translation (PCL, Postscript, etc.) and code translation.
Any Other Specific Functional Requirements?
Output management issues require leverage of existing print capability, local and remote printing, and distribution management through a software package or an equivalent alternative.
File Transfer & Control
File Transfer and Control initiates and monitors files being transferred throughout the system as part of the business processing (e.g., nightly batch runs). File transfers may occur between any two or more devices within the system.
System Startup & Shutdown
System Startup and Shutdown performs the activities required for the startup or shutdown of the entire system (e.g., hardware, applications), or portions of the system depending upon the identified requirements. Within a distributed environment, the system includes both centralized and remote resources.
Implementation Considerations
Will devices need to be shutdown/started remotely as well as be automatic or manual (e.g., using scripts, embedded in schedule)?
If expertise will not be available locally, it is imperative that remote control of the startup/shutdown processes be available. The presence of skills, the availability of tools, and the uniqueness of the application/environment will dictate whether or not startup/shutdown is automatic or manual.
How will Clean Shutdown of all processes be Exposed?
If a system failure takes place, it is important that all processes be shut down well, to ensure that the processes can be re-started and that the integrity of the information will be maintained.
In What Order will Hardware and Software Components be Started/Shutdown?
Based upon the technical requirements of the system (e.g., databases should be started before applications) as well as defined service levels (e.g., one particular application is critical and must be started first), the order of startup/shutdown will be determined.
Are periodic Re-boots Required (e.g., to clean up memory)?
If this is necessary, automatic/manual startup/shutdown of the system should be scheduled (e.g., UNIX systems require this).
Analysis of the System and Other Resources Need to be Addressed?
The state of an application, the system or a specific resource must be known at all times. Common activities performed as part of Startup/Shutdown include:
System startup and shutdown is no longer confined to a centralized site. The system is distributed, in effect creating islands of technology which may be started or shutdown with the flip of a power switch on a workstation. Processes which rely on the system being up and running (e.g., software and data distribution) may fail if a user has switched his/her machine off before leaving for the evening. Such failures will impact the following days processing capabilities and must be accounted for either by the system or through training. In addition, controlled machine startup may be required to initiate tasks or to perform activities such as configuration checking or virus detection/correction.
Mass Storage Management
Mass Storage Management involves those activities related to the handling of various types of centralized and distributed storage media including the monitoring and controlling of storage resources and their usage.
The objectives of Mass Storage management are to: implement the top level of storage management, control the usage level of each storage device in the distributed environment, control all storage related naming standards and placement details in the installation.
Mass Storage Management is more complex in a distributed environment than in a centralized environment since many more storage options become available, as storage may take place centrally or on a distributed basis and the number and characteristics of storage devices have increased.
Implementation Considerations
What DBMS Will be Used and What Utilities does it Have?
The DBMS will often provide much of the necessary storage management functionality; this decision impacts further requirements.
Will Databases be Distributed or Centralized?
Storage management for centralized databases will clearly be simpler then for distributed databases were a global view becomes more difficult to obtain, and where data consistency becomes more of an issue.
What Media Types Will be Used?
It is essential that the types of device to be used are understood before detailed decisions are taken.
Distributed Environmental Constraints?
The allocation and sharing of storage media is more difficult to plan since users are distributed. Mass Storage Management is more complex in a distributed environment as many more storage options become available; storage may take place on disks, tapes, etc. Either centrally or de-centrally.
Product Considerations
What is the Intended Use of the Tool?
Control and manage the data storage environment including any/all media, disk, optical and tape.
Technology's Ability to Support the Operating Systems within the Distributed Environment?
The tool must run in the platform selected in order to control usage of disk space, main memory, cache, etc. In addition, determining the space available helps control the device usage, storage capacity.
What Other Utilities are Available with the Tool?
The tool should take into account the complexity of the distributed environment as well as the flexibility of the scenario that storage may take place centrally or on a distributed basis and the number and characteristics of storage devices have increased.
Does the Tool Provide Support for the Databases Selected for the Distributed Environment?
Additional facilities may be required, even though databases typically have built-in utilities or tools to perform these function and do not generally require a separate tool.
Does the Tool Provide Facilities to Add Color and Support Linkages to Mode Architecture Model?
Backup and Restore Management considers all of the back-up and restorations that need to take place across the distributed system for master copies of data. Depending on the need, these processes may occur centrally or remotely.
Implementation Considerations
What Data/Files Will be Backed Up?
Files that are either unique, store site specific data or are highly volatile should be backed up. This will help ensure that important, business critical data will not be lost in the event of a system failure or disaster. All files do not necessarily need to be backed up as each file backup utilizes storage space and may impede the performance of the system.
What Will be the Frequency of the Backup, the Number of Copies Made, and the Number of Generations Maintained?
The critically and volatility of the information will determine the frequency of the backups and whether or not multiple copies of the data are maintained centrally/locally. In addition the stability of the system needs to be considered as well as any performance impacts of backing up the data as required.
The number of generations maintained will be dependent on the disaster recovery policies in place as well as any government/regulatory controls in existence.
How Will the Integrity of a Backup or Restore be Ensured?
Because databases can be located throughout the distributed environment, care must be taken to ensure that data integrity is maintained. This may mean storing the master copy of data centrally, or synchronizing the commits of updates of the information appropriately.
Will the Data be Backed Up Centrally, Locally, or at an Alternate Site?
Centrally located devices will require the use of both LAN and WAN bandwidth to backup the data, and restoration of the data will be slower. This may be hard to achieve if there are numerous devices in the system. Central location, however, will ensure that backed up data will be stored in one place, potentially making recovery from a system failure or disaster recovery easier as well as centrally less expensive to maintain. In addition, central control over the backup/restore process will require expertise at a single location whereas local control will necessitate expertise in multiple locations. Alternate site control may provide the best mix of central/local placement of skills.
In contrast, local devices do not utilize the WAN bandwidth, and typically provide faster data restoration. Local devices, if available, may be more expensive and may require local expertise.
Alternate site backup combines both of the strategies in that WAN bandwidth to the central site is not over-utilized, and restoration of the data can happen fairly quickly as well as securing information as information is stored in multiple locations.
Will Copies be Held at Multiple Locations?
Backup copies may need to be stored at multiple locations for security purposes (i.e. in the event of a system failure, or disaster, some backup copies may have been destroyed.)
Product Considerations
What is the Intended Use of the Tool?
Provide services and facilities to enable the client to effect timely and accurate recovery in the event of an interruption to processing capability.
What Other Utilities are Available with the Tool?
Backups are typically embedded into production scheduling with restores on an ad hoc basis. Backup/Restore needs to ensure that a file can be only backed up/restored by users with the right access level. Furthermore, file transfer utilities need to be used when the information to archived is sent through the network as well as security for file control access and global authorization should be available and done in concert with the security management facility.
Should the Tool Provide Specific Component Functionality?
Database backup/restore is inherently more complex than backup of standard files. It is important to ensure that all relationships are resurrected after restoring database files. (Integrated with the functionality of the DBMS).
Does the Tool Provide Support to Specific Areas?
The ability to support unattended operations reduces the need for operations expertise in both central and remote locations.
Does the Tool Add Color to Mode Architecture Model Through Performance Measures?
Performance of the backup product is essential. The tool should backup all production data in the processing window provided and the restore capability should match availability and disaster recovery requirements. Performance can be enhanced through the ability to throttle the backup process to reduce network traffic.
Archiving saves and stores information across the distributed environment, either centrally or in distributed locations. Archiving moves datasets, files, etc. from one device to another, usually lower speed, device based on a number of parameters. Archiving can be used to move information to or from distributed and centralized sites.
Implementation Considerations
Which Files and Databases Will be Archived?
Some files and databases need to be stored on fast devices so users can access them quickly. In addition, certain files may need to be maintained for either historic or government/regulatory reasons.
What Media Will be Used for Archiving?
The cost of the media, space available and its performance capabilities should determine which archiving medium is used as well as the existence of central or local expertise.
How Long Should Archived Data be Maintained?
It is important to define the maximum time that data needs to be stored before being deleted, including the number of generations that need to be maintained. This is because the amount of archival space should be determined up front. The maximum time will likely be determined by either government/regulatory controls or disaster recovery requirements.
How Will the Integrity of Retrieved Data or Files be Ensured?
Because databases can be located throughout the distributed environment, care must be taken to ensure that data integrity is maintained. This may mean storing the master copy of data centrally, or synchronizing the commits or updated of the information appropriately.
Will Archiving Devices Reside Centrally or Locally?
Central control over the archiving process will require expertise at a single location whereas local control will necessitate expertise in multiple locations.
Centrally located devices will require the use of both LAN and WAN bandwidth to archive the data, and retrieval of the data will be slower. This may be difficult to achieve if there are numerous devices in the system. Central location, however, will ensure that archived data will be stored in one place, potentially making recovery from a system failure or disaster recovery easier. In addition, central devices may be less expensive to maintain.
In contrast, local devices do not utilize the WAN bandwidth, and typically provide faster data retrieval. Local devices, if available, may be more expensive, and may require local expertise.
Implementing (9334)
Executes change within the distributed environment with tested components and techniques according to the appropriate plan(s). Implementing includes such things as: initial installation, software & data distribution, license management, etc.
System Component Configuration
System Component Configuration provides a mechanism to configure equipment (i.e., hardware and software) which has configuration parameters to set and to manage the inter-relationships between configured components within the system. Configuration information for particular equipment must be coordinated across the system to ensure that all equipment can function together properly.
Implementation Considerations
Where does the Function Get Input From?
Configuration settings can be retrieved from different sources. The release and the rollout schedule will contain a detailed description of equipment and its configuration and can therefore be used as input. Alternatively, the asset inventory system can be updated in advance and then used as an active database to drive the configuring process.
Product Considerations
What is the Intended Use of the Tool?
Definition and implementation of consistent configurations for all configurable components within the system.
What Other Utilities are Available with the Tool?
The asset data has to be updated accordingly and must reflect the actual state of hardware and software and all their relationships. Configuration data may be distributed to the device by Software & Data Distribution; therefore, System Component Configuration needs to get access to Software & Data Distribution processes.
Software & Data Distribution
Software and Data Distribution sends out the correct version of the release package to the distribution locations and updates the locations with the contents of the release package (e.g., software, data, configuration information, procedures and training/support materials.)
The software and data distribution mechanism itself updates either the software, data, or configuration information on a machine(s), reports the relative success/failure of the distribution and updates the asset information for the sites/machine(s) affected by the distribution.
Implementation Considerations
What are Some Limitations that May be Encountered?
Training Planning also impacts how well service will be delivered within the distributed environment. The skill sets required by support personnel will change with the introduction of distributed technologies. Support personnel will be required to have greater breadth of knowledge. No longer can an individual simply understand the network or the applications. The intertwined nature of a distributed environment will force individuals to understand, at least at a high-level, how the system fits together. In addition, support personnel will need to have some specialized skills. As no one individual can fully understand the detail behind the entire system, teams of specialized support personnel will be required to work together to a greater extent in these environments. This group interaction may require new skill sets not frequently found in traditional support organizations.
What are Some Focus Areas to Determine an Appropriate Training Plan?
The existing skills must be assessed and a forward-thinking training direction must be defined. The training plan will likely emphasize newer technologies and different methods of training with the underlying goal of providing the appropriate level of service as required by the SLAs.
Product Considerations
What is the Intended Use of the Tool?
Support the ability to distribute software components to interdependent, multiple heterogeneous platforms from a single source. The features should be automated and only require minimal operator involvement.
What Other Utilities are Available with the Tool?
Software & Data Distribution needs to access and update asset data in the asset inventory system to reflect implemented changes (automatically). In addition the function may be based on the same file transfer protocol as File Transfer & Control; unless the tools uses their own proprietary file transfer method based on a standard communication protocol.
Does the Tool Provide Support for Specific Environments?
Specialized functionality to support operation across the wide-area network environment including: parallel distribution and data compression. In addition, support of platform specific functions and capabilities due to awareness of platform specific information resident in the asset/inventory database.
User Administration
User Administration handles the day-to-day tasks involved in administering users on the system. These tasks include such things as: adding new users, changing user Ids, re-establishing user passwords, maintaining groups of users, etc.
Security Management
Security Management controls both physical and logical security for the distributed system. Due to the nature of a distributed environment, security may need to be managed either centrally, remotely or through a combination of the two methods.
Security Management also handles the logging of proper and illegal access, provides a way to audit security information, rectify security breaches and address unauthorized use of the system.
Implementation Considerations
Some Limitations that May be Encountered?
Security must exist in various levels throughout the system in order to prevent unauthorized access. Security components must be packaged into a security architecture which can be effectively managed by an organization through their security management strategies. The Kerberos security approach within client/server architecture, for example, utilizes interconnected security servers and distributed security clients to provide security for the distributed environment.
The number of security components required to secure a distributed environment will increase due to the computing power available through the use of these new technologies and the heterogeneity of the environment. Although things such as dial-up access, LAN access, multiple host access, etc. introduce new user capabilities, they simultaneously introduce security risks into the system.
What are the Benefits of Single Logon Capabilities?
Due to the number of components, users may be required to have multiple ID(s) and passwords unless the system is designed to allow a user to access all of the required resources through a single logon. As most products on the market typically allow access to only a subset of resources, single logons with multiple ID and password coordination may be difficult to achieve. Issues such as periodic required password changes can be difficult to overcome while maintaining adequate security.
Product Considerations
What is the Intended Use of the Tool?
Protects all computer resources, facilities and data from accidental or intentional destruction, modification, disclosure and/or misuse.
What Other Utilities are Available with the Tool?
Network & Systems Management Planning is responsible for the planning activities involved in running the day-to-day operations and maintenance of the production systems (e.g., capacity planning, performance planning, etc.).
Controlling (9336)
Monitors change to make sure that change is delivered on-time according to established plans, making adjustments to the plan when unforeseen issues or events arise (e.g., rollout management, change control, asset management etc.)
Change Control
Change Control is responsible for coordinating and controlling all change administration activities within the distributed environment (i.e., document, impact, authorize, schedule, implementation control.)
Implementation Considerations
What Types of Changes Will be Controlled by Change Control and What is the Anticipated Volume of Changes?
The types of changes Change Control should cope with need to be defined. Changes can range from a minor document change to the introduction of a complete new service. However, moving a workstation from one desk to another may not require a change request.
Design of the function heavily depends on its size. It may be a relatively small environment with little expected change, or it could be a huge distributed system with many locations, many users and many different platforms.
It is easy to underestimate the volume and complexity of changes in a distributed environment. Changes to different platforms can easily become very complex. Experiences from previous engagements should be used to help predict figures. In a typical distributed environment, several hundred changes per month can be expected.
To What Extent Should Change Control be Integrated with the Asset Inventory System, Maintained by Asset Management?
Impact analysis can use Asset Management to get a detailed list of assets which are dependent on the subject to be changed. It may be a mandatory requirement to provide this list before a change request can be accepted.
To What Extent Should Change Control be Integrated with Incident and Problem Management?
Change requests might be closely tied to incidents and problems, thus when a change is implemented, the corresponding incidents and problems can be cleared.
Which Media Will be Used for Change Request Submission?
Pure electronic forms will be easy to forward over different locations, but it is more difficult to include a signature feature for authorization, and it is not easy to attach documents to provide additional information.
Therefore, further paper forms are typically used for raising change requests but the change administrator then stores the most important information in a change request database. The decision will depend primarily on the size of the system.
There are Some Limitations that May be Encountered within a Distributed Environment.
There will be multiple change drivers including the users, developers/architects and vendors. The change these groups will wish to introduce must be coordinated on a wide-scale basis as the impact of change within these environments is great. Change Control allows the impact of the change to be assessed along with its merits, timescales, etc. It also provides a way of evaluating and rationalizing multiple change requests against one another to determine what changes should actually take place.
Product Considerations
What is the Intended Use of the Tool?
Integrated central repository of source, change and configuration data used to pro-actively manage all events impacting user service. Manage the process of change activity, while maintaining the integrity of both application development and the production environment. Support change control from the initiation of the change, through production configuration across multiple platforms.
What Other Utilities are Available with the Tool?
Asset Management ensures that all assets are registered within the inventory system and that detailed information for registered assets is updated and validated throughout the assets lifetime. This information will be required for such activities as managing service levels, managing change, assisting in incident and problem resolution and providing necessary financial information to the organization.
Implementation Considerations
What Data Will be Stored?
There are four options to consider, when designing the scope of the Asset Management function. Usage of the Asset inventory only as a production system database (core database), including hardware devices, software versions loaded in the production environment, their licenses and network configuration data. Thus the asset inventory system only stores the core systems components in the production environment.
In addition to the production system data as describes above, it contains any existing release and release components such as software modules, documents and procedures. It also contains service level agreements and actual figures for user groups and devices, incidents, problems and change requests. It may also contain additional data such as performance data or log of all backups taken.
How Will Data be Kept Up-to-Date?
This can be achieved by regular and ad hoc audits, using manual and automated procedures. An alternative approach would be to use asset data to drive Software & Data Distribution. The Software & Data Distribution processes would get data from the asset inventory system as input If these processes configured the devices according to the asset inventory it would be up-to-date by definition.
What Phases of an Assets Life Cycle Should be Covered by Asset Management?
It may be appropriate to control assets within the first stage of the life cycle (i.e., from development on) or it my prove more appropriate to implement Asset Management only from the point of delivery.
Product Considerations
What is the Intended Use of the Tool?
Maintain a central repository for all software licenses and assets.
What Other Utilities are Available with the Tool?
Ability to maintain a data model representing the basis for an asset inventory system that reflects the types of assets to be managed and their relationships. The model should be flexible to cope with future structural changes. A record needs to be added to the inventory system when an asset is purchased or created, or when changes to the environment are performed.
How Well does the Tool Integrate with Other Tools in the Environment?
Asset data needed to support various other management functions such as:
Current asset data from the distributed environment needs to be retrieved frequently through regular and ad hoc audits.
Rollout Management
Rollout Management is concerned with delivering new sites or services to existing sites on-time based on the rollout schedule. Rollout Management monitors the rollout progress of all functions against the rollout schedule to ensure that the schedule is maintained. Review of the rollout schedule takes place regularly to determine how well rollout is progressing and to make any adjustments to the rollout schedule based upon any problems or issues which arise.
Implementation Considerations
What are Some Principles that Should be Applied in Determining Rollout Planning?
At the beginning of a rollout, the number of incidents can be dramatic. This happens due to initial problems with hardware and system software as well as the unfamiliarity of the users. In addition to an increased support load, support teams will need more time to process an incident and to solve an underling problem since they will need to become familiar with the new service. Once support teams have become familiar with the system and know how to resolve the most common problems, rollout can be accelerated.
Since many problems will occur initially during rollout, it is important to have quick access to support teams and development teams. If sites are close, support personnel can get to the sites quickly. Once the system is more stable, remote installation can occur.
Instead of planning a tight schedule that keeps teams busy all the time, some windows should be left in the schedule to allow catching up time in case of delays. Otherwise, small deviations to the schedule cannot be handled and larger delays to the entire schedule will result.
When rollout continues over a period of time, hardware and system software updates will affect the initial implementation of the system. The service to be implemented itself may also be updated during rollout. Therefore it is important to review hardware and software maintenance and release plans and to reflect these plans in the rollout schedule.
Will the System be Rolled Out in One Big Bang or Through a Phased Rollout Over a Longer Period of Time?
Rollout of a new service can either be performed at one specific point in time for all locations or phased over a certain period of time. Phased rollout is the preferred approach because it limits the risk of serious business disruptions. In some cases, however, it may be necessary to complete rollout simultaneously for business reasons.
What are Some of the Limitations Encountered in a Distributed Environment?
Rollout Planning handles the greatest period of change in distributed systems management—system rollout and installation. During rollout every site and every user may be impacted by the changes taking place. Since delivery of the system will affect how well it is received by the users and is oftentimes defined by an SLA(s), delivery of the system must take place smoothly with minimal interruption to the users. This can be challenging when both old and new architecture domains must exist concurrently until the rollout has been completed.
Interdependencies within the schedule must be identified prior to rollout to highlight the importance of the schedule and the effort required from each group involved.
Release Control
Release Control is concerned with delivering a release on-time based upon the release schedule. Release Control monitors the release progress of all activities against the schedule to ensure that the schedule is maintained. Review of the release schedule takes place regularly to determine how well the release is progressing and to make any adjustments to the release schedule based upon any issues or problems which arise.
Implementation Considerations
What Will be the Versioning Strategy?
It is necessary to determine how a release will be named and versioned. The following points should be considered when defining a versioning strategy. The versioning strategy should be kept simple and meaningful. Versions should be applied not only for complete releases, but for all logical groups of release components as defined in the release definition data model. Asset Management needs to reflect the release component data model in order to be able to store the asset information. In addition, the versioning strategy will affect Software & Data Distribution to ensure that the appropriate version of software/data is resident on the unit prior to implementing the new release, and co-requisite checking ensures that implementations of software/data will leave a machine in a valid state.
How Frequently Should New Releases be Packaged?
A minimum time interval between two regular releases needs to be defined. Most planned releases typically occur within three to six months of one another.
Will Delta Releases be Allowed?
The need for delta releases as part of the overall policy must be determined. Delta releases are high risk, as they require a much better understanding of what is already implemented.
Delta releases have the advantage of requiring less storage space on the target machine but it may be more difficult to ensure that the base components are compatible. This can become a particular problem when many components have changed and several delta releases have accumulated.
Will Simultaneous Changes Across Platforms be Required?
Implementing releases in a distributed environment requires complex synchronization across machines and platforms. An appropriate strategy needs to be determined.
What are Some Limitations that May be Encountered at Distributed Sites?
Release Planning coordinates the release of updates (e.g., software, data, procedures, etc.) to the distributed sites. An application, for instance, can no longer be delivered upon successful completion of its system test. This is due to the fact that any change in the distributed environment will impact other components in the distributed environment. Releases must therefore be planned carefully to ensure that a change will not negatively impact the distributed system.
Product Considerations
What is the Intended Use of the Tool?
Monitoring and delivery of releases as well as review of release schedule versus planned schedule.
What Other Utilities are Available with the Tool?
Release Planning and Release Control naturally use the same tool, typically a spreadsheet, for creating and maintaining the release schedule.
Migration Control
Migration Control is a function underneath Release Control. Updates to the distributed system must be tested prior to being released into the distributed environment. To control the updates as the move from the development into the production environment, Migration Control ensures that the proper updates are received from development, versioned according to the version strategy of Release Planning, moved into the test environment, moved form the test environment into the production environment after the pre release tests have been successfully completed.
Implementation Considerations
What Units are Subject to Migration?
The groups of components, which are allowed to be migrated, must be determined, for example: single software modules or documents can be migrated on their own and only complete releases (including delta releases) with all their components may be migrated.
Where Will the Release Library be Located?
The library can either be held centrally or can be distributed over various sites. A centralized approach is preferable in order to avoid inconsistencies.
Which Platforms and Media are Used for the Release Library?
The release library may reside of several platforms. UNIX software may be stored on UNIX servers, host software on hosts and third party workstation software may be on floppy disks.
License Management
License Management ensures that software licenses are being maintained throughout the distributed system and that license agreements are not being violated.
Implementation Considerations
What Data Will be Stored?
There are four options to consider, when designing the scope of the Asset Management function. Usage of the Asset inventory only as a production system database (core database), including hardware devices, software versions loaded in the production environment, their licenses and network configuration data. Thus the asset inventory system only stores the core systems components in the production environment.
In addition to the production system data as describes above, it contains any existing release and release components such as software modules, documents and procedures. It also contains service level agreements and actual figures for user groups and devices, incidents, problems and change requests. It may also contain additional data such as performance data or log of all backups taken.
How Will Data be Kept Up-to-Date?
This can be achieved by regular and ad hoc audits, using manual and automated procedures. An alternative approach would be to use asset data to drive Software & Data Distribution. The Software & Data Distribution processes would get data from the asset inventory system as input If these processes configured the devices according to the asset inventory it would be up-to-date by definition.
What Phases of an Assets Life Cycle Should be Covered by Asset Management?
It may be appropriate to control assets within the first stage of the life cycle (i.e., from development on) or it may prove more appropriate to implement Asset Management only from the point of delivery.
Product Considerations
What is the Intended Use of the Tool?
Maintain a central repository for all software licenses and assets.
What Other Utilities are Available with the Tool?
Ability to maintain a data model representing the basis for an asset inventory system that reflects the types of assets to be managed and their relationships. The model should be flexible to cope with future structural changes. A record needs to be added to the inventory system when an asset is purchased or created, or when changes to the environment are performed.
How Well does the Tool Integrate with Other Tools in the Environment?
Asset data needed to support various other management functions such as:
Current asset data from the distributed environment needs to be retrieved frequently through regular and ad hoc audits.
Database Management (9338)
Database Management is the management and administration of database technologies, including monitoring, physical file placement, performance, and sizing.
Database Recovery
Database Recovery is the process of providing recovery of database entities following a logical or physical database failure. This includes database software failure and local disk failure.
Database Disaster Recovery
Database Disaster Recovery is the process of recovering the database entities following a catastrophic failure. This process should be fully integrated in the enterprise-wide disaster recovery plan.
Database Backup/Restore Management
Database Backup/Restore Management is the process of providing point-in-time backup and recovery for logical database restores. This includes application-driven data errors, dropped tables, and corrupt data.
Capacity Modeling & Planning
Capacity Modeling & Planning ensures that adequate resources will be in place to meet the SLA requirements, keeping in mind operational requirements which may require additional capacity. Resources can include such things as physical facilities, computers, memory/disk space, communications lines and personnel. Through this component, changes to the existing environment will be determined, modeled and planned according to the necessary requirements.
Implementation Considerations
What are Some Limitations that May be Encountered?
Capacity Planning & Modeling must coordinate the requirements across the system (e.g., networks, servers, workstations, CPU, etc.) Capacity is driven by the need to meet SLAs with the user communities and as part of the planning and modeling process, future threats to capacity should be identified.
Capacity planning cannot, however, be done separately for each piece of the system. Capacity planning must be done for the system as a whole to understand how the capacity of one portion of the system affects the capacity of another. Due to the large number of components within a distributed environment with any-to-any connectivity that will affect the systems capacity, the equation for determining capacity quickly becomes large, with many interdependencies.
Monitoring (9340)
Verifies that the system is continually functioning in accordance with whatever service levels are defined.
Performance Management
Performance Management ensures that the required resources are available at all times throughout the distributed system to meet the agreed upon SLAs. This includes monitoring and management of end-to-end performance based on utilization, capacity, and overall performance statistics. If necessary, Performance Management can make adjustments to the production environment to either enhance performance or rectify degraded performance.
Implementation Considerations
What are Some of the Critical Elements to Focus on in a Centralized Environment and Distributed Environment?
Performance Management in a centralized environment typically focuses on three main factors: CPU utilization, disk I/O, memory occupancy.
Within the distributed environments, however, these factors extend out into the environment across networks, increasing the complexity of gathering the necessary performance information.
View Performance as a Typically Business Driven?
Performance Management needs to consider performance from a business perspective, not merely a systems one. Most transactions in distributed systems utilize a wide variety of resources, and the measurement of end-to-end response time becomes the sum of the time expended by each one of the components sequentially involved in the transaction less the time while components were processing in parallel.
What Devices/Users Will be Monitored and at which Locations? Will this Information Change?
Understanding the scope of devices/users, and their locations is key to managing performance. Understanding whether or not the scope will change will help determine how Performance Management needs to be approached.
Will Performance be Measured from End-to-End or Merely for Individual Components?
The issues associated with each of these approaches are described above. The approach chosen will have a profound effect on determining the issues that need to be resolved.
Will Monitoring be Continuous or by Demand?
Continuous monitoring can generate significant performance overhead, whereas targeted, periodic monitoring may only be necessary. This strategy will impact the design of the technical infrastructure as well as the tools chosen to manage the systems performance.
Will Only Selected Transactions be Measured, and If so, Should this Selection be Configurable?
It may be necessary to measure business critical transactions only; specified within the SLA. If the facility to select specific transactions is required, significant customization of the system may be necessary.
Will Response Times be Required for all Transactions of a Particular Type, or can Sampling be Used?
Once transaction have been selected for monitoring, the decision needs to be taken whether or not every transaction of that type should be monitored, or only a sample set of those transactions. Full monitoring may increase network and processing overheads.
The Ability to Dynamically Adjust the System to Improve Performance is Also Critical?
As SLAs will likely be tied in some way to performance, it is important to monitor and correct the systems performance as it degrades to ensure that operational levels are maintained and that the SLA(s) will not be violated.
Product Considerations
What is the Intended Use of the Tool?
Collect, analyze and display in graphical format real-time performance characteristics from a wide range of resources. Analyze current workload and configuration data and forecast future requirements, as well as providing input into the Financial planning process.
What Other Utilities are Available with the Tool?
May require use of some or all of the following monitoring tools: operating system monitor, on-line monitor, batch monitor, data base monitor, (host, server) and network monitor (WAN, LAN).
How Well does the Tool Integrate and Interface with Other Tools/Components in the Environment?
Physical Site Management monitors the central and distributed sites environmental and regulatory levels. Physical Site Management ensures that adequate power, cooling facilities, fire suppression, etc. are provided and maintained to prevent system outages. When necessary, corrective actions are issued and monitored according to pre-defined environmental control plans.
Testing (9342)
Ensures that changes to the distributed environment will not negatively impact the distributed environment and that changes will cause positive things to take place (e.g., better system performance, improved operability, etc.)
Product Validation
Product Validation tests potential hardware and software for the distributed environment prior to procurement to determine how well a product will fulfill the requirements identified. Product Validation also ensures that the implementation of a new product will not adversely affect the existing environment.
Implementation Considerations
To What Extent Will the Production Environment be Reflected?
The design of the test environment should reflect the production environment as closely as possible. In principle it is desirable to have an identical set up in both environments. However, this may be cost prohibitive and some parts of the configuration may not be critical to business. The contents of the test environment therefore need to be decided. Yet it is difficult to judge which components of a distributed environment may actually impact services. For example, networking components, such as bridges, are often seen as transparent and not required in a test environment, which my mean that several LANs in production are only reflected by one LAN in the test environment. The risk of adopting this approach must be addressed thoroughly, and should be approved be senior management.
What are Some Limitations that May be Encountered within a Distributed Environment?
Because the technologies are new, it may not be possible to accurately assess what needs to be tested for a particular product. There are many configuration variants in the distributed environment, a single test environment for the validation becomes difficult to achieve and multiple test environments may be required.
Release Testing
Release Testing receives the proper version of a release package (e.g., software, data, procedures, support materials) and tests the release of the upgrade in a test environment to ensure that the:
The design of the test environment should reflect the production environment as closely as possible. In principle it is desirable to have an identical set up in both environments. However, this may be cost prohibitive and some parts of the configuration may not be critical to business. The contents of the test environment therefore need to be decided. Yet it is difficult to judge which components of a distributed environment may actually impact services. For example, networking components, such as bridges, are often seen as transparent and not required in a test environment, which may mean that several LANs in production are only reflected by one LAN in the test environment. The risk of adopting this approach must be addressed thoroughly, and should be approved by senior management.
Will Release Tests Cover the Full Business Cycle and Use Full Business Volumes?
To ensure that the Operability Principles have been satisfied, each release should, in principle, undergo a release test of a full business cycle (to show that Operations can run it) and full business volumes (to show that SLA targets can be achieved). These tests are, however, expensive in terms of dedicated hardware requirements, people, and elapsed time.
In practice, Release Planning will propose an approach dependent on the magnitude and sensitivity of change for each release. The approach must be approved by senior management. If service levels are not to be compromised, major releases must undergo a full release test.
Repositories (9344)
Repositories contain all the management data generated or used during the management process. This includes historical data, capacity data, performance data, problem knowledge bases, asset databases, solution sets, and management information bases (MIBs). The repositories component interacts with the management applications, integration platform, supporting infrastructure, and presentation components. Again it is important to make sure that the other components of the operational architecture are compatible with the database tools.
Production Control (9346)
Ensures that production activities are performed and controlled as required and as intended.
Backup/Restore Management
Backup and Restore Management considers all of the back-up and restorations that need to take place across the distributed system for master copies of data. Depending on the need, these processes may occur centrally or remotely.
Archiving saves and stores information across the distributed environment, either centrally or in distributed locations. Archiving moves datasets, files, etc. from one device to another, usually lower speed, device based on a number of parameters. Archiving can be used to move information to or from distributed and centralized sites.
Integration Platform (9348)
The integration platform provides a common platform for the operational architecture. At the lowest level this means deciding on common standards, interfaces, massage formats, and file logging forms to be used with all the management tools. Third party integration platforms are also readily available. Some of the more well known platforms include IBM NetView, HP OpenView, Sun Solstice EM, SunNet Manager, Spectrum, CA-Unicenter, and Tivoli Management Environment. There are basically two types of third party platforms available. The first group are products like HP OpenView which are very modular. Each tool within the suite can be run separately, however, they all conform to a common framework which allows for greater compatibility and integration and better performance. The other group of products, including the Tivoli Management Environment, require the use of a separate integration platform component into which the management applications are connected. The integration platform and the management applications components of the MAP Operational Architecture Model are integrally related. Many third party vendors insist that they provide solutions which incorporate the event/data generation, event processing, repositories, and presentation components of the MAP operational architecture. It must be noted however that some of these total solution providers may sell a proprietary based solution, at best, and/or may include customized Application Programming Interfaces (API) or Software Development Kit capabilities in order to completely integrate your non-proprietary network. In Addition, some vendors also may not conform to the recent CORBA Open Standards Framework model.
Lastly, some environments use a home grown integration platform. The choice of integration platforms depends upon its ability to integrate with the execution and development environments.
Network Management
Network & Systems Management Planning is responsible for the planning activities involved in running the day-to-day operations and maintenance of the production systems (e.g., capacity planning, performance planning, etc.).
Supporting Infrastructure (9350)
The supporting infrastructure is the subset of operating systems, utilities, languages, and protocols used to support the management of the system. The supporting infrastructure is most often determined by the execution and development environments and the business applications on the system. It is necessary to ensure that the other components of the operational architecture are compatible with the existing supporting infrastructure. This limits the number of possible tool set solutions. Examples of operating systems include HP-UX, AIX, Solaris, SCO, Novell NOS, MVS, OpenVMS, NT and DOS. Examples of support utilities include PS, GREP, IBCOPY, TAR, CPIO and clock correlation. Examples can be broken down according to their function within the OSI model. Session protocols include SNMP, CMIP, FTP, and RPC. Transport protocols include TCP and UDP. Network protocols include IP and IPX. Data-Link protocols include Token Ring, Ethernet, X.25, ATM, SONET, and Frame Relay.
Production Control (9352)
Ensures that production activities are performed and controlled as required and as intended.
File Transfer & Control
File Transfer and Control initiates and monitors files being transferred throughout the system as part of the business processing (e.g., nightly batch runs). File transfers may occur between any two or more devises within the system.
Implementation Considerations
What Platforms Will be Involved in the File Transfers?
The platforms will be determined by both the business and the technical requirements. This will impact the selection of the file transfer tools, and, in particular, how the file transfers are controlled from platform to platform.
How Many Files Will be Transferred? with What Frequency?
The number of files to be transferred as well as their frequency will impact the capacity required on the system (e.g., network bandwidth) as well as the production schedule. In addition, if the volume of data is significant, data compression may be required.
Will Store and Forward be Supported?
Store and forward techniques can help reduce the contention for system resources during business hours. Store and forward can also reduce the amount of traffic in the system based upon the routing tables defined within the system. Instead of having one machine send the same file to multiple machines, for instance, a cascading forwarding mechanism can be used. This also improves the system performance as files are sent a minimal number of times to certain devices which then forward the files on to other devices.
What are Some Limitations that May be Encountered?
File transfers in a distributed environment are not confined between hosts. File transfers can take place in a bi-directional fashion between hosts, servers and workstations. Due to the geographical disparity and number of devices in these environments, file transfers will increase the traffic over the network and will require careful scheduling to ensure that the necessary file transfers take place amidst the rest of the processing.
Managing Hardware (9354)
Managing hardware is all hardware directly used to manage the environment. This includes all staging components. These components are devoted to systems management functions. Examples of managing hardware include management servers, management controllers, management consoles, probes, and sniffers. One significant component in the hardware monitoring arena is Firewall access control policy management. Firewalls are regularly used for network based security management. It is typically a system or group of systems that enforce access control between two or more networks and/or perform network data packet filtering. Usually packet filtering router hardware and application gateways are used to block unauthorized IP packets and enforce proxy defined user commands.
Failure Control (9356)
Involves the detection and correction of faults within the system whether they be minor (e.g., workstation is down) or major (e.g., a disaster) has occurred.
Disaster Recovery
In the event of a significant system failure, Disaster Recovery processes will be invoked to re-route the system resources to a secondary, stable configuration until the primary resources can be restored. Within a distributed environment, disaster recovery must account for differing levels of disaster whether at a central or distributed site(s).
Fault Management
When a negative event has been brought to the attention of the system, actions are undertaken within Fault Management to define, diagnose, and correct the fault. Although it may be possible to automate this process, human intervention may be required to perform at least some of these management tasks.
Implementation Considerations
What are Some Limitations that May be Encountered?
In order to correct faults in a distributed environment, remote fault diagnosis and correction tools may also be required. It may not be possible to count on having technical expertise on-sites, forcing fault management to be handled from a centralized area. Products which perform these functions at present, however, provide somewhat limited capabilities in this arena.
Recovery manages all of the actions needed to restore service delivery after a system failure. With critical business applications being rolled out on distributed technologies, the recovery of these systems must be easy, quick and efficient to guarantee availability of core business systems as expressed in the agreed service levels and operational levels.
Hardware Maintenance
Hardware Maintenance maintains all of the components within a distributed system to protect the investment of the organization. Generally agreed upon in the SLAs, maintenance contracts are carried out, monitored and recorded for each asset as appropriate.
Implementation Considerations
What Will the Hardware Maintenance Targets Be?
Different hardware components will likely have different maintenance targets. These targets should be defined based upon information provided by the vendor as well as information provided from other client engagements.
Where Will Hardware Maintenance be Required?
Hardware Maintenance may be required at both the central and remote locations. Careful consideration must be given as to how the hardware at remote locations will be maintained (e.g., by a local expert, third-party vendor, etc.)
Monitoring (9358)
Verifies that the system is continually functioning in accordance with whatever service levels are defined.
Event Management
An event is an electronic message generated by any component (e.g., application software, system software, hardware, etc.) in the system. Event Management receives, logs, classifies and presents event messages on a console(s) based on pre-established filters or thresholds.
Implementation Considerations
What Type of Events Will be Monitored? More Specifically, What Services Need to be Monitored Across which Devices (e.g., Servers, Workstations, Routers, Hubs, Bridges)?
The scope of events to be monitored will have a major impact on the approach taken for Event management and the tools selected.
Where Will Devices Reside on the Network, and how Frequently Will they be Polled?
The number of devices, their respective locations and polling requirements will significantly contribute to network bandwidth usage.
Where can Event Filtering be Applied?
In order to reduce bandwidth, it is preferable that event filtering be performed locally to avoid sending all event information across the network, utilizing bandwidth and central processing capability unnecessarily.
What Management Protocols Need to be Supported?
The protocol requirements will impact the selection of the tool. For more information on management protocols, refer to the management protocols using SNMP and CMIP as examples.
What are Some of the Limitations that May be Encountered?
The number of events generated in the system will increase due to the complexity of the system. Devices will generate events as well as applications, the technical infrastructure, etc. Common event handling mechanisms will be required to provide management information in a simple, consistent format and to forward important events on for management purposes. In addition, filtering capabilities may also be needed at remote locations to prevent the streaming of events to central/master management consoles.
Performance Management
Performance Management ensures that the required resources are available at all times throughout the distributed system to meet the agreed upon SLAs. This includes monitoring and management of end-to-end performance based on utilization, capacity, and overall performance statistics. If necessary, Performance Management can make adjustments to the production environment to either enhance performance or rectify degraded performance.
Physical Site Management
Physical Site Management monitors the central and distributed sites environmental and regulatory levels. Physical Site Management ensures that adequate power, cooling facilities, fire suppression, etc. are provided and maintained to prevent system outages. When necessary, corrective actions are issued and monitored according to pre-defined environmental control plans.
Implementation Considerations
What are Some of the Limitations that May Encountered?
Important to ensure that adequate power, cooling facilities, fire suppression, etc. are provided and maintained to prevent system outages from external environmental factors. With increased computing power at multiple sites, these tasks may not be simple.
Physical Environment (9360)
The physical environment includes all the support indirectly involved in maintaining and managing the distributed environment. Initially it was thought client/server technology would make data centers obsolete. However, with the migration of mission critical processes to client/server environments, many servers are being maintained in data centers in an effort to increase reliability. As a result, the importance of managing the physical environment has increased. Partially because it was initially believed not to be very important and because it does not relate directly to the information systems, the physical environment of the operational architecture is often overlooked. These systems include UPS, raised floor, power, site survey and preparation, wiring/cabling, climate control, etc.
Related MODE functions The breakdown the MODE functions by operational architecture layer is meant to provide a guideline. The MODE functions mentioned within each component are applicable to that component though the function may not be included in that component. For example, Physical Site Management relates to the physical environment in that the physical environment contains the hardware managed through Physical Site Management. Physical Site Management tools do not necessarily reside in the physical environment layer. Some MODE functions do not require the use of a tool, while other MODE functions have tool solutions that work in different ways. For this reason some functions were included in multiple layers while other functions were omitted.
Implementing (9362)
Executes change within the distributed environment with tested components and techniques according to the appropriate plan(s). Implementing includes such things as: initial installation, software & data distribution, license management, etc.
Initial Installation
Initial Installation prepares the physical location for the rollout of a new site or service, pre-assembles the equipment (hardware and software) based on developed specifications, installs the equipment and tests that the equipment is fully functional prior to allowing the users to utilize the system in a production environment.
Implementation Considerations
Some Guiding Principles:
Precise build procedures must be delivered early enough to drive Release Testing, Procurement, and rollout plans. It must be clear exactly what the install process will cover. Who will perform which tasks when and where? Software and Data must be available in time to create copies for the hangar. This means development teams need to ensure availability of software up to a number of weeks before going live.
To What Extent Will Configuration be Performed Centrally Prior to Installation?
Some of the configuration tasks can be performed in a central hangar. Assembly of the machines may include configuration and software installation. Only minor tasks, such as setting networking addresses have to be performed after the equipment has been delivered to the remote site.
Product Considerations
What is the Intended Use of the Tool?
Prepare physical locations and devices (both HW and SW) for new rollout based on developed specifications and perform installation and functional testing of new devices prior to release to the users.
What Other Utilities are Available with the Tool?
Initial Installation must be able to load rapidly, reliably and consistently a large number of devices with a standard configuration. Automatic update of asset data accordingly, asset inventory must reflect the actual state of the devices; their set up and their networking address.
How Well does the Tool Integrate with Other Tools in the Environment?
During Initial Installation, software and data is loaded at the machines. The Software & Data Distribution function may be used to ship software and data to the location where it is to be installed (e.g. remote sites).
Procurement is responsible for ensuring that the necessary quantities of equipment (both hardware and software) are purchased and delivered on-time to the appropriate locations. Procurement is also responsible for logging all assets into the inventory as they are received.
Implementation Considerations
Will Equipment be Resourced from Multiple or Single Suppliers?
It is likely that organization will have close and long-term relationships to certain suppliers. In many cases, suppliers will offer discounts to their most loyal customers. These partnerships are advantageous for both sides, as long as they do not lead to supplier lock-in, i.e. the organization becomes technically dependent on one supplier. Technical portability and interoperability help support independence.
What Will be the Payment Policy (Immediate or Delayed)?
A management decision is required, which compares cash flow benefits through payment as late as possible against discounts for early payment. This will usually be an extension of an existing policy.
Monitoring (9364)
Verifies that the system is continually functioning in accordance with whatever service levels are defined.
Physical Site Management
Physical Site Management monitors the central and distributed sites environmental and regulatory levels. Physical Site Management ensures that adequate power, cooling facilities, fire suppression, etc. are provided and maintained to prevent system outages. When necessary, corrective actions are issued and monitored according to pre-defined environmental control plans.
eCommerce Application Framework
An eCommerce Application Framework 9400, which may be used to implement the various aspects of the VTrade system set forth above, is illustrated in
Framework Overview
The eCommerce market is rapidly emerging. This is evidenced by the growing numbers of new eCommerce transactional sites, the increasing number of 'exchange of value' transactions performed daily, the emergence of new entities and businesses focusing on the electronic marketplace, the convergence and partnering of existing businesses on the electronic marketplace, and the empowerment of the everyday user to satisfy their needs within the evolving electronic marketplace.
One definition of eCommerce is: 'A commercial exchange of value between an enterprise and an external entity—either an upstream supplier, a partner, or a down-stream customer—over a universal, ubiquitous electronic medium.'
The eCommerce Application Framework includes several portions which may be used in a VTrade system, including: external agents 9402 which perform tasks automatically, electronic merchandising 9404 for performing eTransactions, relationship management 9406 for managing interactions between parties to a transaction, maintenance and administration 9408, order processing 9410 for managing the transaction, customer services 9412, security 9414, decision support 9416 and integration 9418.
The eCommerce Application Framework (eCaf) identifies and describes the application capabilities useful or necessary to implementing eCommerce business solutions. It provides a framework to tie business process, application, and technology aspects of eCommerce together, and a basis for mapping and assessing the capabilities of the eCommerce packaged solutions. This framework should be used as a vehicle for communicating, and designing eCommerce business solutions.
The eCommerce Application Framework has been created to provide an understanding of the types of services and applications needed to implement an eCommerce solution.
The eCaf defines a supporting middle layer between basic Internet or Netcentric enabled products (eCommerce Package Software) and the technical infrastructure (Enabling Technology) needed to develop eCommerce-enabled web sites based on a business-specific selling model (eCommerce Selling Models). Note that eCaf just covers the middle layer.
Each solution or site may have a different selling approach, architecture, utilization of technology, or applications. The eCaf includes the concepts, applications, and services common across the different solutions and has organized them into application capabilities.
Technologically eCommerce business capability requires a logical grouping of services enabling a specific eCommerce functionality. The functionality may be a single technical service within the underlying architecture or an entire application. The capabilities have been derived from surveying multiple eCommerce software packages and eCommerce implementations. As eCommerce evolves, the categories and capabilities are apt to change.
eCommerce Application Framework
The eCommerce capabilities illustrate the highest level categories of eCommerce capabilities: External Agents, Electronic Merchandising, Relationship Management, Maintenance & Administration, Order Processing, Customer Services, Security, Decision Support, Integration.
The capabilities within a given category may cover the full range of potential selling models. Some components may be specific only to a business-to-business buyer-centric implementation. Additional components may emerge as this technology matures.
eCommerce Enabling Technology
The enabling technology for an eCommerce implementation is the same underlying technology used to enable most Netcentric (and in some cases client server) implementations. In general, most implementations will utilize the Netcentric technologies. An understanding of the Netcentric framework will act as a building block for understanding the technology aspects of an eCommerce solution.
eCommerce Selling Models
A wide variety of eCommerce solutions fall under the broad umbrella term of "eCommerce." The vague definition of eCommerce lends itself to a range of implementations and possibilities. A survey of the sites within the current electronic marketplace reveals the majority of the transactional 'exchange of value' solutions concentrate on selling 'products.' Products can be further divided into physical and electronic.
Across the many 'exchange of value' sites, there are three prevalent selling models: seller-centric, buyer-centric, and auction.
Seller-Centric Selling Model
The seller-centric model is the most common. In its simplest form, a company typically provides information about their products and gives the customer the ability to place orders. More advanced implementations use electronic means for supporting the entire sales and support process including: marketing, product display, merchandising, customer needs assessment, order processing, and many other activities. In most seller-centric solutions, the infrastructure is created and maintained by the merchant. The customer needs nothing more than a browser and/or access to the site.
Buyer-Centric Selling Model
In a buyer-centric solution, the main focus is on customer or buyer trying to fulfill a need for a product. In contrast to Seller-Centric sites which offer products, a buyer-centric site displays items the buyer would like to purchase—in effect trying to lure sellers. Many of the same capabilities as seller-centric sites are needed such as order management and payment capabilities. In this case, the customer joins or creates an infrastructure focused on fulfilling his needs. The infrastructure typically provides an environment between the trading partners which promotes browsing and comparing products, ordering products, fulfillment, payment, and any needed customer support services. A concentration should be placed on the ease of transactions and information flow. For this reason, sellers may customize their product line to the buyers' specific needs.
In most buyer-centric cases, the buyer or often a consortium of buyers, provides the bulk of the eCommerce infrastructure. Additional integration and setup may or may not be required for each of the trading partners who wishes to participate. Implementations requiring sellers to specially configure or integrate their own systems in order to participate are usually only successful where the buyer has substantial market power in the relationship, as in GM� or Ford� (buying parts from their suppliers. In such cases, agreements must be made as to what information is to be shared, how to model the information, the standards for messaging and communication, and what technologies will be used. Besides the technical hurdle of integrating multiple systems and the somewhat immature state of the software products to date, convincing trading partners to adopt an Internet commerce approach can also be very difficult. If one is not a particularly big or powerful buyer, it can be difficult to attract potential sellers to come to one's site and spend the time necessary to learn about one's needs. This requires sellers to engage in a very different activity than they have traditionally performed and many are not eager to change their way of doing business for a relatively small customer.
This section of the market has been slower to emerge. As mentioned above, trading partner maintenance is a key issue. Companies at the end of the hub must buy into the hub's practices and vision. Future vision and direction are also important. As changes are implemented, all trading partners have to move together. Getting buy in from all partners has the potential to slow down the adoption of new technologies and process innovations which over time can lead to a lack luster lowest common denominator approach.
Broker Selling Model
Broker or auction type solutions are also emerging, albeit more slowly. Broker implementations don't typically sell their own goods, but rather provide an eCommerce environment to facilitate bringing multiple buyers and sellers together. Both buyers and sellers can utilize the broker's site and infrastructure rather than developing and maintaining their own eCommerce capabilities. In this case, a broker has set up the infrastructure needed to buy and sell goods. The infrastructure will be very similar to a seller-centric solution with the addition of components needed to register goods to be sold (or in a buyer-centric twist—register RFQ's 'request for quote'), price negotiation and bidding, and reconciliation services.
A Trading Network (TN) is an excellent business example of a broker site. Users of the TN can issue Request For Quote's (RFQ'S) on the trading network. The request could be for raw materials, components, or finished items. Suppliers are free to answer an RFQ providing they meet some basic guidelines and requirements. The network provides a true win—win relationship. Since the network can be global, suppliers the purchaser may never have known about are free to participate.
Another example on the consumer side is a sales website. Such a site offers a variety of computer, electronic and fitness goods as well as a general merchandise auction. Customers can browse items in order to view product information and their current bid prices. Interested buyers can place a bid online and see how their bid price compares with others. The auctions are time based and follow a detailed bidding process. As customers are out bid, they are notified via email and have the option to reply with a counter bid.
Packaged eCommerce Software
In relation to packaged eCommerce Software, the eCaf framework provides a basis for understanding and assessing the capabilities of the eCommerce packages.
If a package is used to implement part of the eCommerce solution, an analysis of its underlying technology and business requirements with respect to the Netcentric Framework and the selling models should be conducted. It is important to understand the underlying architecture and any inherent application limitations due to the package's choice of technology used to implement its architecture. In short, it is important to understand what comes 'out of the box.' Be sure to understand each of the main components described by the Netcentric Framework (e.g. Web Browser, Web Server), how the components communicate, and any limitations of the package and architecture of the component.
A multitude of different packages are emerging usually with the name sounding something similar to 'eCommerce Server.' Each package may boast to be different in the problem it is addressing, the architecture, or the underlying processes and technology. In addition, it may claim to provide an 'end-to-end solution' for businesses wishing to transact on the Internet. It is currently very difficult to differentiate between the products. The eCAF provides a basis for understanding and assessing the capabilities of existing eCommerce packages as well as those emerging.
The current eCommerce software packages can be classified in the following categories:
A complex eCommerce solution potentially may utilize software from all three of these categories in addition to any custom code needed to integrate them.
The Relationship Management section of the Ecaf, shown in
Personalization 9600
Personalization is the continuous process of collecting, analyzing, and using information about the end-user in order to improve the productivity and value of their interaction with the organization.
The purpose of personalization is to interact with the customer/user with the hopes of establishing and building a relationship, increasing sales by catering to the individual customer's needs, cross selling or up selling, and enticing users to return to the site. Unlike any other broadcast medium, the Internet was designed for two-way interaction, hence providing the ability to narrow-cast or customize the interaction to the individual user.
Generating demand for a site's products or services and building customer relationships are crucial for any eCommerce implementation. This is even more evident in seller-centric implementations and hype or marketing driven implementations. The customization can occur in many forms. The services and infrastructure can vary drastically depending on the extent of personalization desired. Each eCommerce package may approach personalization using different services and infrastructure.
The enterprise complexity of the personalization approach will drive the architecture components and application required to implement and deliver this strategy. It is critical for the enterprise success to understand how the personalization strategy will affect the entire enterprise.
Conceptual Personalization Architecture
The conceptual personalization architecture is independent of enterprise or industry.
Implementing a personalization strategy into an existing system or a new one requires the design and development of personalization architecture components.
These components are essential to the success of the personalization strategy. They include an Identification component 9610 to identify the user, Information Capture component 9612 to capture information about the user, Content Catalog component 9614 to manage the different contents in the system, Matching component 9616 to match the user's profile attributes with the correct content, Merge & Deliver component 9618 to deliver the content to the user and an Optimization & Administration component 9620 to continuously optimize the personalization interaction and administrate the rules and content as they change or added. See
Personalization Techniques
There is currently a lot of hype and press attention centered on the idea of "personalization". Given the wide variety of products and ideas being labeled "personalization", it is apparent that a variety of different personalization delivery techniques and technologies are evolving. As with most emerging concepts, the initial techniques cover a wide range of complexity in both infrastructure and approach. Most personalized sites use a combination of techniques. Samplings of personalization techniques are presented below:
User Acknowledgement
Personalized Interface
This technique filters the information or content displayed to the user based on what is entered by, or known about the user. Many personalized sites use some form of content filtering. A variety of different filtering techniques have emerged. Some are adaptations of traditional client/server techniques adapted to the Web. In the first grouping of techniques presented here, the user controls how the information is filtered.
This technique simplifies a complex process or repetitive task by storing the user's preferences and inputs required to complete the process. In most cases a series of pre-defined questions and preferences have to be set up in order to use this functionality. 1-Click purchasing can be offered which allows a user to select an item with a single click and purchase the item—by-passing the order selection, order form, shipping and payment pages. A Fastpath approach can be used where the user has performed the function before and allowed the application or web site to retain more static information like shipping address.
Pre-Filled Forms and Information
In situations where user data is required to complete an action, the site can use information that it currently has about the user to pre-fill the form. For example, the site may fill out the order form with the user's last address and order information or the site may fill out the list of items ordered last. This approach differs from Fastpathing in that the user still sees the pre-filled form and has the opportunity to change the data.
Personal Assistant
The site provides an interactive assistant to deliver 'personalized help and assistance'. Its purpose is to help the user with difficult actions and site functionality. Based on observing and recording how often (if ever) the user has used a give function within the site, tips, suggestions, and other forms of assistance can be fine tuned to the user's level of experience.
Non-Interactive Delivery Techniques
Most of the personalization techniques described above are interactive personalization techniques. Content and information is personalized for the user in real time—while the user interacts with the application or site. Some forms of personalization can also be used in a non-interactive, or "push" mode.
"Push" (or "server-push") is where the delivery of information to a user on the Web is triggered and initiated by the information server rather than by the user.
In fact, the information pushed from a server to a user actually comes as the result of a subscription-like standing request created by the user and either stored on the server or on their local machine. This program captures and stores the user's profile locally and then periodically initiates requests for information on the user's behalf from the server.
Push technologies enable an enterprise to reach and provide value to their customer outside of the traditional interactions. Of the personalization techniques described above, content filtering doesn't require that it be delivered though an interactive session. Keep in mind that push does not necessarily mean personalized. A site may simple push the same information to all users or subscribers. Personalized push refers to information that is filtered based on a specific user's request or profile or where the delivery is scheduled for a specific user. There are a variety of different legitimate business reasons to push a users information. The following are some examples of personalized push:
Don't be a junk e-mailer. The push medium is powerful and potentially less costly than conventional mail. This doesn't justify its use as junk mail. It does not work because everyone receives junk mail, and junk mail that ends up in the trash is failed target marketing efforts. Personalize it. Deliver valuable information that the customer is interested in. Allow them to select the topics, how to filter the content and the frequency.
Personalization Process
Personalization is actually a catchall for several underlying technology capabilities needed to create a personalized interaction between an organization and a user. By breaking the underlying technology and logic into simpler components, one can build an understanding of the processes and technology needed to deliver personalized applications.
Personalization is the continuous process of collecting, analyzing, and using end-user information in order to improve the productivity and value of their interaction with the organization. Implicit in this definition is the need to do a number of basic things. Simply put, there needs to be some method for identifying the user, collecting (or detecting) and storing user information, analyzing it, assessing what content or functionality is appropriate, and present it to the user.
Personalization will continue to be adopted by the market place. Numerous sites have incorporated personalization techniques into their sites and the marketplace is full of independent software vendors creating personalization related software.
Each enterprise must assess their personalization opportunities from their own perspective and develop their own personalization strategy. The personalization strategy must be integrated with the enterprise's existing customer relationship, technology and eCommerce strategies.
Developing a Personalization Strategy
Using the Opportunity matrix given below, the opportunities where personalization typically delivers the most value in within the Interact domain. This area consists of opportunities where the organization is interacting with the user or the user is attempting to engage in a dialog. The publishing slice and Knowledge Management aspects of the Interact slice are the areas which are typically the secondary areas of personalization opportunity with the transact slice being last.
Research and product
Integrated design
products and
Product information;
Market of One
Product availability
loyalty programs
Plan and
Publish policies and
HR & Finance info
HR & Benefits
When evaluating what opportunities exists, all areas should be considered. The value of the personalized interaction will be dependent on many factors such as the type of products and services (can they be personalized?) or the type of relationship with the customer or consumer and the ability to capture user information.
A formal personalization strategy should be established that included the near term goals and future vision. Many companies jump right in without any guidance or realization on how they are growing or enhancing the enterprise. The strategy should begin with the big picture. Perform an examination of the critical forces affecting the enterprise and how these forces affect the business process. What are the drivers? Society, marketing, technology, business/industry? With the personalization market emerging, there are still with many unproven business cases and unproven technology. Firms should not engage in personalization simple because they can, nor should they fall prey to the unproven expectations generated by vendors or marketing hype. Firms considering personalization must frame personalization in the context of true enterprise goals (increasing customer retention or increase customer extension), then determine how personalization will help accomplish these goals.
The personalization strategy should evaluate the complexity of the personalization, the cost and time to implement and the potential business impact. In many cases, a true one-to-one personalized site may not make sense. Creating millions of varieties of a product will only complicate the interaction to the point that the user is overwhelmed. In some cases engaging in simple personalized dialogues may be the best near and midterm solutions.
Since different users may wish to interact differently, there may be many right answers to the personalization strategy. Some users are self serving and want to have the tools to explore or make choices on their own, others want immediacy, others may want intimacy such that their feed back and options register with the company. See
The type of dialog that the site engages with the user may vary based on the user. In some cases no personalization or customization should be performed. As more information is captured on the user, the correct type of dialog should be assessed.
Determining the correct touch points and level of complexity of the personalization techniques is an important part of the enterprise's personalization strategy.
Common Impediments to Personalization
Listed below are some of the common impediments to personalization.
The architecture components and processes will differ depending on the type of personalization technique implemented. For each technique, there are important considerations and differences that should be understood. Each technique will vary in approach, information required, and delivery. The following items should be considered:
These questions can be answered in many ways. The impact the answers have is dependent on the enterprise and its personalization strategy.
A few specific techniques to consider are detailed here:
The first task of the personalization engine is to identify the user. Unlike the everyday person to person interactions where a person relies on recognizing the another's face, voice or other attributes to identify the other person, identifying a user on-line can be a difficult process. The simple task of identifying users does not prove to be a simple task at all. A system may personalize an interaction based on the information captured during a single session or information gathered over the entire duration of the relationship. Regardless, the information that is captured needs to be associated with the user. In order to track a user, an identification or tracking mechanism needs to be created.
Identification Techniques
A variety of techniques can be used to identify the user. The technique may depend on the site's security requirement and privacy concerns. Today, the most common approaches are to either create a cookie on the client machine or to have an identification system on the server, such as a user login. In the future, digital certificates will be more prevalent, and should become the dominant identification method.
Client Side Storage—Cookie
A Cookie is a small text file placed on the client machine's hard drive by a Web server. It is essentially a user's identification card, and cannot execute code or deliver viruses. It is unique to the user and can only be used by the server that issued it. Although this is a common method for identifying a user, there are many risks associated with it.
This technique requires the user to log-in or sign on to the site. This requires the creation of a user ID and password to utilize the system and the resources needed to validate and store the ID and password. With this technique, the user must remember their log-in name and password. Additional services to lookup log-in names or request new passwords should also be provided.
Certificates and Digital Id's
In every day life people carry different forms of identification; a person's on-line identity may be no different. Modern cryptographic technology offers certificates or digital IDs that will serve as electronic forms of identification. Digital certificates are still evolving and the key players and details on how the pieces tie together are still falling into place.
One example of an effective use of a certificate is Firefly Passport. There the certificate is tied to a list of user profile information. (Microsoft purchased Firefly for this technology. The name is apt to change over time.) The Firefly Passport gives users an application with which to control their personal information and payment details. The information can be dispensed selectively to third parties to use.
A combination of techniques may also be used. The cookie may be used for the initial identification or the default ID for the Log-in process, while the server side log-in process would then be used to verify the identity of the user. It is important to make this process seamless and unobtrusive. The identification process should fade in the background. It should be present yet invisible and unobtrusive.
Relating Multiple ID's
Creating a log-in or sign-in process introduces the traditional problem of multiple log-ins, (or ID's) from a site or enterprise perspective. If a user forgets their login, they may simply create a new one. This may result in multiple logins for the user, and any information related to the previous login is not associated to the user's new one. To prevent this, a facility to look up existing login names or request a new password should be provided.
As in the client/server world, a single or universal log-in is advised, especially for systems that wish to personalize their site's interaction. If the enterprise already has an existing user base, pushing out IDs to users or allowing the ability to re-use the existing ID should be encouraged. For example, United Airlines created a PIN (Personal Identification Number) for each of their Mileage Plus members that provided access to the Mileage Plus section of their Web site and pushed (physically mailed) this out to the respective user. The PIN was their mileage plus number with a password associated with it. By doing this, they were able to reuse their existing identification process and login IDs.
Information Capture 9612
The personalization process is data intensive and is driven by the information collected about the system's users. The more information the site collects and retains about a user, the more likely it can add value and interact on a personalized level. With out this crucial data, there is no basis to shape the interaction or drive the personalization techniques.
Personalization Profile
The information collected about a user is considered the user's profile. Logically, this is everything the enterprise (site) knows about the user. Attributes from the user's profile will be the input to the personalization process and the driving data for the different personalization techniques. A profiling strategy should be developed by the enterprise that addresses what information to capture, the sources of this information, the methods to capture it, and how this information will be stored. If the customer is to be treated the same at all points of interaction, a common profile should be developed that is shared by all departments and applications.
Determining what information to capture or what attributes make up the user's profile can be a difficult process. In most cases, the profile will be based on the enterprise's personalization strategy, the personalization techniques to be implemented, the data required to implement them and a mix of any user information deemed usable that can be captured. In general, the site needs to capture the information required to perform the analysis aspect of the personalization process for each of the personalization technique to be implemented. This information might include:
Each personalization technique may require a different set of attributes from the user's profile. The information needed to deliver a 'Site Controlled Contextual Inferences' will be very different than the information needed for 'pre-filled forms.' Site Controlled Contextual Inferences Content Filtering requires the creation of rules and the necessary user information that satisfy the rules or 'Contextual Inferences'. (The information required to satisfy a rule is referred to as Personalization Matching Factors (PMFs) and will be discussed in more detail in the Matching Logic component.) For instance, the rule may be based on gender, age, purchase history or customer demographics. On the other hand, the information that is used to Pre-Fill forms may be a different set of user profile attributes. For example, this might be name, address, shipping information and payment information. Another personalization technique may use the same set of user information or may require another subset of user data.
Physically, this data may come from many sources within the enterprise. Information may be gathered directly from the user's interaction with the personalized site through implicit or explicit information gathering techniques. Information may be used from other data sources such as existing application's transactional data, the enterprises' data warehouse, or from other internal or external data sources.
The situation should be analyzed to determine if the 'profile data' should be replicated and stored in additional profile tables or if it should remain within the existing data source. Some personalization techniques will require additional tables to store the user's profile attributes needed to deliver the personalization technique. This will be discussed in more detail within the Matching section of the paper.
Profiling Standards
The industry has recognized the importance of personalization and the requirement of a user profile information to deliver personalization. To date, a profiling standard or definition of a common 'User Profile' does not exist. This means that each site will be required to capture and retain its own set of profile information. From a user's perspective, this introduces additional annoyance since they will be prompted by personalized sites for the same basic information. The Open Profiling Standard has been proposed to address this issue.
Platform for Privacy Preferences and Open Profiling Standards
The Internet Privacy Working Group (IPWG) began to develop the Platform for Privacy Preferences (P3P). P3P extends the Platform for Internet Content Selection (PICS) standard with notice and consent capabilities to enable automatic negotiation of preferences, policies, and information exchange. If P3P settings are accurate, Web surfers should be able to surf at will and only see P3P notices when they stray out of bounds of what is already approved in the profile.
Netscape, FireFly Network Inc. and VeriSign have introduced Open Profiling Standard (OPS), a proposed standard that helps to address the issues of multiple profiles. This proposed standard would provide Internet site developers with a uniform way of getting users' Personal Profile information in order to personalize interaction. The OPS is a standard being worked on as part of the World Wide Web Consortium's Platform for Privacy Preferences ("w3c.org"). It is compatible with the existing vCard and X.509 digital certificate technology standards, which allow for user identification and authentication over the Web.
Individuals will have a Personal Profile that contains their personal information, including their names, e-mail address, mailing address, and any other information they wish to provide. This profile will be stored on their personal computer (or securely stored in a corporate-wide or global directory). The first time that an individual visits a Web site that supports OPS, the Web site will request information from the Personal Profile. To protect their privacy, users can decide whether they want all or part of the information to be given to publishers, and which ones can see it. In addition, if the Web site collects additional information about the individual's preferences, it can (with the individual's permission) store that information in the Personal Profile for future use.
Some of the benefits to the user are as follows:
Users have the ability to selectively release or withhold information in their Personal Profiles, rather than the "all or nothing" process of accepting or rejecting cookies that the user cannot examine. OPS gives individuals both more flexibility and more control over personal information than cookies can.
P3P and OPS have common goals and have unified their projects. The governing term is now P3P.
Information Capture Techniques
Once the profile strategy has been defined and the sources have been identified, the next step is capturing the information. In many cases, the information comes from existing data sources. In these cases the data may require refinement or replication. The remaining information can be captured directly from the user's interaction with the site.
In most cases, the user will control the personalization process or technique. In these cases the user is aware of the personalization technique and chooses to use the interface that will deliver it. For example, a configured interface such as My Yahoo! requires the user to select the layout and topics they wish to display on the personalized page. The configuration (or setup) interface captures the needed information and adds this to the user's logical profile.
On the other end of the spectrum are information capture techniques that the site controls. The site collects information about the interaction. The interactive information capture techniques can be categorized as explicit or implicit.
Explicit Information Capture
Explicit information capture usually provides an interface to collect profile information. The site explicitly asks the user to provide the information. Examples of explicit information capture techniques are:
Implicit Techniques gather information about the interaction without directly asking the user. In essence, the site is recording the interaction in search of useful information. The user may be unaware that the site is capturing information. The most common implicit technique is clickstream analysis. The site records the user's actions, what they clicked on or where they navigated to, the content displayed, time spent or the duration a graphic was displayed. The information gathered is then analyzed for patterns and trends.
Information Capture Concerns
The goal of a personalized site is to increase the value of the interaction of the user with the organization. Unfortunately, the site has the potential to do the opposite. The personalization aspects of the site could actually offend or deter customers. The approach the site uses for information capture will play a large part in the personalized site's success. The following are some items to be aware of when capturing user profile information:
Information may also change over time. The user's interests or their marital status may change over time. It may be necessary to occasionally verify information. If derived information is stored, these may also become inaccurate over time. For example, driver status may change over time due to the occurrence of moving violations or a change in marital status. The same risks apply to information captured implicitly.
Today, the Web content of most sites is unmanaged. The enterprise does not utilize a method of tracking the content or the attributes of the content. Instead, the enterprise has a pool of content that may span multiple directories, departments and web servers. When content is created it is added to this pool of content by simply adding it to the Web server's directory and adding the necessary link required to display it. The content within this pool may be duplicated, outdated or unused. In short, the enterprise has no idea of the extent of the content or information about the attributes of the content.
Unmanaged content may be an obstacle for personalization. In order to deliver personalized content or filtered content the system must know what content exists and the attributes of this content. A content catalog 10000 or content management system should be used to manage the enterprise's content. A simple definition of a content catalog is given below.
What is deemed as content can take many forms. As illustrated in
Matching Logic 9616
This personalization component needs to provide the intelligence to match the user's profile attributes with the correct content and deliver this content to the user. Bridging the profile information to the content is truly the heart of the personalization architecture. A variety of different approaches can be implemented to accomplish this task. The complexity of this matching logic is directly proportional to how flexible, robust and dynamic the personalization aspects of the site are.
The Match concept is the process of analyzing the information that is known about the user and determining the correct content to display to them. Once the user profile attributes have been identified, they must be applied against the rules or matching logic defined within the site in order to determine the appropriate content to display. Three inputs are required in order to complete the Match process:
A simple example of this matching logic is a defined query. The site may provide the logic for a user to view their account information. In this case the profile information is their user ID or account number, the rule is the defined query (SELECT account_info FROM Account where Acct_Id=:User_Acct_Id) and the content is the user's account information stored in Account table. If the content is stored in a relational or object database, SQL queries are an effective method of accessing this data. In this case the 'defined rule' takes the form of a SQL statement. Unfortunately, most of the content is not stored in relational databases or is not directly related to something as simple as a user's account ID. Instead the content is web pages or massive amounts of news feeds and textual information. These situations require a different and possibly more complex approach and infrastructure to perform the matching logic. In this environment, the rules are usually composed of Personalization Matching Factors (PMFs).
Personalization Matching Factor (PMFs)
A Personalization Matching Factor (PMF) is the building block for a rule. It is the information required to perform the matching aspect of the personalization process. This is the demographic/psychographic/sociographic or any other information that will be needed to drive the personalization process. A PMF might be as simple as the user's gender or a complex attribute such as driver type that is derived from a group of data. Included in the definition of the PMF should be the definition necessary to create it.
Developing PMFs will require involvement of the Marketing department and other business entities that understand the customer strategy and the enterprise's customers. It is important to understand the customer needs, what the customer expects, and what makes a difference to them when determining and creating PMFs.
PMFs should be restricted to information that can be realistically captured by the site as well as information that is reliable and accurate. Conceptually, a PMF can be any piece of derived or any conceived information. For example, a PMF could be the user's gender, age, marital status, number of children, the number of years they have been a customer, their profession, driving record, interests such as sports, travel or other leisure activities, favorite color, a personality trait such as if they are detail oriented or pessimistic in nature, or any otherdemographic/psychographic/sociographic piece of information. How would this information be captured? What are the attributes that would be used to derive this? What is the accuracy of this information? Why is this PMF used to personalize? These are the types of questions that need to be asked when determining possible PMFs.
A PMF needs to have a clear definition and a finite list of possibilities. For example, a site may create a PMF called 'Age Classification'. The site would need to define what it means by the PMF 'Age Classification'. For this example, age classification is simple a logical group of users based on their age. The values would be:
Age Classification
Young Adult
Middle Aged
Senior Citizen
A PMF may also be a combination of low level data. If a PMF of 'Insurance Risk' were created, the required data would be far more than age. It would need to include age, driving history, vehicle, region and potentially other data.
Rules and Matching Logic
The PMFs are the building blocks for rules and matching logic. Unlike SQL extensions, there is no industry standard method for accessing 'Web' content and creating rules. Some approaches are detailed below.
The examples above are mainly site controlled. The site either has a pre-defined rule or matching logic that will execute. The site is responsible for determining what has been learned from the interaction, what is enabled based on the knowledge gained, what additional information will provide additional insight. Where possible, the users should be allowed to define the rules and matching logic or the content they wish to view. Provide the user the structure to create a rule or define a query.
Defining legitimate business rules and models is as important as the infrastructure to evaluate them. The rule may execute and content may be delivered but if the rule doesn't make good business sense the effort is wasted. Business and marketing personnel should be involved in defining the rules and verifying that they are correctly translated and technically implemented. This is another reason that the personalization team should include individuals from IT, the business and marking departments. The team needs to understand their existing and potential customer, the content available, and when and why to display it.
Merge and Deliver Content 9618
The rules for matching logic should be defined as stand alone entities so that they may be reused in multiple situations. Each situation may associate the same rule to a different interaction and a different set of content. The matching logic should be associated with a template or interaction and content should be associated with a rule result or condition of the matching logic.
One possible method of associating a rule and content to an interaction is by using a Dynamic Content Area (DCA). A DCA is embedded with a template and points to a specific rule, and a rule results set will be associated with specific content. For example a page may be explaining a particular service to a current user. The site may wish to display on the page a graphic that the user can relate to along with a list of benefits that are personalized to the user and finally list discounts that the user might be qualified for.
A separate DCA would be used for each set of data.
During the design of the site, a decision must be made to determine which areas of the site will provide personalized content to the user, the rules to use and matching logic associated with it, and what content should be displayed for each rule result. Since there is no face-to-face interaction with the user, identifying the content to use is very important. The web site must make the users feel as though they are being communicated directly. Once the page is requested or encountered by the user, the page is generated, and each DCA will request that a rule be executed and the content should be generated according to the user profile.
The normal delivery method of the content is through the use of HTTP. This method will be used to deliver the majority of the content. There are other methods of delivery that may be considered depending upon the content to be delivered. Other delivery methods include e-mail, FTP, Push or Channels and streaming video. Since timing of the delivery is very important, consideration must be given to developing a method of delivery that provides the most impact to the user and does so in a timely manner.
Administration 9620
Personalization is difficult for a number of reasons, but the biggest "gotcha" is that, above all, it requires dedicated maintenance staff. While much of the process of personalization can be automated, the construction of the business rules used to match content to visitors and the creation of the metadata tags required to classify all content still require a tremendous amount of human oversight. The need for such oversight is only compounded by the fact that personalization becomes exponentially more complex as the number of visitors and amount of available content increases. The net result is that firms that decide to engage in personalization without ramping up staff adequately will fail.
Personalization is a continuous process. It is not an application that is delivered and then left unmonitored or forgotten about. Personalization techniques will need to be added, removed and modified. Rules, content, and messages will change. Most enterprises fail to measure their return on investments, or to directly attribute customer behavior to certain initiatives. As a result, the enterprise often invests in initiatives, promotions and campaigns without understanding how they will affect product or customer profitability. Procedures, measurement and reporting devices, and metrics need to be created to allow for the enterprise to evaluate and improve their personalized interactions and deliver their customer strategy. The site may provide the customer a chance to make a purchasing decision. If they decide not to make this purchase, what is the reason why? The enterprise should attempt to gather information on why this result occurs and seek to prevent it in the future. The following optimization and administration components should be considered for a personalized site:
With the emergence of interactive mediums and the inherent capability to gather real time information about the customer interacting with the medium, enterprise's marketing strategies and systems are becoming more customer-centric. With the move from mass (or targeted) marketing to a form of customer-centric marketing, enterprises must evaluate their customer relationship model.
Traditionally, marketing models tended to focus exclusively on customer acquisition (mass marketing) and then on customer selection (micromarketing and target marketing). However, several studies have shown it costs between four and 10 times as much to acquire a profitable customer as it does to retain one. This awareness has resulted in a heightened emphasis on customer retention and extension and has been the driving force of relationship marketing.
However, customer retention and extension are less dependent on traditional marketing and are more tied to the value perceived by the customer during every interaction with the enterprise. In addition, these strategies require a different marketing infrastructure that is information- and customer-driven, rather than product- and creative-driven. Thus, relationship marketing is somewhat of a misnomer, as adding value to the customer relationship is not simply a marketing challenge, but rather a challenge involving every function within the enterprise. This business model calls for enterprises to differentiate themselves by consistently providing superior service at every point of contact with the customer.
The ShARE Model
The ShARE (Selection 9630, Acquisition 9632, Retention 9636, and Extension 9634) customer relationship model 10200 is detailed in
Selection 9630
The selection portion of the ShARE model deals with determining who within the general population will be a company's most profitable customers. Selection deals with determining who makes up a product's target audience, and allows a company to focus their attention more accurately. This is the area where demographic information, such as age, geography, and income are applied to produce a more finite list of likely customers. The selection process allows businesses to make strategic decisions such as NOT to market a snow shovel in Ecuador.
Acquisition 9632
Acquisition focuses on getting a potential customer to use one's service or buy one's product in the most efficient way. This area has traditionally focused on mass marketing and measuring a business' cost per thousands of consumers reached. The classic example of acquisition is Proctor & Gamble's use of daytime television dramas in the United States to sell soap, creating what is now called the soap opera.
Other methods of acquisition include direct mailings, telephone solicitation, toll free order numbers, and, more recently, Internet advertising and online businesses.
Now that companies know it is cheaper to hang on to existing customers than to find new ones, more and more emphasis is being placed on customer retention. Retention focuses on keeping customers for as long as possible. The most effective way to do this, is to provide excellent customer service at each and every interaction with the customer. Since electronic business don't provide traditional customer service, it is important web-based businesses have sites with appropriate support functionality. The support should be easy to use, and meet the specific needs of that product's consumers.
Recommendation Services
Recommendation functions may take up multiple formats. The most common format are simple services to allow the site's users to provide direct feedback, positive or negative, and recommendations about the content or products on the site. By providing these services, the site may create a community where users can interact with each other, furthering the site's worth. For example, a sict could allow for users to submit book reviews. The information is then available for consumption by the general public. While the technology to implement this is rather simple, the process may prove to be a little more complex. The process includes receiving input, reviewing recommendations, filtering and approving content, and then posting the review or recommendations. The lack of a filtration or review process could be devastating to a site.
Another type of recommendation service makes suggestions to its user base. These services can range from simple to complex. A more complex recommendation service may utilize collaborative filtering. Collaborative filtering is the technique of using content or product ratings from the site's user base to predict the interest other potential users will have in the content or products. Correlation algorithms use the profile information, history, and/or input preferences to construct a correlation group of users whose ratings are effective predictors for the new user. Prediction algorithms then use the ratings and profile information of the users to make predictions of the content they most likely will find interesting. (Note: The collaborative filtering technique could be implemented within the personalization system.)
Site Announcements and Event Reminders
Additional relationship building techniques are site announcements and reminders. The underlying services are again personalized. The site has created content which may range from new product announcements based on the customer's last visit or reminders of an upcoming event important to the specific customer. For example, an event reminder could point out an upcoming wedding, personal anniversary or holiday. The user, once reminded, may then utilize the site to act on the event. If the site implements complex event reminders, additional services may be needed to provide calendar and scheduling functionality. These services may also be incorporated with the off-site subscription services to provide reminders to users not logged into the site.
Loyalty and Return Customer Programs
Creating an environment that promotes customers to return to the site is critical for the longevity of the site. Many of the seller-centric implementations will utilize membership services and other incentive programs to try and promote customers to return. For example, site members would receive discounts and additional privileges, thus building a better relationship with the site. Incentives like frequent shopper points or access to member only information are other common methods. The loyalty programs may require additional logic for permissions and content filtering. Most of this may be implemented by gathering and using profiles and integration with a complex personalization system.
Return Programs are services geared toward enticing the customer to return to the site. The Internet eliminates two main factors affecting customer loyalty. The first is proximity. In the brick and mortar medium, customers tend to shop (or browse) close to where they live or work. The second factor is time or how long a store is open. With the Internet being 7 by 24 and geographically independent, these items are no longer relevant. For this reason, considerable effort may be geared toward creating return programs. The most common forms are electronic version of current methods, although they may be more effective due to personalization and real-time delivery.
Push and Off-Site Subscription Services
This section includes merchandising using email to push information to a user. (Note: Subscriptions to sites and information are covered in the Order Processing—Fulfillment component.) Many of the common services for storage, filtering, formatting and approving content would be utilized. Additional services would be needed to push the content to the desired mailing list. Details and considerations for using push technology is included in application discussing the Netcentric Framework, referenced above. Below are some basic services.
Extension asks businesses to answer the question, "How can one increase the loyalty and profitability of this customer?"
Cross Selling and Up Selling
Cross Selling and Up Selling are similar to recommendation services. Cross selling uses some knowledge of the consumer to suggest complimentary or similar products in which the consumer may be interested—"Would you like fries with that?" Up selling is an effort to sell more of the same thing, or a better version of what the consumer may currently be considering—"Would you like that Super Sized?"
Cross selling and up selling are considered an application or service enabled by complex personalization. Although very important from a marketing perspective, once the underlying services for complex personalization are in place, many of the demand generating applications are now possible. Cross selling or up selling could be implemented by product relationships in a database.
Maintenance and Administration 9408
One of the items altered based on the profiles of the users may include price, which may be altered to reflect a discount assigned to the user. A search may also be performed for the internal data in the e-Commerce system prior to the synchronization of the external data.
As an option, load balancing services may also be performed that initiate and stop processes as utilization levels vary in the e-Commerce system. As another option, managing of the contact information may further include tracking responses to the users of the e-Commerce system.
As with any system, a support, administration, and maintenance facility and procedures need to be put in place to remain operational as well as efficient. In general, packaged implementations will only provide minimal maintenance and administration facilities leaving the bulk of the burden to the integrator. The underlying technology for the facilities may be basic batch download/uploads, simple server processes and applications or even browser based. It is important to understand the system administration and maintenance needs, develop a plan, and stick with it. Some of the areas to consider are listed below.
System Monitoring Facilities 10400
The health of a system can be easily maintained by putting in place monitoring facilities and procedures for capturing the system's electronic vital signs. Far too often the users of a system are the first to know of system problems while the administrators are the last to know. This can be prevented by creating automated monitoring facilities for server processes, disk space, memory, CPU utilization, access time, number of connections, and other electronic vital signs. The complexity of these facilities is open for debate. In addition to online monitoring facilities, robust logging, audit trails, and archiving capabilities should be included. These will aid in analysis and forecasting of system needs.
System Administration
The term system administration is a vague term used to categorize the actions needed to support a system. This may include starting, stopping, or restarting servers or processes, scheduling backups and loads of databases or files, recovery procedures or anything else needed to maintain the system. Traditional system administration also includes updates to system software, packages, and operating systems. Listed below are additional system administration considerations an eCommerce system may encounter.
Merchandise Administration 10402
The merchandising aspect may introduce additional administration and maintenance. Procedures should be put in place to handle sold out merchandise and back order items. Updating merchandising content, currency, tax, and pricing may need to be performed on a regular basis. The merchandise administration facility should be able to handle pricing and discount items and have the ability to allow automatic updating and manual override capabilities for authorized administrators.
Personalization Maintenance Facility 10404
The biggest challenges in personalization are determining matching rules for the business's market plans, categorization of the profiles, gathering profile information, and then developing robust content with adequate content indexing. Once these have been established, they should be easily maintained. When designing the personalization services, maintenance of the rules and content should be considered. The people most likely driving this information will not be technology oriented, and may require simple interfaces for altering rules for marketing, advertising, or other personalized content.
Content Administration
As content is added, this information will need to be indexed and integrated with the search technology implemented at the site. Other items such as customer service chat discussions or review would also need to be purged on a regular basis.
Data Administration 10406
Many times, utilizing packages to implement an eCommerce solution will introduce a proprietary data model for customer and product information. In order to make this information accessible to the rest of the organization, the information will need to be synchronized with the enterprise data. Services may be required to determine changes and synchronize the data. This would be true for any information the site gathers not integrated into the enterprise data.
Load Balancing
In addition to the monitoring and maintenance facilities, services should be considered to stabilize performance. Providing the system is scalable, load balancing services would aid in initiating and stopping extra processes as utilization levels vary. Processes could be started to handle additional requests during peek periods providing the user with a consistent level of performance. This is extremely important in periods of peak usage. A good example is the fluctuation of the average response times of some of the current electronic trading systems during market surges. Times during a market surge were 2–3 minutes above their average 6–10 second response time.
Contact Maintenance 10408
Internet users are quick to point out mistakes and opinions for improvements. Sites will receive sporadic emails from users experiencing a variety of emotions about the site. Users may sour quickly if actions are not taken or noted to items pointed out. Responses to user feedback should be monitored to ensure that each message from a user is responded to in some manner.
Maintenance and Administration of the system is often wrongfully overlooked. It is a key component in improving customer satisfaction and building customer relationships. Having robust maintenance and administration facilities should increase the system's overall stability by reducing the time and cost to identify and fix issues, automating processes, and enabling system administers.
Implementation Considerations
Information Staging
The ability to deliver new products and information may be critical to stay ahead or match the competition. The speed at which the information can be updated and migrated to production is critical. Be sure to understand the relationship between the content changes and the correct procedures to migrate the changes to the production system. The ability to maintain and grow the site may prove to be key factors in the site's success.
In most cases, a content staging process should be put in place. In the simplest format, the procedures for modifying and adding content, testing, validation of content and subject matter, authorization and migration to production should be documented.
Order Processing 9410
A medium for receiving the payment may be via credit based payment, debit based payment, and/or electronic cash. Additionally, verification of export restrictions with respect to a selected product may also be allowed.
As an option, the ability to review, update, and cancel the order at any time may be allowed. As another option, electronic rights may also be managed. In even a further option, order tracking information about a status of the order may also be provided.
Allowing customers the ability to not just browse and interact but complete the purchased is crucial for a successful eCommerce solution. This section includes many of the capabilities needed to negotiate and perform the entire transaction. The transaction begins when the user takes action to purchase the item(s). From a seller-centric view, the transaction is initiated once the 'purchase' button is selected. The 'buy transaction' may include sub-transactions such as totaling, payment selection, inventory management and purchase authorization.
It is important to recognize some commerce packages specialize in the transaction processing portion of an eCommerce solution. For example, Open Market's OM-Transact, does not provide a catalog interface or any of the infrastructure for interaction with the potential customer. Instead, it will provide an interface for communicating with its transactional infrastructure.
Each implementation will require specific flow and business logic. The commerce packages available today provide generic order processing business capabilities that will need to be customized to achieve the specific needs of the business. Illustrated in
Merchandise Selection 10500
Some sort of merchandise collection facility is needed. All items of interest should be gathered and organized so they can be reviewed prior to purchase. The most common approaches are an order form or a metaphor such as a shopping cart or basket.
Independent of the medium, the following capabilities should be considered:
The check out phase begins once the user has decided to purchase or order the items gathered. A variety of capabilities may be required or may affect this process. Listed below are some of the services to consider during the check out processing.
Price Verification
Given the geographically independent environment and multitude of potential customer relationships, many factors may affect the actual pricing. The first step in the transaction is determining the price. The price in most cases will be dynamically generated based on the actual price of the items, taxes, fulfillment or delivery costs, and any other item affecting the price. Ideally, product prices, shipping and handling charges and other charges should be maintained separately. This functionality should include the ability to handle tax-exempt customers and transactions. Sales tax and value added tax logging and auditing capabilities should also be included.
In general, pricing is calculated dynamically. Discounts may be applied for many reasons either to specific items or to the entire order. Additional discounts may be given for using a preferred payment mechanism. Other implementations may provide discounts at the end of month based on total sales.
Taxes and Tariffs
The tax issues related to the buying and selling of tangible personal property or services through the Internet, are numerous and complex. Questions include what products and services are subject to tax, when and where to impose a tax on the retail transaction, and what tax (sales or use) the merchant is required to collect. Tax calculation functions with an integrated sales tax or value-added tax (VAT) engine, able to perform real-time calculations based on customer-specified product codes, order point of origin, shipper's address or recipient's address should be considered.
Due to these complexities, most solutions interface with a tax engine to reduce the risk and legalities involved with taxes. Most of the commerce packages available today interface with the leading tax engines.
Shipping Charges
Shipping charges may be applicable for items not fulfilled directly by the site. In some cases, the customer's shipping location may be used to determine their taxes and shipping charges. There are a variety of mechanisms for determining shipping charges. They include:
Order Information
Other basic order information may be gathered during the check out processing. The most common method is an order form. The form should be easily customizable and may contain a variety of information.
After a total has been established, a payment method must be determined. A variety of mediums can handle the transfer of money. The methods, flow, technology, and potentially messaging, will vary by implementation. Issues concerning security, liability, and relationship to fulfillment need to be worked out.
Listed below are some considerations for determining the payment flow and mediums to be utilized.
Payment Methods
There are a multitude of different vendors and technologies available for handling electronic payments. The infrastructure, process, and technology may vary dramatically from vendor to vendor. The actual mediums for the current payment options fall into these categories:
The fulfillment process can be complex and will vary depending on the type of goods being delivered. Integration to existing systems as well as communication of invoices and orders to distributors or trading partners will play an important role.
A tremendous amount of communication and back end processing will be needed. Often implementing an eCommerce environment opens the doors to review the underlying systems and processes. Potential areas include warehouse notifications and P.O. delivery. Print, fax, or sneaker net systems may be upgraded to EDI, email, or another electronic medium. Updating and improving these processes will be critical for providing customer support. Users will come to expect the ability to see the progress of their order as it moves from the site to warehouse to their desktop.
Electronic Distribution
Soft goods may take the form of information, software, graphics, music or any other digital content. Many traditional content providers have imported their content to the Internet. Although the revenue generation is less than what they achieve through their traditional channels of distribution, publishers and other entertainment providers have found the Internet offers a richer, more interactive environment to present their content. The Internet provides consumers the ability to search, evaluate, transact and personalize the content. The Internet will continue to be adopted as an effective distribution channel.
Site Subscription
A very simplistic form of soft goods fulfillment may be achieved by allowing the user access to the site. Functions to handle permissions and access would be required to prevent unauthorized users or actions.
A site subscription may be based on different metering technologies. Internet metering technologies can be divided into two categories: observational metering and usage metering. Observation metering measures site activity while usage metering measures the usage of items such as files, bytes or time.
Electronic Rights Management
Owners of digital content, including authors and publishers, have been searching for a method to protect against the unauthorized distribution of their works over the Internet. Most content available on the Internet today is freely distributed, often without consideration of the content owner's copyrights and appropriate royalties. Protecting Web content is a difficult task. Items such as copyrighted words, images and other 'digital' objects need to be protected from unauthorized (and endless) duplication. Currently, copyright notices can easily be stripped away. There are a few recent developments aimed at tracking rights violations.
Some rights management methods are geared toward identifying legal and illegal uses of a document or digital object. These concepts still require actively searching the Web for signs of abuse. In essence, the methods still allow the content to be extracted and used, basing the majority of the security on trust. Other approaches place a 'security wrapper' around the content so it can only be accessed by authorized users.
The information capable of being searched may include product information and also a status of the order. Also, the customer may communicate with the customer service representative by way of a chat room.
As an option, the purchase history information may also be compiled and displayed. As another option, information including policy documentation may also be provided. As an additional option, an on-line bulletin board may be provided for allowing input from a plurality of customers.
This category includes any component of the solution meeting a user's need normally filled by a human customer service representative. These services fall across the marketing, merchandising, order processing, and other categories. The customer service aspect of eCommerce is as important as selling the actual products. Just as in the world of the paper bill, a lack of customer service, or poor customer service, can destroy any relationship the user has established with the electronic business.
The business drivers for customer service are:
Conducting commerce on the Internet means allowing direct access to the system and its data. New users may have a much lower tolerance for hard to understand interfaces and site layout and may require considerable help understanding what information exists on the site and how to find it. Customer service will continue to be a key component in maintaining customer relationships.
There are a variety of different services to enhance customer service. Which services should be implemented are dependent on the goals and characteristics of the site. Below are listed the key customer services, which are also found in
Site Search 10900
Search engines have become a popular component of any information-intensive site. The ability to lead a user to the type of information he is looking for will not only make the interaction more efficient but enhance the customer relationships. "Search" is a generic term and may be used for searching for a specific product or may be implemented to search for a specific customer's order or other information.
Order Tracking (Order Management) 10902
Providing customers the ability to track their orders can provide tremendous benefits in reduction of support personnel and building customer relationships. Applications of this nature can range from simple to complex depending on the level of detail. The order tracking system should be integrated within the order processing's innate workflow system. Purchase history functions may also be provided.
Return Merchandise/Credit 10904
If the site sells goods, there is always the possibility of the customer returning the merchandise. As with most exception processing, this can create numerous problems, though the return should be allowed. Actually crediting a smartcard or replacing digital currency may be very difficult. The legalities and procedures should be thought out and documentation provided.
Help & Information 10906 and Troubleshooting 10908
There is a tremendous amount of help and information features a site may provide. Listed below are some of the more common examples.
Collaboration Services
Behind security, one of the leading reasons a customer will not 'transact' online is the lack of human contact. Although unbelievable to most technologists, there is still an underlying fear of computers hidden in a large percentage of the potential consumer base. Currently, most seller-centric sites do not provide a truly two-way, interactive, or collaborative environment. The site may have a complex form of personalization which will filter and deliver content geared to the specific user, but in most cases will not provide real-time customer interaction. Interaction may be delivered in the following methods:
For additional detail on collaboration services, please refer to the Collaboration Delivery Vehicle in DAF, found above.
Security 9414
The message digest may include a log of times when modifications to the data occurred. The authentication information may also include a digital signature. In addition, the authentication information may further include a certification. Further, the certification may include a user identifier, a service identifier, a public key which is used to verify the digital signature, a name of an issuer of the certification, a period which the certification is valid, and an email address.
In the last few years, computer crimes have exploded—hackers have defaced the web site of the CIA, stolen information and software from NASA and the Pentagon, and made unauthorized wire transfers causing banks to lose millions. According to WarRoom Research, financial losses from computer crime run at $10 billion a year. Historically, 80% of security problems have been internal ones—either from employees exceeding their level of authorization or ones that are disgruntled. Netcentric computing and eCommerce are increasing the risks due to rapidly evolving technology infrastructures. As access to corporate systems is extended virtually and new security holes are discovered daily, security issues become complex.
eCommerce, while providing immense potential business advantages, may also expose businesses to significant risks. If their systems are broken into, they are at risk to financial loss, embarrassment, lost customers, and potential legal liability. Businesses often hesitate to take advantage of eCommerce because they fear security problems. Although security technologies are continually evolving to mitigate these eCommerce security risks, security breeches occur because businesses fail to implement an appropriate mixture of security solutions.
The problems associated with connecting the network to the vast Internet are widely published. Hackers abound, and new methods for compromising networks are published almost daily. However, what about connecting the network to a partner for project collaboration, or perhaps a supplier for automatic inventory control? One might trust their supplier, however, does one really know how well their network is secured? Contracts and Service Levels can and should deal with many of these issues, however, technology can also be used to enforce security policies.
Once the correct mixture of security solutions has been implemented, the company will experience many benefits besides peace of mind that their site is secure. Security also allows people to conduct business functions over the Internet which previously could only be done in person or with a more private connection. This allows expansion into new markets and new business capabilities, increases efficiency, and reduces the cost of doing business. For example, in the typical electronic storefront scenario, security is enabling an unknown buyer and seller to exchange goods with a reasonable assurance that the transaction will be honored on both ends. Security can also be a selling point for a company's eCommerce services. By demonstrating an increased level of trust and reduced exposure to fraud, a customer may choose one merchant's services over another's. Furthermore, eCommerce technologies rely on electronic automated security rather than imprecise procedural security. This can result in more reliable processing and fewer errors.
Unless customers and users feel the system is secure and there is little to no risk involved with using the system, the implementation will not be successful. Depending on the system, the amount of security in the different security areas will vary. By securing all aspects of the site, it will make it extremely difficult for an intruder to work their way into the system without being detected. There are a number of different approaches which can be employed to provide system security. Among the most common, are firewalling, encryption, and authentication. Each provides a particular type and degree of security, and in many instances it makes sense to use multiple technologies together to achieve the desired result. Security must be built into a system extremely carefully in order to be effective.
The details of security in eCommerce will be discussed in terms of five eCommerce cross-component application types. The five application types discussed are:
VISA� and MASTERCARD� have jointly developed the Secure Electronic Transaction (SET) protocol to allow secure, cost-effective bank-card transactions over open networks. SET includes facilities for:
Consumers get their encryption keys using a specific program integrated into their browser. This program automatically converts a consumer's credit card number into a certificate given by VISA or MASTERCARD. This certificate contains a key and will be attached permanently to the browser of the consumer.
Then, for every transaction the consumer asks the merchant to send his certificate, and the merchant can ask the consumer's bank for authentication with the customer's certificate.
Full implementation of SET requires certificates be issued for each credit card a consumer wishes to use on the Internet. This raises enormous administrative challenges, as well as the problems involved in achieving this level of universal adoption.
Secure Environment 11002
There are different technical approaches for Internet security. The end goal of the security technologies is the same. It is important to pay attention to the approach and questions that they try to answer. For example Secure Socket Layer (SSL) and Secure HTTP (SHTTP) have been viewed as competing technology. SSL uses the TCPI/IP protocol to provide transaction security at the transport level. Security properties are linked to the channel of communication between the two parties. The issue they are addressing is channel privacy for a conversation or transaction. SHTTP provides transaction security at the document level. Each document is designated as private by the sender. This approach is addressing the question of authentication and authorization of web transactions.
Secure Date 11004
The first area to secure is data. It has to be ensured information is protected from unauthorized access. This is mostly important when sensitive data, such as credit card numbers or business figures, are transmitted. Data usually passes a long way before reaching its final destination and can easily be read by a third party. Data, therefore, has to be encrypted before transmission. Today several encryption techniques are used which ensure the data is unusable if intercepted.
In addition to encrypting the data, the parties involved in an electronic transaction need to know that the data received or sent is secure. Authentication techniques require the identities of the sender and receiver are known and the information sent arrives unaltered. Authentication can be accomplished with both the use of a message digest and a digital signature. Details on some of these techniques are discussed below.
Cryptography is an essential component in securing data. In the most basic sense, cryptography is encrypting and decrypting data using an algorithm(s) or key of some sort. Encrypted data is useless without the key to decrypt it. Today several encryption standards exist utilizing a wide variety of algorithms and keys. Details on some of the different methods can be found in the Security for Internet Electronic Commerce Security Technology Handbook.
Message Digest
A message digest is used to make sure no one has altered the message between transmission and reception. It is used to provide data-integrity. A digest is associated with a sent message. The recipient can re-compute the digest and compare the new one with the sent one. If they match, the message has not been tampered during transmission. The algorithm used to compute digest must be the same for the sender and the recipient. A message digest is a short, fixed-length digital code derived in a one-way fashion from a longer variable-length message. As a result, it is impossible to determine the original message on the basis of the digest or to find a different message with the same digest.
Digital Signature
Digital signatures ensure the message recipient only the sender of the message could have sent it. The sender signs a message by encrypting a digest of the message with their private key. No one but the particular sender could have generated the digest corresponding to the message. This provides authentication of the sender as well as non-repudiation of the origin. Encrypting a message digest also links the signature with the message content. The sender can't claim they did not send the message or the message is not the one they sent.
Some security techniques may require the use of a public key for encrypting data. When using a public keys, issues may arise with key management and verification. Often a trusted third party will be needed to issue a Certification Authority (CA) for keys and signatures. Certification Authority declares which public key and signatures belongs to which users and services. Because a user needs the CA public key to check validity of certificates, CA must provide a way to safely deliver its own public key.
A certificate typically contains:
The client environment should also be secured. Since systems may be open to public use, and accessible to a large audience, it could be subject to new types of attacks. An environment must have security mechanisms in place to control who can access it as well as controls on the actions these users may perform. This may be achieved using authorization models. Authorization models are used to determine which entities (for example, people or applications) can access specific applications, data, or resources.
With the onset on Netcentric computing, entire applications or other forms of executable content may be downloaded across a network. This style of computing introduces a variety of security concerns. Downloads may come in the form of applications, applets, ActiveX controls, scripts and a variety of other software. It is important to understand the different security concerns with the downloads.
Java Applets
Java is designed for developing programs to run on many different kinds of computers connected together in a network. A Java Applet is a special kind of Java program attached to a Web page. Applets are embedded into a Web page's HTML definition and interpreted by Java-enabled browser. It is possible to have users download the applet from the Web and run the program locally.
Running some unknown person's untrusted code is also inherently dangerous. For this reason, Java restricts the behavior of Applets to a set of safe actions (Safe applets are labeled as trusted applets). The Java security model restricts an Applet as follows:
Because of its built-in security model, Java addresses these risks head-on. Unfortunately, there are still holes in Java's security model which allow some risks. For example, applets could be created to perform various harmful acts:
ActiveX is a technology developed by the Microsoft Corporation for distributing software over the Internet. Like Java Applets, an ActiveX "control" can be embedded in a Web page, where it typically appears as a smart interactive graphic. Unlike Java, which is a platform-independent programming language, ActiveX controls are distributed as executable binaries, and must be separately compiled for each target machine and operating system.
The ActiveX security model is considerably different from Java Applets. ActiveX places no restrictions on what a control can do. Instead, each ActiveX control can be digitally "signed" by its author in such a way that the signature cannot be altered or repudiated. The digital signatures can then be certified by a trusted "certifying authority", such as VeriSign, to create the equivalent of a shrink-wrapped software package. If downloading a signed ActiveX control causes a machine to crash, the responsible party will be identifiable.
This security model places the responsibility for the computer system's security on the user. Before the browser downloads an ActiveX control that has not been signed at all, or has been signed but certified by an unknown certifying authority, the browser presents a dialog box warning the user this action may not be safe. The user can abort the transfer, or may continue the transfer and take his chances.
Scripting Languages
Internet scripting languages are programming languages embedded in HTML pages and are interpreted by the user's browser (for example, Netscape Navigator or Microsoft Explorer). Typically, they are dedicated to control the user's interaction with an HTML document, for example when:
As scripts are pieces of code from a foreign source executed on the user system, they raise security issues. Indeed, a user must be sure a downloaded script will not perform malicious actions against his system. Scripting languages designers have to manage the balance between security achieved through restriction, and language capabilities.
Secure Server Environment 11008
Securing the server environment will depend upon the technology and architecture of the implementation. Techniques and security models exist for the different methods of server-side computing. Included below is basic security information for some of the different technologies.
Internet Firewall
A firewall is used to protect a trusted network from an untrusted network.
Typically, the two networks in question are an organization's internal network (trusted) and the Internet (untrusted). A firewall is a system or group of systems that enforces an access control policy between two networks. A firewall is a collection of components or a system placed between two networks and possesses the following properties:
Common Gateway Interface (CGI)
Common Gateway Interface (CGI) scripts are a way of processing information submitted to the web server using a form. A CGI script can be written in any language able to use standard IN and OUT streams (usually Perl or C shell). To process a form, the client first submits the information content to the server. On the server, a CGI script reads the form contents, then uses it to write a new HTML page, which is sent back from the server to the client. Security problems with CGI scripts occur on both the client and the server sides.
CGI Client Side
Submitting a form to a CGI script, which is located on a server, implies the sending of the contents of this form over the Network. If the channel used is not safe, form content can easily be read and perverted. Any way of securing the channel, such as SSL, PCT, or S-HTTP, can be used to achieve confidentiality of submitted information. As these protocols must be implemented by both client and server, a user must check the server is able to secure the channel. Current popular browsers are able to warn the user if information is being submitted in an unsafe fashion.
CGI Server Side
Processing a form on the server, using server resources, such as system commands, can lead to security holes. Indeed, forms can be full of malicious content causing the server to perform confidential information delivery, server crashes, or unauthorized accesses.
The only way to protect a server from attacks through CGI script is to be very careful when writing, testing, and using CGI scripts. As far as possible, CGI scripts should avoid executing system commands. Each submitting entry should be checked and analyzed before being processed. Script sources must be hidden as analyzing the source of a script is the best way to find an efficient attack through it. On multiple user systems, the right to install CGI scripts should only be granted to the administrator or trustworthy users.
Common Object Request Broker (CORBA)
The Common Object Request Broker architecture is an open distributed object computing infrastructure standardized by the Object Management Group. CORBA specifies the interfaces, structures and policies used by distributed objects (components) to communicate independently of the language, operating systems, machine, or network.
The CORBA 2.0 specification presents a good set of security policies which provide authentication, data integrity, confidentiality and non-repudiation. The standard leaves to the applications the problem of handling the non-repudiation policies without conforming to the ISO specifications. The standard does not thoroughly solve the problem of interoperability between different security domains.
Distributed Component Object Model (DCOM) The Microsoft Component Object Model (COM) provides a model based on Object Technology, to manage inter-process communication on a local computer. Microsoft's Distributed Component Object Model is an extension of COM, supporting the distribution of collaborative processes over a network.
Security issues in DCOM concern:
The Remote Method Invocation allows a programmer to create distributed Java-to-Java applications. This allows remote Java objects to be invoked from other Java virtual machines, even those on different hosts. A Java program can call a remote object only when it has obtained a reference to that remote object. This can be done by:
A client can call a remote object on a server, and that server can also act as a client when calling other remote objects. As RMI both implies execution of foreign code and communication over a network, deploying RMI requires a secured environment and secured communication.
The RMI specification does not define any security features for distributed transactions. In order to secure the transfer of information between hosts located in different address spaces, some security features need to be added to the specification.
Although only a few embodiments of the present invention have been described in detail herein, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or scope of the invention. Therefore, the present examples and embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims.
|Cited Patent
|Filing date
|Publication date
|Oct 1, 1986
|Jan 17, 1989
|Strategic Processing Corporation
|Interactive market management system
|May 27, 1986
|Apr 18, 1989
|Deming Gilbert R
|Electronic funds transfer system
|Nov 15, 1989
|Dec 1, 1992
|Teknekron Transportation Systems
|Shipment system including processing of document images
|Oct 13, 1994
|Feb 10, 1998
|Full Service Trade System Ltd.
|Full service trade system
|Jan 4, 1995
|Mar 24, 1998
|Citibank N.A.
|System and method for a risk-based purchase of goods
|May 30, 1996
|Apr 14, 1998
|Sun Microsystems, Inc.
|Digital delivery of receipts
|Aug 24, 1995
|Sep 15, 1998
|Carnegie Mellon University
|Method and apparatus for purchasing and delivering digital goods over a network
|Sep 16, 1994
|Oct 20, 1998
|First Virtual Holdings Incorporated
|Computerized system for making payments and authenticating transactions over the internet
|Jun 2, 1995
|Nov 3, 1998
|International Business Machines Corporation
|Method and system for bill presentation and payment reconciliation
|Jul 1, 1996
|Dec 8, 1998
|Sun Microsystems, Inc.
|Electronic check exchange, clearing and settlement system
|Sep 12, 1995
|Mar 2, 1999
|Computer implemented automated credit application analysis and decision routing system
|Dec 9, 1996
|Mar 16, 1999
|Sun Microsystems, Inc.
|Method and system for electronic bill payment
|Aug 30, 1996
|Apr 6, 1999
|Intertrust Technologies Corp.
|Systems and methods for secure transaction management and electronic rights protection
|Aug 20, 1997
|May 11, 1999
|Talati; Kirit K.
|Method and apparatus for electronic commerce
|Jul 19, 1996
|May 11, 1999
|Biffar; Peter C.
|Self-contained payment system with circulating digital vouchers
|Feb 6, 1996
|Jul 27, 1999
|Supersonic Boom, Inc.
|Method and system for remote user controlled manufacturing
|Aug 18, 1995
|Aug 24, 1999
|Microsoft Corporation
|System and method for controlling access to data entities in a computer network
|Oct 10, 1997
|Oct 19, 1999
|Intelisys Electronic Commerce, Llc
|Electronic procurement system and method for trading partners
|Nov 21, 1997
|Nov 2, 1999
|Craig Michael Watson
|Integrated bill consolidation, payment aggregation, and settlement system
|Nov 3, 1995
|Feb 29, 2000
|Visainternational Service Association
|Electronic bill pay system
|Oct 11, 1997
|Apr 25, 2000
|I2 Technologies, Inc.
|Framework for negotiation and tracking of sale of goods
|Jun 7, 1995
|May 2, 2000
|Citibank, N.A.
|Electronic delivery system and method for integrating global financial services
|Jul 11, 1997
|May 2, 2000
|Auction Source, L.L.C.
|Real-time network exchange with seller specified exchange parameters and interactive seller participation
|Oct 30, 1997
|May 2, 2000
|Nelson; Theodor Holm
|Many-to-many payments system for network content materials
|Mar 13, 1998
|Jun 6, 2000
|Kabushiki Kaisha Toshiba
|Mutual credit server apparatus and a distributed mutual credit system
|May 5, 1999
|Jun 13, 2000
|The Clearing House Service Company L.L.C.
|System and method for intraday netting payment finality
|Sep 16, 1996
|Jul 4, 2000
|Eastern Consulting Co., Ltd.
|Method for processing business activity financial data
|Oct 7, 1998
|Jul 18, 2000
|Cybercash, Inc.
|System and method for merchant invoked electronic commerce
|Nov 6, 1997
|Aug 29, 2000
|Intertrust Technologies Corporation
|Systems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information
|Mar 19, 1997
|Aug 29, 2000
|Optimark Technologies, Inc.
|Method and apparatus for automating negotiations between parties
|Nov 5, 1998
|Oct 10, 2000
|The Planning Solutions Group, Inc.
|Method for automatically identifying, matching, and near-matching buyers and sellers in electronic market transactions
|Nov 16, 1998
|Oct 31, 2000
|Tradeaccess Inc
|System for interative, multivariate negotiations over a network
|Feb 9, 1998
|Nov 21, 2000
|Tradecard, Inc.
|Full service trade system
|Apr 14, 1998
|Feb 20, 2001
|International Check Services
|Demand deposit account data processing system
|Feb 13, 1998
|May 15, 2001
|Saranac Software, Inc.
|Methods and apparatus for internet based financial transactions with evidence of payment
|Dec 2, 1998
|Jul 10, 2001
|Gary Shkedy
|Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
|Oct 22, 1999
|Sep 4, 2001
|Venturemakers Llc
|Method of and apparatus for interactive automated registration, negotiation and marketing for combining products and services from one or more vendors together to be sold as a unit
|Oct 26, 1998
|Nov 6, 2001
|Veridian Information Solutions
|System for controlling access and distribution of digital property
|Apr 7, 1998
|Nov 13, 2001
|Linda J. Camp
|Method for certifying delivery of secure electronic transactions
|Nov 20, 1998
|Jan 1, 2002
|Citibank, N.A.
|Method for electronic merchandise dispute resolution
|Nov 16, 1998
|Jan 1, 2002
|Trade Access Inc.
|System and method for representing data and providing electronic non-repudiation in a negotiations system
|Nov 16, 1998
|Jan 8, 2002
|Trade Access, Inc.
|System and method for providing and updating user supplied context for a negotiations system
|Aug 24, 1999
|Mar 26, 2002
|Verifone, Inc.
|System, method and article of manufacture for managing transactions in a high availability system
|Jun 17, 1996
|Apr 16, 2002
|Hewlett-Packard Company
|System, method and article of manufacture for transmitting messages within messages utilizing an extensible, flexible architecture
|May 8, 1998
|May 7, 2002
|Lendingtree, Inc.
|Method and computer network for co-ordinating a loan over the internet
|Jun 25, 1999
|May 7, 2002
|Visa International Service Association
|Electronic statement presentment system
|Nov 3, 1998
|Jun 11, 2002
|Nextcard, Inc.
|Method and apparatus for real time on line credit approval
|Oct 3, 1997
|Jul 9, 2002
|Priceline.Com Incorporated
|System and method for aggregating multiple buyers utilizing conditional purchase offers (CPOS)
|Apr 19, 2001
|Sep 20, 2001
|Keil Dean S.
|System and method for debit account transactions
|Mar 1, 1999
|Nov 7, 1999
|Kerry Mclellan
|Systems and methods of paying for commercial transactions
|Title not available
|Title not available
|Sep 25, 1998
|Apr 1, 1999
|Nokia Networks Oy
|Electronic payment system
|"Sales and Refunds" <http//www.store.apple.com> Oct. 12, 1999.
|BizRate.com, retrieved from the internet on Dec. 13, 2001; http://www.bizrate.com/content/about.xpml.
|Brinkman Technologies Inc., retrieved from the internet on Mar. 25, 2002 from http://www.banksystems.com/.
|Carsdirect.com; retrieved from the internet on Dec. 13, 2001; http://www.carsdirect.com/the<SUB>-</SUB>company/cdc<SUB>-</SUB>advantage.
|Dayco Statement Regarding Related Applications.
|Dunne, Nancy, "World Trade: Call for Consumer Safeguards" Jun. 1999, Financial Times, London Edition 1 ED, p. 8.
|eBay Incorporated, "Feedback Overview", Dec. 1998.
|HSBC Website pages, http://www.ukbusiness.hsbc.com/public/ukbusiness/psc/en/psc<SUB>-</SUB>import<SUB>-</SUB>loan<SUB>-</SUB>about.jhtml.
|Citing Patent
|Filing date
|Publication date
|Dec 10, 2001
|Jul 24, 2007
|Ncr Corporation
|Parallel selection processing for financial processing in a relational database management system
|Apr 10, 2003
|Sep 11, 2007
|Cisco Technology, Inc.
|Reliable embedded file content addressing
|Jul 29, 2003
|Jan 22, 2008
|Accenture Global Services Gmbh
|Rapid knowledge transfer among workers
|Dec 30, 2003
|Jan 22, 2008
|Nokia Siemens Networks Oy
|Method and system for authentication using infrastructureless certificates
|Jan 21, 2004
|Apr 22, 2008
|International Business Machines Corporation
|Method, system and program product for electronically executing contracts within a secure computer infrastructure
|Sep 21, 2005
|Jun 24, 2008
|Unisys Corporation
|Method for knowledge management
|Aug 26, 2002
|Aug 26, 2008
|Teredata Us, Inc.
|Object-oriented representation of a generic profitability rule for financial processing in a relational database management system
|Apr 12, 2001
|Sep 16, 2008
|Twelve Horses Technology Limited
|Messaging system
|Aug 30, 2001
|Oct 21, 2008
|Pioneer Corporation
|Commodity order system and commodity order method in commodity order system
|Aug 12, 2004
|Oct 28, 2008
|Sap Aktiengesellschaft
|Virtual community generation
|Mar 26, 2004
|Dec 16, 2008
|Saab Ab
|Method of establishing rules for a device which is intended to be able to be used for generating decision support
|Mar 28, 2002
|Dec 23, 2008
|International Business Machines Corporation
|Method and system for manipulation of cost information in a distributed virtual enterprise
|Jan 30, 2001
|Feb 3, 2009
|International Business Machines Corporation
|Automotive information communication exchange system, method, and program product
|Jul 27, 2000
|Feb 17, 2009
|Khai Hee Kwan
|Computer system and method for on-line display, negotiation and management of loan syndication over computer network
|Apr 25, 2005
|Apr 21, 2009
|Oracle International Corporation
|Internal audit operations for Sarbanes Oxley compliance
|May 2, 2002
|May 5, 2009
|Guaranteed Markets Ltd
|Systems, methods, and mediums for transaction management
|Nov 16, 2007
|May 19, 2009
|Amazon.Com, Inc.
|Method, system, and computer readable medium for the selection of content items for presentation to users
|Mar 14, 2001
|May 26, 2009
|Bennett James D
|Online purchasing system supporting buyer affordability screening
|Mar 14, 2001
|Jun 2, 2009
|Bennett James D
|Online purchasing system supporting sellers with affordability screening
|Dec 19, 2005
|Jun 2, 2009
|Sap Ag
|Method and computer system for workflow control
|Aug 21, 2003
|Jun 16, 2009
|International Business Machines Corporation
|Automatic software distribution and installation in a multi-tiered computer network
|Aug 2, 2006
|Jul 7, 2009
|Hewlett-Packard Development Company, L.P.
|System and method for managing virtual collaboration systems
|Oct 16, 2001
|Sep 8, 2009
|Tradecard, Inc.
|Providing cargo insurance in a full service trade system
|Nov 19, 2002
|Oct 6, 2009
|Amazon Technologies, Inc.
|Detection of fraudulent attempts to initiate transactions using modified display objects
|Dec 12, 2005
|Oct 27, 2009
|Amazon Technologies, Inc.
|Method and system for analyzing inventory purchasing opportunities with respect to inventory health
|Aug 29, 2005
|Nov 10, 2009
|China Unionpay Co., Ltd.
|Bankcard transaction exchange system
|Feb 18, 2004
|Nov 10, 2009
|Citrix Systems, Inc.
|Inferencing data types of message components
|Apr 3, 2001
|Dec 1, 2009
|Barker Geoffrey T
|System and method for providing configurable security monitoring utilizing an integrated information system
|Feb 7, 2003
|Dec 8, 2009
|Decisionmark Corp.
|Method and system for providing household level television programming information
|Sep 30, 2003
|Mar 2, 2010
|Toshiba Corporation
|Automated accounting system, method and computer-readable medium for MFP devices
|Aug 30, 2005
|Mar 9, 2010
|Goldman Sachs & Co.
|Method and system for processing financial data objects carried on broadcast data streams and delivering information to subscribing clients
|Apr 15, 2004
|Mar 16, 2010
|Citrix Systems, Inc.
|Methods and apparatus for synchronization of data set representations in a bandwidth-adaptive manner
|May 4, 2006
|Mar 23, 2010
|Citrix Online, Llc
|Methods and systems for providing scalable authentication
|Apr 15, 2003
|Apr 27, 2010
|Navio Systems, Inc.
|Methods of facilitating merchant transactions using a computerized system including a set of titles
|May 15, 2003
|Apr 27, 2010
|Navio Systems, Inc.
|Methods and apparatus for title structure and management
|Aug 27, 2003
|Apr 27, 2010
|Spectrum K12 School Solutions, Inc.
|Method and system for compliance forms and compliance forms user interface
|Apr 25, 2008
|May 11, 2010
|Gateway, Inc.
|Electronic retail order communication
|Jan 16, 2007
|May 11, 2010
|William James Duncan
|Invoiceless trading and settlement method and system
|Mar 9, 2005
|May 18, 2010
|Omega Patents, L.L.C.
|Vehicle tracker including input/output features and related methods
|Aug 17, 2007
|May 25, 2010
|Qualcomm Incorporated
|System, method, and/or apparatus for digital signal sorting
|Jun 15, 2006
|Jun 29, 2010
|Citrix Online, Llc
|Methods and systems for receiving feedback from a scalable number of participants of an on-line presentation
|Nov 25, 2009
|Jul 6, 2010
|Cybersource Corporation
|Method and system for detecting fraud in a credit card transaction over the internet
|Dec 14, 2007
|Jul 27, 2010
|Amazon.Com, Inc.
|Personalization using multiple personalized selection algorithms
|May 18, 2006
|Aug 10, 2010
|Bgc Partners, Inc.
|Systems and methods for providing valid responses to requests for quotations
|Feb 18, 2004
|Aug 10, 2010
|Citrix Systems, Inc.
|Rule generalization for web application entry point modeling
|May 31, 2005
|Aug 24, 2010
|International Business Machines Corporation
|Electronic sales and contracting method, system and program product
|Aug 6, 2004
|Aug 31, 2010
|Fujitsu Frontech Limited
|Electronic payment system, a recording medium recording an electronic payment program and an electronic payment apparatus
|Sep 28, 2006
|Sep 28, 2010
|Tradecard, Inc.
|Securitization of a commercial transaction
|Nov 26, 2007
|Oct 5, 2010
|Accenture Global Services Gmbh
|Rapid knowledge transfer among workers
|Dec 30, 2005
|Oct 5, 2010
|Citrix Systems, Inc.
|Systems and methods for automatic installation and execution of a client-side acceleration program
|May 15, 2003
|Oct 12, 2010
|Navio Systems, Inc.
|Methods and apparatus for title protocol, authentication, and sharing
|Mar 28, 2002
|Oct 19, 2010
|International Business Machines Corporation
|Method and system for distributed virtual enterprise dependency objects
|Apr 15, 2004
|Nov 2, 2010
|Citrix Systems, Inc.
|Methods and apparatus for sharing graphical screen data in a bandwidth-adaptive manner
|Mar 12, 2007
|Nov 2, 2010
|Citrix Systems, Inc.
|Systems and methods for identifying long matches of data in a compression history
|Feb 13, 2004
|Nov 2, 2010
|Citicorp Development Center, Inc.
|System and method for secure message reply
|Nov 1, 2006
|Nov 9, 2010
|Citrix Systems, Inc.
|Methods and systems for real-time seeking during real-time playback of a presentation layer protocol data stream
|Dec 13, 2004
|Nov 16, 2010
|Michael Stockton
|Method and system configured for facilitating management of international trade receivables transactions
|Jun 26, 2001
|Nov 30, 2010
|Buyer-driven targeting of purchasing entities
|Mar 12, 2007
|Dec 14, 2010
|Citrix Systems, Inc.
|Systems and methods for configuring flow control of policy expressions
|Mar 12, 2007
|Dec 14, 2010
|Citrix Systems, Inc.
|Systems and methods for configuring handling of undefined policy events
|Aug 1, 2007
|Dec 28, 2010
|Citrix Systems, Inc.
|Systems and methods for state signing of internet resources
|Jun 15, 2007
|Dec 28, 2010
|Savvis, Inc.
|Shared data center disaster recovery systems and methods
|May 8, 2002
|Jan 4, 2011
|Cybersource Corporation
|Method and apparatus for evaluating fraud risk in an electronic commerce transaction
|Mar 12, 2007
|Jan 4, 2011
|Citrix Systems, Inc.
|Systems and methods for providing dynamic ad hoc proxy-cache hierarchies
|Mar 12, 2007
|Jan 4, 2011
|Citrix Systems, Inc.
|Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance
|Mar 12, 2007
|Jan 11, 2011
|Citrix Systems, Inc.
|Systems and methods for using object oriented expressions to configure application security policies
|Oct 5, 2009
|Jan 18, 2011
|Citrix Systems, Inc.
|Systems and methods of using application and protocol specific parsing for compression
|Aug 25, 2006
|Jan 25, 2011
|Nathans Michael G
|Preferred credit information data collection method
|Mar 10, 2005
|Feb 1, 2011
|Amazon Technologies, Inc.
|Method and system for event-driven inventory disposition
|Jan 5, 2006
|Feb 8, 2011
|Oracle International Corporation
|Audit planning
|Feb 18, 2004
|Feb 15, 2011
|Teros, Inc.
|Using statistical analysis to generate exception rules that allow legitimate messages to pass through application proxies and gateways
|Jun 17, 2003
|Mar 1, 2011
|Oracle International Corporation
|Audit management workbench
|Oct 23, 2002
|Mar 1, 2011
|Goldman Sachs & Co.
|Correspondent bank registry
|Jun 10, 2008
|Mar 8, 2011
|International Business Machines Corporation
|Consumer rating and customer service based thereon within a virtual universe
|Jan 31, 2007
|Mar 22, 2011
|Hewlett-Packard Development Company, L.P.
|Coordinated media control system
|Feb 12, 2003
|Mar 22, 2011
|Decisionmark Corp.
|System and method for delivering data over an HDTV digital television spectrum
|Oct 16, 2008
|Mar 29, 2011
|Citrix Systems, Inc.
|Systems and methods of clustered sharing of compression histories
|Dec 30, 2005
|Apr 5, 2011
|Citrix Systems, Inc.
|System and method for performing flash crowd caching of dynamically generated objects in a data communication network
|Dec 20, 2005
|Apr 12, 2011
|Citrix Systems, Inc.
|Performance logging using relative differentials and skip recording
|Jun 9, 2004
|Apr 12, 2011
|Syncada Llc
|Automated transaction processing system and approach
|Oct 19, 2007
|Apr 12, 2011
|Citrix Systems, Inc.
|Systems and methods for managing cookies via HTTP content layer
|Mar 18, 2003
|Apr 26, 2011
|Spx Corporation
|Method and apparatus for automating multi-national insurance information requests
|Jan 8, 2009
|Apr 26, 2011
|Barker Geoffrey T
|Predictive threat assessment
|Jun 17, 2003
|May 10, 2011
|Oracle International Corporation
|Impacted financial statements
|Nov 10, 2006
|May 24, 2011
|Pardalis, Inc.
|Common point authoring system for the complex sharing of hierarchically authored data objects in a distribution chain
|May 31, 2001
|Jun 7, 2011
|Goldman Sachs & Co.
|Method and system for processing raw financial data streams to produce and distribute structured and validated product offering objects
|Aug 15, 2008
|Jun 7, 2011
|Otowest, Llc
|Messaging system
|May 31, 2001
|Jun 7, 2011
|Goldman Sachs & Co.
|Method and system for processing raw financial data streams to produce and distribute structured and validated product offering data to subscribing clients
|Jul 22, 2008
|Jun 14, 2011
|Bank Of America Corporation
|Logon access management and cross-reference
|Feb 20, 2008
|Jun 28, 2011
|Cybersource Corporation
|Method and apparatus for evaluating fraud risk in an electronic commerce transaction
|Apr 29, 2004
|Jun 28, 2011
|International Business Machines Corporation
|Method, system and program product for protecting electronic contracts created within a secure computer infrastructure
|Sep 15, 2006
|Jul 12, 2011
|Citrix Systems, Inc.
|Methods for providing performance improvement recommendations
|Dec 26, 2002
|Jul 12, 2011
|Ricoh Company, Ltd.
|Online merchandising system, server, estimation managing method, computer program product, and computer data signal
|Nov 1, 2006
|Aug 9, 2011
|Citrix Systems, Inc.
|Methods and systems for recording and real-time playback of presentation layer protocol data
|Jun 17, 2003
|Aug 23, 2011
|Oracle International Corporation
|Continuous audit process control objectives
|Aug 23, 2006
|Aug 30, 2011
|Decisionmark Corp.
|Method and system for creating television programming guide
|Sep 29, 2009
|Aug 30, 2011
|Citrix Systems, Inc.
|Inferencing data types of message components
|Apr 30, 2009
|Sep 27, 2011
|Intuit Inc.
|System and method for merchant risk management
|Mar 14, 2001
|Oct 11, 2011
|Bennett James D
|Online purchasing system supporting lenders with affordability screening
|Mar 12, 2007
|Oct 11, 2011
|Citrix Systems, Inc.
|Systems and methods of dynamically checking freshness of cached objects based on link status
|Feb 2, 2007
|Oct 18, 2011
|Hewlett-Packard Development Company, L.P.
|System and method for transferring objects in a video conferencing session
|Jan 14, 2005
|Oct 18, 2011
|Citrix Systems, Inc.
|Method and system for requesting and granting membership in a server farm
|Dec 23, 2003
|Nov 1, 2011
|Bank Of America Corporation
|System and method to manage supply chain settlement, risk and liquidity
|May 26, 2010
|Nov 1, 2011
|Citrix Systems, Inc.
|Systems and methods for identifying long matches of data in a compression history
|Jan 17, 2008
|Nov 8, 2011
|Alibaba Group Holding Limited
|Method and system for authentication via communication terminal using short message
|Mar 30, 2009
|Nov 22, 2011
|Citrix Systems, Inc.
|Systems and methods for sharing compression histories between multiple devices
|Apr 14, 2011
|Nov 29, 2011
|Goldman Sachs & Co.
|System for processing raw financial data streams to produce and distribute structured and validated product offering data to subscribing clients
|Nov 12, 2007
|Dec 6, 2011
|Computer Associates Think, Inc.
|System and method for optimizing storage infrastructure performance
|Feb 22, 2006
|Dec 6, 2011
|Microsoft Corporation
|User interface for an inkable family calendar
|Sep 15, 2006
|Dec 13, 2011
|Citrix Systems, Inc.
|Methods and interfaces for displaying performance data related to a current remote access session
|Jan 26, 2009
|Jan 3, 2012
|Citrix Systems, Inc.
|Systems and methods for fine grain policy driven cookie proxying
|Jan 31, 2007
|Jan 24, 2012
|Hewlett-Packard Development Company, L.P.
|Device control system
|Mar 12, 2007
|Jan 24, 2012
|Citrix Systems, Inc.
|Systems and methods of providing security and reliability to proxy caches
|Jun 23, 2004
|Feb 7, 2012
|Guangrong Ying
|Method and system of bidirectional marketing with feedback
|Aug 21, 2006
|Feb 14, 2012
|Citrix Systems, Inc.
|Systems and methods for weighted monitoring of network services
|Jul 24, 2003
|Feb 21, 2012
|Goldman Sachs & Co.
|Gaming industry risk management clearinghouse
|Sep 13, 2005
|Feb 28, 2012
|Computer Associates Think, Inc.
|Application change request to deployment maturity model
|Feb 21, 2008
|Feb 28, 2012
|International Business Machines Corporation
|Method and system for accessing a resource implemented in a computer network
|Mar 20, 2001
|Mar 20, 2012
|Goldman Sachs & Co.
|Automated global risk management
|Jan 14, 2005
|Mar 27, 2012
|Citrix Systems, Inc.
|Method and system for real-time seeking during playback of remote presentation protocols
|Nov 7, 2008
|Apr 3, 2012
|Citrix Systems, Inc.
|Systems and methods for managing printer settings in a networked computing environment
|Oct 3, 2005
|May 29, 2012
|Citrix Systems, Inc.
|Simulating multi-monitor functionality in a single monitor environment
|Mar 18, 2008
|May 29, 2012
|Nec Laboratories America, Inc.
|Mining library specifications using inductive learning
|Oct 30, 2009
|Jun 12, 2012
|Citrix Systems, Inc.
|Systems and methods for single stack shadowing
|Jun 18, 2003
|Jun 26, 2012
|Goldman, Sachs & Co.
|Proprietary risk management clearinghouse
|Jan 20, 2010
|Jun 26, 2012
|Goldman Sachs & Co.
|Method and system for processing financial data objects carried on broadcast data streams and delivering information to subscribing clients
|Oct 31, 2011
|Jul 17, 2012
|Accenture Global Services Limited
|Rapid knowledge transfer among workers
|Jul 7, 2009
|Jul 24, 2012
|International Business Machines Corporation
|Method and apparatus for facilitating business processes
|Jan 14, 2005
|Jul 24, 2012
|Citrix Systems, Inc.
|Methods and systems for generating playback instructions for playback of a recorded computer session
|Jun 28, 2001
|Jul 31, 2012
|Jpmorgan Chase Bank, N.A.
|System and method for characterizing and selecting technology transition options
|Jun 24, 2011
|Aug 14, 2012
|Michael Lewis
|Method and apparatus for generating a bi-gram score in fraud risk analysis
|Dec 30, 2005
|Aug 28, 2012
|Citrix Systems, Inc.
|System and method for performing flash caching of dynamically generated objects in a data communication network
|Mar 12, 2007
|Aug 28, 2012
|Citrix Systems, Inc.
|Systems and methods of compression history expiration and synchronization
|Jun 4, 2010
|Sep 4, 2012
|Citrix Systems, Inc.
|System and method for establishing a virtual private network
|Jan 27, 2010
|Sep 4, 2012
|Citrix Systems, Inc.
|Using statistical analysis to generate exception rules that allow legitimate messages to pass through application proxies and gateways
|Aug 4, 2009
|Sep 11, 2012
|Syncada Llc
|Transaction accounting auditing approach and system therefor
|Jan 15, 2010
|Sep 25, 2012
|International Business Machines Corporation
|Electronic sales and contracting
|Jul 21, 2009
|Sep 25, 2012
|Citrix Systems, Inc.
|Systems and methods of prefetching objects for caching using QoS
|Mar 12, 2007
|Oct 16, 2012
|Citrix Systems, Inc.
|Systems and methods for load balancing based on user selected metrics
|Jul 22, 2005
|Oct 16, 2012
|Citrix Systems, Inc.
|Method and systems for securing remote access to private networks
|Jun 17, 2003
|Oct 23, 2012
|Nigel King
|Process certification management
|Oct 30, 2009
|Oct 23, 2012
|Citrix Systems, Inc.
|Methods and systems for joining a real-time session of presentation layer protocol data
|Dec 30, 2005
|Oct 30, 2012
|Citrix Systems, Inc.
|System and method for performing granular invalidation of cached dynamically generated objects in a data communication network
|Apr 14, 2011
|Nov 6, 2012
|Pardalis, Inc.
|Common point authoring system for the complex sharing of hierarchically authored data objects in a distribution chain
|Mar 5, 2004
|Nov 13, 2012
|Wms Gaming Inc.
|Discovery service in a service-oriented gaming network environment
|Jan 14, 2005
|Dec 25, 2012
|Citrix Systems, Inc.
|Methods and systems for generating playback instructions for rendering of a recorded computer session
|Dec 15, 2009
|Dec 25, 2012
|Institute For Information Industry
|System and method for product recommendation and automatic service equipment thereof and computer readable recording medium storing computer program performing the method
|May 11, 2009
|Dec 25, 2012
|Property Liquidators Llc
|System and method of auctioning a defaulted loan
|Jul 15, 2011
|Dec 25, 2012
|American Express Travel Related Services Company, Inc.
|System for reducing information required to open a new account
|Oct 9, 2009
|Dec 25, 2012
|Citrix Systems, Inc.
|Systems and methods for configuring policy bank invocations
|Aug 30, 2010
|Jan 8, 2013
|Citrix Systems, Inc.
|Systems and methods for communicating a lossy protocol via a lossless protocol using false acknowledgements
|Dec 29, 2010
|Jan 8, 2013
|Citrix Systems, Inc.
|Systems and methods for providing dynamic ad hoc proxy-cache hierarchies
|Jul 22, 2005
|Jan 29, 2013
|Citrix Systems, Inc.
|Method and systems for routing packets from a gateway to an endpoint
|Dec 9, 2009
|Jan 29, 2013
|Citrix Systems, Inc.
|Systems and methods for domain name resolution interception caching
|Jan 27, 2010
|Feb 12, 2013
|Citrix Systems Inc.
|Methods and apparatus for synchronization of data set representations in a bandwidth-adaptive manner
|Sep 27, 2011
|Feb 26, 2013
|Goldman, Sachs & Co.
|Method and system for processing raw financial data streams to produce and distribute structured and validated product offering data to subscribing clients
|Dec 22, 2005
|Mar 5, 2013
|Syncada Llc
|Multi-supplier transaction and payment programmed processing approach with at least one supplier
|Apr 3, 2002
|Mar 5, 2013
|Vig Acquisitions Ltd., L.L.C.
|System and method for providing configurable security monitoring utilizing an integrated information system
|Sep 22, 2010
|Mar 12, 2013
|Trade Technologies Inc.
|Method and system configured for facilitating management of international trade receivables transactions
|Mar 17, 2000
|Mar 12, 2013
|Syncada Llc
|Validation approach for auditing a vendor-based transaction
|Apr 20, 2012
|Mar 26, 2013
|Enpulz, L.L.C.
|Advertising infrastructure supporting cross selling opportunity management
|Jun 22, 2001
|Mar 26, 2013
|International Business Machines Corporation
|Method and system using an enterprise framework
|Apr 18, 2012
|Mar 26, 2013
|Enpulz, L.L.C.
|Promotion infrastructure having dispensing controls
|Apr 18, 2012
|Mar 26, 2013
|Enpulz, L.L.C.
|Promotion infrastructure having third party posting service
|Apr 18, 2012
|Mar 26, 2013
|Enpulz, L.L.C.
|Promotion infrastructure having dual input and dual output interface
|Jan 11, 2010
|Apr 16, 2013
|Citrix Systems, Inc.
|System and methods for automatic time-warped playback in rendering a recorded computer session
|Apr 19, 2012
|Apr 23, 2013
|Enpulz, L.L.C.
|Network infrastructure supporting a multi-seller promotion and transaction environment
|May 18, 2012
|Apr 23, 2013
|Ebay Inc.
|Management of business processes
|May 26, 2005
|May 14, 2013
|Citrix Systems Inc.
|Method and system for synchronizing presentation of a dynamic data set to a plurality of nodes
|Mar 10, 2005
|May 21, 2013
|Amazon Technologies, Inc.
|Method and system for managing inventory by expected profitability
|Mar 30, 2011
|May 21, 2013
|Amazon Technologies, Inc.
|Removal of expiring items from inventory
|Apr 18, 2012
|Jun 11, 2013
|Enpulz, L.L.C.
|Promotion data and codes supporting redemption processing
|Jun 14, 2012
|Jun 11, 2013
|Enpulz, L.L.C.
|Multi-search infrastructure supporting advertising and internet search term reuse
|Jan 11, 2011
|Jun 11, 2013
|Amazon Technologies, Inc.
|System and method for event-driven inventory disposition
|Apr 18, 2012
|Jun 11, 2013
|Enpulz, Llc
|Promotion infrastructure supporting selected and emailed promotion delivery
|Feb 16, 2012
|Jun 18, 2013
|Enpulz, L.L.C.
|Sales promotion system supporting a plurality of differing sellers
|Jul 2, 2012
|Jun 18, 2013
|Enpulz, L.L.C.
|Competitive advertising and sales infrastructure
|Feb 16, 2012
|Jun 18, 2013
|Enpulz, L.L.C.
|Seller selection of content for promotion creation
|Jun 14, 2012
|Jun 18, 2013
|Enpulz, L.L.C.
|Advertising system supporting multi-advertiser system communications
|Aug 21, 2012
|Jun 25, 2013
|Enpulz, L.L.C.
|Promotion system supporting web content and promotion searching
|Feb 22, 2008
|Jul 2, 2013
|Accenture Global Services Limited
|Conversational question generation system adapted for an insurance claim processing system
|Jun 19, 2012
|Jul 9, 2013
|Enpulz, L.L.C.
|Multi-seller sales system supporting multiple sales portals and promotion systems
|Jun 15, 2012
|Jul 9, 2013
|Enpulz, L.L.C.
|Advertising system supporting multi-advertiser system interface structures
|May 22, 2012
|Jul 23, 2013
|James D. Bennett
|Persistence mechanism for facilitating online transactions
|Dec 30, 2005
|Jul 23, 2013
|Citrix Systems, Inc.
|Method and device for performing caching of dynamically generated objects in a data communication network
|Feb 22, 2011
|Jul 30, 2013
|Citrix Systems, Inc
|System and method for performing flash crowd caching of dynamically generated objects in a data communication network
|Jun 18, 2012
|Aug 6, 2013
|Enpulz, L.L.C.
|Advertising system supporting multi-advertiser system remote advertisement posting
|Jul 16, 2012
|Aug 6, 2013
|James D. Bennett
|Online purchasing system supporting lenders with affordability screening
|Mar 12, 2007
|Aug 6, 2013
|Citrix Systems, Inc
|Systems and methods of prefreshening cached objects based on user's current web page
|Feb 16, 2012
|Aug 13, 2013
|Enpulz, L.L.C.
|Email promotion portal supporting buyer anonymity
|Feb 22, 2008
|Aug 20, 2013
|Accenture Global Services Gmbh
|Rule generation system adapted for an insurance claim processing system
|Nov 27, 2012
|Aug 20, 2013
|American Express Travel Related Services Company, Inc.
|System for reducing information required to open a new account
|Mar 15, 2013
|Aug 20, 2013
|Fast 101 Pty Ltd.
|Invoiceless trading and settlement method and system
|Jun 5, 2008
|Aug 27, 2013
|The Western University Company
|Consolidated payment options
|Aug 21, 2012
|Sep 17, 2013
|Enpulz, L.L.C.
|Sales promotion system with secondary sales server system
|Dec 30, 2005
|Oct 1, 2013
|Citrix Systems, Inc.
|Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing
|May 31, 2011
|Oct 15, 2013
|Citrix Systems, Inc.
|Systems and methods for providing a VPN solution
|Jun 9, 2005
|Oct 15, 2013
|Syncada Llc
|Transaction processing with core and distributor processor implementations
|May 29, 2009
|Oct 22, 2013
|Rdm Corporation
|Method and system for thin client based image and transaction management
|Mar 3, 2010
|Oct 29, 2013
|Oncircle, Inc.
|Methods and apparatus for title structure and management
|Aug 21, 2012
|Nov 5, 2013
|Enpulz, L.L.C.
|Promotion system supporting emailed promotions with transaction accounting
|Aug 21, 2012
|Nov 5, 2013
|Enpulz, L.L.C.
|Sales promotion system supporting coupon link in multi-seller environment
|Jun 29, 2010
|Nov 12, 2013
|Bgc Partners, Inc.
|Providing valid responses to requests for quotations
|Jun 14, 2012
|Nov 12, 2013
|Enpulz, L.L.C.
|Whois server verifying whois records and search engine accesses
|Jun 26, 2009
|Nov 19, 2013
|Syncada Llc
|Financial institution-based transaction processing system and approach
|Oct 7, 2009
|Nov 19, 2013
|Citrix Systems, Inc.
|Systems and methods for real-time endpoint application flow control with network structure component
|Jun 26, 2009
|Nov 26, 2013
|Syncada Llc
|Financial institution-based transaction processing system and approach
|May 17, 2005
|Dec 10, 2013
|Visa International Service Association
|Method and system for providing buyer bank payable discounting services
|Sep 20, 2011
|Dec 24, 2013
|Citrix Systems, Inc.
|Methods and systems for cataloging text in a recorded session
|Jul 13, 2010
|Dec 24, 2013
|Citrix Systems, Inc.
|Systems and methods of revalidating cached objects in parallel with request for object
|Mar 3, 2008
|Jan 7, 2014
|Routeone Llc
|System and methods for electronic signature capture in e-contracting transactions
|Mar 12, 2007
|Jan 14, 2014
|Citrix Systems, Inc.
|Systems and methods for configuring policy bank invocations
|May 25, 2010
|Jan 21, 2014
|Citrix Systems, Inc.
|Systems and methods for communicating a lossy protocol via a lossless protocol
|Apr 12, 2013
|Feb 11, 2014
|Ebay Inc.
|Management of business processes
|Mar 29, 2010
|Feb 11, 2014
|Syncada Llc
|Order-resource fulfillment and management system and approach
|Mar 4, 2004
|Feb 25, 2014
|International Business Machines Corporation
|System and method for workflow enabled link activation
|Feb 12, 2008
|Feb 25, 2014
|Fast 101 Pty Ltd.
|Invoiceless trading and settlement method and system
|Oct 4, 2011
|Mar 4, 2014
|Amazon Technologies, Inc.
|Continuous planning review system
|Oct 24, 2012
|Mar 4, 2014
|Enpulz, L.L.C.
|Web search with visited web page search result restrictions
|Jun 14, 2007
|Mar 11, 2014
|Ebay Inc.
|Method and system for manipulation of cost information in a distributed virtual enterprise
|Apr 20, 2011
|Mar 11, 2014
|Goldman, Sachs & Co.
|Method and system for processing raw financial data streams to produce and distribute structured and validated product offering objects
|Apr 14, 2006
|Mar 18, 2014
|Citrix Online Llc
|Systems and methods for displaying to a presenter visual feedback corresponding to visual changes received by viewers
|Jun 14, 2007
|Mar 25, 2014
|Ebay Inc.
|Method and system for manipulation of cost information in a distributed virtual enterprise
|Apr 2, 2012
|Apr 1, 2014
|Enpulz, L.L.C.
|Forecast and demand based price calculation
|Jan 18, 2002
|Apr 1, 2014
|Intellectual Ventures Fund 83 Llc
|System, method and software product for ordering image products using images stored on a digital storage device from a plurality of order terminals
|Jun 30, 2010
|Apr 8, 2014
|Citrix Systems, Inc.
|Rule generalization for web application entry point modeling
|Aug 17, 2011
|Apr 8, 2014
|Citrix Systems, Inc.
|Inferencing data types of message components
|Dec 30, 2005
|Apr 15, 2014
|Citrix Systems, Inc.
|Systems and methods for providing client-side accelerated access to remote applications via TCP pooling
|Sep 14, 2012
|Apr 15, 2014
|Vig Acquisitions Ltd., L.L.C.
|System and method for providing configurable security monitoring utilizing an integrated information system
|Mar 12, 2007
|Apr 15, 2014
|Citrix Systems, Inc.
|Systems and methods of using the refresh button to determine freshness policy
|Feb 16, 2012
|Apr 22, 2014
|Enpulz, Llc
|System supporting seller's promotion creation
|Feb 16, 2012
|Apr 22, 2014
|Enpulz, L.L.C.
|Geographical and dispensing limits for E-promotions
|Dec 30, 2005
|Apr 22, 2014
|Citrix Systems, Inc.
|Systems and methods for providing client-side dynamic redirection to bypass an intermediary
|Dec 21, 2010
|Apr 29, 2014