The Power of the Journey

A customer journey is really two things for marketers:

1. A plan to engage customers along a marketing pathway
2. A picture of what activities the target audience does and when they do them

Sounds simple, right? But it’s fueled by a lot of variables working in harmony.

The Importance of Alignment

Elements like technology platforms, qualitative insights, quantitative measurements and strategic design thinking not only have to be pointed in the same direction – they have to be operating at the right velocity. This becomes the difference between a scattershot marketing approach that’s impossible to measure versus a well-organized strategy that engages an audience on its own terms.

So how can you create this tight, strategic coordination? You need a closely aligned relationship between human-centered thinking and technology that can easily adapt on the fly, like Salesforce Marketing Cloud. Whether selecting high-level strategic engagement channels (e.g., digital marketing, social, email) or low-level logic parameters (e.g., how long to wait before sending an email), it’s critical to keep your audience in mind.

2 Key Questions for Leveraging Automation

When developing a customer journey that leverages an automation platform such as Marketing Cloud, keep two basic questions in mind:

1. How should you stack marketing channels to maximize engagement? Journeys involve tracking activity against a defined pathway and engaging people along the way. Obviously, that means understanding the proper channel to employ at the proper moment. But what channel should be the starting point? Where do you want your customers to go? What do you want them to do when they get there? Determining the right channel to initiate engagement, where to follow up, and when to encourage conversions is an important and often delicate dance. Theoretically, there’s nothing new in this idea. It’s common sense. Yet how often do we find marketing experiences that direct people to a website and then give no clear path forward from there? Collect an email address through a web form, but only ever follow up one time? Or don’t tie a digital marketing campaign with a social media strategy? This lack of alignment is the norm rather than the exception. But with a plan that you think your way through, that doesn’t need to be the case.
2. How does your target market use different channels? Now let’s say you have a plan. Once a prospect has shared their email address, what happens next? When do you send them an email? Right away or wait a day? If they don’t respond to the email, when do you follow up? How do you appear personalized and interested without badgering them? Understanding how your audience will use different channels spurs the specific tactics and execution of your plan – and creates the full picture of your customer journey. Back to Marketing Cloud as an example, the Journey Builder feature allows you to formalize a series of rules that guide channel-specific tactics. You can determine how long after the lead is captured to wait before engaging in a specific channel, as well as define the logic to keep engagement going, depending on the action taken (or not). The journey should, ideally, be able to support multiple paths based on your audience’s interactions. Do they open an email but not click on a call-to-action? Did they follow the call-to-action, but not fill out a form? Can you simultaneously engage them over a social channel as a reminder? Or does social serve in support once the prospect becomes a captured lead?

It Takes Both Sides of the Coin

Remember, tools like Journey Builder can automate these decisions, saving time and expense. But the logic that marketers use has to be more than a guess, too.

Aligning your tactical decisions with a strategic understanding of your audience’s behavior is the key to increasing engagement – and increasing conversions.

I really didn’t expect to see the day when Rational Application Developer would be supported on Mac OS, but it appears that RAD v9.0 will do just that.

While tablets have been taking a big bite out of the laptop and desktop sales across the broader consumer market, developers still generally need some real horsepower to do their jobs. Many of those developers have been moving from Windows or Linux to OS X and MacBooks, and you can see evidence of this conferences (even IBM conferences) and at most companies.

More and more of our customers are allowing and supporting Macs, and one even mandates them for development. So it’s good to see IBM recognizing the movement in their support for Mac OS in the newest version of RAD.

Before now, many of us with MacBooks would create a Linux VM to run our IBM software stack. That may or may not include RAD, depending on whether we or the client chose to just use Eclipse instead (perhaps a topic for a future post).

Before you get all excited and go download it, read Cody Burleson’s post on the issues he had with the Installation Manager. It is a beta after all, and he got it working by downloading the images and installing the pre-Installation Manager way.

My colleague Martin Ridgway recently posted on how your web site’s performance is important to the user experience. Of course this is true for WebSphere Portal sites as well, so I wanted to steal…er, leverage his recommendations and elaborate with some specifics on how we see those implemented within WebSphere Portal sites.

Before I go into some specifics, let me emphasize the need for disciplined testing when changing these settings. First, test the system as-is. Use tools such as HttpWatch, YSlow, Firebug, etc to examine headers and how many resources are being requested. Make one change at a time and retest. You should also consider creating a versioning strategy for your CSS and JavaScript files that will work in conjunction with your caching strategy.

Minify text files
The same applies for Portal sites. However, you usually don’t want the minified versions for your Dev environments. So consider performing the minify (and optionally obfuscate) actions in your build scripts. You do have build scripts and a CI environment (Jenkins, Bamboo, etc), don’t you?

Gzip all the things!
If you’re using Apache as your web server, this is relatively easy to accomplish using mod_deflate. You can deflate/gzip JavaScript or CSS based on file extension, but that won’t work for all of the HTML pages generated by portal because they don’t have extensions. You’ll have to catch and compress those based on their MIME type: text/html.

If you’re looking at tacking this process one step at a time, I would prioritize gzipping over minifying, at least in a Portal environment. And we often see HTTP servers that are very underutilized, so adding some compression to the response path will not likely cause a problem. Monitor your web server hardware/VMs and web server performance to be sure.

Concatenate, concatenate, concatenate
There is a lot going on in the construction of a typical Portal page, so minimizing the number of HTTP requests can be tedious. One thing you’ll notice quickly is the number of Dojo resources that are downloaded for each page request. These can be optimized though.

Using CSS sprites within a Portal theme is an easy way to trim a handful (or sometimes tens) or calls, depending on who chopped up your comp into HTML/CSS. If you have a web developer handy, have them help you with this. If you don’t, then you can find online CSS sprite generators that can help you take care of some of the problem.

Browsers have a cache. Use it!
The full range of caching options you have available from WebSphere Portal is beyond this post, but you can easily use the mod_expires and mod_headers Apache directives to set the cache durations in the response headers, and you can control this based on mime type or URI (LocationMatch directive).

Perceived performance is as important as real performance
It’s often not possible in a Portal site to move all of the JavaScript to the end of the page. Try to do this for any JavaScript that is site-wide and stored in the theme, but any custom JavaScript that appears in portlet applications will be loaded in-line based on where it falls within the page.

Living on the edge
Responsive web design is relatively new, and even newer in WebSphere Portal sites. There is an article on developerWorks that will help you implement RWD based on the default Portal theme.

In conclusion

What Martin said. Seriously, his recommendations apply to all types of web sites, regardless of the underlying technology. Then use some of these tips and the very thorough WebSphere Portal Tuning Guide to continue to make your site perform as quickly as possible for your users.

I recently posted about how to make your IBM WCM environment easier to use for content authors. In many cases, that may be sufficient for your needs, but sometimes it may be appropriate to augment that with more formal training. This training would be specific to your WCM environment – not on generic WCM authoring. Here are some of the cases where we’ve seen clients request, and ultimately benefit from customized WCM authoring training that we have created:

• There are dozens, hundreds (or more) potential authors. It isn’t unusual to have hundreds of content authors for a portal site in a large organization, particularly when the portal is being used for intranet-type purposes.
• Content authors haven’t been involved with the creation of the site and have no context for how or why the system was created. Training can provide background on the site itself, why it exists, and how to author content for it.
• Due to complex content requirements, the WCM developers couldn’t make the authoring experience trivial in every case.

So, what are your options?

No Formal Training
Don’t create any formal training at all – just focus on making the authoring process as easy as possible.

Instructor-Led Training (Online, or in person)
You could create a custom course for WCM authoring, and make it specific to your WCM libraries and templates. We’ve seen these type of courses range in duration from 1 to 12+ hours, depending on the complexity of the WCM assets to which the authors will be exposed.

The way you’ll get the most interaction between an instructor and the students is to hold training in-person. This is obviously difficult and costly when you have a large number of authors, or a widely distributed author community.

An alternative is to have virtual instructor-led training. You’ll also need to identify tools for voice calls, screen sharing, and post-course surveys.

If you have authors in different continents, the logistics of scheduling both the students and the instructors becomes more difficult. You’re also much more likely to encounter connectivity or performance issues with conference call numbers or screen sharing software. Also, if you choose to print any material, your printing and shipping costs can go up significantly.

You will also need to consider how to the students will perform the exercises or labs. Will you need to create a course image on laptops or VMs? Do you have a dedicated training environment, or an environment that can be reserved for training occasionally?

Self-Paced Training, Recorded Demos
This could be as simple as a series of modules delivered via presentations or wiki pages, or it could be created as eLearning videos, which would be more engaging and perhaps more educational to your target audience.

Which to Choose?

At Perficient, we’ve seen each of these options multiple times. At a minimum, my recommendation would be this:

1. Build the WCM environment, especially the authoring templates, so they are extremely easy to use, including liberal use of help text and descriptions for most assets and template elements.
2. Provide clear, concise documentation for non-trivial authoring scenarios. Point to the documentation (in a wiki, an IBM Connections community, Sharepoint, etc) from the WCM authoring environment itself so it’s easy to find. Hint: An easy place to put this link would be on the custom launch page that you should create and also in a URL in the top navigation of the WCM authoring environment.
3. Collect feedback from trial group of authors after the first few authoring templates are nearing completion. Only approach 2-5 potential authors initially for their opinion, and make revisions based on that.

Be sure to include those tasks on your project plan and allow ample time for documentation and template revisions. If you want to create formal training in any of the formats above, involve the course creators early for high-level planning, and ensure they’re available when WCM assets are getting approved so they can build the course based on final (or close to it) assets.

One of the key areas we focus on with many of our IBM Portal/WCM implementations is the authoring of web content within WCM. Let’s face it – while the out-of-the-box interface isn’t difficult to use, it is easier for technical users to learn than for non-technical content authors.

However, there are a number of things that can be done during a WCM implementation to dramatically improve the WCM authoring experience – many of these don’t require much effort:

1. Instead of allowing a lot of choices within a piece of content, it is sometimes easier on authors to give them separate, but similar templates. In a perfect world, WCM would allow something like template inheritance to make this easier.
2. Hide any elements that authors do not need to complete
3. Provide descriptive help text for all non-trivial elements.
4. Try to finalize 1-2 templates early and let a few individuals try to author content. Then adjust templates and help text accordingly.
5. Limit selections (e.g. categories, site areas, etc) via WCM security. Authors will then see only the selections they are allowed to choose based on their authority. This allows a great deal of reuse within WCM.
6. Set default values when applicable. If you use a naming convention for the “Name” field of your content items, set the default value to an example of that naming convention.
7. Create custom launch pages in the WCM Authoring environment that give the authors a better starting point.
8. Version 8 provides a few options (“Basic Home Page” and “Home Page”) that are better than the default. At a minimum, choose one of those, but a custom landing page is even better.
9. Custom workflow actions. These can sometimes be implemented with relatively simple usage of the WCM Java API, yet provide a lot of time saving and usability improvement. For example, one client of ours had the requirement for the approver group to be set based on who is creating the content. So if the author is in HR, the approver group should be HR_Approvers. If the author is in Marketing, the approver group should be Marketing_Approvers. This is relatively easy to do with a custom workflow action, a simple lookup table, and some basic coding to the WCM API. There are alternatives with out-of-the-box WCM features, but it requires more duplication of assets.

For most new IBM Portal/WCM implementations, there will be a period before go-live when a large amount of content will need to be entered. Sometimes this can be done programmatically in bulk, or with a migration tool such as Kapow Katalyst, but it is very frequently done manually.

If the authoring environment isn’t easy to use, this will cause delays and pushback from the business users who need to enter the content. In some cases, I’ve seen this task fall back on the development team, and content entry isn’t what they want to be doing in the weeks before go-live.

In some cases, more formal education on WCM authoring may be required. Stay tuned for a future post with opinions on that subject as well.

Splunk hosted a webinar earlier today on their Splunk for WebSphere Application Server 2.0 application. This is an application they wrote that extends Splunk’s already powerful capabilities to provide WebSphere-specific searches and reports.

If you’re not familiar with Splunk, you should take a look. In a nutshell:

Your IT infrastructure generates massive amounts of data. Machine data – generated by websites, applications, servers, networks, mobile devices and the like.

By monitoring and analyzing everything from customer clickstreams and transactions to network activity to call records, Splunk turns your machine data into valuable insights.

Troubleshoot problems and investigate security incidents in minutes (not hours, or days). Monitor your end-to-end infrastructure to avoid service degradation or outages. And gain real-time visibility into customer experience, transactions and behavior.

There are many questions that arise in typical WAS-based environments that this app will help answer, and answer very quickly. For example:

• A host needs to have an OS fix applied. Which applications are running on that host so I can test them after the fix is applied?
• The QA environment seems to be behaving differently today. What changes were made in WAS in the past 7 days? Were there any recent restarts? Who performed those actions?
  • NOTE: This is great reason not to let multiple people use “wasadmin” or “wpsadmin” users. Assign groups to WAS administrative roles and make admins log in with their own account so their actions can be audited.
• There are a lot of errors and/or exceptions in the logs. Which ones occur the most so that I can prioritize their resolution? Are users seeing errors that correlate with errors being seen in the logs?
• Users are seeing intermittent failures on the site. Which of our cluster members are seeing the most exceptions or errors, or is it evenly distributed?
• Which of our hundreds of JVMs are running right now, and which are not?

WebSphere Application Server collects a great deal of information in logs and in memory (JMX, PMI, etc). This is the raw information that is needed to understand how the environment is operating. However, it’s hard to get to that information and consume it quickly, correlate it with other information, and then resolve problems based upon it. A few of the problems we see frequently are:

• Performance metrics and application logs are often not available to the people who are best suited to solve the problems.  e.g. Developers don’t have access to production systems that contain the logs.
• It is very time-consuming for administrators to access each host and each log, then manually search them to find the problems. Generally not all logs are even inspected which means root cause exceptions might be missed.
• There may be a log monitoring agent installed, but it will often only look for particular regular expressions and will not provide context (the events occurring before and after the obvious error)
• Difficult to determine trends in problems. Is a particular exception new? Has there been a gradual or rapid increase in exceptions? Over what time period?
• Too many customers don’t map an LDAP group to the WAS administrative roles, so it’s impossible to determine who made WAS changes.

Splunk and their app for WAS help solve those problems by easily collecting logs, configurations, and performance metrics for centralized searching and reporting. The main classes of information it collects and reports on are:

• Component Inventory (cells, nodes, hosts, applications servers)
• Security
• Users
• Operational information (errors,  configuration changes, and more)
• Performance (PMI metrics via JMX, such as database connection pool usage, thread pool metrics, etc)
• Solution Administration (information for the Splunk admins about the collection of WAS data)

If you already have a robust monitoring tool for your WAS environment (e.g. ITCAM, Introscope, New Relic, etc), that’s great – keep using it. Splunk will complement it by filling in gaps around monitoring configuration changes or logs. And if you don’t have a tool to monitor your WAS environment…well, you should, and Splunk is an excellent option to fill a lot of holes at once.

So how do you try this out?

1. Download Splunk (it’s quick, and there’s a FREE version where you can index 500MB of data per day indefinitely)
2. Install the Splunk for WebSphere Application Server 2.0 beta app. You can install just the app portion to Splunk if you are testing locally with a WAS instance on the same server with Splunk. This is perfect for a POC.
3. Configure the app by following its setup screens and pointing to your local WAS environment.
4. Use Splunk to learn more about and improve your WAS environment (a.k.a. “Profit!”)

The Splunk for WAS application was targeted for  the base application server. But since IBM and other vendors have written a LOT of applications on top of WAS, this Splunk for WAS app is useful for those environments as well.

For example, WebSphere Portal logs by default to WAS’s log files (unless you enable tracing, in which case trace.log is also created). WebSphere Portal has its own set of informational, error, and audit events that it logs, and it will be fairly easy to set up additional dashboards in Splunk to report on those values. Similar principals will apply to WebSphere Process Server, WebSphere ESB, WebSphere Commerce, and many more.

Since Splunk has this handy app for WAS, it should make it relatively easy to build a Splunk for WebSphere Portal application. Hopefully that’ll be a future post.

If you don’t regularly check the IBM Portal wiki or subscribe to updates via RSS, you might not have seen the WebSphere Portal v7 Tuning Guide that was just released.  Many of the sections are similar to the previous editions, but there are also new sections for areas such as:

• Disabling features you might not be using, such as tagging and rating, search, and friendly URLs.
• Page Builder Theme Tuning
• Nested Group Cache
• Startup performance using Development and Lite Modes
• Many others…

Don’t get too carried away and start tuning right away.  The very first paragraph of the PDF contains a very important recommendation:

Remember that both tuning and capacity are affected by many factors, including the workload scenario and the performance measurement environment. For tuning, the objective of this paper is not to recommend that you use the values we used when measuring our scenarios, but to make you aware of those parameters used in our configuration. When tuning your individual systems, it is important to begin with a baseline, monitor the performance metrics to determine if any parameters should be changed and, when a change is made, monitor the performance metrics to determine the effectiveness of the change.

Every non-trivial implementation of WebSphere Portal (are there any trivial ones?) will need some degree of automation, mostly around release management.  Most customers have three or more portal environments: Development, Production, and one or more in the middle.  In the last few years, we’re seeing a greater demand for Disaster Recovery environments as well.  Promoting code and other portal assets through these environments from development to production isn’t a trivial task.

There are a number of different ways to tackle the problem, but the solution that is right for your environment will depend on a few things:

1. What individual or team will do the actual deployments?  Does it change in each environment?  What is their skill level?
2. What are your most frequently changing assets?  WCM content, page configurations, custom portlet code, pure Java EE applications, something else?
3. What is the initial budget for automation (as always)?  Keep in mind that automation, done properly, will save time and prevent errors long-term.
4. Do you already have scripts or processes and just need to fill some gaps, or are you starting from scratch?
5. Do you need to just deploy to one vendor’s products (e.g. IBM), or do you also need to manage deployments to other application servers, portals, etc?

Unfortunately, the technique to move each Portal-related asset from environment to environment is different.  Here are some, but not all, of the asset types and deployment techniques for them:

• Portlet applications – scp to primary node, then deploy to WAS or Portal, and run XMLAccess to activate
• EAR or WAR files to WebSphere AppServer – scp file to the Deployment Manager, then use wsadmin or hot deployment.
• WCM content – syndication (either manual or automatic)
• Portal pages, layouts, etc – XMLAccess, ReleaseBuilder, Site Management functionality
• Portal Configuration (properties stored in WAS) – wsadmin
• Themes and skins – deploy as WAR to WAS, register via XML; Redeploy wps.ear

We have built and extended various solutions over the years, and we’ve seen a many IBM customers do the same.  While a number of products have come out in recent years to try to address this issue, many customers still attempt to build their own solution.  The custom-built solutions are typically command-line only, have a limited number of features, and have to be maintained by the 1 or 2 people who created it.  If the original author left the company, the solution often sits idle or even dies when the infrastructure upgrades to a new version of WAS or Portal.

You have two high-level options:

1. Buy + customize.  Your “buy” options today are:
   • BMC BladeLogic Application Release Automation (was Phurnace)
   • IBM Rational Automation Framework for WebSphere (RAFW)
   • Xebia Labs Deployit
   • Nolio

   And there may be others that are harder to find.  It’s likely that none of those will be perfect for your needs, but they should still save you significant effort overall, and they are all supported by more than just the scripting wizard in your infrastructure team.  So it’s definitely worth evaluating those tools before choosing to…

2. Build it all. This will involve some combination of wsadmin (Jython usually), wpscript, XMLAccess, ReleaseBuilder, scp/ssh, Ant, and other commands at your disposal.  You should also consider a command execution framework such as STAF, Fabric, or Capistrano.

I hope you weren’t looking for an easy answer. When this question came up 2+ years ago, build-your-own was almost always the best option. The companies I mentioned above have made a lot of progress since then, so now I typically recommend to investigate them first and build only the pieces that they do not address.

Let me know if you have any opinions on this. I’d also love to hear about any horror stories you have around this topic.

Jason Wicker of IBM has posted a comprehensive set of security concepts and considerations for IBM WebSphere Portal.  While much of this information exists in various forms throughout the v6.1 and v7.0 InfoCenters and Redbooks, Jason captures it all in one place.

I’d recommend that Portal customers and consultants use that article as a security-related checklist to help ensure all of those items are at least discussed.

The title of Jason’s article states that the information is for Portal administrators.  I agree that it’s important for Portal admins to know about these topics, but I think it’s even more important for the Portal Architect to be familiar with them and know when to recommend each for implementation.

In the past few years, we have seen a lot of our new and existing customers show interest in having someone else run their WebSphere Portal infrastructure.  They’re happy with their investment in Portal, but may have any number of reasons why they don’t want to manage it themselves anymore.

As you start to talk to cloud providers, you’ll get a wide variety of responses on how they’ll actually support WebSphere Portal.  It’s easy enough for any provider to say “yes, we’ll support WebSphere Portal”, but what does that really mean?

Many will basically support the underlying infrastructure, but not touch WebSphere Portal.  They’ll rely on someone else to do that, and may have a partner like Perficient that they’ll recommend to provide those services.  Other providers have started to add in-house services around WebSphere Portal (and WebSphere Commerce) to address the more common services.

Once you identify a few cloud providers to approach, here are a few questions to get the conversation started and find out exactly what they will and will not do with WebSphere Portal:

Will the provider:

1. Install, cluster, configure, and secure WebSphere Portal?
2. Migrate your existing Portal into their new infrastructure?
3. Perform fixpack and patch maintenance?
4. Monitor performance externally only (e.g. response time of URLs, CPU or memory utilization), or also monitor metrics from PMI within the JVM?
5. Deploy portlet applications to each of the environments?
6. Perform “routine” portal changes such as creating or updating pages, etc?
7. Execute XMLAccess scripts to promote changes through SDLC environments?
8. Open and work PMRs with IBM as necessary?
9. Expose the logs to developers?  Do they have to SSH into each server, or do they provide an optional log management product to index and consolidate logs?
10. Provide a mechanism to quickly create new Portal instances (for POC, development, or scaling purposes)?  Warning: this also has Portal licensing implications.
11. Host and support other dependent software, such as reverse proxies (e.g. Tivoli Access Manager), content management systems, enterprise search software or appliances, etc?

Ultimately you, the cloud vendor, and potentially another services provider will have to agree upon the roles and responsibilities.  But the offerings are now mature enough that it is worth exploring, and you should have no problem getting multiple quotes for comparable services.  Now, the tough part might be determining exactly how much it is costing you to run Portal today!

Let us know if you’ve had any positive or negative experiences with moving WebSphere Portal to a cloud vendor.