Framework and Business Logic Components

CHAPTER 1 Custom Business Programs and Business Packages

This chapter will contrast custom business programs and business packages, while looking at the actual state of business program development in the business field. It will then introduce an actual example of a business program, developed using ‘Business Logic Components’ and clearly show that this is positioned between custom business programs and business packages.

The discussion on business packages in this chapter will focus on component-based reuse, the main theme of this book, due to the pioneering role of business packages in reuse. The unit of reuse implemented so far has normally been large products, such as business packages or small functions like general subroutines. In addition to these, this chapter will introduce ‘Business Logic Components’ that cover an area not covered by general subroutines. Unlike large business packages, ‘Business Logic Components’ offer the benefit of being able to be made into a finished product by being combined with various small components.

1.1 Differences between Custom Business Programs and Business Packages

By focusing on what sort of business they support, business systems in the business field can be classified into many types, including financial accounting, sales management, inventory management, customer management, and production management. However, even when you are talking about a production management system, there is a major difference between a business system in charge of semiconductor production management and a business system in charge of automobile production management. Consequently, production management systems are sometimes seen as different things depending on the industry. Based on such industry and business differences, if you were to count the number of types of such business programs, the figure could reach several hundred types depending on the counting method.

However, the number of business programs that are actually being developed far exceeds this number. This is because in many cases they are developed as custom business programs for various enterprises. This is due to the fact that even enterprises in the same industry, which are conducting the same business, differ in how they think about business processes and their procedure details.

Custom business programs are frequently likened to tailor-made clothing, as are business packages to ready-made clothing. This is because customer business programs are developed to fit in perfectly with the concepts and procedures for the business processes of a specific customer (single enterprise). On the other hand business packages are developed in an attempt to fit in with the concepts and procedures for common business processes of many enterprises. This is the major difference between custom business programs and business packages.

1.1-a Customization Required by Business Packages

Enterprise business procedures generally have a lot in common, but they also have company-specific portions. There is a great deal of variation in actual business procedures due to such factors as the enterprise characteristics of each company, including its historical background, executive policy, interdepartmental dynamics, and special methods of conducting business; special industry characteristics including the types of products and services handled by each industry, industry practices, and other matters of concern; and creative efforts to differentiate the company from another. Consequently, each enterprise desires a special business program that fits in with its own concepts and procedures concerning business processes.

However, since business packages are developed in a sense to satisfy the greatest number of users, they cannot always support all variations. As a result, when you try to introduce a business package to a specific client (single enterprise), you will find certain parts that do not fit in. In other words, among special business packages focused on a specific business, as are sales management system packages, it is usual to find some sort of inconformity arising from differences in industry characteristics (same business but different industry) and enterprise characteristics. In addition, among industry packages focused on a specific industry, as are hospital packages, it is usual to find some sort of inconformity arising from differences in enterprise characteristics.

This is why adaptation work (likened to customization or fitting, and hence, known as tailoring) of a business package to the business procedures of a specific customer (single enterprise) is required. Even though there are hard-wired packages that cannot be customized, most business packages were designed with some sort of customization in mind. In short, a customization mechanism is built in to adapt the business package to a new customer environment.

1.1-b Customization Methods

Customization methods can be essentially classified as one of the following two types:

• Parameter customization

• Program customization

Parameter customization is simple because customization work concludes merely by specifying parameters with clear-cut meanings as viewed externally. To make parameter customization possible, however, the extent of customization must be established in advance, and then what is required to support this must be built in. For instance, if you assume that either the last invoice cost method, moving-average method, periodic average method, or estimated cost method will be used as the appraisal method for inventory, what is required to support it must be built in. It is also possible to specify the appraisal method for inventory that a customer actually employs by the parameters you give to a business package.

By building in what is necessary, customization work becomes extremely simple because all that needs to be done is to specify parameters. Nevertheless, customer requests that can be satisfied by this method are limited to the extent that the business package development firm can only specify such requests as parameters by making assumptions ahead of time.

This method could be called a sort of true/false or alternative form exam question.

Program customization is the satisfying of customer requests by changing or creating new parts of a program module within a business package. Consequently, any request can be met in principle. However, customization work tends to be a big job because it involves cutting deep into the procedures within a program, rather than simply specifying declarative information with clear-cut meaning as viewed externally like parameters. It is sort of like surgery for reconstructing internal organs, and the amount of work required for this is from 100 to 10,000 times, that of parameter customization.

If all customer requests could be satisfied using parameter customization, work would be extremely simple. Unfortunately, the extent to which customer requests can be met with parameter customization alone is limited. In a manner of speaking, it is impossible to create and add new functions to internal organs simply by adjusting parameters. As a result, program customization’s raison d'etre lies in its ability to meet any sort of request.

This method could be called a sort of written exam problem.

Two-stage customization applies the best portions of the two-customization methods. This two-stage method uses parameter customization to meet frequently found customization requests, and when this method cannot meet such requests; it uses program customization as a sort of secret weapon. In short, it is a sophisticated method that allows some customization to be easily completed while at the same time conferring flexibility that enables any sort of customization requests from customers to be met.

There are some things worth noting about the terms used here. There are business packages out there that are said to be able to meet almost all customization requests simply by specifying parameters. It must be noted that the term parameters used in relation to such business packages, and the term “parameter” as used in parameter customization, specify completely different things. The term “parameter” in this book means declarative information with a clear-cut meaning as viewed externally. In contrast, the other parameter is information that depends on the internal structure of a business package, and it is usual for procedural information other than declarative information to be included. In a manner of speaking, these kinds of parameters are an internal language (a kind of programming language) for writing business packages; hence, this book regards the work for setting such parameters as program customization. Normally, as previously stated, amount of such parameter customization work is actually 100 to 10,000 times that of parameter customization in this book. Consequently, even though both terms use the same word, they are actually two different things. Parameter customization, which some venders are claiming to be simple and easy, is another kind of program customization, which is not easily completed.

1.1-c Custom Business Program or Business Package? (Part 1: General Discussion)

A business package is intended to be sold to many enterprises rather than a specific customer (single enterprise). And hence, its development requires unique know-how and considerations, and also runs up development costs beyond a custom business program. Therefore, business programs that can only be sold to a specific customer (single enterprise) are normally developed as a custom business program, rather than purposely deciding on the business package style.

In contrast, a package style is advantageous for development of those industries and business field business programs, which can be sold to many customers (enterprises), and have few variations in customization requests. If you were to estimate the total cost of hypothetically developing individual custom business programs for each customer (enterprise), a business package that can be developed once and used by many customers (enterprises) clearly results in a dramatic cost reduction.

Topic 1: Dreaming of the “Golden Egg” Business Package

Even in the business field, financial accounting is special for reasons discussed later, and its variety in connection with customization requests is limited. This sort of application field is suitable for business packages and can meet most requests simply through parameter customization.

To raise the parameter customization rate (percentage of customization that can be met simply by setting parameters) of a business package, it is essential to collect sufficient information about the customization requests. For example, in the process of evolving into an organism that can adapt to a diverse range of environments, genetic information for adapting to each environment must be obtained. In this exact same manner, the evolution of a business package that can adapt to a diverse range of environments requires information about customization requirements.

In reality, there are also exceptional cases where the parameter customization rate for a financial accounting package reaches nearly 98 percent by using information-gathering tactics. Such information-gathering tactics are based on the principle of having a package customized simply by setting parameters, without passing the source program to the person in charge of customization. Whenever program customization is absolutely necessary, the source program will be disclosed in the exchange of detailed information about that customization case. Doing this makes it possible to widely collect detailed information about customization requests. If information can be collected, the later application of development funding and development time will enhance the business package and enable it to evolve into something that meets the newly understood requests by means of parameter customization.

Business packages with a high parameter customization rate can be thought of as equipment that requires a large capital investment. As it is like developing an automatic sewing machine for tailor-made custom clothing, a large initial investment is required. However, the equipment will produce a large profit as long as it is operated effectively. This is because like the goose that laid golden eggs, the simple setting of parameters will allow the production of business programs one after the other, as long as the business package can be applied.

Creating such a goose that lays golden eggs is not possible for just any business program. Actually, it is only possible for business programs for application fields in which the need for creative adaptation (NCA) is low. (Chapter 5 discusses NCA in detail, but for now, refer to the explanation given in “Keywords for Understanding This Book.”) With business programs for application fields in which the NCA is high, new customization requests that cannot be met, no matter how many parameters you add, will arise, and hence, it is impossible to adequately raise the parameter customization rate. Each time you encounter a new customer (enterprise), what is required must be built in, and maintenance for responding to changes in the needs of the world is continually required. Therefore, the creation of a goose that lays golden eggs is generally difficult. It is only possible in the case of application fields for which NCA is exceptionally low, such as with financial accounting packages. In the financial accounting field NCA would be low, because there is the constraint of legal provisions that must be obeyed and creative activities are restricted.

Note that the use of ‘Business Logic Component Technology’ enables the creation of business programs (business packages) that come close to a goose that lays golden eggs, as described in Chapter 5, even in business fields with high NCA.

1.2 Custom Business Program and Business Package Development Firms

This book has so far focused on technical matters, but now let’s change the viewpoint and expand the discussion from the perspective of development firms that are making an all-out effort to raise profit. This point of view is crucial to the understanding of what is really happening.

1.2-d Business Package Development Firms

The profit of business package development firms is largely affected by the number of business packages they sell. Consequently, they focus their efforts on selling as many business packages as possible and position those that will likely sell well as their flagship products. In addition, since they can lower the price if a business package sells well, they can expect a further increase of users through a low-price strategy.

Under such circumstances, it is thought that the flexibility of being able to meet all requests is crucial to increasing the number of business packages sold, but in reality, this is not always the case.

Employing the two-stage customization method is the best way to create business packages that can meet the various customization requests from a variety of customers. However, business package development firms almost never employ this method for their flagship business packages. This is because the requests of the majority of enterprise clients can obviously be met using parameter customization, and hence, the remainder is the minority. Even if they were to perform program customization for this minority, the expected increase in units sold would in most cases be miniscule compared to the amount of time and effort required, which is why the two-stage customization method is not employed. The author would like to remind you, that the time and effort for program customization is of a different order of magnitude, anywhere from 100 to 10,000 times, compared to parameter customization. In light of this gap, you can understand why business package development firms shy away from program customization.

Now if you were to say business package development firms exhaustively build in what is necessary to meet all requests through parameter customization, you would be wrong. Necessary development stops at a happy medium. A look at this situation reveals that these firms build in what is necessary, starting from areas in which there seems to be the most enterprise customers that will benefit from the additional development (in other words, areas in which there seems to be a chance to increase the number of units sold); hence, they can only get so far before the returns start thinning out. That is the time when the work of building in what is necessary stops. Rarely do firms purposely expend the time and effort to build in what is necessary to meet requests for which they only expect a miniscule increase in profit.

Rather than such a long explanation, you might find the following shorter one easier to understand. The work of building in what is necessary to enable parameter customization takes more time and effort than program customization, and that is why it stops at a happy medium.

Note that there is another reason why the work of building in what is necessary is not carried out exhaustively to enable parameter customization. This is described in 5.1 “Requirements for Practical and Effective Component-Based Reuse Systems.”

As described so far, business package development firms do not strive to be able to meet all requests through customization. Rather, they usually place an emphasis on sales techniques and customer guidance that leads the customer to a position in which they can meet requirements through parameter customization. In reality, this guidance policy has a major effect on the number of business packages sold.

This should have been mentioned earlier, but the discussion so far assumes that customization service is included in the business package price. If business package development firms were to separately charge for customization service, the discussion would likely head in a different direction.

However, once business package development firms start strongly advocating a switch to fee-based customization services, they may not be able to avoid fostering customer expectations for customized business programs. Once this happens, the switch to fee-based customization services will become incompatible with the guidance policy of business package development firms that are attempting to sell without customization. As a result, you almost never find cases of business package development firms making a business out of customization service. Business package development firms are oriented towards business that does not require constant monitoring, which is an area that has nothing to do with customization.

1.2-e Custom Business Program Development Firms

Custom business programs for enterprises are sometimes developed in-house by the enterprises themselves, but usually it is the computer manufacturer or dealer that develops and delivers them along with a computer. In this case, the fee basically depends on the labor cost for development. In short, the fee for contracting the development of a custom business program is usually decided based on an estimate in man-months, a hypothetical unit of measure for how long it would take one person to develop a program.

However, since there is a vast difference between the amount of work each developer can manage and the quantitative analysis for business program specifications is difficult, the actual number of man-months required for development varies widely. Consequently, contract work for developing business programs is very risky. Losses may be incurred, but there are also instances of unexpectedly high profit. In addition, averaging out a large amount of contract work mitigates variability, resulting in the difficult business of being able to produce a profit one way or another. Nevertheless, from the perspective of computer hardware sold along with business programs, this was more than feasible as a business because it was possible to make a good profit in a stable manner, at least until the open movement started gaining momentum.

Under such circumstances, increasing the number of developers and the amount of contract work for developing business programs is considered crucial. By doing so, variability is statistically mitigated, and this leads to increased sales of hardware, which has a large profit margin.

In addition to the above-mentioned approach of increasing both developers and work, there is also a work saving strategy of increasing only the amount of work without increasing the number of developers, due to the rationalization of development work for custom business programs. However, rationalization is not advancing in environments where estimates in man-months directly link with sales. You could easily say that custom business program development firms do not feel that they have to implement cost reductions, no matter what. For instance, even when they did try to come up with a rationalization plan, it was conspicuously lax. Wagering a company’s fate on rationalization is extremely rare.

Generally, rationalization does not readily progress without strong external pressure. Furthermore, there was once no pressure whatsoever. However, with the advance of the open movement and price reductions for hardware, both of which exert downward pressure on profits, even custom business program development firms are being forced to rationalize.

Now let’s take a more in-depth look at custom business program development firms by categorizing them either as system integrators or firms that carry out development work on a subcontract basis under such integrators. In addition to computer manufacturers and dealers, custom business program development firms also include the software development companies that actually develop the programs that the others order. It was once usual for computer manufacturers and dealers to have software development companies develop custom business programs, and then take on the role of system integrator (put together a system comprised of hardware and various pieces of software) themselves.

Before the advance of the open movement, the information necessary for development flowed from computer manufacturer to dealer, and then to software development companies, which put software development companies in a weak position. However, control by information weakened after the advance of the open movement. That is why powerful software development companies are increasingly receiving direct orders from customers. We have entered an age where the various abilities of both system integrators and software developers are increasingly coming under question.

1.2-f Reuse

Unexpectedly high profit can be made in the contract development of custom business programs. For instance, there are cases where a software development company receives orders for similar business programs. In such cases, cleverly allocating the same developers to that work enables the adoption of a measure referred to as the conversion or appropriation of programs. Appropriation in this case refers to a developer reusing a custom business program developed for Company A to develop a similar custom business program for Company B. This is also known as duplication, but because of its negative connotations, as is often the case with many other words as well, I will hereafter use the term reuse, which does not harbor such a negative meaning.

Reuse is generally carried out on a personal basis. It is usual for a certain developer to reuse a program he or she has developed. If reuse could be carried out systematically, it would serve beautifully as a rationalization plan for development work. However, when you consider the time and effort it takes to decipher a program so that it can be reused, it is usually better to develop programs from scratch. One theory holds that it is best not to reuse a program written by someone else unless eighty percent or more of it can be used exactly as is without having to be deciphered. For that reason, rationalization plans for systematically implementing reuse have not been exhaustively pursued.

1.2-g Custom Business Program or Business Package? (Part 2: Cost of Customization)

From the standpoint of business program users, the question arises, which is more advantageous, using a business package or ordering a new custom business program? If they could find a business package that exactly fits their needs, the answer would certainly be a business package. However, that is not always possible to find. That is why some form of customization becomes necessary, and the resulting expense is a villain of sorts.

There is a funny, yet unfortunate anecdote related to this. A certain consulting firm (not mine) once said that it was more expensive to customize a certain business package for one of their customers (an enterprise) than it would have been to develop a custom business program from scratch.

Generally, the applicable scope of a business package is fixed, and the moment you try to deviate from that scope, the cost of customization will start increasing. A typical example of this is subsequently switching to program customization after parameter customization could not adequately meet customization requests.

Accurately estimating the cost of customization is vital to the application of a business package, and failing to do so will lead to a mistake being made in choosing between a custom business program and a business package.

In conclusion, when deciding whether a custom business program or a business package is advantageous from a business perspective, making an assessment that takes into account the cost of customization is crucial. This is a conclusion from a user standpoint. At the same time, this is also the reason why the markets for business package development firms and custom business program development firms are separate.

1.3 Business Packages with Special Customization Facilities

This section will introduce the products of Woodland Corporation, which has now been merged into FutureArchitect, Inc. This company occupies a unique position among custom business program development firms. Woodland Corporation was a medium-sized enterprise that has delivered over 10,000 business systems as an office computer dealer (a mid-range computer dealer), but unlike other custom business program development firms, it has been completely involved in the rationalization of development work. The company has also developed business programs that use ‘Business Logic Components.’ Such programs should be referred to as business packages with special customization facilities, which are located between custom business programs and business packages. Let’s take a look at the features of these business packages with special customization facilities.

1.3-h Woodland Corporation's Efforts

Woodland Corporation got involved in the rationalization of development work for custom business programs because they thought they had problems in the following two areas:

• Real variation in development cost; and

• Labor-intensive development

Based on their prior development experience, they knew that although custom business programs also have company-specific portions, common portions are more numerous, and hence, they pursued research based on their hunch that there must be a better way.

If they could standardize program portions related to common specifications and then adjust only the program portions related to each company’s variety of standards, development work for custom business programs could be rationalized. However, this is easier said than done. There is no clear demarcation between common portions and company-specific portions, and such demarcation is by no means easy to do. (To use the latest terminology, such demarcation is the compartmentalization of frozen areas and hot spots.) Consequently, the ability to cope, no matter where company-specific portions are, was necessary, and they had to rethink the correspondence between programs and specifications from scratch.

For reference sake, let’s take a look at the current state of reuse being spontaneously carried out by individuals. For instance, when reusing a custom business program originally for Company A to remake a new one for Company B, we know that by focusing on the portions wherein specifications differ between Company A and B, all that is required are program changes related to those portions. Therefore, development becomes markedly easier than having to develop all new business programs.

It would be wonderful to enable systematic reuse on a personal basis. However, it is not easy to make reuse systematic. Only the developer knows the correspondence between a program and its specifications. Therefore, it is not easily understood by others. Comprehending this correspondence requires you to become the student of the developer and decipher the program from inside out. This enables you to figure out where you should make changes just as if it were a program you developed yourself. However, since programs cannot be easily deciphered as if you are reading a novel, it takes an extremely long time to get acquainted with them. Knowing this, investment towards getting acquainted with programs may be another rationalization plan.

Woodland Corporation concluded that this would not be an essential solution. Even if they were to apply this rationalization plan to a so-called “spaghetti program,” a disorganized mass of code, it would inevitably lead to failure. Accordingly, they headed in the direction of making the correspondence between programs and specifications easier to understand by devising a structure for business application programs.

1.3-i Program Partitioning with Data Item Association

In reality, the company faced many detours through trial and error. However, since it would be difficult to understand that account, let’s set it aside so that we can get to the heart of the matter.

In the 1980’s, they decided to start partitioning programs in accordance with data items, not only because of the focus on data-oriented approaches (concept of emphasizing data items), which was also garnering attention in Japan, but also because it made good sense based on past development experience. Past experience made them realize that over eighty percent of each company’s variety of standards was related to data items in one form or another.

They were inclined towards partitioning with data item association because they thought it would allow not only the developer, but also anyone else to understand the relationship between a program and its specifications. This is due to the fact that in the business field, specification change requests are represented using data item names. Please also refer to Appendix 2 “General Features of Business Applications in the Business Field.”

For example, a data item named “product unit price” appeared in a specification change request in the form “we want to change the method for computing ‘product unit price’ discounts.” They focused on the fact that when implementing the customization, as in this example, they should be able to meet the request simply by changing the program portion corresponding to the data item “product unit price” that they could extract.

After pursuing this idea in search of how to partition programs, they found that there were also a few portions that would not correspond with data items, but by using their ingenuity they still succeeded in partitioning most in accordance with data items. They were able to realize their idea by gathering program fragments that extracted portions corresponding to each data item and then standardizing them (forming them so that they fit in with a certain template).

As a result, they were able to make data item correspondences in seventy to eighty percent of business programs, and the correspondence of each program fragment with specifications became clear just as they had intended. Moreover, each fragment became a closed block that could be understood by itself. In addition, almost all were one hundred lines or less. On top of that, the effect of fitting in with a template was gained, and each fragment became easy to decipher because they took on a stereotypical format. Finally, they made it easy to search program fragments by making the name of each one start with the name of the data item they contained, and no large-scale search system was required to do this.

Note that a program fragment corresponding with a data item has the qualities required of ‘Business Logic Components’ that will be discussed in Chapter 5, and hence, this book refers to them as data item components.

Woodland Corporation used such data item components and ‘Business Logic Components’ to develop a synthesis system for business apps aimed at a sales management system. They named it SSS (triple S). This system is perhaps the first to be comprised of ‘Business Logic Components’ that fit the definition given in this book. The combining of these components enabled the production of sales management systems that were exactly how they expected.

Figure 1-1: SSS Components and Component Synthesis

There are some approximate boundaries between ‘Business Logic Components’ and component synthesis tools, but these are not clearly separated in SSS. However, since they can be conceptually distinguished in a clear manner, I will refer to them as SSS component sets and SSS tools as shown in Figure 1-1.

The first time I saw this system, the only SSS component set offered was one for sales management operations (sales management activities). However, I was able to clearly predict that they would be able to use the same component synthesis tools (SSS tools) to produce business systems, as long as they developed component sets for other businesses. Since this component-based reuse system is actually a mechanism that effectively functions in the business field at least, enhancing component sets will lead to their development into ERP packages.

1.3-j Custom Business Program or Business Package? (Part 3: Conclusion)

If you look back over time, you will find there tends to be a polarization between custom business programs on one-end and business packages on the other, and this polarization causes problems, as described hereafter.

Business packages are reasonably priced because of the extensive reuse involved, but they are geared towards the avoidance of customization. Few efforts are being made to create business programs that fit exactly. If you want something that is a perfect fit, you must order a custom business program. However, since custom business programs employ almost no reuse, which means they are developed nearly from scratch, they are not reasonably priced.

Accordingly, people end up wanting what are called business packages with special customization facilities, which combine the best of business packages and custom business programs, are moderately priced, and fit perfectly.

If you were to try to elaborate a plan for such a system, you would realize that areas that could not be dealt with using parameter customization when adopting two-stage customization should be designed so that they could also support special orders through program customization.

The story so far could stand on its own, but then the cost of customization would be a problem, and it would not be possible to keep prices within a reasonable range. There is a problem with using program customization to deal with areas that cannot be dealt with using parameter customization. The problem resides in the fact that there is a high customization cost (two or more figures higher). Therefore, it can be seen that reducing the cost of program customization will become an issue that must be resolved.

The ‘Business Logic Component Technology’ developed by Woodland Corporation is one answer to this issue. When performing program customization using this technology, the applicable scope is limited to a number of data item components. For instance, even if a business application program had 100,000 lines in all, you would only have to focus on data item components in about 1,000 of the lines when performing program customization. Furthermore, this work is much simpler than customizing the usual 1,000-line program because the data item components are standardized.

Conventional program customization work required the detailed examination of some 10,000 lines out of 100,000, followed by touchups here and there throughout that wide region. In addition to the large number of programs lines, this sort of work is difficult because you have to very careful about its tendency to have adverse effects on program operation. The use of ‘Business Logic Component Technology’ enables the amount of program customization work to be vastly reduced compared with such conventional work.

Since there is at least a single-digit reduction in the amount of customization work, program customization for business packages with special customization facilities using data item components must be thought of as a completely different beast compared to what came before. Consequently, this book refers to it as component customization.

Table 1-1: Custom Business Programs, Usual Business Packages, and Business Packages with Special Customization Facilities

Evaluation Point

Type of Software

Support for Special Orders from Customer

Cost Burden on Customer

Custom business program

Can be supported in every way because the program is custom built.

Large burden because a single customer incurs all development costs.

Business package

Often results in support within the range possible with parameter customization.

Small burden on each customer because a single package can be reused for many customers.

Business Packages with Special Customization Facilities

Can be supported in every way because of component customization.

Small burden on each customer because a single package can be reused for many customers. However, the cost burden of component customization is inescapable.

In conclusion, the author would like to present the comparison shown in Table 1-1 “Custom Business Programs, Usual Business Packages, and Business Packages with Special Customization Facilities” and discuss the gist of this chapter using the keywords described thus far.

Since there is such a huge cost gap between parameter customization and the conventional method of program customization for business packages, business package development firms have adopted a strategy of avoiding program customization. These firms have headed in the direction of the polarization of custom business programs on one-end and business packages on the other.

However, since component customization can reduce this gap and in a sense enable a cost reduction in program customization, it is possible to produce business packages with special customization facilities that fuse a custom business program with a business package. In addition, a custom business program or business package can fulfill the aim of taking the best of each, being reasonably priced and fitting perfectly.

It is therefore easy to conclude that business packages with special customization facilities are the answer to the question “custom business program or business package?”

AppliTech, MANDALA and workFrame=Browser are registered trademarks of AppliTech, Inc.

Macintosh is a registered trademark of Apple Computer, Inc.

SAP and R/3 are registered trademarks of SAP AG.

Smalltalk-80 is a registered trademark of Xerox Corp.

Visual Basic and Windows are registered trademarks of Microsoft Corp.

Java is a trademarks or registered trademark of Sun Microsystems, Inc.

===> Chapter 2