For a start, I would like to mention the following information :
1. The team is segregated into the following : Engineering, Application Consultants (incl. Solution Architect and Project Manager) Quality Assurance Team and Operations.
2. The Portal Server has more than 40 applications (one application may contain 10 or more pages and each page containing 5 or more portlets) , mostly written in JSR 168 except for JSP Server Portlets.
3. The Production Portal is live, so this Portal has to be duplicated on another machine.
4. The LDAP Server is used globally and it contains more than 1000 groups and 100,000 users. The Portal is enabled to use Dynamic Group.
5. DB2 used is 8.2
6. The new architecture will be integrated with Omnifind Enterprise Search Server.
7. A new crawler will be created to craw the proprietary document management system.
8. Implemented a proper code change management on Websphere Portal.
Since the project team is composed of different teams, the following are the roles and responsibility of each teams :
1. Engineering Team : Setup the infrastructure, including Database Transfer and LDAP Integration.
2. Application Team : Migrate applications from 5.1.0.1 to 6.1, create crawler, Install Omnifind Enterprise and implement code change management.
3. Quality Assurance Team : Provide Load Test, Performance Testing and Security Testing
4. Operation Team : Certify the installation and migration and will support the servers installed and applications migrated on operational point of view.
Migrating is not the difficult, but the difficulty lies on making sure that these new environment will make my client's life easier, especially on managing Websphere Portal, promoting codes and implementing applications. The issue that my client is facing right now is that each Portal Environment is configured on it's own and there's no integration. I believe majority of the Portal Infrastructure is configured this way. What does this mean ? Let me give you an example.
Say you have 3 distinct portal environment, Development, Staging and Production. Each was installed on its own. Imagine creating an application for your user, say a business application. This business application requires 10 pages, with each page having an average of 5 portlets. Each page have different security configuration. As a developer, you know how to configure this on development environment. If your company is not that big and you don't have processes in-place, my guess is that your company will also ask you to deploy the portlets and pages plus configuration on staging and production. No problem, since you configured this and develop this, you know how to do so. However, let me remind you that doing this means you need to do every step in every environment, meaning that if you assign security in development for the portlet, you need to do so in staging and production. No problem since you're the one doing it.
However, let's bring the same scenario in a big MNC. MNC normally have proper processes in-place, meaning each environment is managed by distinct teams. On my client, they have a team managing development, staging and production. Development is open for developers so this is not a problem. However, the problem arises when this application is promoted in staging. A different team needs to install, re-do the configuration you did in development. Same thing will happen in production. The problem here is that, since this is a manual process, and different team are doing it, there's a tendency of human error, like misconfiguring the ACL on a portlet. This has a big issue on doing UAT and most of the time, on my client's experience, this causes delay on UAT. Aside from this, this brings frustration on the team managing staging and production as they are mostly blamed for the issues.
As we progress on this post, I will show you how to solve this issue by implementing Release Builder, to minimize manual work. You may wonder, why Release Builder and not Site Management ?
The reason is that Site Mangement required the different environment to open up to each other, and as per my client's policy, this is a security breach. You don't expect Staging and Production servers communicating with each other as you're opening a hole for potential hacking (if say, your Production was compromised, which means your staging can be compromised and the hacker may ultimately enter your network).
I'm part of the Application Migration team so most of my post will detail the tasks that I'll be doing to migrate the applications.
No comments:
Post a Comment