;
Integrated Solution Options

The Role of the Enterprise Architect in Application Systems Integration

The Case for an Integrated Solution from a Single Vendor

We once asked the CIO of one of our consulting clients what choices he had made with his company’s applications architecture. “Our strategy is really quite simple,” he replied. “We have opted for SAP.” Having installed SAP R/3 modules for the finance, purchasing and distribution functions, he intended to replace his organisation’s remaining legacy systems with further SAP products over a five-year period. The logic behind his strategy was clear: by sourcing his applications from a single vendor, the company would benefit from having a totally integrated applications portfolio with efficient workflows and data shared across all domains. This strategy would also provide the company’s executives with much tighter control of the business. The main role of the enterprise architect in this situation was to support the planned migration from the remaining suite of legacy systems to the enterprise-wide SAP platform.

The Impact of Outsourcing Decisions

Not long after our discussion, the CIO’s fellow business executives blew a hole in his plans for a monolithic, integrated business model by deciding for economic reasons to outsource the company’s sales warehousing and distribution activities to a specialised logistics firm. Now that these activities were no longer under the company’s direct control, the management had to rely on the external partner to supply information on finished product stockholdings and on the progress of despatches to customers. But what made sense from an overall business perspective negated some of the advantages of the integrated system.

Extensive outsourcing of such services, including those supporting the client organisation’s core business, is a common feature of modern enterprises. Consider, for example, the major pharmaceutical companies who previously conducted their own clinical trials. Today these companies often commission those trials from external, specialised firms that also serve their competitors. The enterprise architect has a vital role both in reviewing and advising on the IT-related aspects of such contracts and in ensuring that the necessary linkages between the information systems function properly.

The Case for Specialist Solutions

Even in cases where the business model is relatively stable, the idea of committing an organisation’s entire application portfolio to a single supplier has one huge disadvantage: that of suboptimal solutions. Whatever claims a vendor might make, no single firm is able to offer the best solution in all domains and all the time. Furthermore, when a firm asserts that its solution supports ‘best practice’, this is more likely to be ‘common practice’, designed to suit the needs of the widest possible range of customers. Catering for the bulk of the market makes good commercial sense from the perspective of the supplier; the unfortunate  consequence is that practices that are leading edge or out of the ordinary may not be incorporated.  For the organisation, it can be even worse and mean that in areas of potential differentiation, they are pretty much exactly the same as their competitors,  meaning a potential competitive advantage is being lost.

How an Enterprise Architect can Help

Here the skill of the enterprise architect is that of finding the right balance between the advantages and risks of systems integration and those of selecting solutions based on best functional fit. For example, they may decide to choose Oracle Fusion for the main supply chain applications, SalesForce for CRM and Workday for HR and workforce management.

As with the company that outsourced its logistics, corporate politics will often force the issue. A few years ago a newspaper publishing group needed to renew the application software supporting its publishing activities – the core of the business. In line with the architectural principle ‘Buy rather than Build’ the IT function evaluated several potential package solutions, and in consultation with the business a specialised package was identified as providing the best fit with evolving business needs. A major concern, however, was that for performance reasons the supplier had opted to use a relatively obscure database management system (DBMS) to store the information processed by the system. This raised a major problem, however, as the company had already decided to standardise on the use of Oracle databases. The advantage of this was the potential to rationalize the company’s data, guarantee its integrity, and share data between applications. Introducing a hybrid database environment would make it more difficult to achieve these aims.

The dilemma faced by the IT function exemplified the common problem of how to manage technology innovation. The investment decision had to be based on classic trade-offs, including the balancing of risks. Should the company adopt a state-of-the-art solution tailored to the needs of the publishing business but with inherent technology risks and costs, or should it wait and hope for Oracle to deliver an appropriate publishing solution in the fullness of time?

Given the criticality of the publishing application to the business, the IT function decided in this case to override the standard DBMS policy. As it turned out, physically sharing data with other applications would have been impossible even if the selected publishing package had made use of an Oracle DBMS. This was because the database effectively formed part of a closed system with access to the data provided only through facilities provided by the vendor. Sometimes the enterprise architect has to go with the flow and accept that incompatibilities and data duplication are a fact of life. In such cases the challenge is to manage the situation, not to obstruct it.

Contact Us