Stay or Modernise? – Considerations for Modernising Legacy Applications
Your functional requirements, your existing online presence and your existing infrastructure strongly influence your choice of mobile platform.
Many companies are currently in the process of improving their digital offerings via mobile and web platforms as a basis for driving revenue and enhancing customer engagement....
Many companies are currently in the process of improving their digital offerings via mobile and web platforms as a basis for driving revenue and enhancing customer engagement. More often than not organisations adopt a divide and conquer approach to making such services available on digital platforms and in doing so, their enterprise architecture tends to suffer.
For example, consider a financial services organisation who made their loan application service available on the web five years ago and made the same service available on a mobile platform two years ago. It is probable that the initial web application was developed to directly integrate with back off systems while the mobile application was independently developed to integrate with the same systems – both systems share a common data set and little else. Should this organisation wish to roll out additional services (e.g. top-up application) to customers then the development effort will be executed on two fronts (i.e on both web and mobile platforms). If the organisation continues with this strategy to the digital enablement of their organisation they will find that their systems will be fragmented and increasingly difficult and expensive to maintain, extend or support.
Consider the alternative scenario where the organisation adopts a Service Oriented Architecture (SOA) for the delivery of new systems. In this scenario, existing systems are left in place but the essential data and logic elements of the system are exposed in the form of web/xml-based services which perform specific programmatic or data function. These essential services are then available for:
In this scenario, all systems share a common set of data and business services which are available to be invoked as required.
The key benefits for the organisation in implementing a SOA-based architecture:
In this context, it is clear that a strong business case can be made for the implementation of a Service Oriented Architecture. This is particularly true in the case where the architecture can be introduced on a phased basis and part of a larger program to introduce new digital channels.
Your functional requirements, your existing online presence and your existing infrastructure strongly influence your choice of mobile platform.
In today's market, finding the correct person to fill contract Oracle positions is a major challenge for businesses. Finding a candidate with the required professional and technical skills to undertake a fixed-term, highly specialized and technical job is almost impossible.
If you are in the process of rolling out systems into new channels (e.g. a mobile presence), migrating toward a cloud-based deployment or integrating with a new partner, you should give consideration to how your systems are integrated. An effective integration infrastructure facilitates business agility, simplifies on premise and in-cloud integration and reduces operating costs.
Your functional requirements, your existing online presence and your existing infrastructure strongly influence your choice of mobile platform.
Streamlining the process of migrating from OWB to ODI.
Background: Many Oracle customers currently use the Oracle Warehouse Builder (OWB) product as part of their data warehouse environment. Oracle noted in an OWB Statement of Direction that the current release of OWB (11.2) is the terminal release of the product and that no future releases are envisages. Furthermore, future database releases beyond Oracle Database 12c Release 1 will not be certified with OWB 11.2. On this basis, OWB customers need to identify a strategy and approach to migrate from OWB.
Background: In my previous blog entry: http://www.metalogic.ie/news/9/46/Best-Practice-Code-Organisation-and-Management-for-Oracle-ADF-Applications/d,ML_V2_News_Detail I described some initial considerations when starting a new Oracle ADF project, particularly in relation to ADF modules structure. Another consideration, when starting new ADF projects is that of building the project. In this blog I would like to explain one possible way to approach the application build process.
Using the Oracle Advanced Analytics Database Option can introduce analytic capability into existing Oracle solutions, delivering significant benefits with minimal time, cost and effort.
Recent trends in business intelligence and analytics has seen a shift in interest
Most Oracle ADF project codebases require reorganisation during their lifetime. Getting the structure correct at project outset can save significant effort and pain in the longer term.
A questions that often arises in enterprise software development environments is one of "how do we track requirements, change requests and software bugs. Additionally, how do we track source code to requirements, change requests and software bugs and track issues to software releases? Finally, how do we track time and effort against issues".
There are a number of questions that commonly arise in relation to Oracle database licensing.