The traditional view considers the projects as different and independent streams.
Even though acceptable from a certain point of view (a managerial one) because of the easiness of project management, in reality this view is completely false nowadays. In fact, the traditional view was acceptable some years ago when the IT department had to automate a certain amount of human tasks. Independent projects were set up and each stream was dedicated to a specific project. For each one, a budget, resources and a time frame were allocated. The management had the possibility to measure the achievement of a given project.

Such view is nowadays not anymore useful. In fact, in an heterogenous distributed environment, more and more projects are interrelated and integration is needed. Testing becomes difficult. The quality is not anymore acceptable at the project level, but instead, must be considered as a framework where each project fits in. It is the first paradigm of the enterprise.

The streams in the Traditional view need some deliverables from other streams. At this stage, reuse is seen as a mandatory constraint. The Component Based Development (CBD) paradigm is the second paradigm inside the enterprise, previous to any new development. Reuse is not about technical matters only. It is not enough to start a new CBD project to make true and useful CBD. In fact, when customers are asked why they start a CBD project, most of the time, their answer is about reuse. And when a control is made to check what has been effectively reused, in many cases, few (some technical classes) or nothing at all is reused! In fact, when the project is done, it is to late for the reuse paradigm. Starting from scratch avoids reuse. And thinking to reuse on the next CBD project is unfeasable because CBD has not been foreseen in its whole.

The reason many CBD projects fail is that most of the time CBD is seen as Object Oriented.
This is not the same. CBD encompasses OO. Old systems can be componentized and reused in a CBD environment. CBD is a framework. There are concepts and methodologies specific to CBD that are supported by tools.

Another problem is that even in CBD projects a classical analysis is still made. CBD means that a new paradigm must be adopted earlier in the development process. People must think in terms of components. The existing Business Rules has to be extracted from the legacy systems and componentized in order to be reused further in the development.
What is important in the second picture, is the fact that the Legacy Systems are the start of new developments. They provide the basis for Enterprise Application Integration (EAI) and new projects such as e-business projects.

Some people often say that when deciding to start a new project (in particular e-business projects) or rewrite a legacy application from scratch they are convinced that the Business Rules will be totally different and that reusing old Business Rule is a nonsense. To that people we answer that about 30% to 40% of the business rules are complitely reused in new projects, sometimes we see more than 75% of the business rules reused, even in packages application (ERP).
The best way to fail in building e-projects is to ignore the second picture - the importance of legacy systems - beeing convinced that new technologies will solve all the problems and that starting from scratch is a way for throwing the past away.

Customers who adopt the first view will fail in their initiative. A simple example is following: A company start an e-commerce project in order to give the possibility to e-customers to buy their goods on the internet. The new project started without any care for a legacy system in place that managed also orders, delivery of goods and customers management in the traditional way. When legacy systems continue to run parallel with Internet applications, major synchronization problems can occur. In that case, the legacy system updated customer data one way while the Internet application did so another way. This caused unexpected results and delays for customers.

As more functions move to the Web, business-rule synchronization problems can spin out of control.
It takes a comprehensive, enterprise-wide coordination strategy to ensure that business-rule capture, reuse and synchronization are managed effectively over the long term.

Our solutions are the most efficient, flexible, quality-based and cheaper of the market, due to our fully innovative and customer-driven approach. Discover them and compare them to the solutions provided you by our competitors.