The Xoriant Whitepaper: Last Mile Soa Implementation


Published on

How businesses embrace the "last mile" adoption of Services-Oriented Architecture determines their competitive edge today.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Xoriant Whitepaper: Last Mile Soa Implementation

  1. 1. How businesses embrace the "last mile" adoption of Services-Oriented Architecture determines their competitive edge today. A Xoriant Whitepaper Author: Girish Gaitonde
  2. 2. 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 critical 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. Page 2
  3. 3. BACKGROUND 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 processes. 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. CHALLENGE 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 model Page 3
  4. 4. • 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. POTENTIAL SOLUTIONS The following depicts a potential architecture for unlocking legacy applications. It assumes that the enterprise has adapted middleware toolsets to facilitate integration. Datamarts, Mainframe Work station Work stations Servers Data warehouses 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 architecture. Page 4
  5. 5. 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 8. Operations a. Monitoring b. Alerts TECHNOLOGY FACTORS 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 the adapter. 1. Real-time, batch processes 2. Loose-coupling 3. Model/Meta-data driven 4. Validations 5. Transformations 6. Transaction support 7. Data provisioning 8. Data Security 9. Orchestration considerations 10. Monitoring 11. Scalability 12. Reliability 13. Availability 14. Reusability Page 5
  6. 6. 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 altogether. Page 6
  7. 7. CONCLUSION 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. References 1.,1 2. is-data-the-missing-last-mile-for-soa-success/?cs=31411 Page 7