The Xoriant Whitepaper: Last Mile Soa Implementation
How businesses embrace the "last mile" adoption of
Services-Oriented Architecture determines their
competitive edge today.
A Xoriant Whitepaper
Author: Girish Gaitonde
An international network equipment company was able to cut down its bad debt write-downs
by eventually connecting the remote D&B credit data store to their order entry system
through their enterprise middleware bus by creating custom interfaces.
A financial institution was able to increase the accuracy of their marketing campaigns by
seamlessly integrating their marketing system to continuously cleaned customer data, which
was held in a remote database.
A telecommunications service provider used SOA oriented architecture and implementation
toward improved competitiveness and profitability by optimizing quote to service, shorter
delivery times, fewer rejections and elimination of stock-outs of key components by integrat-
ing several new systems with legacy systems.
Most integration projects face the challenges of budget, cost overruns, undue
delays due to various business and technical factors, not mentioning
over-promise and under delivery by technology vendors and service partners
alike. Business Agility is determined by accuracy, timeliness and holistic view of
business data such as Customers, Partners, and Products etc. These problems
are exacerbated by additional factors such as M&A, IT consolidation and other
business driven events such as Compliance. Imagine how disastrous it would be
to have outdated Customer’s financial status or inaccurate Product information
while making mission critical decisions. These information discrepancies in
Master Data Management occur due to incorrect integration arising out of
inadequately addressing “last mile” challenges. A clear understanding of the
“last mile” challenges and potential solutions including recognizing
value-added partnerships can make a huge difference in business survival in
today’s competitive environment.
Organizations are increasingly leaning towards SOA as their new architecture, primarily due to the
realization that legacy means of integration have not helped them in reducing reliance on the
software application vendors and being able to leverage upcoming applications, services and
information sources. Legacy applications remain expensive to operate and maintain, and do not
provide easy means to participate in the overall Business Architecture supporting critical business
It is true that middleware technologies and architecture such as SOA, BPM and EAI have changed
the landscape of how information is exchanged to achieve desired business agility. These
technologies also have the potential to eliminate barriers between isolated application silos and
enable reuse of critical business services across the organization. However the promise of this
architecture and technology falls short in delivery due to unanticipated issues, some of which are
business related and some are purely technical in nature. Such unanticipated issues can have
serious financial implications on the overall integration budget and the project effectiveness, as
they are discovered during project implementation phases in a totally ad hoc manner. This leads
to the last mile problem.
Typically integration, which is properly done leveraging SOA and Composite Application
frameworks, enables implementation of enterprise wide business processes. However the
Business Architecture that maps out critical components to implement core business processes,
may assume certain functionality in the participating legacy applications and data/information
sources such as databases, data warehouses, etc.. Such functionality is not easily accessible in
reliable, accurate and timely manner and in the right format, may end up posing huge risks in the
later stages of the project. This issue is well known in the industry as the “last mile” challenge. This
phase originated from the telecom industry.
There are several challenges in addressing the “last mile” issue. Although each deserves an
elaborate undertaking, we will consider few with the intention of highlighting the issues and
potential solutions. Some of these are,
• Inability to participate in business data visibility aspects which are critical to business
operations. e.g. Master data view on all customers, products. A few (but not all)
causes of this could be incompatible data formats, incoherent data contexts, etc.
• Stale data or data that is old resulting in inaccurate view of state of affairs. Timeliness of
data refresh affects accuracy of data. e.g. A customer’s account status may be in
jeopardy, but not updated in the master view.
• Inability to adapt to changes – change in legacy applications, change in enterprise data
• Inability to provide adequate data monitoring capability resulting in data quality issues –
which could include duplicate records with no defined stamp of authenticity.
All these result in data that are inaccurate, not timely and inconsistent which could jeopardize
business operations, not mentioning compliance issues.
The following depicts a potential architecture for unlocking legacy applications. It assumes that
the enterprise has adapted middleware toolsets to facilitate integration.
Mainframe Work station Work stations Servers
This architecture assumes that there exists a corporate standard for representing business data,
lack of which is another issue altogether. One should question the overall integration strategy if
this does not exist in the plan.
Just as in addressing any challenges, one should make plans to apply correct methodology and
approaches to not only to “unlock” the legacy applications, but also enable them to “partici-
pate” in the intended business architecture vision. Such participation may involve legacy applica-
tion consuming other services or offering its own business data and workflow to other applica-
tions to realize the intended business processes. Here is where custom adapters, which expose
the data and business processes inside the legacy applications to the enterprise information bus,
play a big role. Typical middleware vendors make and sell adapters for standard applications like
Oracle and SAP, but adapters to the legacy applications inside the enterprise have to be devel-
oped from scratch. Thus the problem is not “simply” developing an adapter that exposes legacy
data but to allow for operations on the data.
The adapter must also expose “business operations” that would be critical in the overall business
The following are some of the critical steps one should consider addressing this challenge of
building effective and long lasting custom adapters to the legacy applications:
1. Establishing of data/process ownership/Governance (ICC)
2. Performing “gap analysis”
a. Gap in business process
b. Gap in legacy application data model and standard data model
3. Developing strategy to address the gaps discovered in Step 1
4. Performing application readiness assessment, to study the technical feasibility of
“unlocking” the legacy application
a. Web service wrappers for legacy API
b. Recoding legacy application
5. Change control process
a. Metadata analysis
b. Metadata changes/maps to enterprise data model
6. Mapping & Validation Challenges & Strategy
a. Data Mapping
b. Process Mapping
7. Change control processes
Following are some of the features that must be considered and prioritized before building
adapters for the legacy applications. Each application must also undergo a readiness assessment
against these tasks to discover potential issues. It also helps to size the complexity of building
1. Real-time, batch processes
3. Model/Meta-data driven
6. Transaction support
7. Data provisioning
8. Data Security
9. Orchestration considerations
14. Reusability Page 5
One should avoid building point to point interfaces. Looking for already available extracts in
staging tables, CSV files and reports should be considered. The way these data sources are
handled is also helpful in considerations for migrating to more dynamic environment. Model
driven interfaces accommodate changing landscape rather than having static data model. But
one should be careful not to over-engineer solutions and create ad-hoc interfaces.
The following figure shows some of the tools and framework components required for building
adapters. For example, deployments support requires services such as Notification to notify
stakeholders of potential exceptions. It may simply leverage enterprise monitoring tool for that
purpose. Whereas Logging, Auditing etc would be needed by any component to facilitate further
troubleshooting and/or tracking purposes.
It is critical to understand the role the legacy applications and data play in the enterprise business
processes. This will dictate the use cases for designing the adapters. Such use-cases typically
representative of sub-processes required in the overall business processes, such as obtaining
product master data for compiling bill of materials, obtaining customers from a CRM system etc.
Versioning is another challenge for consideration, as realistically speaking most systems are not
static and often evolve. Change is the only constant. As systems evolve the architecture needs
to accommodate new changes. This whitepaper does not go over issues of migration, version
support, interoperability with other tool sets etc., These are topics for another discussion
How seamlessly legacy applications or the other enterprise applications participate in the SOA
strategy determines success rate for SOA/SOI/EAI. Poorly thought out last mile interfaces can
potentially bring down the project. Clear understanding and best practices are keys to achieving
success. There is no replacement for such insights. Having a ready plan helps to address such issues
early on in the project lifecycle, and helps in managing the expectations.
Also ICC or Integration Competency Center consisting of technology, policies, people, gover-
nance, best practices and processes allow for rapid, reusable, repeatable and cost-effective
deployment of business services, meeting corporate objectives.
Lastly, even more critical is having a business partner who understands these issues deeply and can
help achieve your overall success. It is not sufficient to have a partner who can reengineer and map
the business processes in the overall SOA theme. In addition, a technically savvy partner who can
bring in the people, processes and deep and broad technical ability to solve the last mile problems,
which crop up however thorough the planning has been, is very crucial. Normally, the business and
technical capabilities are found in totally different organizations.