by John P. Carbone and Joseph R. Hudicka

All organizations have goals that are central to the foundation of their businesses. Over the course of time, organizations pursue these strategic objectives by making critical business decisions at key points in time. The decisions made within an organization will bring the entity closer to, or further from, its overall strategic goals. To add to the complexity of effectively making these decisions within the setting of a global economy, many for-profit organizations find themselves continually rethinking strategic objectives and reshaping the way in which they interface with the ever-changing climate surrounding them. As customers and vendors are forced to reinvent themselves in pursuit of profit maximization, the energy and pace of the global economic system reaches a frenetic level.

In order to keep pace while maintaining forward momentum, organizations need to continuously reassess external indicators such as market share, demand curves for product and service offerings, and legislative mandates. Internal assessments are also required to map organizational core competencies to tasks that will ultimately accomplish the organization’s strategic goals. In this scenario, organizational goals become a slow moving target bobbing about the surface of the water, continually being pushed around by the infinite economic crosscurrents flowing around them.

How an organization chooses to do business within the marketplace is one of the most basic decisions that can drastically affect corporate profit. Many questions arise as management continually reassesses existing circumstances. Some questions such as "Should more money be put into advertising this year?" will require immediate attention. However, there will be periodic strategic-level questions that arise due to management’s perception of the overall marketplace based on the information it has at its disposal. For example, a vitamin pill manufacturer might ask the question "Should we move into the business of generic over-the–counter medicine production?" Considering that the manufacturing processes might be very similar, one might be inclined to think that this is a reasonable expansion into a new business line. Instead of compressing vitamin C into tablet form, the process compresses aspirin.

Although the manufacturing expertise to expand into such a venture might be in place, the overall organizational capability might be lacking. A vitamin pill manufacturer might not be equipped to deal with the legal reporting requirements imposed upon it by state and federal agencies should it decide to enter into the production of over-the-counter medicine. Lot control would most likely be more stringent. Government personnel auditing the manufacturing process might certainly expect an appropriate "paper trail" demonstrating the tight lot control. Expiration dates, vendor selection, disposal of outdated raw materials and any number of new issues might need to be addressed by a firm making a move into a new arena. Internal cost reporting requirements might require analyses by product, product type, customer, vendor, or advertising campaign.

This represents a tremendous amount of information for an organization to analyze.

Organizations traditionally will limit the amount of information analyzed as a function of the limits of their organizational information system. Since organizations cannot possibly anticipate all of the demands that the market environment will impose upon them, they should develop an information system that is as flexible, scalable and affordable as possible. This organizational information system must be able to evolve rapidly in order to meet the challenge of management directing the organization into new environments, as well as responding to new pressures from old environments.

In his book, Competitive Advantage, Michael Porter describes the value chain. "Every firm is a collection of activities that are performed to design, produce, market, deliver, and support its product. A firm’s value chain and the way it performs individual activities are a reflection of its history, its strategy, its approach to implementing its strategy, and the underlying economics of the activities themselves." Basically, the value chain of a firm is composed of its support activities and its primary activities. Together, these activities define how the firm conducts its business and determine the firm’s destiny. "Each business is part, but only a part, of a value chain running all the way from the periodic table of elements to ultimate dust … Each firm must be understood in the context of an overall chain of value-creating activities of which it is only a part." Support activities require systems that work for the day-to-day transactional processing and traditional accounting functions. More advanced and customized applications are needed to dovetail into the value chain configuration the firm uses at any point in time. While it might be expected that applications with basic functionality might not change over a long period of time, peripheral applications and reporting requirements might completely change due to strategic shifts in direction.

There is a spectrum across which organizations typically choose to respond to these challenges. On one end, an organization can purchase an off-the-shelf software package. This alternative is sometimes cost effective but limits the organization to the functionality that the package supplies. Also, the package may include much functionality that is unnecessary for a particular organization resulting in paying for something that is not used, or may be used ineffectively.

At the other end of the spectrum, an organization can either use its own internal development team or hire outside consultants to create a completely customized information systems solution. While possessing the advantage of potentially getting exactly what the organization needs, this method can consume a great deal of time and resources. Also, there is no guarantee that the completed system will function in exactly the ways that management envisioned. The majority of first-time implemented systems fail and require some level of re-analysis and rework to become fully functional. Given the fast pace of the surrounding climate, delays in getting a system up and running can be disastrous. Where is the middle ground on this spectrum?

Having made the case for the information system that can evolve, the natural question that follows is "How can such a system be built?" Information systems have a Database Management System (DBMS) at their core where all of the data is stored. Getting the information into and out of the database is the job of the individual applications that collectively function with the DBMS as the organization’s information system.

Applications can be classified into two different groups:

1. Basic Functionality Applications
2. Environment-Specific Applications

Basic functionality applications include business functions common to many organizations. Some typical examples include (but are certainly not limited to) General Ledger, Accounts Payable, and Accounts Receivable. Such applications can be modeled and designed generically. Using an object-oriented focus, Complex Objects (COBS) have been created. A COB³ is a pre-built portion of an application including a set of tables, forms, reports and triggers. Each Complex Object is specially designed to be quickly and easily assembled and bolted into an existing application with a minimum of development time and effort.

The COB-based approach provides prepackaged, time-tested, basic functionality, thus eliminating the need for development resources being channeled into the design of the most common system functions. COB-based system deployment invites custom development only where it should and has to be, namely to meet the unique specifications of the organizational environment.

Basic functionality COBS come with standard forms, screens and reports but the periphery is completely open to the addition of an Environment Specific Development Layer (ESDL). This approach has been used to deploy systems in both the commercial and government sectors.

This systems deployment approach using COBs acknowledges the fact that basic organizational functions are similar in nature - up to a certain point - after which, there are many ways in which an organization can choose to run its business within the myriad of environments where it might find itself operating. Using a DBMS and a Complex Object, an organization can achieve its own system specifications with minimal additional programming effort. Complex Objects are designed with anticipatory development "hooks" on the periphery of each application.

The following tables offer some points to consider when making decisions about package solutions or ground-up development.

The tremendous advantage of the Complex Object-based approach is the ability to immediately deliver all basic functionality to the organization, while enabling more rapid incremental development of environmentally mandated specific requirements. An organization can purchase a Complex Object and deploy it immediately as the building blocks of the larger, overall information system.

After the database engine is in place and Complex Objects have been deployed, another layer of application is laid upon this foundation. An Environment Specific Development Layer (ESDL) is developed and joined to the appropriate underlying database tables deployed at the Complex Object layer as shown in Figure 1.

Figure 1: COB-based Approach to Layered Deployment

It is this ESDL application layer that defines the personality of the organization, that is, how the organization will function within the environment in which it has chosen to operate. This application needs to be developed by people who can understand the business processes and convert such knowledge into a functioning application. It is the ESDL layer where firms should expend the most resources to create a systems environment capable of adapting to changes in the business environment.

Over time, if the strategic position of the organization shifts, it can shed a portion of the ESDL layer and redevelop sections of the application(s) to reshape its business face without major changes to the inner COB and core DBMS layers. In most cases, the ESDL will simply evolve over a period of time, adding layers of functionality as shifts in business posturing occur.

Many decision-makers believe that it is counter-intuitive to use resources for the area of a system that is most vulnerable to change. The fact is, if true Complex Objects are deployed initially, in combination with a well thought out development effort of the ESDL using a sound methodology, it is conceivable that only incremental development of the ESDL will ever be needed.

The Lancaster County Tax Collection Bureau (LCTCB), faced with booming growth in population and a predominantly manual approach to the process of collecting local taxes, decided to develop an enterprise-wide Revenue Acquisition and Distribution System. The project called for the development and deployment of a system for the scanning, data-capture, data cleansing and storing of the tax information using an Oracleâ database. The tax information would be manipulated with custom designed front-end applications. Faced with the uniqueness associated with the administration of tax collection and compliance, LCTCB selected the services of Dulcian, Inc. to design and develop their ESDL.

Using the CADM development methodology, generic COB-based applications were customized to perform very specialized functions such as supporting the arbitrarily complex workflow rules associated with processing tax returns. Although complex in nature, the application system was also able to support legislative changes in the tax law.

While tax administration is a unique task, the General Ledger system mechanics are identical to that of any for-profit business. A Dulcian-designed, Oracleâ -based General Ledger Complex Object was bolted into the tax application, delivering immediate functionality and saving resources for the specialized development of the ESDL. The Environment Specific Development Layer represents the unique application functionality that gives the LCTCB organization its personality and characteristics as a tax collection bureau. It is the ESDL where resources should be used to develop an application layer that increases productivity along the organizations specific value chain.

While certain general functionality can be obtained from the use of COBS, organization-specific functionality must be derived from an effective ground-up development effort of the ESDL layer. In any organization, this development of efficient systems is dependent on three factors:

1. A sound methodology
2. The right tools
3. People with the necessary expertise to use the tools within the accepted methodology

Certainly, the overall System Development Life Cycle guides a development project from conception through production and maturity. But a more specific methodology tied to commercial development tools needs to be embraced in order to ensure the success of the effort. A methodology, such as CADM, employing numerous quality control points and meticulous system requirement tracking techniques should be chosen.

Team members developing the ESDL layer will most likely be comprised of both staff personnel and outside consultants. Since the ESDL defines how the firm will interact with its environment, it is extremely important that team members from the organization not only participate but also help to drive the development effort. Placing the focus on ESDL development makes the process less arduous because resources are conserved during COB deployment.

Typical functional areas where Complex Objects might be deployed include:

• General Ledger: A GL COB can support the scalable needs of organizations. It supports basic accounting functions and allows each journal entry to be associated with any number of objects in the database.
• Inventory / Merchandise Movement: Everything from the request for purchase orders to the final inventory put-away can be supported in this structure. Movements can be associated at the detail level to support PO and invoice creation within the COB.
• Budgeting: COB-based budgeting can be implemented to support any level of hierarchical budgeting. Designed to permit budgeting for any level of object in the database on any criteria. Budgets can be rolled up to any level of aggregation.
• Workflow: Workflow is vital to any organization. Workflow engines can be deployed as COBS in a simple model that supports the basic flow for an object. A more complex workflow model might be used to support full state transition diagrams for each type of object.
• Demographics: Any object can have any number of address, phones, electronic addresses, or contacts. Functions (e.g. billing, general information) can be specified for the demographic objects.
• A/R & A/P: All of the normal functionality usually found in A/R and A/P modules but developed as a Complex Object allowing for much easier interface modeling of additional applications.
• Security: Any number of security events can be associated with an application. Security setup screens can allow the user to specify what user roles are allowed to perform each security event.
• Comments: To allow comments of any type to be attached to any object in the database.
• History: Providing an audit trail for all changes to an object in the database.

Finally, no system implementation will be successful without the proper development talent and expertise. The best possible talent should be used in designing and building a system that can serve the organization’s immediate needs and goals. If implemented as we have described, it should also be able to meet many of the organization’s future needs and keep pace with the rapidly changing business climate of the next millennium with a minimum of effort and expense.

John P. Carbone, CPA, MBA is a member of the Institute of Management Accountants. He is Chief Financial Officer of Dulcian, Inc. an Oracleâ product development and consulting company. He is also a member of the adjunct faculty at Mercer County Community College in NJ where he has taught Cost Accounting. jcarbone@dulcian.com

Joseph R. Hudicka is a data migration and systems design specialist for Decision Support (OLAP) and On-Line Transactional Processing (OLTP) systems with specific business knowledge in the areas of finance, health care, pharmaceutical and manufacturing. He is co-author of Oracle8 Design Using UML Object Modeling, Oracle Press, 1999. Joe is the chief architect of DataMIG ™ (Patent Pending), a complete data migration management tool suite. Joe is a member of the Oracle8 Customer Advisory Council providing insight regarding future enhancements to the Oracle8 Server technologies. He delivers presentations regularly at major Oracle conferences and local Oracle user groups.

jhudicka@dulcian.com