Perficient Portal Solutions Blog

Subscribe to RSS feed

Archives

Follow our Portals and Social Business board on Pinterest

Posts Tagged ‘12things’

12 Things to Get Your Portal in Production Quickly: Wrap Up

Over the last 3 weeks Mike Porter and I have covered a number of topics to consider when trying to accelerate your speed to production for a portal project.  In case you missed any of the installments, here they are.  Good luck on your project!

Previous Installments

  1. Dependency Management
  2. Ramp Your Resources
  3. Don’t Forget Your Users
  4. Visualization Tools
  5. Use the Capabilities Portal Provides Out of the Box
  6. Foundation One Step at a Time
  7. Use an Experienced Core Team
  8. Use Collaborative Tools
  9. Provide Ramp Up Time for Less Experienced Resources
  10. Change Management
  11. Don’t Forget Mobile
  12. Use an Iterative Development Methodology

12 Things to Get Your Portal in Production Quickly: Part 12 Use an Iterative Development Methodology

Mention of the word, “methodology” need not elicit groans.  Without a repeatable approach to projects it’s easy to miss key requirements, expectations, errors, etc.   So use a software developer methodology for your project.

Which methodology to use?

Frankly, I don’t care which methodology you use as long as it’s not a waterfall methodology.   I’ve been at clients where they describe their waterfall approach as the gating approach and that provides an apt description.  Waterfall lacks the agility to deal with the change we see in projects now.   You probably don’t have the luxury of launching your new site revision in 15 months.  Your end users probably demand a much shorter release cycle.  That cycle most likely cannot be met by a waterfall methodology.   Instead, you should consider SCRUM or RUP.

Rational Unified Process or RUP provides an approach where you iterate through development and include requirements and design for that piece of functionality.   Out of the three things that can change, RUP usually lets the timeline or the $$ slip.  If you run into a problem developing that new portlet then tack on a few days and adjust the plan accordingly.

SCRUM uses a sprint approach to deal with change and focuses on modifying scope as change occurs.  If you run into a problem developing a new portlet, then cut a view from the portlet and finish your sprint without it.  At the end of the sprint, revise the backlog to slot that missing view into the next sprint.  At the same time, you would push other functionality out of the sprint.  SCRUM and other agile standards operate on the mantra that change will occur, you just have to be able to modify scope as necessary.   If you work on a constant release cycle, that might fit into your needs nicely.

If you have a more focused release as we consultants often have, you may have to modify your approach.  We usually end up modifying an agile approach to finish high level requirements before hitting the sprints.  We will also add extra time if the scope isn’t as flexible as the date.   It’s a matter of rolling with the priorities of the project.

Regardless, as boring as the approach seems, you need to choose and stick with a defined approach.  At the same time, you need to use that methodology as a means to an end rather than the end itself.  When you focus solely on the methodology then you end up sliding into disaster just as easily as if you had no repeatable approach at all.

12 Things to Get Your Portal to Production: Part 10 Change Management

Any project will have change.  No one project ever includes the entire scope or has complete buy in from all the stakeholders or goes off without some major issue.   That means you have to both budget for it and plan the process by which you will accept change.

Step 1: Don’t be Afraid of It

I’ve seen plenty of consultant and client project managers who are literally afraid to talk to anyone about a change which will have an impact to the project.  In a previous post on how not to run a portal project I noted that you will be up late at night trying to launch your portal if the PM has yet to notify anyone of a two month delay and the business thinks the site will launch in two weeks.  I’ve seen clients that are annoyed and I’ve seen them down right angry.  Down right angry comes from complete lack of communication.  In any change management process, you must work with the business and give them enough information to make a decision.   But the first step is to notify them of any issue and work with them to resolve it.

Setup a Process

Before any issues arise, you should define a process with the key stakeholders.  It needn’t be long or onerous.   You can even include some automatic steps for minor change.  But you have to setup a process that includes:

Read the rest of this post »

12 Things You Can Do to Get Your Portal to Production Quickly: Part 7 – Use an Experienced Core Team

Use an Experienced Core Team

Part 7 in our series is perhaps one of the most important: Use an Experienced Core Team.  “We have a bunch of smart people and they can figure this portal thing out” is a sure way to put your project in jeopardy.  I cannot stress enough how important having the right team in place is to accelerating your delivery.  The first question you might have is what roles does a core team consist of?  There are quite a few roles and they can vary from customer to customer but here are some of the common ones:

  • Portal Architect
  • Portal Development
  • Infrastructure and Administration
  • Deployment
  • Security
  • Services
  • Release Management
  • Business Analysts
  • Project Management

Your leads in each of these areas need to be proficient in the technology and the processes within your organization.  If not, you will wind up burning cycles just trying how to figure out how to do basic activities and will wind up making decisions that will take you some non productive paths.  I am not going to go through each role but will focus on a couple of key ones.

Toolbox

Portal Architect

This is by far the most important technical role in a portal project.  A strong senior portal architect understands all capabilities of portal and has lead portal projects from inception to production in the past.  They also have the ability to participate in a hands on capacity as well if needed which may include writing code, doing performance tuning, implementing a web content management solution, installation and configuration, etc.  They need to understand all the capabilities that portal offers and when they should be used.  Portal is a large toolbox.  You don’t need to understand how to use each tool in the box but you need to know what tools are in there and when to use them.  I’ve seen too many customers who went down the path of writing custom solutions when portal provided very similar capabilities out of the box.  Other skills the architect will have will be to be able to accurately size work efforts, ability to work with the business, and general strong leadership skills.

Project Management

A strong technical project manager is critical.  A good PM will be able to manage the many dependencies an moderately complex portal project will certainly have.  This includes being at least technical enough to understand terminology and to be able to easily communicate with developers and other technical team members.  They need to be very forward looking to make sure dependencies are lined up and completed in advance so a development team isn’t sitting idle waiting on infrastructure, security, requirements, software etc.  A strong PM will also be able to fill a BA role when needed or if portions of the project are slow.  The PM is typically the overall delivery lead in the trenches on portal projects.

Business Analysts

A strong lead business analyst is very important to set the direction for the implemented solution which can bring the most business value.  IT driven business requirements seldom deliver what business wants so an analyst who has a strong working relationship with the business but also understands what portal can deliver will be the best fit.

Summary

Many different roles and responsibilities are required for a large portal project.  Putting together an experienced and solid core team will undoubtedly increase your chances of success and and speed to market.  While an argument can be made that this is true of any project, it applies exponentially to portal due to all the integrations, dependencies, and product capabilities.

 

12 Things to get Your Portal in Production Quickly: Part 6 Foundation One Step at a Time

The value of a portal comes from the time saved in putting out new functionality.  It means getting to market more quickly with new products.  A portal should allow quicker turn around when the business requests a change or enhancement.  Because portal is loosely coupled and provides a lot of configurable services out of the box, it should be much faster.  That said, you still need to create a foundation for all the aspects of a portal that you might re-use again and again.  I’ve seen two approaches to creating a reusable foundation.

  1. Take the time to identify key foundational items and then build them all out before rolling out your first site.
  2. Roll out your first site at the same time you build some foundational aspects of your portal.  In subsequent phases, as you add functionality, make sure that they are reusable and well documented.

I lean very heavily towards option two.  Very few companies are willing to pay the price for option 1.  That combined with the fact that your web sites will evolve over time and you can’t think of all the foundational aspects of a portal.  So yes, build a foundation but do it over time.  Always keep in mind that you want a foundation of reusable services and processes as you build. The cost will be incremental and will allow you to see some big value in future phases.

What is a portal foundation?

If a portal provides a bunch of out of the box functionality, then what do you mean by foundation you might ask.  Well, here are things that the portal doesn’t provide completely setup and ready to go and which you could create a re-usable foundation:

  1. Account Management: setup and editing of things like profiles, preferences, etc.
  2. Forgot password, change password self service
  3. Allowing business users to manage new users and delete existing users
  4. Setting up a reporting framework and portlet to easily surface new dashboards, charts, etc.
  5. Defining the process and setting up sample code for integration to SAP, Siebel, Peoplesoft, and other systems.
  6. Defining and setting up the content management process and templates so new changes re-use your WCM tools rather than create from scratch.
  7. Setup search with a search portlet that can be configured and re-used for different scopes, etc.
  8. Define, implement, and automate the release management process as much as possible
  9. Define best practices for coding, reuse of portlets, etc.
  10. Define key standards for branding, ajax, spring, hibernate, and other libraries you might use.
  11. Ensure chat, wiki, and other services are easy to use.
  12. Setup a process to allow users to create new communities, spaces, etc.
  13. Define a set of templates. This includes content management templates, page templates, and site templates.  This will make it easier and quicker to bring online new sections of sites or entire sites.
  14. Define themes for your web site, mobile phone, tablet, etc.

The list could go on but you get the idea.  The foundation of your portal will make it easier to launch new functionality and new sites with a minimum of effort and if possible, with the business fully involved.

12 Things Not to Do on Your Portal Project: webinar

Yesterday I presented our 12 Things series as a webinar.  The presentation is the abbreviated version.   If you want to read the whole series you can look at the recap with all the links to each post here.

 

Tags: , ,

Posted in News

12 Things You Shouldn’t Do on a Portal Project: Wrap UP

We have shown you a variety of ways in which you can screw up your portal project.  Glenn Kline and I had fun documenting them.  Of course, we had less fun living through them or consoling clients who were living through them but time heals all wounds and now we can laugh about it.  We’d like to end with a riff on David Lettermen’s top 10 list.

Late Night with Portal

You will probably be working instead of watching David Lettermen’s top 10 list on Late Night if……..

10. We have really smart people, I’m sure they can figure out this portal thing without any help at all.

9. The project team decides to use Agile and the PMO wraps their ‘gating’ process around it.

8. The integration team says, “We’ve almost decided on a Services layer.” It’s three months into the project.

7. The project manager has yet to notify anyone of a two month project delay and the business thinks the project will launch next week.

6. It’s month three of a 5 month project and you finally received sign off on requirements.

5. WCM isn’t absolutely perfect for us, let’s develop our own content solution.

4. The security team doesn’t need to be involved in the decision, I’m sure they will be on board.

3. You do a technical review and you hear the phrase, “I wasn’t here when they made this decision.” At least 5 times.

2. We don’t need to install the environments until the week before we really need them.

1. We are only 2 weeks from production and performance seems a bit slow.  Maybe we should run a performance test.

 

So have fun and good luck on your projects.

Previous Installments

  1. Where’s My Homepage?!?
  2. The Business Asked for It
  3. Methodology for Methodology’s Sake
  4. The Never Ending Strategy
  5. I Built It But Now I Can’t Support It
  6. We Can Get Big ROI From a Portal
  7. Is Best of Breed Always Best?
  8. When Developers Can’t Develop
  9. When Not to Use a Portal
  10. When Web 2.0 is 2.Much
  11. Infinite Loops on the Homepage
  12. Building My Own MVC

 

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register

12 Things You Shouldn’t Do on a Portal Project: #12 Building My Own MVC

Here is the last in our series and it tells the story of an architect at a customer who felt that Java Server Faces, Spring MVC and Struts were not good enough so he designed and built a custom Model View Controller (MVC)  framework for development in WebSphere Portal.

What Happened

This particular company had a really smart architect who didn’t like any of the existing MVC’s available and supported with WebSphere Portal.  He managed to convince his company they should build a custom MVC for portal and all other development projects.  It all was going well until he left the company, the MVC team shrunk, and development on the MVC essentially ceased.  A couple years pass and portal is a couple of major releases ahead, Java has been updated, JSR 286 is available, and now the portal development team is pulling their hair out trying to figure out this custom framework and crippled by not being able to use out of the box portal and open source capabilities.

What Should Have Happened

Portal contains a well documented API and leverages well documented MVC frameworks.  There are three main choices available: JSF, Spring MVC, and Struts.  All have their strengths and are well supported by either IBM and/or the open source community and make a great choice depending on your organizations needs.  Additionally there are many other development tools and frameworks available.  For rapid portlet development, consider using the IBM Web Experience Factory (formerly Portlet Factory.)  Additionally there are numerous other development tools and frameworks such as DOJO and jQuery for scripting engines, Spring, Hibernate, Ibatis, Display Tag, and the list goes on.

When a development need comes up, first look to what is available.  De-compiling and repackaging code is never the answer unless you want to instantly invalidate the ability for IBM to support you.  There are many public API’s available within portal that provide tremendous capabilities.  And lastly, if you are left with no options simply explain the situation to business.  It is unlikely they will ask for a completely custom ground up solution once they understand the ramifications of doing so and will work with you to find a palatable solution.

Previous Installments

  1. Where’s My Homepage?!?
  2. The Business Asked for It
  3. Methodology for Methodology’s Sake
  4. The Never Ending Strategy
  5. I Built It But Now I Can’t Support It
  6. We Can Get Big ROI From a Portal
  7. Is Best of Breed Always Best?
  8. When Developers Can’t Develop
  9. When Not to Use a Portal
  10. When Web 2.0 is 2.Much
  11. Infinite Loops on the Homepage

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register

Tags:

Posted in News

12 Things You Shouldn’t Do on a Portal Project: #11 Infinite Loops on the Homepage

It’s the fear of anyone who has launched a web site or an application that has any possibility at all of becoming well used.  What if your site can’t keep up with the load and the server crashes?  A crashing server due to resource overload can happen for a variety of reasons but today’s topic looks at how lack of testing can get you in hot water.

What Happened

In the early days of portal, we helped develop an employee portal for a well known fast food franchise.  One  portlet on the homepage was of medium complexity and required some complex logic.  As  part of the process, the portlet went through your typical system test process.  It passed with flying colors. The portlet did everything it was supposed to do. The portlet was then placed on the homepage in the production environment.

Not long after, the server crashed.  Then it crashed again. Deeper analysis pointed to this portlet.  We dispatched one of our brighter consultants to take a look at it.  Damian had to look fairly deep in the code to find that the original developer had coded an infinite loop that began sucking up resources every time it was hit.  Since this portlet resided on the homepage, it was hit fairly often.  The continual load placed on the server by this infinite loop eventually brought the server to it’s knees.

An infinite loop in your code can bring your site to it's knees

Read the rest of this post »

12 Things You Shouldn’t Do on a Portal Project: #10 When Web 2.0 is 2.Much

Ajax is a good thing, right?    Well, not always.

What Happened

A financial company had a content based intranet and the implementer decided that absolutely everything should be done using Ajax.   The home page had about a dozen portlets on it.  Some were personalized but most simply displayed non personalized content which did not change often, perhaps  hourly at best.  Some content even changed less than once a day.  The fundamental problem with this approach is that an Ajax request incurs at least a 1/10 of a second overhead in simply establishing an HTTP connection.  Given that a browser typically can only handle 4 simultaneous HTTP requests, all these request fire off synchronously, plus they also incur an heavy load on client side processing.  As a result of all this, page load times were about 15 seconds in single user scenarios.  Under load, page load times rose to over 30 seconds.

 

What Should Have Happened

Any portlet which simply serves content should never be implemented with Ajax.  This is especially true if the content is shared across multiple users and can be cached.  Cached portlet content can be retrieved in milliseconds where retrieving the same content (even if cached) with an Ajax based approach will take over 1/10th of a second.  If you multiply this times the number of portlets on your page times the number of page hits, it is easy to see the magnitude of extended wait time Ajax introduces into the portal.  After converting a majority of the portlets on this customer’s home page to not use Ajax, the page load times were reduced to less than 4 seconds under load.  The figure below shows the typical lifecycle for an Ajax call on a portal page.

WebSphere Portal Ajax Lifecycle

Ajax of course is extremely powerful and can create great user experiences; however, it must be used in appropriate situations.  Here are a few guidelines for when using Ajax is appropriate in portal.

  • A portlet will take longer than a second to render
  • The content of the portlet is not common between users
    • Portlet takes longer than a second to render
  • Content may change often and is minimally cacheable
  • A portlet will likely be interacted with
    • In place refreshes save entire page refreshes
    • Better user experience
    • Better performance
  • When a portlet connects to a system which may be unreliable
    • Prevents portal from hanging if system fails
    • Lets user interact with remainder of portal

One other word of advice about Ajax.  When web pages are assembled vial client side aggregation, the information which is rendered with Ajax typically cannot be indexed by search engine crawlers such as Google.  So, if you have a public site and you want it searchable, it is imperative to evaluate how Ajax is used.

Previous Installments

  1. Where’s My Homepage?!?
  2. The Business Asked for It
  3. Methodology for Methodology’s Sake
  4. The Never Ending Strategy
  5. I Built It But Now I Can’t Support It
  6. We Can Get Big ROI From a Portal
  7. Is Best of Breed Always Best?
  8. When Developers Can’t Develop
  9. When Not to Use a Portal

Join us this month on Wed, June 29th for our Perficient Perspectives webinar in which we explore the 12 Things You Shouldn’t Do on a Portal Project in depth.  More Info / Register