Your SlideShare is downloading. ×

Portal Deployment Best Practices | IBM Portal Excellence Conference 2009

2,526

Published on

Michael Porter, Principal, Portal and Collaboration Solutions at Perficient, presented at the IBM Portal Excellence Conference, Tuesday, October 13, 2009. …

Michael Porter, Principal, Portal and Collaboration Solutions at Perficient, presented at the IBM Portal Excellence Conference, Tuesday, October 13, 2009.

Successful portal projects depend on aligning your business needs to the technology and then using common best practices to run a successful project. In this session we will discuss how to align your business needs to create a portal solution and
then running a successful project by taking a holistic approach to portal. Topics will include solution roadmap, portal
governance, common technologies to include, and project management best practices that will make your project a success from a business and technical perspective.

Published in: Technology, Business
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,526
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
296
Comments
0
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Session B05 Managing the Portal Deployment Best Practices Speaker(s): Michael Porter, Principal
  • 2. Agenda
    • Aspects of a successful portal deployment
    • Holistic approach to portal
    • Vision and Alignment
    • Governance
    • Training
    • Methodology
    • PM Best Practices
    • Installation and Config
    • Development
    • Testing
    • Deployment
  • 3. Aspects of a Successful Deployment
    • Does it meet the end user’s goals?
    • Is it well used?
    • Can you prove that you saved money?
    • Can you prove that you increased revenue?
    • Does your company or organization view it as a success?
    • The Portal is a tool that gets you to the end goal.
    It’s the end result that matters!
  • 4. Vision and Alignment
    • Meet with Leaders
    • Figure out their business needs
    • Give them “Portal 101”
    • Align portal to the business
    • Prioritize the alignment
      • By audience
      • By what it will do
  • 5. Sample Vision
    • Customers
      • Prospects
      • New Customers
      • Existing Customers
    • Partners
    • Suppliers
    • Employees
    • The portal will drive sales
      • Web Channel for SMB (sales, care, service)
    • The portal will decrease costs through automation and access to information
      • Customer, Partner, Employee
    • The portal will improve and automate premium services
      • Company A service differentiation
      • Improved services to help encourage adoption of self service for elite customer
    • The place for customers and partners to conveniently interact with Company A .
      • Not the only place
      • Will provide a positive customer & partner experience
    Constituents Strategies
  • 6. Follow Through: Complete the Alignment
    • Interactive workshops with the client
    • Engages Line of Business and IT Mgmt.
    • Identifies value in the context of the client’s business challenges
    • Provides a high-level plan on where to begin and what can be delivered over a period of time.
    • Define Priorities and Dependencies
    • Three questions:
      • Complexity
      • Business Value
      • Organizational Readiness
    • Define the dependencies
      • Project, Organization, Technology
    • Create a roadmap
  • 7. Sample Roadmap and Dependencies
    • Timeline takes into consideration the client priorities, complexities, and critical Dependencies
    • Roadmap is a living document that is continually reviewed and updated.
  • 8. Governance
    • Organizations must understand the roles they fill
    • Key standards need to be set
    • Projects should not start from scratch
      • Give them lines of communication
      • A Foundation of standards and tools
      • A knowledge store
      • A place to interact with the project
    • Give business and IT a way to interact
    • Levels of Governance
      • Strategic
      • Tactical
      • Operational
      • Business Administration
  • 9. Sample Governance: Strategic
  • 10. Training
    • You cannot just give them a tool and let them go
    • Groups to train
      • Administrators
      • Application Developers
      • Content Developers
      • Leadership
      • Business Users
    • Type of training
      • IBM’s Portal Curriculum
      • Portal 101
      • End User Content and Portal Admin
      • Mentoring
  • 11. Methodology
    • Portal is a loosely coupled, highly scalable technology
    • Portal has many different pieces and parts
    • It works best with iterations and “baby steps”
    • It works best with frequent reviews and re-prioritizations
    • Consider any iterative type methodology
    • RUP
    • UML
    • SCRUM
    • XP
    • Crystal
  • 12. Project Management: How to Fail
    • How to fail when managing a portal project
    • My job definition is to get a report and summarize it in another report
    • My job is to make a list of all the risks and put them on a piece of paper
    • My job is to make a list of issues and put them on a piece of paper
    • My job is to hold a weekly meeting and present my pieces of paper
    • My job is to have a developer tell me of an issue on Thursday and assign someone to address it when I create my status report on Monday
    • I’m a Project Manager, it’s the process rather than the end goal or the technology that’s important.
    • Aside from some spiffy PM tools and a cool certificate on the wall, a good admin could do my job………………………..
  • 13. Project Management Different Philosophy
    • A good project manager is worth his or her weight in gold: pay accordingly
    • A good project manager
      • Sits with architects and developers over lunch
      • Understands the technology well enough to understand the dependencies
        • Can you create a page on the portal?
        • Can you set security?
        • Can you place portlets?
        • Do you know the general approach to integration?
        • Do you know the general approach to content management?
      • Acts immediately on issues with dependencies
      • Is forward looking and ensures deliverables and key technology is ready before developers start working on them.
      • Can translate a developer issue to a business language
      • Isn’t afraid to act like a Business Analyst if the need is there
      • Uses the collaboration tools, project spaces, etc. to their best advantage
  • 14. Project Management Tools
    • Team Space
      • Use it religiously
      • Give it some structure
      • IT and Business need access
      • Consider newer collab tools that are more agile
    • Project Work Plan
      • Update it
      • Use it to get in front of issues
    • Risks and Issues
      • Jira, spreadsheets, part of team space
      • Great tools but only to give the PM something to do
    • Reports
      • Important but only as part of the end result
      • A PM Cannot spend all of his or her time creating reports.
    Remember: the tools are only used to get you to the end result
  • 15. User Experience
    • Objective testing to make sure your UI works
    • Consider Visualization
      • IBM’s Portal Experience Modeler
      • iRise
      • Let users see the solution early
      • Capture requirements in that context
    • User experience type testing can user iterations like portal development
    • Make it part of the project and not some separate activity that has nothing to do with the project
      • More easily cut from the project (not a good thing if you are focused on the end result and not just launching a portal)
      • More expensive
      • Worse results
    Embed UX in your process. Involve the users early and often
  • 16. Development: Foundation and Standards
    • Follow the Enterprise Standards
      • If they don’t exist, then set them
    • Development tools
      • Eclipse
      • RAD
      • Portlet Factory
    • MVC (Struts, JSF, Spring)
      • Simple portlets don’t need an MVC
    • Other standards and scenarios
      • Caching
      • DB access
      • UI standards (based on those User Experience best practices)
    • Bottom line is that developers are more productive when you’ve defined the tool set and use them on multiple projects
  • 17. Development: Developer Types
    • Visual Designer
      • Don’t spin wheels having other developers do this
    • Content Developer
      • Simple programming like jsp’s and javascript
      • Templating
      • Configuration
    • Portlet Developer
      • Front end, not as deep as the integration or application developer
      • Must be familiar with MVC for more complex portlets
    • Integration Developer
      • Creates integration services to back end
      • Usually the most experienced
  • 18. Development: Estimation
    • Rule of Thumb: Take whatever the architect or developer gave you and double it.
      • If you use the really good ones to estimate, they forget they are probably 50-75% more efficient than your average developer
    • Use a ranking system: Low, Medium, High
      • Nothing EVER takes less than 4 hours
    • After you get the development estimate, then add in everything around it
      • Requirements
      • Design (if developer didn’t take that into account)
      • All kinds of testing (more on that later)
      • Deployment and launch
      • Time to migrate or create the content
  • 19. Administration
    • Allocate Portal and System Admin time
      • They help developers resolve issues
      • They get the environments up and running
      • They prep for post launch monitoring
    • Do not forget Release Management
      • If not setup correctly, this leads to disaster and a lot of wasted time
    • DBA Allocation
      • Light for just the portal
      • Heavier when creating custom apps surfaced on the portal
    The more complex your project(s), the more important Administration
  • 20. Testing
    • Good architecture the first step in the process
      • Define load and critical applications
      • If Prod is clustered then Test must be clustered
    • Don’t cut the testing because you are behind
    • Involve QA team early
    • Types of Testing
      • Unit: Developers must do it
      • System: How does everything work together
      • User Acceptance: important but it better not be the first time users see it
      • Load or Stress: extremely important. Do baseline and then keep doing it.
        • Hit it hard
        • Hit it over an extended period
        • Hit it with different users
        • Use multiple scenarios
          • Content, application, search, login, etc
    A portal has many moving parts. One part cannot take down the portal
  • 21. Deployment
    • Portal Installation
      • All environments setup and running
    • Portal
      • Themes and Skins
      • Portal Configuration
      • Portlets
    • Content
      • Templates
      • Migrate the actual content
      • Rules
      • Workflow
    • Database
      • Setup tables and base data
    • Services layer
      • ESB, EAI, App Servers
      • Connectors
    • Search Servers
    • LDAP Servers
      • Setup users
      • Setup security
    • Identity and Authorization Management
      • TIM/TAM, OIM/OAM, Siteminder
    • Legacy Systems
      • Code changes
      • Config changes
    Again, Portal has many moving parts, deploying means you have to prep all those parts………………
  • 22. Deployment
    • Identify all the systems that need to be launched or that have modifications
    • Identify all the people in charge of it
    • Identify who’s on site and who’s on call
    • Important: Do whatever you can before launch
      • Migrate themes and skins
      • Run database scripts and setup db’s
      • Create rules for workflow engines
      • Etc
    • Setup back out procedures
      • If the worst happens, can I return to my previous product ready state?
    • 6 weeks before launch, start weekly planning meetings
      • Remember that a PM’s job is to get in front of it. DBA’s, Sys Admins, Architects, and developers will let it slide if you do. Push them more than once a week in a meeting
  • 23. Post Launch Success
    • Setup a help desk
      • Train them on identifying the issue
      • “ The portal is down” is the most common error but usually it’s not the portal but some back end system
    • Setup monitoring
      • Server
      • System
      • Process
      • The actual portal itself
    • Allocate time for your developers to be a level of support until help desk and other support processes are in place
    • Create a feedback portlet and act on feedback
      • Make it part of the governance process
    Once a portal is launched, you have to maintain it
  • 24. Additional Information and Resources
    • WebSphere Portal – IBM Site
    • http://www-3.ibm.com/software/genservers/portal/
    • WebSphere Portal Business Solutions Catalog
    • http://catalog.lotus.com/wps/portal/portal
    • Websphere Portal Developer’s Zone
    • http://www-106.ibm.com/developerworks/websphere/zones/portal/
    • Product Documentation and WebSphere Portal Wiki
    • http://www-3.ibm.com/software/genservers/portal/library/
    • http://www-10.lotus.com/ldd/portalwiki.nsf
    • Education
    • http://www-01.ibm.com/software/lotus/training/portalofferings.html
    • WebSphere Portal Blog
    • https://www.ibm.com/developerworks/mydeveloperworks/blogs/WebSpherePortal/
  • 25. Please take a few minutes to fill out the session survey. Thank you Session ID: B05 Session: Managing the Portal Deployment Project: Best Practices Presenter(s): Michael Porter
  • 26.
    • © IBM Corporation 2009 All Rights Reserved.
    • The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.
    • References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.
    • All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.
    • IBM, the IBM logo, WebSphere, Lotus , Lotus Notes , Domino , Quickplace, Sametime , Workplace and Quickr are trademarks of International Business Machines Corporation in the United States, other countries, or both.
    • Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
    • Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.
    • Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
    • Other company, product, or service names may be trademarks or service marks of others.
    • All references to Renovations Inc. refer to a fictitious company and are used for illustration purposes only.

×