Solution & Business Architecture

Integration to Fusion Accouning Hub from your EBS or PeopleSoft Ledger (Co-Existence Strategy)

on Tuesday, 02 February 2016. Posted in Solution & Business Architecture, Blog, Oracle Financial Applications

Integration to Fusion Accouning Hub from your EBS or PeopleSoft Ledger (Co-Existence Strategy)

















Co-existence approach implies that a customer is not upgrading but they will keep adding Fusion Application solutions (see diagram about Fusion Topology). In that case customers will always look for opportunities that Fusion brings that address their critical needs while minimizing the risk to their current Applications investment. This is the focus of the co-existence adoption model.

A question that has been coming often lately is about integrating multiple non Oracle financial systems to fusion accounting hub. Below is a visual architecture example How to implement Fusion Accounting Hub by utilizing your current as is systems - multiple sources with different formats and loading it with SQL Loader. into FAH. The main advantage of this approach is that you can continue using your E-Business Suite or PeopleSoft applications for your procurement, supply chain, payables, receivables without disruptions.


Below is an example of an integration with multiple inputs:






















Sharing OBI Best Practices - July 2014 SIG (Special interest group) sessions

on Friday, 01 August 2014. Posted in Solution & Business Architecture

Sharing OBI Best Practices - July 2014 SIG (Special interest group) sessions

Last three weeks have been working/sharing with different EMEA and US clients, this included other Oracle Aces on the topic of Oracle Business Intelligence. Below is a quick recap of 3 best practices, every customer should follow unfortunately it seems still today not everyone is following:

1)On the metadata – presentation layer,  seemed a rampant issue within the the sessions, lots of companies still use too many columns in their tables. Follow the Rule of 9; Tables should be organized to show nine or less columns per level.

2) To make the dashboards more effective – Use visualization a picture is worth 1000 words, don't forget the human brain processes pictures better than words.

3) Be highly selective in determining which metrics make it on your dashboard. Ask yourself how your metrics dashboard, connect to the bottom line. Does everyone understand the metrics that matter? An example within these sessions we had employees working for the same company that had different definitions on the same metric.

On the Oracle Knowledge Management site, search for 1455806.1, a must read presentation for any client invested on the Oracle Business Intelligence products.




7 Tips to Improve your Project Solution Architecture Outcome

on Wednesday, 23 October 2013. Posted in Enterprise Software , Solution & Business Architecture, Blog

7 Tips to Improve your Project Solution Architecture Outcome

The goal of architecture is to identify the requirements that affect the structure of the application and design a business solution.

 A well thought-out architecture should always consider these important principles:

   Build to change instead of build to last

   Understand the end user needs and the domain before designing components

   Identify sub-systems in your product and consider layers and components to abstract them and identify the key interfaces

   Use an incremental and iterative approach to designing the architecture

   Learn from company history, document your decisions and identify and mitigate key risks

But as we all know: every organization has its share of political drama: personalities clash, diverging agendas. Having worked at many companies here are some thoughts and tips to avoid architecture delays or having your project stopped:

 *** Communicate like you are a Teacher, not a Preacher

 A general assumption, architects are supposed to share their knowledge and experience. Failing to share that information is pretty much against the job description. But how you communicate that experience is the most important part of the job.  Think of your best teachers in school—did they ever go in front of the classroom and tell you how smart they were?  I don’t think so.  They found subtle ways to express their knowledge that encouraged learning and asking questions.

 Tip #1 that I often use , I start my sentences with ‘I think’ this will open discussion items and questions and encourage a two-way discussion.

 Tip #2 Architects are usually quite smart and have a breadth of knowledge but the tone, quality and delivery of the Information is more important than the content, try to always communicate like a teacher .


*** Standards apply to Architects, Developers and COE (Center of Excellence)– Don’t take the easy path take the smart path

 Enterprise architects put together standards documents that lay out , architecture patterns, coding conventions, infrastructure, source code nomenclature, and build structures.  But to publish those standardsand fail to hold yourself to them is the highest form of hypocrisy.  If you can’t follow a standard, why would you expect anyoneelse to follow it too?

An example, a company wanted to perform a point (system)to point (system) development, in this case standards existed to use web services with these systems, the development team took a quick decision and coded the point to point development and satisfied the business requirement. The director of the COE (Center of Excellence) did not realize an impact existed onto a surrounding system , the issue caused a security and reconciliation issue. In this case the cost to fix the data & interface was 4 times the initial budget.

 Tip #3 : By applying the standards to your work, you’re respecting the standards of the organization; you also see what will be painful for other groups. Respect your standards and reduce the power politics within your organization.

Tip #4 : Always try to eliminate 'it’s not my job” attitudes at your workplace, especially when you have the role of the architect.


***Command from the dugouts, not from the Ivory Tower

Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved.  Instead, these segregated groups architecture and development teams have generated one or more of the following:

 *        Contempt for the architecture because the developers had no say in

the architecture

*        Rejection of the framework because it was impractical to apply to

the project at hand

*        Blatant disregard for the standards set by architects because the architects did not have to respect company deadlines as a result of the delays introduced by their work

 Tip # 5: Architects should be a member of the project team, never as a visiting diplomat to the team.  Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments.

  *** Architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be an architect

 An example, when a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture.  All the while, the architect assists in solving problems that arise from his or her design from a practical standpoint, same as any enterprise software deployment

 In short, the architect’s involvement is continuous, not disconnected.

 Tip #6 : Make sure the architect is involved in the design, build and deployment phase.



Tip #7 : Always begin your intervention with a contextual diagram and perform a walk through with the team, don’t write too much text it may cause confusion at the beginning. Developers and implementers interact better with diagrams.

 For architecture projects to succeed there must be a partnership of developers,implementers and architects. Successful partnerships require two way communication and trust, none of which happens when someone acts like God’s gift to mankind, insists on his way or the highway and doesn’t actively get his hands dirty.

Feel free to share your tips , comments and thoughts.



Business architecture always adapt to your audience - 4 tips

on Thursday, 22 August 2013. Posted in Business Analysis, Solution & Business Architecture, Blog

Business architecture always adapt to your audience - 4 tips


Always make a point to understand your audience, audience analysis involves identifying the audience and adapting a speech to their interests, level of understanding, attitudes, and beliefs. Taking an audience-centered approach is important because your material effectiveness will be improved if the deliverable is created and delivered in an appropriate manner.

I have seen many times technical people speaking to the business and not talking at the right level and emphasizing technical information like security, protocols and interfaces. An example application A will push the actuals to application B (good) instead of saying Application A attributes are connecting to table AR_Actuals and the trigger releases the information into Application B table GL_Open_balances. 

Depending on your audience adapt your architecture diagrams accordingly.

In my view, here is a sample architecture of a business architecture diagram that will connect with business savvy people to initiate architecture discussions. here are my tips:

  1. A Business Architecture must be process centric
  2. Be able to apply enterprise-wide architecture and process-level models and techniques that are aligned to your roadmap
  3. Develop a measurable architecture for planning, budgeting, organization design, compliance, human change management, and the introduction of breakthrough technologies
  4. Be able to use an architecture model to accelerate capability change projects and model development


 Do you have any favorite tips or would like to share your experience on this topic?

The Biggest Problem in Corporations - Data Proliferation, 3 tips to tackle this issue

on Friday, 14 June 2013. Posted in Solution & Business Architecture

The Biggest Problem in Corporations - Data Proliferation, 3 tips to tackle this issue
Data is impacted by numerous processes, most of which affect its quality to a certain degree. As data proliferation in the enterprise continues its exponential expansion and the size, complexity, and heterogeneous nature of IT systems environments scales to keep up, data quality and trust become increasingly important. Trusted data initiatives will remain strategic.

The business drivers that are pushing (Master Data Management) MDM:

•   Runaway costs that include bad data

•   Missed opportunities mostly from lack of transparency from the business pipeline

•   With the potential jail time to corporate officer’s regulatory compliance, security and sensitive data will continue the push towards a standardized view of critical data.

•   Integrating new businesses as M&A continues, consolidating corporate data from multiple acquisitions.

2014-16 will be great years for MDM, I think standards and the trustworthy view of critical data will be propagated and included in the processes of most businesses. I think we will soon reach a meeting point between MDM and Big Data, as we know big data comes in many forms: some is structured, some unstructured; some is generated internally, some externally. The current MDM solutions are know being built with internal and some external integration points.

When selecting an MDM technology I would recommend use the Gartner or Forrester reports, and in my opinion I would only spend time looking the top right quadrant.

Some companies are naïve when it comes to choosing MDM technologies, wrongly assuming that the market is mature and that everything works fine these days. In my view, this is wrong it will take another 3-5 years for this area to mature.

Below is the year over year Gartner Magic quadrant on MDM

MDM 2012-2013 Gartner Comparison

Three tips

  1. Shortlist your suppliers and make sure they have a track record with your type of data
  2. MDM projects are always tricky, follow a think big start small approach. The approach should consider all data domains, but take a gradual, step-wise approach to implementation, delivering incremental business value
  3. In 2014,I think companies will be moving toward an Enterprise App Store similar to Google and Apple store and this will oblige companies to accelerate their efforts on MDM.(look into creating an enterprise app store)

One of the big accomplishments of these technologies, analysis of data has become a key differentiator within many industries.

Like usual please share your thoughts on MDM, Big data and the Enterprise App Stores trends

Architecture for the cloud; Tips to build and deploy your cloud based applications

on Friday, 12 April 2013. Posted in Enterprise Software , Featured, Solution & Business Architecture, Enterprise Architecture

Architecture for the cloud; Tips to build and deploy your cloud based applications

The cloud and cloud-based solutions are here to stay. This will continue to drive business solutions for a long time. Why? Clear and measurable benefits below i believe are the top 4 reasons :

1- Almost zero upfront infrastructure investment

2- Just-in-time Infrastructure

3- More efficient resource utilization

4- The possibility of usage-based costing on your back office applications

Cloud is a disruptive force. However, the cloud’s “Achilles heel” is a lack of integration with the rest of the enterprise. Realizing its full potential relies, for the foreseeable future, on integrating data in the cloud with on-premise applications and databases.

Today’s enterprise cloud initiatives require decoupled data systems working together , without the need for personnel and other resources to set up and maintain them , making integration key to a successful deployment.

Most companies cannot and will not abandon their previous IT investments to make the leap to the cloud all at once. Instead, there is more likely to be a gradual shift in business processes to the cloud over time, similar by nature to a perpetual proof of concept.

As the cloud delivers on its promise, more processes will be shifted to this computing model. Complexity and diminished ROI will be the consequence when long-term strategy and goals are not implemented in advance. Put simply: integration needs to be a forefront, not on the afterthought of your project strategy.

Always design for failure, be a pessimist when designing architectures in the cloud; assume things will fail. In other words, always design, implement and deploy for automated recovery from failure.

In particular, assume that your hardware will fail. Assume that outages will occur. Assume that some disaster will strike your application. Assume that you will be slammed with more than the expected number of requests per second some day. Assume that with time your application software will fail too. By being a pessimist, you end up thinking about recovery strategies during design time, which helps in designing an overall system better.

If you realize that things fail over time and incorporate that thinking into your architecture, build mechanisms to handle that failure before disaster strikes to deal with a scalable infrastructure, you will end up creating a fault-tolerant architecture that is optimized for the cloud.

Questions that you need to ask: What happens if a node in your system fails? How do you recognize that failure? How do I replace that node? What kind of scenarios do I have to plan for? What are my single points of failure? If a load balancer is sitting in front of an array of application servers, what if that load balancer fails? If there are master and slaves in your architecture, what if the master node fails? How does the failover occur and how is a new slave instantiated and brought into sync with the master?

Just like designing for hardware failure, you have to also design for software failure.

Below is a baseline to help you consider all the moving parts required to build and deploy your cloud based applications.


Lastly build process threads that resume on reboot and good cloud architecture should not be impacted to reboots and re-launches.

Like it or not, the cloud is a disruptive force, that i think will require us to move towards a more data centric business model.

Like usual, please share your thoughts and experiences

Oracle Global Architecture

on Tuesday, 01 January 2013. Posted in Solution & Business Architecture, General - Misc. Tips

A powerful force drives the world towards a converging commonality, and that force is technology. It has proletarianized communication, transport and travel. It has made isolated places and impoverished peoples eager for modernity’s allurements. Almost everyone everywhere wants all the things they have heard about, seen, or experienced via the new technologies.

The result is a new commercial reality – the emergence of global markets for standardized consumer products on a previously unimagined scale of magnitude. Corporations geared to this new reality will benefit from enormous economies of scale in production, distribution, marketing, and management. By translating these benefits into reduced world prices. That is good for everyone.

Companies are now forced by globalization aspect to innovate and get to the market faster and to plan, define and support their products at a very quick pace.

I will be sending to all registered members a presentation that I did in San Francisco on the possibility of merging the oracle applications towards a global architecture and a Visio on the intricacies between modules.

Service Oriented Architecture (SOA)

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

SOA will dramatically change our working environments. Oracle SOA suite is the beginning of standards-based applications that are secured, managed and governed , and are spawned

by changes like Mergers & Acquisitions, regulatory compliance, and increased competition.  

With this in mind, we introduce the concept of a Service Oriented Architecture (SOA).


What is SOA it is a design blueprint for applications within an enterprise.


Corporations will adopt SOA, to increase their business agility, for faster response changes, increased technology asset reuse, reduced integration expenses, reduced business risk & exposure

The ability of SOA to change, evolve, and manage business processes throughout an

enterprise is changing the way IT works. SOA is enabling IT to operate as a

business unit. Alignment and accounting for IT investments is now based on business

strategies and transactions. SOA in an enterprise will identify and highlight

business dependencies and encourages cooperation and communication between

business units and IT.


SOA uses Services. Corporate applications evolve into organized collections of what are

referred to as “business services”. Looking at these applications from a service

orientation perspective closely maps to business initiatives and processes. So a

service can be payroll, or extending credit, or adding a new customer—it’s no longer

only a technical transactional process.

A well architected SOA provides top to bottom management visibilityof existing web services, so one doesn’t go on a “scavenger hunt” for any given

application. A SOA provides for a more rapid method of distributing applications and

increased agility. By leveraging, and the reuse of existing enterprise software,

infrastructure, and networking/bandwidth, the costs of custom integration and

interoperability are lowered. Manual tasks are reduced or eliminated. Compliance

within an organization’s industry is accomplished by exposing business

processes and reducing risks. For even greater cost savings, these

business services are reusable for many different applications both within and outside

of the enterprise without costly changes.

Most corporations have started to plan and implement a SOA adoption.

SOA Architecture Strategy

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

Use industry best practices any new integration solution should be designed using SOA and principles.




  • Create services to represent business processes not API’s or methods.
  • Provide visibility to web services through a published web service catalog.
  • Modularize services by functionality, maintaining independence and therefore flexibility.
  • Use schema standards such as Open Applications Group (OAG) and design patterns to ensure technology agnosticism.
  • Divide processes into atomic single purpose independent services.
  • Ensure loose-coupling of systems by separating system specific translations and functions from generic business process services.
  • Utilize tools that readily enable SOA: WebLogic Integration (WLI) in conjunction with an Enterprise Service Bus (ESB).

Security Architecture Approach

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

 Please note I have been lately putting my latest blogs in a picture format mostly because my content has been copied onto other websites without my consent.


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


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.



What is the Architecture Requirements & Strategy deliverable

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

What is the Architecture Requirements & Strategy deliverable

The applications architecture strategy consists of:the proposed applications architecture,

  • a comparison of the proposed architecture to the current environment.
  •  The applications architecture partitions the proposed business applications environment into separate applications areas. These applications areas are selected to align to the customer's business processes and to support all customer organizational units.

The main purpose of the Architecture Requirements and Strategy deliverable is to provide a reference at any time for resources working on tasks within the Application and Technical Architecture process in support of the enterprise project. 

This document is the source for the application and technical architecture requirements, strategy, approaches, direction, risks, benefits, and assumptions. The document alsocovers the delivery of project and support services to assist the company in the completion of the project.  All members of the team should understand and follow the same strategy. 

The document describes the key requirements that will underpin the design of information systems architecture. The requirements are a major input into downstream activities within the Applications and Technical Architecture process and will help to identify high-level specifications for the company’s business information systems.

On a practical level, the requirements will have a continuing influence on the scope and content of the architecture design work throughout the project life; therefore, it is important that the list is as complete as possible and agreed on early during the project. The architecture team will need to keep these requirements in mind throughout the project and help create architecture that is compatible with them.  Furthermore, if the architecture requirements alter mid-project, the changes should be noted and disseminated in a timely manner.

This document will be distributed to all architecture team members at the process kickoff meeting.  Subsequent changes to the architecture scope will be communicated universally before implementation of these changes begins. 

The project manager uses this document to understand how the architecture team plans to conduct the architecture work, and how the architecture effort may impact the overall project.



The Logging and Reporting Architecture Design

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


The Logging and Reporting Architecture Design is the design specifications for the logging, monitoring, and reporting infrastructure

Below is my checklist that I use for my logging and reporting architecture design of the solution architecture

  Understand the client’s current logging and reporting architecture.

·          Interview the security manager and system administrators to determine what logging and monitoring is currently in place.

·          Review current capabilities by examining network diagrams and infrastructure components in the Technical Infrastructure Assessment and Technical Infrastructure Requirements or by touring the site.

·          Document all critical servers, including network appliances, routers, switches, and intrusion detection systems, where logging should be enabled. Pay particular attention to critical, externally accessible devices and servers.

2.       Develop the business management requirements for logging and reporting.

·          Interview the project sponsor or the CIO to determine the business goals of the project.

·          From these interviews, determine what servers and infrastructure devices are critical to operations.

3.       Interview user groups to determine their logging and reporting requirements, such as bandwidth, performance, reliability, scalability, security, and performance. User groups include telecommunications, applications, network, human resources, accounting, internal audit, and legal.

4.       Define system capabilities, dependencies, and assumptions based on the management and user requirements. Use the Security Web Sites tool to include security-related web sites in your research.

5.       Develop the system operating environment for the logging and reporting architecture.

·          Document the operational policies, operational constraints, existing operational environment, existing support environment, and constraints on design and implementation.

·          Verify that attempts to modify this information are logged and trigger an alarm that shows source and destination IP addresses, protocol type, time and date, data (size and packet details), and activity. Keep records for 1 year unless otherwise instructed by legal counsel.

·          Verify that these events trigger alerts: unauthorized scanning or probing of networks, malicious code presence, unauthorized attempts to access services (whether in use or not), changes to files without change request approval, large increase of traffic, loss of connection to any of the servers within the production environment, and loss of connectivity.

·          Review the architecture with the security manager or system administrator who will have ownership of the reporting system.

6.       Document the system users, including personnel profiles, organizational structure, personnel interaction, personnel activities, and documentation. This information is required for selecting triggers and alerts.

7.       Work with the project manager, security manager, and system administrators to document the process flow for the logging and reporting infrastructure.

·          Define the processes.

 ·          Create process models to illustrate the flow and sequence of operations; for example, a Visio diagram showing servers that have logs, how the logs are transferred to the central server, and how the reporting server transmits alerts and notifications.

8.       Document the system definitions for the logging and reporting architecture.

·          Include operation modes and states of the architecture, the system functions and their relationships, and configuration allocation for hardware, software, facilities, and system interfaces.

·          See vendor hardware and software data to understand the implications of client requirements.

9.       Meet with the client to determine the performance requirements of the logging and reporting architecture, such as physical locations, constraints, hardware and software performance, support requirements, safety requirements, the size of the log files, and the frequency of log traffic.

10.   Develop quality assurance plans for the design.

·          Develop requirements for the testing environment that will be used to verify the design requirements and constraints. Include a network diagram of any testing equipment you will use.

·          Document the configuration of your testing environment with an example of each type of log or report, such as checkpoint firewall logs, UNIX syslogs, router and switch logs, and Windows event logs. Describe the architecture of each central logging server that will be used.

·          Document the results of your tests. List each criterion and develop a test to confirm it. For example, validate that each device can communicate with the central logging server, validate that the logging server can receive traffic, and ensure that the logging server can communicate to a reporting server or a third-party monitoring system.


ZOO Comment

Copyright 2018 All rights reserved.