Practical Hyperion Financial Management Architecture Tips

on Tuesday, 01 January 2013. Posted in Solution & Business Architecture, Blog

One of the most popular products from the Hyperion suite is Hyperion Financial Management (HFM) used for financial consolidation, to implement Hyperion Financial Management this requires a Tier Configuration. This article shares experiences and architecture tips and tricks, to implement HFM.

HFM requires a tier configuration. The primary goal of N-Tier architectures is to stage the processing by the type of processing for the purposes of scaling the end-to-end solution by the type of processing and protecting corporate resources by the level of risk.  While protection of corporate resources is less critical for intranet applications, it still remains a driving factor in defining an N-Tier application environment.The Hyperion products follows two basic N-Tier architectures patterns.  One is centered on client delivery architecture and the other is a web-based architecture.  

The tiers for the client-based architectures are as follows:

1.             Application Client 2.             Web Server 3.             Application Server4.             Database Management Server staging_architecture

Figure 1:  Client Staging Pattern 

The web-based architecture, which is used for the majority of the Hyperion business functionality, has the following tiers

1.             Web Browser 2.             Web Server 3.             Application Server(s) 4.             Database Management Server

 web_staging_architecture

Figure 2:  Web Staging Pattern 

If one evaluates the risk of compromising any one of the tiers of the architecture, one will reach the conclusion that the most valuable attribute of the application is the data.  Confidently, N-Tier architectures strive to insulate the data repository from the user and hacker communities by strategically positioning the database as the last tier of the architecture.  If one works from the back of the architecture to the front, one will notice that the components of the architecture begin to be less important to the overall integrity of the system and more vulnerable (from a systems perspective) to the mistakes of users.   Fortunately, In most clients implementation it will be retained within the corporate intranet so the exposure to hackers is dramatically less but this will be increasing in the future with the announcement at Openworld 2010 of the “cloud” push.   There is one minor deviation to these design patterns.  The Hyperion Analyzer and Hyperion Reports require a second level of Application Servers.  In the case of Analyzer, most of the logic for building results sets resides in the HFM application tier.  Therefore Analyzer leverages this business logic, by connecting to the HFM application server to build custom views of the HFM data.  In addition, the Hyperion Reports application utilizes a print server to build defined reports in PDF format. 

All locations that use Hyperion Financial Management Retrieve where performance is an issue should have the ability to use Hyperion Analyzer for ad-hoc reporting, to minimize performance load.

Scaling Strategy

The advantage of N-Tier architectures is that the architect may add resources at each tier to relieve bottlenecks in system performance.  Because there are numerous tiers, there are numerous scaling strategies that target each tier.  In general, there are three basic scaling strategies:

 1.             Horizontal Scaling – add or remove computers at the tier under analysis in order to size the tier according to the expected or measured workload.

2.             Vertical Scaling – add or remove computer power at the tier under analysis in order to size the tier according to the expected or measured workload.  Some of the items that are sized according to vertical scaling strategies include:

a.     Disk Storage

b.    CPU power

c.     Memory Capacity

d.    Network Capacity

3.             Workload Distribution Scaling Strategy – The allocation of system resources to handle different workloads on separate resources.  In this strategy, more system resources are allocated to higher priority tasks in order to enforce a priority for processing system requests.a.     Horizontal Scaling Strategyb.    Vertical Scaling Strategyc.     Load Distribution Scaling Strategy While the process of evaluating the scaling requirements is usually covered in your performance documentation, the ability to scale at each tier is an architectural capability.  In addition, the scaling capabilities are dictated by the applications with some level of discretion given to the deployment architect.  The scaling strategy for most Hyperion clients, web, application, database, and database storage tiers are as follows.

Client Tier Scaling Strategy

The client tier is unique in respect to scaling because it is not a shared resource, but there are many of them.  The uniqueness is centered on the fact that the client application resources are not coordinated among other clients that may be running.  A client system must be singly capable of performing to the expectations of the user that it serves.  As a result, the strategy for scaling at the client tier is considered vertical.  The computing power of the client desktop must be sufficient to run the client applications whether they are Hyperion, EBS, or Citrix clients. It is recommended to create a Desktop Configuration document covering the minimum requirements for the desktop.

Web Tier Scaling Strategy

The responsibility of the web tier is to respond to web based requests.  There are two general types of requests that may be requested of a web server and that is a request for a static web page or a request for a dynamic web page.  Static web pages are documents and require no computational resources to build the document at the time of the request.  A dynamic web page requires some type of computation such as formula calculations or database queries in order to build the response for the server request. Requests for static web pages are served from the web cache or from the disk while requests for dynamic web pages are passed back to the application tier.   The workload characteristics of this tier are memory and network intensive.  In the cases when encryption is used, the workload becomes more CPU intensive.  This type of workload works well with single CPU servers with a large amount of RAM.  In the cases where encryption is used, it is useful to add another CPU to the server.  When the server is scaled up or down, the preferred scaling strategy is horizontal.  Therefore, in HFM’s case consolidation systems will make use of horizontal scaling at the web tier.   Another tip with Hyperion products you should leverage load distribution scaling at the web tier by using two web tier strategies.  Would recommend HFM application workloads at the web tier to be handled by two load balanced IIS Web Servers running on two separate servers.  Web requests for Hyperion Analyzer or Hyperion Reports recommend be handled by two load balanced, HTTP Web Servers that are running on the application servers in my experiences allocated from Oracle Weblogic. Horizontal scaling in both cases are enabled through the user of a set of hardware load balancers.    There are two primary reasons for using workload distribution scaling at the web tier;

  1. The Analyzer and Reports processing is considered to be secondary to the core HFM processing. Therefore, the traffic generated by Analyzer and Reports should have a minimal impact on resources reserved for consolidation applications
  2. In most cases clients, usually prefer the choice of hardware load balancing to software load balancing for the Weblogic Application Server.  As a result of this business decision, a matter of architectural simplification dictates that the web and application tiers are collapsed onto the same servers.  Therefore, web traffic destined for Reports or Analyzer applications are balanced over two application servers that are also running the  HTTP server to service web traffic.  In my last implementation we used hardware load balancers to distribute web-based requests over the WebLogic servers. 

 In most clients web configuration, the workload characteristics of the HFM traffic is expected to be light and the Reports and Analyzer traffic is expected to be even less.  If HFM traffic increases to a point to require scaling the web tier up then adding more web servers is possible.  Scaling the web tier down (below two HFM web servers) is not recommended due to failover requirements.   The web traffic associated with the Reports and Analyzer applications is expected to be low in comparison to the workload associated with the application server that is running on the same server.  It is expected that scaling the Reports and Analyzer application servers (WebLogic) up will be due to the application server requirements, but the web server tier will benefit from any scaling requirements for the WebSphere application server.  It is not recommended to scale HTTP Web servers down below two servers due to the failover requirements. 

Last point, HFM provides mission critical data that should be available to users 24x7x365.  Since this system generates reports for both internal management and external legal and regulatory bodies. Add a buffer because it is a a web based application. (Add 15-25%)company due to the global nature of your architecture and apply a factor to take into effect different global internet connection speeds.

 

 

Comments (2)

  • Rene Engle

    Rene Engle

    02 May 2013 at 23:11 |
    Could not have said it better myself
  • Frank Castillo

    Frank Castillo

    13 June 2013 at 12:52 |
    Couldn't have said it more positively myself

Copyright 2015 Appsconsultant.com. All rights reserved.