Category: Technologies
Posted by: bagheljas
For implementing business process agility using Oracle SOA BPEL Process Manager, most books cover few of the following domains:

  • Designing and architecting SOA composite applications
  • Developing SOA composite applications using BPEL
  • Testing and debugging SOA composite applications
  • Installing, configuring, deploying, securing, and administering SOA composite applications

In this book, we have combined these domains to deliver the complete handbook. It provides our readers an understanding of what goes outside of their direct responsibilities. This horizontal understanding improves the collaboration among the cross functional groups that would result in increased team productivity. You can preview and buy the book at
Packt PublishingAmazon.comBarnes & NobleSafari Books Online
Oracle SOA BPEL Process ManagerIt is also available at LYBRARY, Computer Manuals, and most internet book retailers.

You will find an overview of technical fundamentals, step-by-step tutorials, and industry leading practices implementing SOA composite applications.

Language : English
Release Date : June 2013
ISBN : 978-1-84968-898-7
Read about in Oracle Magazine July/August 2013 Book Beat
Category: Best Practices
Posted by: bagheljas
Web Application Security
Category: Best Practices
Posted by: bagheljas
Best Practices for Developing & Deploying SaaS
Category: General
Posted by: bagheljas
Disaster Recovery Solutions design is driven by the following recovery objectives:
  • Recovery Point Objective: Worse case data loss is acceptable for applications for a disaster event.
  • Recovery Performance Objective: Application need to perform at the same level as primary site or we can limit user access or ok to have degraded performance for applications if disaster happens.
  • Recovery Functionality Objective: Functionality of applications needed at same level as primary site or can they operate with limited functionality.
  • Recovery Location Objective: Location characteristics such as power grid, distance relative to primary sites and corporate offices
  • Recovery Time Objective: Worse case of Time to recover for applications for a disaster event
  • Recovery Redundancy Objective: Defines the redundancy objective for the Disaster Recovery Site such as same as Primary Site or certain layer as production and while others have no redundancy

We often find that these objectives together help us define DR tiers such as Platinum, Gold, Silver and Bronze to fit into a budget to delivery DR capability for an enterprise.
Category: General
Posted by: bagheljas
  • App to App dependency (Internal and External) needs protocol transformation for cloud deployment
  • COTS products current license is not supported for cloud deployment
  • Gaps in Application grouping and Sequencing also known as Wave Plan and Detailed Migration Plan for each wave
  • IP based configurations that sometime even hard coded in the application code
  • Application platform components clustering protocol not supported in the cloud
  • App to Infrastructure dependency needs architecture transformation for cloud deployment
  • Application platform components and underlying middleware & operating systems has direct binding with the server hardware platform
  • Application system architecture needs to be revised for matching the current performance baseline
  • User functionality and experience impacts by network latency sometime needs to be addressed by re-design of the application architecture
  • Transformation of proprietary implementation of Load Balancers and Security Controls in WAF, Firewall, IPS/IDS etc.
  • Transformation of services/systems deployment life cycle management tools and processes such as monitoring, backup and recovery, automation (config, build, patch and deploy), ITIL etc.
Category: Best Practices
Posted by: bagheljas
Change is inevitable for an enterprise application life cycle. The change for an enterprise application comes in various forms and the most common words used for the application changes are migration, transition, transformation, upgrades and consolidation. The diagram below creates a layered architecture for an enterprise application changes named as Enterprise App Migration Layers. The Enterprise App Migration Layered Architecture provides a cross industry standard approaches for application migration needs.
Enterprise App Migration Layers

It is leading practice to limit number of layers changing for a given migration event to keep the migration simple as much as possible. In contrary, you get economies of scope benefits to combine the changes in multiple layers. Therefore, selecting changes for a migration event is an art and science that needs to combine with the capabilities, refresh requirements (usually driven around app platform components end of life timelines), timeline objectives and cross functional resources availability.

  • 7. App Consolidation - App Merger & Acquisition: When an enterprise have more then two applications serving one functional domain that either applications is capable to serve functional users. In this case, enterprise architect often port less desired application stack to the most desired application stack. On the other hand, if a functional domain is matured and common in industry that has an economical Cloud Computing Software as a Service (SaaS) provider(s) that meets your functional, performance and security requirements. An enterprise architect may consider to migrate to a SaaS provider. It is a leading practice to develop and execute comprehensive testing plan with multiple domains such as features, system, integration, security, performance, backup & disaster recovery and user acceptance. This layer migration usually driven by top down enterprise IT strategy with or without cloud.

  • 6. Platform Refresh - App Refresh: You are refreshing application COTS product to latest version or adding new components for new features either on existing or latest versions of underlying technology stack. The migration is manual in nature but one may consider build automation. It is a leading practice to develop and execute testing plan in domains such as features, system, integration, and user acceptance.

  • 5. Platform Consolidation - App Remediation: You are retaining application COTS product version and functionality but porting underlying technology stack to desired vendors to comply with enterprise architecture mandates such as DB2 to Oracle, WebLogic to Tomcat, IIS to Apache etc. The migration is manual in nature but one may consider build automation. The most common type of migration when an enterprise is looking to eliminate expensive technology components from the enterprise technology portfolio or migrating to Public Cloud Computing - Infrastructure as a Service (IaaS) provider. It is a leading practice to develop and execute testing plan in domains such as features, system, performance, integration, and user acceptance.

  • 4. Middleware Refresh - App Lift-n-Shift: You are retaining application COTS product version and functionality but upgrading the underlying middleware technologies to latest version such as Oracle DB, WebLogic AS and Apache WS. The migration is manual in nature but one may consider build automation. It is a leading practice to develop and execute testing plan in domains such as system, security, performance, integration, and user acceptance.

  • 3. OS Refresh - Middleware Lift-n-Shift: You are upgrading versions of underlying operating system or migrating to an standardize operating system image of existing version. One may consider tools like AppZero or manual transformation. The most common migration type when an enterprise is changing and/or outsourcing to managed hosting provider. It is a leading practice to develop and execute testing plan in domains such as system, security, integration, and user acceptance.

  • 2. Infrastructure Refresh - Logical Lift-n-Shift: You are refreshing server hardware platform only. It is a leading practice to leverage tools to perform Logical Lift-n-Shift migration. The industry leading tools for such migration are PlateSpin Migrate, Rackware, VMWare Tools, and Data Gardens. It is common to hear the terms like P2P, P2V, V2P and V2V migrations for this kind of exercise. The most common migration type when you are migrating to Cloud Computing - Infrastructure as a Service (IaaS) provider.It is a leading practice to develop and execute testing plan in domains such as system, security, performance, integration, and user acceptance.

  • 1. Tech Center Refresh - Physical Lift-n-Shift: You are either moving from on-premise data center to colocation or changing colocation provider only. It is a leading practice to develop and execute testing plan in domains such as integration, and user acceptance.
Category: General
Posted by: bagheljas
The Data Center Migration Timeline is directly influenced by the following factors:
  • Transformation Objectives and In-flight Enterprise Initiatives
  • Business, Technology and Applications Constraints driven move groups and available maintenance windows
  • Miscellaneous vendors SLAs and time needed for the procurement, build and validation phases
  • Organization’s maturity - availability of infrastructure (Network, Compute and Storage), applications and business data related to source environment
  • Stake holders’ resource plan and skills & maturity level
  • Swing infrastructure (Network, Compute and Storage) availability and migration tools capabilities
  • Security and Compliance Needs
  • Migration Methods Needed and Utilized:
    • Physical Moves (Lift-n-Shift)
    • Logical Moves (Server Image and Data over Wire)
    • Green Field (Build and Deploy)
  • Environment Nature and Size:
    • Number of Physical Devices
    • Number of Operating System Instances
    • Number of Applications & Types
    • Total Storage
    • Number of Databases and Total Size
    • Number of File Shares and Total Size
    • Number of Network Zones and VLANs
    • Number of Firewalls and Load Balancers Rules
    • Number of Components between End User(s) and Server(s)
    • Number of Data Centers and WAN Sites
    • Number of Environments in SDLC
    • SDLC Types & Timelines
Category: General
Posted by: bagheljas
The Application-2-Infrastructure Mapping for an application is the information about the network, compute and storage used for the application system deployment. Application-2-Infrastructure Mapping is mission critical for system deployment life cycle. In most organizations, the Application-2-Infrastructure information is not easily available and often it is tribal knowledge. There are tools in the market claims to auto-discover and create the mapping for you. The reality is that there is no tool in the market that can auto-discover and create Application-2-Infrastructure Mapping for an enterprise applications portfolio. The first iteration of creating Application-2-Infrastructure Mapping is manual in nature. The Mapping tools such as BMC ADDM and HP ADDM will auto-discover the infrastructure elements also known as application elements but application owner needs to define the mapping rules. The tools have a library of these rules for some of the popular applications technology stack that doesn't cover 100% of an enterprise application portfolio. The standard library often misses covering the custom implementations for a popular applications technology stack.

Sample Schema Elements for Application-2-Infrastructure Mapping:
  • application Name
  • application Description
  • application environment/landscape(s)
  • application serviceUrl(s)
  • serviceUrls DNS / GTM / GSLB / L7LB Configuration
  • application VIPs / LTM / LSLB / L4LB Configuration
  • application Network Information
    • Internet / WAN
    • Zones / vLANs / ServerGroups
    • networkfirewallRules
  • misc access and security controls
  • web server(s)
  • application server(s)
  • database server(s)
  • misc servers such as batch, messaging queue etc
  • data replication methods and tools
  • server(s) storage LUNs mappings
  • server(s) NAS mappings
  • server(s) technology stack
  • server(s) Operating System Processes
  • application dependencies - common/core services
  • application dependencies - enterprise applications services
  • application dependencies - external applications services
Category: Buz Words
Posted by: bagheljas
The word Technology Stack means different things to different people due to their roles and responsibility. The context of Technology Stack also changes it's contents such as Application Technology Stack versus Server Technology Stack that hosts an Application Component(s). The Application Technology Stack serves the Strategy and Design needs while Server Technology Stack serves the Implementation and Engineering needs as a result the Application Technology Stack drives the Server Technology Stack.

The Technology Stack schema elements are given below:
  • Server Platform such as x86, Mainframe, Mac, Solaris
  • Operating System such as Windows, Linux, Solaris
  • Middleware - Web, App and Database Platforms
  • Application Products
    • Commercial-Off-the-Shelf (COTS)
    • Opensource-off-the-shelf (OOTS)
  • Hardware and Software Appliances such as Google Search Appliance

Application Technology Stack may have multiple Server Platform and Operating System while Server Technology Stack will have only one Server Platform and associated Operating System. Application and Server Technology Stacks both can have multiple Middleware Platforms and Application Products.
Category: Buz Words
Posted by: bagheljas
The Applications Metadata is the information about an application that provides high level quick insight into the underlying business architecture, application architecture, system architecture and infrastructure architecture of the application. The Applications Metadata of an enterprise portfolio is a key foundation to develop IT strategy that includes cloud strategy, applications and infrastructures rationalization strategy, data center migration and consolidation strategy, technology refresh strategy, security strategy, and business continuity & disaster recovery strategy for the enterprise.

Sample Schema Elements for Applications Metadata:
  • Core Information
    • applicationName
    • description
    • serviceUrls
    • applicationType
    • businessFunction
    • businessCriticality
    • userBase
    • userType
    • securityAndCompliance
    • cloudReadiness
    • roadMap
    • knownIssues
    • comments
  • Target SLAs
    • Site
    • System
    • Service
  • Implementation Information
    • implementationType
    • technologyStack
    • applicationArchitecture
    • applicationDependencies
  • System Maintenance
    • blackoutPeriod
    • maintenanceWindow
    • maintenanceTypes
  • Sizing Information
    • userBaseSize
    • transactionVolume
    • transactionRate
    • operatingSystemsInstances
    • webAppServersInstances
    • databaseServersInstances
    • databaseSize
    • filesystemSize
  • Software / System Deployment Life Cycle (SDLC)
    • type
    • lifeCyclePath
    • lifeCycleDuration
    • testingType
    • testingDuration
    • state
  • Backup and Disaster Recovery
    • performanceObjective
    • RPO
    • RTO
    • deploymentState
  • Contacts
    • business
    • development
    • testing
    • productionSupport
<% %Y ()%>