Cincom Acknowledges There Is A Composite Applications Environ-ment Out There Part Two: Challenges and User Recommendations

Event Summary

Cincom Systems, Inc. (, a privately-held, Cincinnati, OH based provider of software solutions and services primarily to complex manufacturers for nearly four decades, continues to strive to provide its customers an evolutionary path through frequent major technological changes, enabling them to keep pace without major disruption of their business. To that end, on March 14, amid worldwide economic woes and strong global competition from peer companies, Cincom Manufacturing Business Solutions claimed to be weathering the storm by providing compelling business value to those seeking to eliminate waste, improve business processes, and integrate disparate business systems

In fact, Cincom's case may even illustrate a new role for former traditional ERP vendors. Not only have these vendors expanded their suites to offer supply chain management (SCM), CRM, portals, analysts, supplier relationship management (SRM) and what not applications, they also now offer BPM and integration software for managing a client's entire applications portfolio environment together. Cincom's growth will have likely come from extended applications, but also apparently from the integration and the BPM opportunity. Most mid-size and larger companies already have multiple types of CRM, SCM, or even back-office systems, and must find ways to get those systems to work together. Going forward in the near to mid term, these enterprises will likely allocate most of their budgets on improving and better leveraging already installed applications, given that a vast majority of them will have yet to improve their mission-critical processes. As a result, the major enterprise applications providers have had to open up their architectures so that they can interconnect with other systems.

The above story becomes pervasively told by many of contemporary enterprise applications providers as they prepare themselves for the enterprise service model', involving service-oriented architectures (a.k.a., software as a service) that are all open standards- and Web services-based. These moves have partly been in tune with recently outlined challenges that the future enterprise applications should try to solve. Namely, in TEC's recent series of articles, named "What's Wrong With Application Software?" discussed have been the realities of business versus the ability of application software to cope with those realities. Those realities included:

1. Economics Across the application life cycle, the high cost of development, support and enhancements in term of money, time and quality limit the ability of installed software to meet many demands of business (see What's Wrong with Application Software? It's the Economics).
2. Businesses change Change is a fact of life and software must change with the business. Software must be an enabler (rather than an impediment) of business change, both during initial deployment and across its life cycle (see What's Wrong With Application Software? Business Changes, Software Must Change With The Business).
3. Businesses are unique Industry to industry, company to company, all businesses have some uniqueness. The idea that one size fits all does not materialize (see What's Wrong With Application Software? Businesses Really Are Unique - One Size Can Never Fit All).
4. Business processes not application boundaries Business processes must be enabled across the artificial boundaries of disparate applications (see What's Wrong With Application Software? Business Processes Cross Application Boundaries).

Apparently, many in the enterprise applications vendors' community recognize these realities and many are attempting to offer solutions that will deal with them. However, most of these seasoned vendors like Cincom are logically evolving their existing application framework to meet these market needs. Evolving means a slower process where incremental changes are made to the existing architecture in such way that it eventually meets these demands. However, if history helps us predict the future, it is very difficult to execute this strategy effectively, and only the most resourceful and/or steadfast vendors are tipped as winners in the long run.

This is Part Two of a two-part note.

Part One detailed recent Cincom announcements and began discussion of the Market Impact.

The Competition

SAP's recent announcement of xApps would also be an excellent example of an evolutionary strategy. With xApps, SAP is enabling composite applications to be built more easily since xApps uses SAP's NetWeaver infrastructure to tie other applications into SAP applications (see SAP Weaves Microsoft .NET And IBM WebSphere Into Its ESA Tapestry). Moreover, Oracle with its 9i Applications Server (9iAS) Enterprise Edition, PeopleSoft with its AppConnect, J.D. Edwards with its eXternal Process Integration (XPI)/eXternal Business Process (XBP), Baan with its OpenWorldX, and Cincom with Environ have all been ringing the changes of their BPM platform roadmaps.

However, the status of almost all above composite applications is that mere announcements have been made and we are now awaiting delivery. Building composite or cross-applications has not been an easy feat as shown by only a few of, e.g., SAP xApps developed so far. Most of them are still a figment of someone's imagination and will require much custom work until becoming tried-and-true and reusable. Each individual cross-application will involve sophisticated process modeling and process-level, data-level, and UI integration, and often it will involve creating and supporting a system of record that comprises data from multiple systems. Even after all that effort beforehand, the wide variety of technologies and formats of various independent software vendors' legacy solutions one can encounter in any new application for some cross-application, will inevitably mean some tweaking anew.

The mitigating factor for Cincom, though, could be its narrow focus on complex manufacturing and the longevity and a repetitive nature of its multiple partnerships, mentioned above. The vendor has already envisioned a number of typical painful processes and has delivered their templates within Environ to speed up the cross-applications deployment. The following list of ready-made templates bellow should give enough room for improvement to both existing and prospective customers:

  • Quote to order.

  • Order change management.

  • Order to build.

  • New part/product introduction (NPI).

  • Engineering change management (ECM).

  • Electronic kanban management.

  • Order fulfillment.

  • Order to cash.

  • Legacy systems integration.

  • Many other measurements of KPIs.

The customer has a choice to apply one of Environ's flexible business-process templates to the most distressing business activity, and to possibly experience the recognition of the cross-functional nature of most business processes and the elimination of non-value-added steps. Alternatively, customers can use the Environ/BizTalk tools to create their own business process orchestrations to span multiple transactional systems. Still, while Environ provides the core foundation to interlace the existing technology infrastructure investment so that the user can reap the rewards of real business-process optimization, when used on top of applications Cincom do not typically partner with and/or that are based on non-Microsoft technologies, its deployment will likely depend on customized or 3rd-party EAI technology.

Further, Environ, XPI/XBP and/or SAP xApps/NetWeaver will mainly address the above issue No. 4 -- "Business processes, not application boundaries", but the other three burning issues will not necessarily be addressed with these announcements. In other words, hardly any product above makes the underlying product architecture future-proof' allowing developers to both add business functions and change underlying technology platform as justified. The next generation of enterprise architecture must allow for business change to be adopted on an on-demand basis within the existing architecture as the business evolves, and it must provide the cost, time and quality characteristics to make change a practical choice for the business. It would be quite utopian to expect that from product instances based on outdated and/or very proprietary technologies like COBOL, RPG or ABAP, despite Cincom's notable effort to componentized CONTROL.


To that end, while the evolution strategy is safer in the short run for both the customers and the vendor, minimizing both investment and disruption, the evolutionary strategy has limits in how much can be accomplished. The existing product becomes a limit on the amount of innovation that proves practical. Namely, CONTROL was originally written in COBOL, which has prompted Cincom to decompose the code into an object-oriented similar approach in its later releases. Contrary to it, its newer products (i.e., iC and iD Solutions) have long been based on objects and Microsoft-centric technologies. CONTROL also initially ran on Supra DB only (therefore being the most proven there, and with a majority of installations), while the support for Oracle DB was introduced during the mid 90s.

Thus, while Cincom has lately embraced the trendy Microsoft technology that promises a building-block approach to application development, and XML-based interconnectivity, its vast majority of customers still run on a fat client two-tier client/server architecture and on its proprietary Supra database. Migrating these onto new, more advanced product releases and/or continued concurrent support of diverse product architectures will demand immense R&D resources. The technological foundation disparity of the products has also taken its toll by doubling the development expenses and in delivering products integration tools.

Cincom will also have to address other challenges in order to continue to thrive in this ruthless competitive environment (i.e., complex manufacturing) with a limited opportunity and functionality that is not easily leverageable in many other diverse sectors. Many larger vendors with more resources and leading-edge technology have invaded Cincom's stronghold, and have also been closing the functional parity gap. The likes of SAP, Oracle, Baan, Intentia, IFS and Ramco Systems have espoused strong counterpart offering to CONTROL. Particularly challenging would be IFS, both in terms of strong vertical functionality and proverbial few generations mature component-based product architecture that has been amenable to accommodating many of the above four challenges, as illustrated in the fact that over 80% of its global customers are on the single code base and in its components' compatibility even if coming from different major product releases (see IFS To Be At Customers' (Web) Service).

Some vendors have even decided to attempt using a brand new approach to software to solve our issues. One vendor in case would be Ramco who has used an internally developed Model Based Architecture to build a series of application products and do customized applications development. With its recent announcements, Ramco is attempting to address all four issues above (see Ramco Ships Technology And Products. Is This The Future Of Enterprise Applications?). Although the proof is still to come based upon the experience of the early adopters, the early returns are promising since its customers are seemingly reporting that the basic economics of application software has indeed been impacted.

Today, the subject of improving core product technology often arrives at a discussion of Model Based Architecture. Although not necessarily a panacea, what makes Model Based Architecture different is that it is practical, proven approach, and which is changing some of the basic rules and paradigms of software development. It is rather a metadata about the application; it applies many of the basic concepts of manufacturing to the creation of code, and is rather a life-cycle tool, not just a design or development tool.

Manufacturers have been increasingly using Product Lifecycle Management (PLM) to design products from automobiles to VCRs to microwaveable dinners. PLM takes an integrated approach to the product lifecycle, from the initial idea to design & development to production to product retirement. In other words, PLM covers the entire lifecycle, from the idea to create a new VCR or flavor of ice cream to the design specifications, to production, to managing engineering changes to product retirement. Before PLM, we had a number of individual tools that helped in part, but they were not integrated, for example, computer aided design (CAD) helped in design, whereas manufacturing execution systems (MES) only helped manage a product in production.

Likewise manufacturing, we can look at today's enterprise software architecture and typically identify similar islands of automation, since there are a series of development tools that help with initial development, but little or no integration exist across the software lifecycle (i.e., specifications, design, evaluate, construct, test, deploy, and replace). Most software development tools are thus like manufacturing CAD systems helping with development but not across the lifecycle. The new enterprise applications architects should, therefore, learn from PLM and take an integrated, lifecycle view of the effort, possibly by observing Ramco's approach.

Consequently, the necessary evolutionary delivery of the above diverse products/technologies has thus somewhat stretched Cincom's resources during last few years. In addition to that, venturing into new territories, outside of traditional ERP boundaries and into some non-manufacturing industries, might have resulted in an additional value proposition and new opportunities, however, the multiple products delivery had for some time confused/detracted customers, sales force, and partners.

Still, by recently focusing on helping its customers leverage their existing installations to pull together and improve their business processes, Cincom might again pursue just enough avenues for the company to handle the opportunity to attract new business and remain in control of its ETO heartland.

User Recommendations

Cincom's target market, multi-site and multi-national complex manufacturing companies and their divisions with up to $250 million-a-year revenue range and up to 300 concurrent users per site, with a support for the entire lifecycle of a product or project should consider the company's value proposition. Existing Cincom customers should continue to follow Cincom's product path. They should evaluate the new products and technology with an eye towards moving forward with Cincom, while bearing in mind what the other vendors have to offer.

Cincom's manufacturing solutions target complex manufacturing, but they can also handle other manufacturing modes like repetitive, make-to-order (MTO), make-to-stock (MTS) and assemble-to-order (ATO). CONTROL is aimed at larger mid-size organizations in A&D, instrumentation and control, machinery, medical, telecommunications, heavy equipment, transportation, power engineering, and maintenance, repair & overhaul (MRO). The system is particularly a good fit where the products' specifications vary enormously according to end user configuration, products are of a very high value, there is significant value-adding activity in design and manufacturing, where product lifecycles are long, and hybrid (mixed-mode) manufacturing techniques are involved.

Nevertheless, many industries outside of Cincom's target market such as insurance, banking & financial institutions, healthcare, and education, may benefit from evaluation Cincom's iC and iD solutions in a stand-alone manner. Existing users of earlier product releases, particularly those running on Supra database, may benefit from querying the company's future product development, product migration path, and/or service & support strategy.

On a more general note, enterprises looking for new solutions should consider the vendors who have either rewritten their products on a new framework or are taking new approaches described above. Enterprises who are looking to fill in their existing application portfolio should look first at their incumbent vendors for a solution. However, they should investigate alternative suppliers and the possibility of creating composite applications as an alternative approach. If the incumbent vendors do not adequately fill the need, vendors with strong application function plus the ability to participate in composite applications should be favored.

There is also the reality that there are often areas of the business process where there is no underlying application to support it, such as a manual process/workaround, a spreadsheet, or some other solution that keeps the business process from being fully automated by applications. What is required from an ideal composite solution is the ability to integrate the business process, integrate the applications and data, and supply additional functionality to "fill the gaps" to produce a cohesive, composite application that ensures transactional and contextual integrity across the entire business process.

Very detailed information about Cincom CONTROL is contained in the ERP Evaluation Center at

comments powered by Disqus