This chapter covers the initial portal assessment leading to a Proof of Value (POV), which needs to be executed for portal engagements at program and/or project levels. One of the main assessment goals is to capture the business drivers for choosing this technology and evaluate the business value to be added with a portal solution. The outcome of the business assessment is a current and future state gap analysis and subsequently a mapping of the business drivers to portal capabilities. The assessment covers business and technology aspects. It helps drive the next discussion of the need for portal governance, process, and organizational changes that a portal project can bring as a requirement to an enterprise moving to the portal paradigm. This chapter will provide orientation to get started with assessing and looking at options for a portal POV; and how the cloud plays an important role in the enablement. By the time we are done, we will have looked at the following topics:
IBM WebSphere Portal (WP), IBM Web Experience Factory (WEF), and the cloud
Cloud service models — SaaS/IaaS/PaaS
A case study
Cloud use cases applied
Portals are single point of access for information, knowledge, business services, and transactions; providing aggregation and role-based access to Business to Business (B2B), Business to Consumer (B2C), Business to Employee (B2E); along with vertical and horizontal domain support. Portals also allow for that data to be served on a variety of devices, anytime, anywhere. From an architectural viewpoint, a portal is an architectural pattern implemented and realized via a product with out-of-the-box integration potentials and capabilities. From a technology standpoint, the IBM WebSphere Portal is a J2EE application with its engine being compliant with portal-specific APIs, such as JSR 168, JSR 286, and WSRP. So what is the cloud and how can it help you with your WP and WEF related initiatives? Let's first start with some basic definitions.
Cloud is a delivery model that uses virtualization to build, provision, deploy, and enable environments, resources, and services. More precisely, its canonical definition according to the working definition of cloud computing published by the U.S. Government's National Institute of Standards and Technology (NIST) is as follows:
Cloud computing can be described as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (for example, networks, servers, storage, applications, and services) that can be rapidly provisioned, and released with minimal management effort or service provider interaction.
To complement it, IBM defines cloud computing as follows:
Cloud computing changes the way we think about technology. Cloud is a computing model providing web-based software, middleware, and computing resources on demand. By deploying technology as a service, you give users access only to the resources they need for a particular task. This prevents you from paying for idle computing resources. Cloud computing can also go beyond cost savings by allowing your users to access the latest software and infrastructure offerings to foster business innovation.
For almost every new technology and trend in business and technology initiatives, there are standards developed around it. Along with the Open Cloud Manifesto, there are some use cases for cloud computing defined in a white paper entitled Cloud Computing Use Cases 2.0 pioneered by the Cloud Computing Use Case group. Let's now take a look at cloud NIST definitions as for the three major cloud service models. Because, whenever the cloud topic is involved, it is in the context of these services models, which are Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Let's break them down and look at their defining characteristics:
SaaS: SaaS is related to an application that is served and consumed over the wire, where the consumer itself has no control over the runnable software in terms of the operating system, network infrastructure, and hardware; so it is more like a black box for the consumer. The consumer only uses the service provided but does not control nor have knowledge of the behind-the-scenes mechanics.
PaaS: PaaS is related to the consumer having a little bit of control over the hosting environment for the application it consumes and runs. So the platform can be an application framework; but still the consumer does not have any control over the hardware, network, storage, and operating system for that hosting environment.
How WP and WEF in the cloud can help your initiative, and the value added will vary depending on what phase of the Systems Development Life Cycle (SDLC) you are addressing. Regardless, if you are planning a new infrastructure or portal migration, or a POV, the level of value the cloud brings can vary. However, the return on investment (ROI) can be achieved in all phases of the SDLC.
How are WP and WEF represented in the IBM business SmartCloud and Amazon Cloud? For those interested in the new cloud delivery model of provisioning portal development, integration, system test (user acceptance and performance), and production environments, the IBM SmartCloud has a plausible and viable solution. Based on the starting guide, we will walk you through the whole process. For the purposes and scope of this chapter, we will focus on the development environment only.
In this book, we will base all of our case study examples on a fictitious bank client named A2Z Bullion Bank that has, as a business driver, the need for modernization of its call center operations. Another major driver is the need to revamp and rebrand some of the banking operations via the consolidation and integration of a lot of application functionality, previously available in Customer Information Control System (CICS). Even though this client belongs to the financial sector, all the examples in this book can be easily correlated and translated to several other industry domains.
At a high level, the A2Z Bullion Bank, which has been providing other commercial banks with Bullion Vault services, uses 3270 terminals for its offshore call center operations. It uses CICS and a relational backend for its many frontend applications, all of which need to be consolidated via Portal. So far, the bank had only interfaced with other bullion or central banks, but it is now opening its operations to other corporate broker consumers interested in Bullion Vault services. The Vault services allow users to store physical bullion metal bars (gold, platinum, palladium, and silver) in the Vaults. Transfers from fiat currencies and loans are also services aligned with Vault services. Furthermore, users can forecast and trend their future Vault performance based on future metal spot prices. The bank stakeholders have decided on the need to have a self-service consumer-oriented channel for this new activity.
The goal of the bank is to understand how portal and the cloud would be able to help in the modernization process to be able to gauge the value added and ROI.
Let's start with our case study and the Business Value Assessment (BVA). IBM BVA is an IBM-driven methodology and should be applied with the help of IBM consultants and business partners. The generic steps of a portal BVA are cited and illustrated as follows:
1. One of the main goals of the assessment is to capture the business drivers for choosing this technology and evaluate the business value to be added with portal. The outcome of the business assessment is a current and future state gap analysis and subsequently a mapping of the business drivers and requirements to portal capabilities. The assessment covers business and technological aspects, and helps drive the next discussion of the need for portal governance, process, and organizational changes that a portal project can bring as a requirement to an organization new to portal. First, we cover in a workshop-like format with active interviewing of stakeholders per module target background, objectives, and defined approach. The output of these first items serves as an input to feed the next exercise. The business need and portal solution align together via the particular business and technical drivers and the current state of the business assessed. This initial portal assessment needs to be done for every portal engagement at a project and ideally at the program level. Next, we will cover the main steps in the BVA cycle — background, objective, and approach.
2. Business need and portal alignment.
3. A "Day-in-the-Life" demonstration.
4. Financial case.
5. Recommendations and next steps — POV.
It provides you with a vision of the portal when it's complete.
It gives you a high-level cost and benefit analysis to define the value of a portal solution in financial terms. The corporate positioning helps to set the stage for defining the vision, the strategy, and the execution.
It starts with the million dollar question — "What should our organization do with a portal and workplace to solve their current pain points and address the need for the future and new business demands?" We will not go into any details of this approach in this book, but we will give you the pain points to make our lifecycle story complete and give you a frame of reference for your own portal initiatives. The following diagram will provide the high-level phases to get the portal off the ground. Any portal engagement would have to apply a similar level of analysis in order to realize the portal value.
The A2Z Bank has funded a program with PMO support to facilitate the need for governance around the portal initiative. They are in the process of being educated on the value of having such infrastructure support around the new initiatives. They want to have a POV done quickly to show how the portal value can be added within a short time to market. The major business drivers were the need for modernization and the new line of business and self-service customer channel to support. A series of workshops was done with several lines of business stake holders to cover the preceding aspects.
One of the main focuses of capturing current state is to capture the current organization processes in place at the enterprise level and understand how they can be positioned to a future state and enterprise road map that has portal capabilities in its critical path. From there, a future state can be mapped out and a demonstration can be done at a more generic level with the "Day-in-the-Life" demonstration for vertical markets. Then a POV using stubbed data from real data and service models can be used to further illustrate and demonstrate quick business-driven development with the IBM SmartCloud, WP, and WEF patterns.
Once the workshop and interviews that focus on documenting current internal processes, governance maturity level, and so on are all done, there is a mapping to portal and cloud capabilities, along with the demand for fast application development and value to market. The outcome of this exercise will allow the value of portal to be illustrated and imagined. The next step is to map out the demonstration of financial case to the "prospects" executive sponsors.
The following list consists of a high-level road map potential with a few critical points identified and their recommended solution provided:
According to the BVA, 70 percent of the A2Z IT budget goes into maintenance of current applications
According to the BVA, 39 percent of A2Z bugs in the system are due to misconfiguration
According to the BVA, 85 percent of its IT capacity sits idle
According to the BVA, 49 percent of the A2Z enterprise applications are not integrated but working in large IT silos and without any governance oversight
In order to make the business case and demonstrate, some of the added value with portal and the cloud, a series of presentations were made available to top decision makers and stakeholders. These dynamic demonstrations are not just static PowerPoint presentations. They are full-fledged, interactive demonstrations presented via a web browser. It allows for stakeholders to relate to and anticipate that their business goals would be positively changed by portal capabilities. These are necessary steps in bringing the road map vision closer to the business case. Take your time to watch them and look at a sample that matches the industry domain for which you work. After these presentations were shown, that was a general consensus that the portal initiative would have A2Z Bullion Bank on the right road to the future. The next step was to create a financial case to show the financial gains of adopting both portal and the cloud as the new paradigms for A2Z Bullion Bank Infrastructure Technology.
IBM Industry Toolboxes for WebSphere Portal at http://www-01.ibm.com/software/websphere/portal/industry/
WebSphere Portal Web 2.0 for Banking at http://www.youtube.com/watch?v=uR3FUl8Jqws
WebSphere Portal works for Banking Part 1 at http://www.youtube.com/watch?v=X4_vqk2qpCE&feature=related
WebSphere Portal works for Banking Part 2 at http://www.youtube.com/watch?v=jVsRaeFlU80&feature=related
IBM consultants, software sales experts, and business partners can help build a financial case for an enterprise. In this case, A2Z Bullion Bank utilized the services of an IBM business partner for most of its modernization efforts. The financial case was built and shown to the CFO and his teams, along with other important executive players, such as the CTO and his teams. The financial case is an important module in the BVA exercise, as it plays the role of the major decision-maker item in a value proposition. Besides the huge financial gains, this cloud-enabled portal initiative (with fast time to market value proposition as one of the main criterion) and major pain points with which the current IT infrastructure deals and struggles with, were going to be addressed.
Stakeholders also watched online banking, multichannel banking, and payment presentations, and were highly impressed with all the capabilities that portal could bring to the table as a way to allow A2Z Bank to move into the future.
The next steps were laid out and agreed upon.
In our sample, we will perform the following steps:
1. Use a cloud provider to quickly provision the development environment dedicated to the POV.
2. Use the WP and WEF cloud patterns to expedite the development and integration phases along with IBM Industry Toolbox.
3. Use the feedback from the BVA to drive the use cases for the POV with the assistance of a portal architect and WEF specialist.
4. Have the scope and use cases for the POV, and implementation plan reviewed and approved before moving to implementation. In this case, the POV was going to be focused on the banking channel only using data mostly from the banking template, but add some customization, and serve as a functional development sandbox for portal-related development efforts.
With a POV funded and ordered to be delivered within a timeframe, the decision was made to use the IBM development and test cloud. After that, a private cloud would be used to jump-start the physical infrastructure for the entire portal initiative lifecycle.
A program-level road map was designed and agreed upon in the following circumstances:
1. Where first phase would transfer and/or integrate some of the foundational functionality into portal information architecture for both the banking channel and the call center. It would use the new IBM X150 DataPower appliance to mediate the data entry points and functional layers via SOA reference architecture; along with the Master Data Management reference architecture.
2. Second phase would deal with portal areas such as Business Process Management (BPM), content management, Single Sign-On (SSO), and custom search. The entire program would have strong governance, Application Performance Management (APM), and business intelligence (via analytics) support. This initiative would take advantage of the cloud capabilities for its plan of business success via IT execution. Cloud patterns would be reused to expedite the environment build-out and time to market via IBM Workload Deployer (second phase BPM, SSO, search topics will be fully covered in the next edition).
The BVA covered a lot of ground and provided a road map for the future.
IaaS would be adopted for this transformation effort (as a consumer) saving costs
PaaS would be adopted for this transformation effort (as a consumer) saving costs
SaaS would be a service model on which the bank would start capitalizing via its call center and self-service channels (as a cloud provider); thus generating profits
A decision was made to start the prototype effort using a cloud provider. Both the Amazon and IBM SmartCloud are great options, which provide both development and test micro images that can be easily and quickly deployed. They both offer the elasticity and standardization on top of virtualization and the value of central monitoring, and quick environment build-out is added along with the other advantages. In this chapter, we will share how to get started with both cloud providers. In the real world, one would choose one cloud provider, but for informational purposes, we will show both of them for the prototype and POV goals. Let's first start with IBM SmartCloud. This next section will demonstrate how to log in, choose, create, manage, and deploy both the portal run-time environments and the WEF development environment in IBM SmartCloud, Amazon Cloud, or on a standalone virtual image machine.
To get your IBM Cloud up and running, perform the following steps:
1. Contact your IBM representative to set up an account, and order the SmartCloud plan and the capacity options for reserved, capped, or uncapped resources.
2. Register and create a login ID, and access the cloud.
3. We then choose a pattern topology based on the needs and scope of this environment. In this case, it will have WP, WEF, IHS. Initialize a new instance and add necessary topology artifacts (start and stop portal server—start and stop HTTP server). Start WEF and get your Hello portlet up and running. For further information on this step, please read the IBM Smart Business Cloud getting started guide - WebSphere Portal V6.1.5 article located at http://www-10.lotus.com/ldd/portalwiki.nsf/dx/IBM_Smart_Business_Cloud_A_getting_started_guide.
4. Prepare and deploy the banking template and create necessary portal pages to host the portlets based on the wire frames identified and proposed during the BVA and implemented via services contract for the POV initiative.
5. Customize the template with the bank data model (captured, documented, and stub developed during the BVA) and the desired corporate branding. Prepare some stub data for the POV itself.
To get your Amazon EC2 Cloud up and running, perform the following steps:
1. Sign up for Amazon Service.
2. We register and create a login ID and log on to the console.
3. We then choose an AMI pattern topology based on the needs and scope of this environment. Go to http://aws.amazon.com/amis/2048 for the standard development Amazon Machine Image (AMI) for portal.
4. Initialize a new instance and add necessary topology artifacts and launch it (start and stop portal server, start and stop HTTP server). Start WEF locally and get your Hello portlet up and running. For more information on how to boot and manage your portal image, please read IBM Websphere Portal and Lotus WebSphere Content Management Amazon Machine Image Get Started Guide located at http://public.dhe.ibm.com/software/dw/cloud/wps-wcme/Get_Started_Lotus_AMI.pdf.
5. Create a test project on WEF and download the WebSphere Portal Solution Installer. Consult the IBM WebSphere Portal Solution Installer - User Guide for any questions related to the Portal Solution Installer. Move the.war files to portal and deploy portlets and pages to the cloud (or to a standalone virtual machine from VMware). Smoke test the banking portlets' functionality.
For a great advanced demonstration on how to manage Amazon images, please watch the multimedia presentation by Andrew Glover in the IBM developerWorks article — Cloud computing with Amazon EC2. It can be found at http://www.ibm.com/developerworks/offers/lp/demos/summary/j-cloudamazonec2.html.
6. Prepare and deploy the banking template and create necessary portal pages to host the portlets based on the wire frames identified and proposed during the BVA.
7. Customize the template with the bank data model (captured, documented, and stub developed during the BVA) and the desired corporate branding.
The next steps are common to either cloud provider. They are as follows:
1. Prepare the environment for the portlets using IBM Toolbox banking portlet. Follow this article and read the instructions on how to do so. In this case study, we use the IBM Toolbox banking portlets to jump-start the development for the financial domain. We look at the real banking data model and document it with the labor resources allocated to the POV.
2. Prepare the environment (either cloud or a private standalone virtual machine mentioned in cloud vendor choice steps).
3. Configure the banking portlet database along with authentication, and run a verification test to make sure the containers are up and running with the expected container and application-level connectivity. Create a test project on WEF, and download the WebSphere Portal Solution Installer. Consult the IBM WebSphere Portal Solution Installer User Guide for any questions related to the Portal Solution Installer. Move the
.warfiles to portal and deploy portlets and pages to the cloud (or to a standalone machine). Smoke test the banking portlets' functionality.
4. Prepare and deploy necessary custom test stub data. Create a custom data or stub a service layer and implement it for the POV. In case of A2Z Bank, a service layer was created to map to the data layer as part of the POV requirement to have a fully functional portal. In this case, the SQL provided to build the data model for the banking template was architecturally converted into web services definitions with the proper operations to the data layer, as part of the POV project scope. The following link provides the documented data model, which was converted into XML and then created as service interfaces:
These steps require the collaboration of a portal, service, and data architect.
Once your Portal sandbox environment is operational, (regardless of the cloud vendor or if you create a standalone virtual machine) and you have some stub data to play with, perform the following steps:
After the POV was done and its success was acknowledged, the next steps were laid out for the full-blown portal initiative to be kicked off. It was decided that while the banking template would speed up time to market on the self-service channel, the Web Experience Factory would allow for fast development of custom code for the center effort. Both of them would benefit from the advantages of using a cloud service and delivery model.
We hope we have given the reader the tools to look into the various possible adoptions of cloud computing in relation to portal initiatives. There are ways to look into the pain versus gain and cost benefit of such claim that "cloud computing can be viewed as a means of reducing cost, increasing revenue, improving business agility, and enhancing the total customer experience". Joe Weinman from www.cloudonomics.com coined the term "Cloudonomics" and laid out 10 laws and formulae to contextualize the value created by cloud computing. They could be used to look at your own portal and gauge the benefits of cloud computing.
To simplify, let's look at first five ones that made the business case for A2Z portal in the cloud, and how the ROI is measured against these items as follows:
Law no. 1 — Utility services cost less even though they cost more: The "Value of Utility in the Cloud" (simulation) enables assessment of different provisioning intervals and their resulting costs in light of the demand function." That means a good cloud estimation model can show hybrid, shared, dedicated cloud patterns, and the overall cost benefit of outsourcing your cloud to a provider versus creating and managing your own enterprise cloud. Besides, this can take into account how the pay-per-use model (as opposed to just on demand) can help us build a financial case.
Law No. 2 — On-demand trumps forecasting: "The ability to provision capacity rapidly means that any unexpected demand can be serviced, and the revenue associated with it captured. The ability to rapidly deprovision capacity means that companies don't need to pay good money for nonproductive assets". So, if the portal utilization growth rate is linear versus exponential, the value of the cloud utility exercise can help us define the capacity provisioning approach based on the estimated or known growth patterns.
Law No. 3 — The peak of the sum is never greater than the sum of the peaks: Under this strategy, the total capacity deployed is the sum of these individual peaks. However, as clouds can reallocate resources across many enterprises with different peak periods, a cloud needs to deploy less capacity. So, let's say that in the banking domain (unlike tax businesses are concerned about April 15th, a retailer with Black Friday, a broadcaster with Super Bowl) due to the dynamic nature of its business, A2Z Bank used the cloud to manage the sum of the peaks and the peak of the sum, as metal and bullion markets vary on a daily basis on the different world markets.
Law No. 4 — Aggregate demand is smoother than individual: These two laws (3 and 4) are related in that value of aggregation and the value of resource pooling for peaks. They point out that economies of scale can apply cloud to its problems.
Law No. 5 — Average unit costs are reduced by distributing fixed costs over more units of output: So in other words, A2Z Bank took into consideration demand patterns for both new bullion banking business and call center operations when deciding on the benefits of cloud computing for its enterprise portal solution.
Infrastructure as a Service (IaaS) can be highly beneficial to portal applications for server, networking, data center, storage functionality, and the scalability. These are foundational and business critical infrastructures, which require the most flexibility to stay operational within the expected service-level agreements. There are, however, other business drivers as follows:
Reduced capital expenditures and labor costs for portal and overall IT.
Fast provisioning and deprovisioning of services to be exposed or consumed by portal.
Elastic resource pooling as computing resources are pooled to serve multiple capabilities. It fosters dynamic allocation and entitlement of virtual and physical resources based on service-level agreements, as well as on changing demand.
Superior service management with visibility, control, and automation across IT and business services. One of the main portal challenges is around having this visibility around portal services.
A plethora of possible portal deployment choices over the cloud, behind the firewall or as an integrated service delivery platform make it even more appealing.
The fact of the matter is that portal is an entry point to content, data, information services; and its performance and availability directly depends on the availability of all the services associated to it. Furthermore, cloud computing as a technology paradigm is only viable because that technology offers many benefits to business organizations deploying business solutions as follows:
Reduced capital and licensing expenses portal efforts. They can be as much as 50 to 75 percent due to the on-demand provisioning of virtualized test resources via a test cloud.
Decreased portal operating and labor costs as much as 30 to 50 percent by automated provisioning and configuration of portal test environments. Portal application deployments and environment build-outs and configuration can be unique and prone to errors if not automated.
Improved quality by reducing defects that result from faulty portal configurations as much as 15 to 30 percent.
In this chapter, we covered the main phases of an initial portal evaluation. We looked at how a BVA can be done to uncover the value added by portal and how a road map for the entire enterprise can be one of the outputs of the BVA exercise. We looked at how a prototype can be started leveraging cloud using development images from either Amazon EC2 or IBM SmartCloud. We saw how patterns are built to expedite the prototype environment and kick off the portal effort. In this case, this fully functional environment would be leveraged for future development purposes. We also looked at high level, how Portal accelerators and toolbox assets can expedite the realization of value for an enterprise moving to the Portal paradigm. Remember that team work is always the best solution. These efforts are implemented with the collaboration of all stakeholders involved in a technology transformation effort and the support of IBM software, services, and other subject matter experts.