Intro:
Organizations either grow - some in an organic fashion, others in an inorganic fashion. Chances of IT strategies falling apart are high. Each time there is a definitive process of achieving IT-nirvana by aligning to a single/dual platform strategy seems to become a reality, a merger or an acquisition seems to come knocking on the door. This is a reality with which IT organizations need to live with. Changing or adaptive businesses is a reality and any strategy being worked out for the next few years need to consider this as the prime driver for a strategy that aligns with this fact. Therefore, coming up with an application retiral strategy for any organization is a nightmare. There needs to be a new way of looking at things with a move towards BPP. Every new merger, every new acquisition brings with it a multitude of such applications which turn the laundry list into a huge list of unmanageable process applications that support processes across the value-chain.
In the changing world of web 2.0 and mash-up corporations, there has to be a new approach to solving this perpetual nightmare. I introduce the concept of "Reverse Engineered xApps" or "RExApps"here. Not that such a term exists in the market today, but hey, isn't the SAP ecosystem meant to define the future along with SAP? And when do organizations really start monetizing their ESOA initiatives?
Defining Reverse Engineered xApps:
Any 3rd party, best-of-breed, custom-built or any application, based on an analysis of the processes that these applications support, can be taken down and be composed with the SAP NetWeaver Composition Environment to provide a retrofit+Delta functionality to ensure the retiral of applications that support a business process. The driver being business process, RExApps will help bring together the processes, better it, and help such applications to be retired in a phased manner. Any composite that considers multiple SAP/non-SAP applications in the landscape, agnostic of the platform they are built on, can be collapsed into logical processes that are rendered by the UI, consuming services and use the ERP as a system of reference. Key points as to what gave the need for the concept - "RExApps" are as follows
1. Application-retiral strategies exist, but they fail to align with SOA initiatives
2. More often than not, branding a new UI in a different language, is considered synonymous with application retiral
3. Application retiral strategies are driven by siloed approach of downing one system and bringing up the same in another system of reference
4. Monetization of SOA is never tied up to an Application retiral strategy
5. More often than not, application retirals is driven by a count of application systems, not by business processes
Many other reasons
Why it makes sense:
Application migration strategies are not new, C++ applications being moved to Java, Java applications being retired to fit into standard process defined by the core R/3, ECC or any other reference system can be viewed in different light. Process-supporting applications that render the need for chaining up multiple applications using different EAI tools have oft rendered the era of true interoperability with services a distant dream. And the same would continue if the old-school approach of retiring applications is not relooked. Key points as to why "RExApps" would make sense are as follows:
1. Cost: A retiral strategy that actually brings money to the table
2. Applicability: A retiral strategy that builds on the SaaS concept
3. Process reengineering: True process engineering can be attained with RExApps as the glue between IT & Business
4. Time: Collapsing of processes could be faster than application "collapsibity"
5. Technology: Complete adherence to an SOA roadmap, with any approach to SOA
Sample this: Think about how much of a license & consulting costs can be saved by retiring best-of-breed applications from different application vendors.
When it makes sense:
When organizations start groaning under the pressure of a large list of such applications, when an organization landscape is cluttered with different platforms, Diffenent applications, different UI strategies, different EAI tools, unnecessary Interfacing to them alive, huge outsourcing costs incurred in their maintenance and many other such factors provide the necessity to create a concept that can be applied in the real world to monetize SOA initiatives. RExApps, if applied on an Organization model could very clearly change the monetization models of SOA initiatives.
Where it makes sense:
Organizations that grow primarily by mergers and acquisitions, that's where RExApps make most sense. Consider the following scenarios, where interoperability would be a potential nightmare, even if one were to bring on an entirely new set of composites to solve the problem -
a. Value Chain xApps
b. Supply Chain xApps with SaaS
c. Business exchanges
d. Heterogeneous Composite
e. Multi-system Composite (SAP + Non-SAP)
f. Multi-system Composite (SAP + SAP)
g. Business to Enterprise xApp
h. Enterprise to Business xApp
i. Upgrade scenarios where supporting systems get impacted as well
j. Many other scenarios
How it makes sense:
Imagine a world, where the biggest ISV on the planet on its own platform (aka SAP), is swept under the carpet. And reduced to a system of reference for business process and data. The logical constructs of processes which form the motherboard of business processes, would send out signals. If these signals are captured by a receiver with no information loss and decoded to present it in a way that covers an entire business process, then wouldn't that be a lot better way for business users to work it? Work it - it is more like doing interactive TV! If one extends this analogy to the world of application retirals, if the Composition environment can be constructed with a set of tools that would best capture and help a business analyst play around with the processes, improvise them and then consider the systems of references that lie underneath - what you get is a concept that I would term as "Reverse Engineered xApps".
Check the latest set of demos of iPRO (a safe passage for e-Procurement applications) @ Reverse Engineerd xApp demos with iPRO towards an application retiral strategy, which provides a mash-up application for e-Procurement applications retiral to help understand the concept of "Reverse Engineered xApps", much better. The concept would run across the value-chain.
Outro:
Since the focus of this blog is on the concept, I would keep this technology free. The bottom line is to innovate with ESOA that would put the money back on the table for organizations and increase bottom line. SOA is not a technologist's domain alone, neither is it a process expert's baby. Cost of building it? Lesser than 1/4 the investment of moving forward with a newer solution - even from SAP. Time to compose? Depends upon the process being evaluated by RExApps. Surely, innovation with SOA would only be limited by one's imagination.
