Hiding the silos

paving the way to e-business success through successful integration projects

Paul Baumgartner, PMP, Consultant, Origin Technology in Business


It is hard to imagine a CEO of a large company who has not thought of how E-business can play a role in his or her company. Most large companies have made their mark in the Web world by making marketing, product, and contact information statically available on the Internet. Yet, in order to advance to higher levels of an E-business maturity model, a company must undertake back-office integration projects in order to provide a satisfying “web experience” to the customer who desires to transact business via the Web. The challenge before companies today is to synthesize well-entrenched “silos” of functionality so customers can seamlessly research products, place orders, review order status, and conduct after-delivery support all with one website. This paper will explore the cultural, staffing, scope, timing and project integration challenges project managers face in executing back-office integration projects.

The Non-Integrated Website

The end-users of a company's E-business offerings are its customers, suppliers and employees. This “web constituency” frequently will find clues on a website that suggest the company has not adequately integrated its back-end for E-business. Some of these clues are:

• A customer ordering process that does not indicate if the item being purchased is in stock.

• A customer must use a variety of a company's websites to carry out a relationship with the company. Each site has its own look and feel and content standards.

• An intranet site that requires an employee to enter and maintain multiple copies of personnel data.

• A message that confirms an Internet transaction with “Please allow four to six weeks for delivery.” This phrase is commonly seen in the off-line world to allow time for receiving a paper form, interpreting handwriting, validating information and entering data when fulfilling transactions. None of these steps exists in the online world, so why should it take four to six weeks to fulfill an E-business transaction?

If a company's customers become dissatisfied with the web experience that results from non-integration, the competition is just one click away. Web constituents are placing great demands on companies today. Customers expect to transact business over the Internet. Suppliers give preference to companies that offer a web procurement link. Employees look to intranets for the knowledge required to do their jobs. Competitors who are more experienced in E-business enjoy cost advantages, increased market share, higher customer satisfaction through personalization and new nontraditional sources of income (e.g., Federal Express' E-business offerings have allowed it to enter the business of logistics consulting).

Many company websites have been built to mirror the company's organization chart. Each unit on the organization chart has a back-end silo or set of silos, which solely support the unit's operations. A company's inventory of back-end systems which are critical to all units' operations are referred to in this paper as the “back-office.” In the same way that silos were created, companies can create websites with an internal focus as opposed to a constituency focus. Such websites place the burden on the web constituents to piece together their relationship with the company. The company that fails to hide its silos on its E-business offerings will fail to provide the holistic “web experience” that its constituents expect. To make its internal operations appear seamless to web constituents, a company can start by understanding how its silos came about.

The Creation, Proliferation and Management of Silos

Until recently, there was little incentive to integrate systems. The construction of silos began in the heyday of the mainframe, when most computing activity centered around automating core business activities that were manually intensive and inefficient. Separate project teams worked in parallel to build systems required by different functional areas. For example, in a bank, one project team would build deposit systems; another would create loan systems. The fact that the two project teams each created their own customer file was less important than rushing to automate so that the large cost of forms, paper and clerical staff would no longer be necessary.

Silos proliferated as changing business environments and the personal computer (PC) revolution brought on the decentralization of computing in the 1980s. During this time, a plethora of non-integrated systems were developed as a result of computing activity in the business units. Dissatisfied with the centralized nature of corporate IT, business units had free rein to develop whatever system in whatever technology that was available to meet highly specific requirements. Over time, these custom-built systems housed multiple copies of customer data, employee data, financial numbers, etc. In the client/server movement of the early 1990s, concerns over creating more silos were pushed aside in favor of attractive client interfaces, which accessed data on a server. The demand for attractive Windows interfaces and faster development cycles also outweighed the added effort required to maintain client/server applications on a multitude of user computers with dissimilar hardware and software configurations.

Exhibit 1. E-Businesses Maturity vs. Project Complexity

E-Businesses Maturity vs. Project Complexity

Even though systems were not integrated, corporations still required the use of integrated data. As a result, what clerical staff remained shifted their day-to-day responsibilities from data entry to a new activity: taking data from one system and manually entering it into another. Data was taken from silos and re-keyed into other systems many times over. The introduction of tools such as spreadsheets and e-mail made it easy to re-key and distribute data. In some cases, small server applications were developed to alleviate some of the re-keying. However, these applications were poorly written, designed for a highly specific purpose, and often forgotten unless there was a change to a system on which the application depended. For the most part, companies accepted re-keying as a necessary evil rather than attempt to integrate their systems. The silos lived on.

Incentives to integrate began to surface when companies looked to enhance relationships with customers. Banks realized that the customers who deposited money were the same customers who signed loans with them. Therefore, banks became focused on relationship selling and cross-selling. In order to do this successfully, bank staff only needed one set of data about a customer. At this time, databases that reflected relationships, called relational databases, became popular. Banks merged selected deposit and loan data into large, organized data storage areas, called data warehouses, so that a teller could see the bank's full relationship with a customer.

More incentives surfaced as companies sought to react sooner to an ever-changing business atmosphere. To respond quicker to external competitive forces, companies relied more on financial data that was rolled-up from numerous business units. The corporate accounting department provided most of this data, and almost all of its data was re-keyed several times over. The time it took for data to be re-keyed from the source system to its final destination did not provide financial numbers quick enough for senior management to react to changing market conditions. Moreover, since the data was continuously re-keyed by humans, it was highly prone to error. Companies sought a “be-all, end-all” system that would allow corporate accounting departments to automatically receive and manage operational data from disparate source systems. In response, companies implemented enterprise resource planning (ERP) systems, which were large, integrated software packages designed to automate financial, HR and manufacturing processes. Yet another strong rationale for the implementation of ERP systems was to replace existing silos that were not Y2K compliant. While a company's staff functions dedicated themselves to implementing ERP, another technological revolution was occurring in the line functions of the company.

Enter the Web

E-business was born around the mid-1990s. The popularity of the World Wide Web soared as marketing departments scrambled to establish an Internet presence. After seeing what competitors had done, companies rushed to establish their own websites with general information such as contact information, a company description, directions to the company offices, pictures of company headquarters, pictures of the company's products, etc.

Companies learned that setting up a website was easy, inexpensive and low risk. The learning curve to develop web applications was small in comparison with that of other development tools. As a result, business units inside companies used the Web to meet their needs of publishing content-based information for the rest of the company's usage. Companies established corporate-wide web-based networks, called intranets, and a plethora of internal websites sprung into existence. The web environment brought the added advantage of being able to access a site from any user's computer running on any hardware platform. As a result, decentralized development efforts shifted focus from the client/server arena to the Web.

As companies learned more about the Web, they instituted broad categories of functionality that reflected their level of maturity with E-business. Exhibit 1 shows the levels of maturity through which a company can progress with E-business.

Level 1 denotes a company's first steps with E-business, which is generally focused on content delivery. The static content is typically what the web constituency would find in the company's paper brochures, thus the name “brochureware.”

Level 2 is the introduction of interactivity. Companies noticed that customers were drawn to websites that allow for two-way communication. Such interactive functionality included the ability for Internet users to register themselves with a site and to enter data into a page and be presented with an interpreted result (e.g., loan payment calculations).

To achieve Level 2 maturity, companies were pressured not only to build interactivity into their sites but also to find better ways to manage rapidly changing content. Storing highly volatile information such as price lists and product catalogues in static web pages was very inefficient. As such, companies standardized on development tools that allowed content to be stored in a database. Tools such as Lotus Notes/Domino and Microsoft Active Server Pages allowed users to dynamically manage content by interacting with a database. These tools made it easy for a company to make the transition from Level 1 to Level 2. Such tools had functionality to connect to external data sources; however, they were primarily designed to be stand-alone content management and data registration databases, and, as a result, companies used them in that way.

Onward to E-commerce

Companies now are being pressured to move to Level 3 of E-business maturity, where they enter the realm of conducting electronic commerce with their web constituents. The constituents now seek to use the company's website to mix and match products, order a custom-configuration of products (e.g., a custom-built PC from Dell), select shipping options, arrange payment, check on delivery status, and obtain post-delivery assistance. They expect to see standard data, a standard user interface, and a workflow that hides the departments and plants that perform work to satisfy the transaction. Consequently, company sponsors of line E-business initiatives now must divert their attention from the front-end to the back-end.

At the same time, senior management is urging its staff functions that enabled ERP systems on the back-end to “extend the enterprise.” With Y2K initiatives behind them and core ERP functionality in place, companies are asking their ERP proponents to extend access of ERP and silo data to customers, employees and suppliers for their use. In other words, the back-end is now in search of a front-end.

To move to Level 3 maturity, the ERP-oriented sponsors of the back-end will, at some point, meet the web-oriented sponsors of the front-end. Their mutual charge will be to enable the company to conduct transactions with its web constituency. Once this is achieved, sponsors will be asked to use transactional data to personalize the web experience for its constituency (Level 4). After this accomplishment, sponsors will face the task of extending internal workflows beyond company doors (Level 5). The key competency that a company must develop to go from the realm of standalone web activity to e-commerce is integration.

A Culture Clash

As Exhibit 1 shows, moving from providing basic interactivity (Level 2) to enabling transactions (Level 3) greatly increases the complexity of a project. To successfully integrate its back-end, a company will have to “jump” to levels of complexity to which the company may not be accustomed. To engage in an E-business initiative that brings together components of its ERP systems, silos and web offerings, a company may experience unprecedented levels of project risk, cost, staffing issues, concerns for scope, etc. Even when a company has mastered offering electronic transactions with customers and employees, it faces another “great leap forward” when it pursues integrating externally, e.g., integrating with its supply chain. Procurement and data transfer with suppliers involves not only the merging of dissimilar systems and business processes, but also dissimilar cultures.

Adopting projects that are more complex and more risky can also uncover dissimilar cultural identities within a company itself. When the front-end web-oriented sponsors finally meet with the back-end ERP-oriented sponsors to create a fully integrated back-office, there is a high likelihood of culture clash. Both front-end and back-end personnel have dramatically different mindsets shaped by prior experience. As such, there will be differing expectations, and Exhibit 2 outlines examples of those expectations.

As Exhibit 2 demonstrates, “expectation gaps” are highly likely when front-end sponsors meet with back-end sponsors. Imagine the scenario where a front-end web-oriented sponsor wants to show inventory status to customers ordering products on the company website. A project time estimate is provided to this sponsor who immediately questions why it takes six months to complete the project. After all, in the mind of this sponsor, all that is being requested is a mere web page or similar display of inventory status that can be done in hours; so why is the time estimate in months?

Exhibit 2. Differing Expectations of the Back-Office Integration Project Sponsors

Differing Expectations of the Back-Office Integration Project Sponsors

The above scenario may seem like an exaggeration, but it illustrates that the web-oriented front-end environment and the ERP-oriented back-end environment are inherently bipolar. As companies have matured beyond static web pages and basic interactivity, their front-end web-oriented sponsors have falsely assumed that creating commercial software is easy, inexpensive and low risk. These sponsors receive a rude awakening when they move into the realm of integrated e-commerce, where they realize that software development is more of a profession than an art. The back-office integration project team is not only challenged with the technical integration of ERP, silo and web-based systems, but also integrating cultural differences as well. The recognition of intra-company cultural differences is a key component of the cultural transformation companies must undergo to take full benefit of E-business. The importance of cultural transformation for E-business is underscored by Chris Selland, VP of E-business strategies with the Yankee Group: “The most critical step in becoming an E-business is a cultural, rather than a technological, transformation” (Selland, 1999, p. 13).

Selecting the Right Staff

Although aligning expectations and integrating cultural differences are both critical to the success of a back-office integration project, having the right level of expertise on the project is just as critical. The expertise required for a back-office integration project is hard to find and difficult to keep up to date. Because of this, companies will rely more and more on external service providers to fulfill highly defined roles. Such roles can include a software developer who is highly specialized in a middleware product (such as IBM's MQ Series) or a business analyst who is skilled in integration terminology and data mapping. External service providers can also offer unbiased technical architecture analysis as well as project management services.

Although there will be more and more reliance on external service providers to fill specific roles, internal IT departments will welcome the fact that the success of a back-office integration project requires the active involvement of in-house technical staff. The back-office integration effort does not fit the IT turnkey model offered by many outsourcing firms. Nor can a systems integrator come in with a “packaged” solution that IT can just “plug-and-play.” For back-office integration to be successful, it must be highly tailored to the company's systems and its business processes. In-house personnel have the knowledge of one or more of the silos being integrated as well as a deeper understanding of the company's business and culture. Moreover, testing and deploying the integrated solution involves internal staff who set-up, configure and maintain the company's IT infrastructure.

The back-office integration effort can foster a relationship of mutual dependence between the internal IT organization and the external service provider when the right mix of effort by both is achieved. By leveraging this new vendor/client partnership, the internal IT organization is free to develop a competency that will give the company an edge over its competition: the ability to successfully integrate its applications. The internal IT organization will no longer ponder its identity by asking questions like:

• “Do we spend too much time on maintenance instead of development?”

• “If we outsource all this work, what's left for us to do?”

• “Are we doing too many tasks the users should be doing?”

Now when asked “What do you do?” an IT organization will have a resounding answer: “Application integration!”

What's Included?

A back-office integration solution driven by E-business should have a well-defined scope: provide the data required to meet the E-business need. This can be accomplished if the E-business solution has a clearly defined scope. This is not always the case.

Chris Koontz, a managing consultant with Parks & Company, suggests some steps for developing the data requirements for an E-business application (Koontz, 2000, p. 24). After the business goals of an E-business application are defined, an analyst will work with the users to develop a list of information required to fulfill the business goals. The information may or may not exist electronically within the company. The focus is not where the existing information is stored or who has what access, but instead to capture and understand all information that the E-business application requires. Only after completion of this step does focus shift to where the data is stored, or should be stored. Voila! Data requirements are specified, and scope is defined.

If data is missing, one approach may be to request that the data be stored in an existing system. However, this option may be technically or organizationally unfeasible. In one such case, the organizational owners of a globally implemented ERP system were presented with many requests to report on employee data that was not stored in the ERP system. The owners were open to storing such data in the ERP system, but only on the condition that a sound business process existed to ensure that the data was entered and kept up to date. Unfortunately, very few business units could meet this condition, so the ERP system stored very little more than its standard data.

Another approach is similar to developing a data warehouse: create a custom back-end system that is fed by other systems. The custom system holds all the data required by the E-business application, so scope is well defined. Scope can become a challenge if others in the company discover that the custom system meets most of their needs, and they too want to utilize this system, but with modifications. If not properly managed, applications originally destined to be client applications can quickly turn into server applications. The result can be a poorly designed data warehouse that is difficult to maintain.

Timing Is Everything

A common issue that inhibits back-office integration for E-business is misaligned timing. For example, data required by an E-business application is captured in an ERP module, but that module is not going to be installed for another year.

ERP implementations are typically measured in years. An ERP payroll or HR module is normally installed first, and it must be customized to fit the local tax laws and employment regulations. Other modules that follow affect most work processes in every location and plant. Customers of ERP implementations understand that to reap the full benefits of ERP, it is going to take time. ERP implementation timeframes are in direct contrast with front-end web-oriented timing expectations. Front-end sponsors must react quickly to the demands of the company's web constituents, or risk losing business to a competitor.

What if the front-end sponsors cannot wait for the next implementation of an ERP module? One option is to create a stand-alone interim system. Such a system offers a piece of the functionality offered by an ERP system, but the functionality it includes contains only what is required by the E-business initiative. An example of this could be a small application that reports inventory status to customers ordering products over the Web. Warehouse personnel maintain data in the system by updating a product's inventory status each time the product is picked off the shelf. True, this approach does not seem efficient and it does not reflect true inventory “availability” (i.e., stock may be committed but not picked). Nevertheless, an interim application provides 80% of the required back-end functionality for 20% of the effort of installing an ERP module.

Although the interim solution approach can meet the timing requirements of an E-business initiative, the same scope issues mentioned above apply. The interim solution is only a temporary measure until the full ERP module is implemented. However, others in the company may find need for the data captured by the interim solution, which introduces the risk that the interim solution becomes a source for other systems through integration. When the time comes for the interim solution to be phased out, its “client” systems may be too dependent upon it. This could pose a number of challenges to an otherwise simple ERP module implementation.

Project Integration Itself

Finally, project integration presents some special challenges in back-office integration projects driven by E-business.

A project manager of a back-office integration project driven by E-business will have to balance the needs and cater to the mindsets of multiple stakeholders. Integration projects are highly cross-functional in nature. They cannot succeed without the support and active participation of front-end web-oriented people, back-end ERP-oriented staff, subject matter experts with intimate knowledge of the silo systems, external service providers, IT infrastructure people and other parties with interest in the integrated data. An example of a project manager's intense interaction with multiple stakeholders would be his or her management of deliverable hand-off from one stakeholder to another to create the end product.

Indeed, the project manager's role as a master coordinator is as fitting as it gets in a back-office integration project. In order to get commitments from various parties in a highly volatile and matrixed business environment, the project manager must increasingly rely upon his or her ability to build relationships. This is especially true with external service providers, who, unlike employees of the same company, do not know the company's culture and way of doing business. The project manager who can successfully run a back-office integration effort will be the one who optimizes his or her relationships with people inside and outside of the company.


It is interesting to note that banks saw back-office integration as a prerequisite to building better customer relationships years ago. Today, it is the E-business-savvy company that will strive to integrate its back-office in order to enhance relationships with its customers, suppliers and employees. The company that triumphs in doing this will successfully recognize the cultural differences inherent in integration projects and manage expectations accordingly. The company will build competencies in application integration as well as forge new relationships with external service providers. The company's E-business initiatives will be key inputs for scope and timing considerations of back-office integration projects. The strength of relationships among the diverse body of project stakeholders will be a critical factor in the success of these projects. The success of back-office integration projects will allow the company to effectively hide its silos from its web constituency, and as a result enjoy the fruits of E-business.


Selland, Chris. (1999). The Key to E-business: Integrating the Enterprise. E-business Advisor (October).

Koontz, Chris. (2000). Develop a Solid E-Commerce Architecture. E-business Advisor (January).

Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA



Related Content

  • Project Management Journal

    Getting Past the Editor's Desk member content locked

    By Klein, Gary | Müller, Ralf To reach acceptance, every research paper submitted to Project Management Journal® (PMJ) must pass several hurdles. This editorial aims to declare the editorial process and reveal major reasons for…

  • Project Management Journal

    Coordinating Lifesaving Product Development Projects with no Preestablished Organizational Governance Structure member content locked

    By Leme Barbosa, Ana Paula Paes | Figueiredo Facin, Ana Lucia | Sergio Salerno, Mario | Simões Freitas, Jonathan | Carelli Reis, Marina | Paz Lasmar, Tiago We employed a longitudinal, grounded theory approach to investigate the management of an innovative product developed in the context of a life-or-death global emergency.

  • Project Management Journal

    Validation of a New Project Resilience Scale in the IT Sector member content locked

    By Rahi, Khalil | Bourgault, Mario This article aims to present the concept of project resilience and to validate, through quantitative analysis, to assess its two key dimensions: awareness and adaptive capacity.

  • Project Management Journal

    Narratives of Project Risk Management member content locked

    By Green, Stuart D. | Dikmen, Irem The dominant narrative of project risk management pays homage to scientific rationality while conceptualizing risk as objective fact.

  • Project Management Journal

    Navigating Tensions to Create Value member content locked

    By Farid, Parinaz | Waldorff, Susanne Boche This article employs institutional logics to explore the change program–organizational context interface, and investigates how program management actors navigate the interface to create value.