Tuesday May 01, 2012

What makes a DB2 migration easy ?

The four key elements are:
1. COTS application - This means no application database access or database schema to migrate (assuming no database customizations)
2. No integration interfaces - There are no web service, FTP/file, COTS API or other input, output or input/output interfaces.
3. No ETL / batch processing - The is no batch processing or ETL jobs (Oracle Data Integrator, Informatica, IBM DataStage etc.) that are outside the COTS application.
4. No data to migrate - Really ? Yes, all the data is transient. It is part of a print server, real time data capture or caching system.
This may seem like it does not happen. However, I just encountered a set of applications run by a major corporation that has all four elements!

Wednesday Apr 18, 2012

Do More with SOA Integration

Packt has come out with a new SOA 'greatest hits' (SOA content from a number of Packt books) book:

Do More with SOA Integration on Amazon
Book contains content from a couple Packt books I have co-authored.

Monday Dec 26, 2011

Cloud Migration Lifecycle - Step 2 of 5

After setting up the PaaS and IaaS environments, the application owners can take advantage of the PaaS and shared component to more quickly assemble the applications and deploy it through a self-service mechanism. If their role entitles them to make the request, it is automatically provisioned. If not, it gets routed to their management and/or IT for workflow approval (just like a procurement process). The assembly of the applications can be done using the Oracle Virtual Assembly Builder. Oracle Virtual Assembly Builder is used to quickly create and configure end-to-end multi-tier applications and provision them onto virtualized resources. For example, a web server, application server, and database can be package into self-contained assembly and deployed to the Oracle cloud using a seb-based self-provisioning application. The other component of the applications is a central repository for all application assemblies. This central repository can take the form of an "iTunes-like" web accessible location for enterprise applications.

Tuesday Nov 29, 2011

Application Virtualization has challenges

information Week article discusses the challenges associated virtualizing applications in the cloud:
Application Virtualization Challenges
'Golden images' quickly diverge from their pristine initial condition because of:
1. OS patches
2. Application updates
3. Configuration changes
"Applications, once released into the wild, tend to quickly diverge from the golden image"
"The difficulties face by developers and systems admins in deploying apps to the cloud are reminiscent of those encountered transitioning from mainframe to the client/server era"

Wednesday Sep 07, 2011

Cloud 2.0 migrations versus Cloud 1.0 migrations

In the early 1960s when companies started migrating to the Cloud 1.0 (mainframe-based cloud), existing computerized systems to migrate from did not exist. The manual systems, that sometimes the computerized application replaced, were rudimentary and easily replaced by a computer-based system. This made moving to Cloud 1.0 much easier than Cloud 2.0 migrations as you where implementing a new system clear of any legacy ‘baggage’. Today, companies are shackled with hundreds of business applications based upon mainframes, mid-range, and client/server systems deployed using mostly custom developed applications or Commercial Off-The-Self (COTS) products. Migrating existing IT systems to the Cloud 2.0 involves migrating everything from the data to the application, application deployment solutions or procedures, management and monitoring software, integration, data warehouse, business intelligence, replications solutions and backup and recovery, and perhaps even hardware infrastructure.

Thursday Aug 11, 2011

Oracle Integration Products

Keeping with the theme of integration. Check out this article I just wrote that is published here: http://www.packtpub.com/article/oracle-tools-products?utm_source=oracle.com&utm_medium=link&utm_content=agency&utm_campaign=mdb_009140&utm_source=Oracle+Employees&utm_campaign=40955e40ec-Packt_s_Oracle_Employee_Newsletter_August8_10_2011&utm_medium=email&mc_cid=40955e40ec&mc_eid=d3eb770bcf

Tuesday Jul 19, 2011

Data,  process,  and  application   integration  convergence

Data integration is typically the domain of the organization and people that manage the databases. The products used to integrate data in theses organizations are a combination of custom data transfer and load scripts, ETL and ELT products, and in some cases database stored procedures. Application integration, on the other hand, is often done by the application developers using custom written applications, message brokers or an enterprise service bus. Process integration is often done by developers but can also be done by business analysts, or even business users. Process integration uses a workflow engine, BPEL product, or a proprietary orchestration engine like Microsoft BizTalk to orchestrate a set of processes into one business flow. Each of these technologies have traditionally offered solutions focused in their own domain: • Data Integration – Used to unload, move, transfer and load data from one database engine to another database engine from the same or different vendor. Also, used to load flat files received from outside or within the company, and extract flat files from the database. • Application Integration – Focused on applications communicating with each other to complete a business transaction, or exchanging data and messages between two or more applications. Many times used instead of data integration so that application business logic can be applied to the data before, after or during processing. • Process Integration – Process integration combines a set of standalone processes into one end-to-end business process. Process integration usually involves integrating with many different applications, data sources, or web services in order to fulfill on business flow such as a purchase order. What is happening is that each of these integration technologies is adding capabilities of the other two technologies: • Data Integration – Data integration products all have web services support. This has not always been the case. Web Services exposed in data integration products can be consumed by applications or business processes. This makes integrating data integration products with applications or business processes very easy. ELT and ELT products have always had robust workflow engines that are very similar in functionality to a process integration product such as a BPEL Process Manager. • Application Integration – Application integration products now all have data adapters for the major relational databases, content management repositories, XML files and flat files. This opens up the option of doing both application and data integration at the application tier. • Process Integration – Process integration products, like Oracle BPEL Process Manager, have a number of adapters from message, to flat file and relational databases. BPEL Process Managers were built from the ground up to support web services so they obviously can communicate with any application, data, or another process that is exposed as a web service. Each of these products will probably continue to be sold separately by IT vendors. However, the focus on orchestrating business processing using a BPEL Process Manager, exposing applications, process and data as web services will cause these separate products to act and look more a like one product than separate products. The adoption of SCA is expediting the convergence of data, application and process integration.

Migrating legacy client/server and mainframe technologies to the Oracle cloud.


« April 2014