Sadia Tahseen

Sadia Tahseen


Sadia Tahseen is a fusion middleware architect for Dell services. She has over eight years of experience in Information Technology that predominantly consists of working on Oracle databases and Oracle fusion middleware. Sadia has designed and developed solutions in the manufacturing, engineering, telecommunications, finance, healthcare and industrial sectors. She holds a Bachelor's degree in Computer Science from Osmania University in India, and a MS in Computer Science from the University of Illinois at Chicago.

Sadia is passionate about fusion middleware and cloud computing. She currently holds the Oracle Certified Professional, Oracle Certified SOA Implementation Infrastructure Specialist and Oracle SOA Pre-Sales Specialist certifications. Sadia is involved in a number of Oracle user groups and gives presentations at their conferences.


rss  subscribe to this author


Evolution of About Fusion Middleware Practices in Manufacturing Domain:
Adoption of SOA Published: August 28, 2013 • Service Technology Magazine Issue LXXV PDF

Abstract: This article discusses the evolution of integration in the manufacturing sector, highlighting the pros and cons of the various approaches that have been successively adopted before selecting SOA as the most effective choice. This article also discusses the implementation of governance initiatives when applying SOA-based solutions to achieve overall Integration success.


Nowadays, manufacturing companies are facing challenges to become more flexible and agile as business models change. There has been a great deal of concern regarding speed deployment with reduced ongoing maintenance and support costs. The ability of companies to quickly adapt to a changing business environment depends on the agility of their corporate culture, flexibility of the business processes they incorporate, and the interoperability they employ. Enterprises are required to support open industry standards (SLA) and integrations that are easy to maintain and less risky to evolve, in addition to withstanding the necessary upgrades.

Another driver of business change is the increasing number of regulations that the government and other agencies have imposed on manufacturing companies. Companies must trace not only the main products through their entire lifecycles until they reach the consumer, but also the secondary products that are derived from the core manufacturing process.

To tackle these issues, service-oriented architecture has been used to leverage industry standards that allow for complete, integrated, best-of-breed, and plug-and-play types of architecture for IT systems leveraging a functionality that can be added, changed or removed quickly based on market demand.

This article presents the evolution of integration in the manufacturing sector, from custom point-to-point integration, EA integration, to AIA PIPs integration and SOA integration before demonstrating the reasons why SOA integration is the most effective choice.

Point-to-Point Integration

Point-to-point integration between clients and servers had been the main method of communication for previous systems, whereby the client had to be aware of the server and the server of the client since they used the same communication protocol. Each client/server system has its own language schema and data model for communication.


Figure 1

Enterprise Application Integration

A new strategy called Enterprise Application Integration (EAI) was developed in an effort to simplify point to point communication. With EAI, all communication comes through one central point for handling, routing, language translation, transaction sequencing, and mediation of the message content/protocol before arriving at the final destination. EAI tools typically offer "all-in-one" cohesive solutions that come at the cost of flexibility and footprint. The EAI approach is an improvement over point-to-point messaging.


Figure 2

Oracle Application Integration Architecture

Companies began to adopt Oracle AIA Process Integration Packs (PIPs), which are pre-built integration packs that were created by Oracle to provide out-of-the-box integration between their various ERP systems. They had initially intended to create a marketplace in which Oracle partners could create and sell PIPs to their own customers. This concept led to the creation of several PIPs, but as time passed many of their partners had limited or stopped supporting the PIPs that they have created.


Figure 3

Master Data Management

Manufacturing companies began to adopt Master Data Management (MDM) PIP, which is dependent on vertical industry, products set, market segment, production type and complexity, and supply chain type. This approach also provides a framework that enables MDM integrations with other Oracle and non-Oracle applications. The major benefits of MDM PIP are enriched customer information, faster MDM implementation, lowered TCO, and accelerated SOA enablement.

However, systems utilizing MDM PIPs between their Oracle and Siebel systems experienced disruptive decision-making and failed to catch errors that often ended up being reported to Oracle SR. Moreover, there was a high degree of mandatory customization and extensions over time, which were difficult to be implemented in MDM PIP. Additionally, the frequent upgrading of their ERP systems introduced the risk of requiring a PIP version that had not been created or updated yet.

The AIA framework that enables MDM flows provides a service-oriented architecture framework that accelerates SOA adoption and project deployment in the enterprise. MDM services within an SOA make accurate, cleansed, consolidated, and enriched master customer data available to enterprise business processes. The introduction of SOA through the AIA framework provides open standards and flexibility for the enterprise to facilitate a modular approach for the introduction of software packages.


Figure 4 – Estimations of the efforts required for integration implementation, upgrading, and maintenance over the course of a five-year period are displayed for three different strategies: custom build, AIA FP, and AIA PIP.

The analysis that is displayed in Figure 4 is an integration process between two application systems, with an average of 16 integration operations being performed. The study showed that the use of the foundation pack (FP) was 57% less effort than a custom build and use of PIP, which was 70% less effort than a FP. This significant reduction in effort translates into a significant reduction in the total cost of ownership.


Order-to-cash integration (O2C) was eventually developed for the Oracle systems in which they had initially incorporated O2C PIP as its middleware layer. The benefit of using a O2C PIP is that it reduced development time during initial project phases and had high reusability, while using EBOs eliminated the initial requirement analyses for data models and reduced risks. The Oracle partners who created this PIP did not provide adequate support during its implementation and maintenance, so that the PIP may no longer be supported by Oracle and its partner if the upgrade cycle of the company's ERP systems of company was too time-intensive.

Moreover, O2C PIP had interoperability issues and required a great deal of customization and extensions, including XREF/DVM mapping and configurations. Assumptions also needed to be made, like XMAN reports being present for cross-checking for mapping. Above all, PIPs were not available for all of the interfaces being used in the manufacturing sector, which would require a high degree of customization and extensions for those interfaces increasing complexity and ambiguity.

The decision to incorporate a custom AIA PIP was made in order to achieve greater control over the design and interface points. However, this decision had more cons than pros, making it impossible to implement. The cons included a lack of Oracle support for custom PIPs, the risk of data for development and maintenance being inconsistent, and a failure to catch errors, which often ended up in reports being sent to Oracle SR. Also, continuous maintenance was required for Oracle/Siebel upgrades, in addition to more time and resources being needed for development and maintenance.

Service-Oriented Architecture

The SOA integration approach gave companies the flexibility and agility to adapt to changing integration requirements and leverage industry standards, which allows for complete, integrated, best-of-breed, and pluggable types of architecture for IT systems. SOA is not just focused on application integration but also on application construction from existing assets. Incorporating SOA resolved problems that could not be addressed by other integration methodologies.

SOA components like the ESB facilitated a flexible connectivity infrastructure for integrating applications and services without reducing the number, size and complexity of the interfaces. It provided a central point for connecting distributed applications, and utilized a pattern of connectivity for the software that is running parallel on different platforms and written in different programming languages and programming models. It made message routing, mediation, transformation easier apart from providing security, logging and transactional support.

Another important component that is utilized in SOA is BPEL, which allows multiple business services to be used together to implement a business process. It is essentially used in orchestration or the routing of services. Service-oriented architecture allows for the creation of composite business applications from independent, self-describing, and interchangeable code modules called services, which are reusable.

Services are self-contained, independent, and can stand on their own without external dependencies. They are connected through service components like the BPEL or Mediator in Service Component Architecture (SCA) defined in the OASIS standard. SOA in enterprise architecture leverages the enterprise canonical data model. The ability of a company to adopt SOA depends on its maturity in being able to set priorities and meet business goals.

Oracle's SOA is focused on working with services to enable service-orientation, whose adoption has a multifaceted impact on the organization in that it builds and leverages IT assets for optimal business benefits. SOA incorporates the use of separately standing interfaces by emphasizing the loose coupling of software components. Service-oriented computing must be business-driven, vendor-neutral, composition-centric, and enterprise-centric.

SOA has gained increasing attention as a result of its ability to reduce costs for IT application development via service reuse, increased business agility, and the ability of higher-level applications and processes to remain insulated from changes in lower or back-end applications. SOA also allows for continuous improvement of operations through service-level agreements (SLAs) and improved communication between business and IT.

By utilizing this approach's service management capabilities, organizations can isolate, diagnose, and fix production problems for service-oriented applications more quickly than for monolithic applications, saving money and reducing or even preventing customer dissatisfaction.

One of the major benefits of SOA is related to maintenance and the operations space. As SLAs are encroached, maintenance teams can proactively resolve problems before they actually occur. Nowadays, large-scale implementations tend to utilize or migrate to Oracle SOA 10g/11g for integrations between their systems. There were Oracle fusion middleware standards set for these enterprises that were based on SOA and AIA standards.

The ability of an organization to follow SOA depends upon its SOA maturity model. The maturity and strength of SOA lies in reusing services that are already built. The usage of SOA in manufacturing has evolved greatly. The SOA maturity model basically serves two purposes. The first purpose is descriptive and enables companies to understand their relationship with others in the industry so that they can communicate in the same language, while the second to provide a roadmap so that they are able to set priorities.

The three SOA strategies that can be adopted based on maturity are, namely:

  • Project-Driven – SOA tools and techniques are applied to a project that is extended between multiple departments, with the foundation built on SOA capabilities.
  • Service/Consolidation-Driven – SOA is used as a means to consolidate the duplicate capabilities between the various systems of different departments.
  • Process-Driven – Companies use SOA as a foundation to automate business processes.

Another important role that SOA maturity in the organization will drive is the concept of service versioning, whereby changes to service contracts are rolled out in various service versions each with their own set of consumers. In such a scenario, it is the responsibility of SOA Governance body within the organization to ensure that service consumers move to the latest version of the service in a stipulated time frame. This will help avoid the redundancy of processing logic when multiple versions of the service exist.

Maturity Levels
0 No SOA No SOA approach is being implemented.
1 AdHoc Awareness of SOA exists, and some groups are embarking on building services. No SOA plan is being followed.
2 Opportunistic An SOA approach has been selected and is being opportunistically applied. The approach has not been widely accepted or adopted, and may be informally defined or documented.
3 Systematic The approach has been reviewed and accepted by the affected parties. There has been buy-in to the documented approach and the approach is always nearly followed.
4 Managed The capability is being measured and quantitatively managed via some type of governance structure. The appropriate metrics are being gathered and reported.
5 Optimized Metrics are being consistently gathered and used to incrementally improve capability. Assets are proactively maintained to ensure relevancy and correctness.

SOA governance also needs to be incorporated in the early stages of SOA integration. SOA governance can be defined as the interaction between policies, decision-makers, and processes in order to ensure SOA success. Architects need to have a governance initiative when implementing SOA-based solutions. When the SOA roadmap is being built, an SOA governance roadmap and process need to be developed, the risks understood, the lifecycle and change impact analysis properly managed, and the appropriate processes, policies and tools made available.

SOA governance provides the ability to quickly and continuously translate and transmit business strategy and requirements into processes, policies, and controls that can guide the evolution of the company's infrastructure and enterprise.

Failure to provide effective SOA governance exposes your organization to serious risks that result from:

  • cultural resistance to change
  • fragmented approaches to SOA
  • ineffective communication of priorities and best practices
  • insufficient adoption of services
  • rampant and redundant service creation across siloed SOA initiatives
  • resources wasted on services that can't be reused

Effective governance ensures that communication, collaboration, and the flow of information keep SOA initiatives and investments connected to the enterprise to deliver sustainable business value.

High-Yield Questions for Stakeholders
  • Which key inefficiencies do you see across your organizations core business processes?
  • How much time, effort and portion of the budget are spent on integrating IT systems and business processes in your organization?
  • Describe the complexities introduced to your IT environment in case of any recent mergers, acquisitions or migrations of application systems?
  • What percentage of time & IT budget goes into maintaining application to application connections?
Business/Project Manager
  • How much time are spent rekeying errors or manual integration tasks?
  • How much manual paperwork and data entry is being produced by your department? What are the causes for this volume?
  • How often do simple integrations turn into new business requirements?
  • What is the extent of the upgrades and customizations/extensions performed on the applications?
  • What are the commitments to applicable IT and Integration standards?
  • How is SOA governance implemented?

Effective SOA governance depends on the information up-down value chain so that communicating goals and progress to all stakeholders can help ensure both top-down and bottom-up support for SOA. To ensure SOA success, policies should be enacted and processes that support SOA roadmap delivery facilitated. This is the essence of governance with SOA—enacting policies and procedures to ensure the timely and appropriate execution of the SOA roadmap.

According to a strategic planning assumption performed by Gartner Group's Paolo Malinverno throughout 2010, the lack of working governance arrangements will be the most common reason for the failure of SOA projects, with a probability of 0.8. Conversely, companies that have established governance to help individuals make good decisions within the context of the problem space have matured their SOAs successfully. These companies have also achieved an effective layering of SOA capabilities in many different areas.

A SOA roadmap built using a maturity model, such as Oracle's Five-Level SOA Maturity Model, allows companies to begin their SOA undertaking and manage the migration by building on each successive step to ultimately deliver the SOA benefits expected: service reuse, improved integration, interoperability and business agility

To meet business, EA and SOA goals, policies must be enacted across different business areas, such as architecture, technology infrastructure, information, finance, portfolios, people, projects, and operations. This is the role of governance and therefore policies, which need to be designed and enacted to ensure this alignment. The format and medium for policies may be different, since some policies can be captured and enforced in technology. The greatest benefit and return on investment with SOA occurs when companies stop trying to maximize investments locally (silos) and start maximizing all of assets across the enterprise.

Many reports indicate that 60 to 80 percent of the TCO of an application is spent on maintenance, meaning even a 10-percent cost reduction in the maintenance space will greatly outweigh a 10-percent cost reduction in the development space. Business processes and applications that leverage services should be designed to achieve lower maintenance costs and transparency for the business.

As SLAs are encroached, maintenance teams can proactively resolve problems before they actually occur. Most successful SOA efforts have used a centralized team to help provide consistency and best practices. Over time, these operation support teams can become more decentralized as the processes mature.

The runtime monitoring of services and service levels, including logging and auditing, and the runtime enforcement of policies, such as security policies, is best implemented early on in the SOA undertaking. The sooner you set the appropriate monitoring and policy enforcement infrastructure in place, the earlier you will be able to understand service usage patterns and change security policies as your requirements evolve.


Something that SOA leverages in the manufacturing space is the concept of "kaizen," which is the Japanese word for "continuous improvement or good change" that focuses on removing major obstacles from the process to production efficiency. As major problems are resolved, we encounter new and smaller problems that either went without being detected before, or were lower in priority.

Various integration approaches that had been implemented over time were accompanied by inefficiencies and ultimately led to the adoption of SOA. Items of secondary priority can be addressed, as high-priority bottlenecks and hindrances are continuously eliminated. Improvements can eventually be made through the gradual fine-tuning of processes. As we keep improving on governance and overall EA practices, issues that had gone unnoticed before will be escalated until they are fixed, automated, or resolved.