Best IT Blog

Sample – Application Maintenance and Project Support Methodology

Posted in Application (380),Projects (400),Security (1500) by Guest on the June 30th, 2013

“Managed Service Provider” provides maintenance services for its clients Application Systems that cover a wide range of technologies and businesses, and are typically critical to a client’s business. Our consultants take a proactive approach to Application System maintenance, by focusing on long-term functionality, stability and preventive maintenance to avoid problems that typically arise from incomplete or short-term solutions. This approach, coupled with our quality processes, allows our clients to continually reduce recurring maintenance costs. While we perform most of the Application System maintenance work using secure and redundant communication links to our client’s systems, we also maintain a team at the client’s facility to coordinate certain key interface and support functions. 

We believe that a matured support plan would lay the foundation for an effective application maintenance and development support framework for our clients. 

Project Initiation Phase

  • To define the scope of work for onsite/ offshore
  • To translate client’s objectives into detailed SLAs, procedures and guidelines
  • To develop connectivity and infrastructure plan 

Knowledge Transfer Phase

  • To understand client’s business and technical environment
  • To understand systems to be maintained and supported
  • To draw up detailed plan for maintenance and support

Knowledge Acquisition 

Activity Description
Business Overview
  • Team will get to know the Top level functionality
  • Main Processes will be discussed during this phase
Technical Overview  
  • Team will get an understanding on Technical Architecture
  • Development Environment will be discussed
  • Team will understand the History of maintenance and problem logs
  • Standards, Testing and Acceptance procedures will be looked upon
Analyze existing system metrics  Team will analyze the existing metrics. Following are some of the metrics which will be analyzed during this phase:

  • Number of programs
  • Program performance
  • Present and planned support base
Planning  Once the above phases are completed, the team will plan for the following:

  • Maintenance Plan
  • Finalize Team
  • Structure (Onsite/Offshore/Offsite)
  • Fine tune team size
Connectivity  After the teams are finalized and the plans are made, following activity takes part:

  • Finalize Connectivity requirements
  • Establish connectivity from Offshore/Offsite
Finalize Service Levels  Service levels are discussed based on the historical data and the commitment from “Managed Service Provider”:

  • Quality metrics
  • Productivity metrics
  • Maintenance metrics
 Interaction with external teams  Once the service levels are finalized, the team will have interactions with the following team:

  • Operations council
  • Database Administrators
  • Change Control Board
  • Third Party Vendors


Comments Off on Sample – Application Maintenance and Project Support Methodology

Welcome to Weblog

Posted in O S (375) by Guest on the June 27th, 2013

Why did we build this site, why did I we start this blog?

Because in our years of IT experience we found that consulting companies think they have all the answers. The truth is they don’t even know all of the questions for most organizations.

You found us because you were looking for information in an effort to fast track your projects or simplify your job. Since 2007 we have tried to provide the best most relevant information we can on the subjects below.

We focus on, among other things on:

IT Architecture,

Business – Strategies,

Change – Management,

Data-Center Procurement,

IT Services, Help-Desk,

Application – Assessments,

Data – Overview,

Data Demographic Assessments,

Identity and Access Management (IAM) – Role Based Access Controls (RBAC),

Roles – and – Responsibilities,




IDS – Services,

Incident – Response,


IT Methodology,


OS Security,

Project Management,

RFI, Risk – Management,

RMD – Policy – Procedure,

Testing, Web – Services

See our supportive technology templates at: for remediating of these technology solutions. 

Always verify the accuracy, completeness of the information on this site before you use it.


Comments Off on Welcome to Weblog

Comparison between Mindmap and Microsoft Visio

Posted in Visio Samples - Stencils (457) by Guest on the June 25th, 2013

Hands down Microsoft Visio…..

Many more features to Visio just all around a better product. In addition we have tried to contact Mindmand for support and partnerships and they don’t even bother to respond.

Not that Microsoft responds to our inquiries either but at least the products work far better.

We are going to post the remainder of the Mindmap files we have and stop building document solutions for Mindmap.


Comments Off on Comparison between Mindmap and Microsoft Visio

Enabling – Oracle Audit Configuration for Security Audit Trails

Posted in Application (380),Security (1500) by Guest on the June 22nd, 2013

Make sure you have enough disk space to support the storage of the event logs and make sure you have a process or strategy for log rotation / retention.

The purpose of this document is to define the specific Oracle parameters required to capture the desired Oracle database events to the SYS.AUD$ table on test database residing on host “Host-Name”. 

The audit parameters specified below are recommended in general to enable auditing. 

  • Modification of users accounts on Oracle (create and delete accounts)
  • Access granted and denied for Oracle database and its tables
  • Configuration changes on the Oracle database objects
  • Users accessing database directly rather than through an application 

Oracle User Permissions

When the Oracle Recorder was installed on “Host-Name”, an Oracle user account was specified.  This is the account that the Oracle Recorder uses to access the records in the SYS.AUD$ table.  The account must have the required permissions to access this table. 

The following command is used to set the required Oracle UserID permissions: 

    • (and for Oracle 9.x – 11g SELECT ANY  DICTIONARY)

Activate Oracle Audit Trail

To activate audit trail, enter the following command in the Initialization Parameter File, $ORACLE_HOME/dbs/init”Database-Name”.ora, and restart the Oracle instance: 

audit_trail = DB 

To restart the Oracle instance, enter: 

SVRMGR> shutdown abort;

SVRMGR> startup;  

Configure Oracle to Audit Connections

In order generate the Oracle audit events to identify users connecting to the database directly rather than through an authorized application, it is necessary to audit for successful or unsuccessful connections and disconnections. 

To set audit for events of successful or unsuccessful connections and disconnections, enter: 


Configure Oracle to Audit Database Object Access and Modification

In order to generate Oracle audit events for database objects, enter the following command to set the relevant audit parameters. 


These Oracle audit parameters will generate the events to support the following test cases: 

  • Access granted and denied for Oracle database and its tables
  • Configuration changes on the Oracle database objects
  • Modification of users accounts on Oracle (create and delete accounts)


Comments Off on Enabling – Oracle Audit Configuration for Security Audit Trails

Sample Visio – Simple IT Infrastructure

Posted in Visio Samples - Stencils (457) by Guest on the June 18th, 2013
Comments Off on Sample Visio – Simple IT Infrastructure

Network Security Scan Types and Considerations

Network Scan Types and Scope
This network scanning recommendations defines network scan types, identifies reasons for scanning, identifies times when network scanning is allowed, who should approve network scanning, and specifies who should be notified when network scanning is done.

Network device location scan – This scan may use different means to determine IP addresses of active devices on the network. Methods:

ARP Scan – An ARP broadcast can be sent to network IP addresses asking what is are the responses

MAC address of the host with IP address x.x.x.x. If a response occurs, there is an active host at that address.

Internal full port scan – Checks to determine what services are running on each host. This may be done against selected hosts or all hosts including servers and workstations.


Socket connect scan – Tries to complete a socket connection to a port on a host computer.

This scan allows the host computer to log the connection.

SYN scan – Sends a SYN packet to the host indicating that it wants to open a socket. But when the host responds it does not finishing establishing the connection.

FIN scan – Sends a FIN packet to a host port. If a service is not running, the port responds with a reset signal. If the port has a service running on it, the signal is ignored.

External full port scan – Checks to determine what services are running on each host. This test is done from outside the firewall and is directed toward any IP addresses owned by the organization being tested. It may use the socket connect scan method, the SYN scan method, or the FIN scan method.

Internal vulnerability scan – Tests the server to see if it is vulnerable to known flaws in the operating system, services, and applications that are running. This test may be directed toward one or more hosts including servers and workstations. This test goes beyond performing a full port scan. It attempts to get information about the operating system and services running on the host. It will attempt to determine the version of the services running on the host. and may even do a penetration test.

External vulnerability scan – Same as the internal vulnerability scan except it is done from outside the organization network and is directed toward any IP addresses owned by the organization being tested.

Internal Denial of service scan – This is a scan using packets which are intentionally designed to make a system crash or tie up resources. The scan is directed against ports but the data sent is usually misconfigured in some unusual way.

External denial of service scan – Similar to the internal denial of service scan except it is directed against IP addresses owned by the organization being tested.

Password Cracking – This test may send default passwords and brute force password guessing against accounts on specified systems. This is really not like a network scan but is covered in this recommendation since it could potentially disrupt service depending on the password policies of the organization. 

Many scanning services will offer some combinations of these types of scans. This recommendation covers all types of network and host scanning.

Network Scanning Reasons

Network scanning may be performed for several reasons

To determine whether computer systems are vulnerable to attack and fix them.

To show companies you may interact with that our servers are reasonably secure.

To fulfill regulatory requirements.

Network scanning shall not be performed without written permission.

Network Scanning Disruptions
Network scanning can be very disruptive to both a network and hosts that are operating on a network. No network scanning shall be allowed without close adherence to this recommendation and the associated procedures. Network scanning can cause systems to crash and network devices to become unreliable which can become very disruptive to the business operations.

Comments Off on Network Security Scan Types and Considerations

Sample Visio – Sample Project Delivery Flow

Posted in Projects (400),Visio Samples - Stencils (457) by Guest on the June 12th, 2013
Comments Off on Sample Visio – Sample Project Delivery Flow

Service Oriented Architecture

Posted in Application (380) by Guest on the June 11th, 2013

Enterprise IT infrastructure today consists of what are generally referred to as “silos”, or “stovepipes”. An effective approach to achieving integration and enabling the rapid development of new business offerings is to interpose a “services tier” between client devices and back-end resources. Through this approach, back-end resource functionality is made available via well-defined, network-callable components. These components can make back-end functionality readily available to clients, but unlike the silo approach, provide building blocks for combining simple services into fully featured, value-added services.

The service-oriented architecture (SOA) establishes a standard middle-tier platform across the enterprise that allows for easy discovery and integration of information resources. Services-oriented architecture involves standardizing middle-tier interface technology such that once implemented, a middle-tier component is available for use by other middle-tier components without complex message reformatting and protocol conversions. Such standardization transforms the middle-tier from being a collection of silos and elevates it instead to being an enterprise-wide services tier. 
The rationale for choosing the SOA architectural style can be summarized as follows:

  • It embodies best practices for the technology to be used
  • It satisfies short- and long-term architectural needs
  • It reduces risks associated with ambiguous specifications and rediscovery of standard patterns
  • It makes divide-and-conquer approach in the evolution of existing systems practical
  • It provides the foundation for integration between various enterprise services

The important consequences of adoption of that architectural style are the following:

  • It is the interaction of services and assembly of components that creates “applications” and “systems” as opposed to a singular monolithic application.
  • Distribution and scalability is built-in and not an afterthought.

Attributes of Service Oriented Architecture
A service-oriented architecture is an architectural style that emphasizes functionality built using standard component-container technologies.

Conceptually, the service-oriented architecture is unified yet it is not monolithic, that is, it is a collection of coarse grained, loosely coupled business services and has the following important characteristics:

  • Service-based – Not Just Code-Based: The unit of re-use should emphasize reusable generic service functionality, be readily available, deployed as components across the enterprise and capable of being centrally managed and controlled to achieve the desired quality-of-service (QOS) levels.
  • Assembled – Not Built: Using services as building blocks, systems should be formed, to the extent that it is possible, by assembling existing services, not by starting from scratch. Some of the parts may even be provided by resources from outside the corporate boundaries. Assembly should be rapid and efficient, not a costly process of custom integration. This however does not preclude from building the service blocks from beginning if it makes business sense to do so.
  • Physically Distributed: It should be possible to distribute processing across multiple physical network devices. This allows spikes in demand to be met using horizontal scaling techniques.
  • Quality of Service (QoS) Driven: The services framework must be implemented in a manner which takes into account management, security and other systemic qualities.
  • Implemented in Layers: Layering maximizes the independence of processing components from their underlying platform implementations.

Layers provide a way for logical organization of components in the system from the point of view of their technical – rather than business-related – functions.  In a layered organization of a system, the emphasis is placed on the following:

  • Reduction of interactions between layers – the typical rule is that a given layer interacts only with its immediate neighbors.
  • Reduction of dependencies between layers – a given layer is ideally directly dependent upon a single layer that provides services to it.
  • In addition to providing a clean logical decomposition of the system (in addition to components), layering reduces impact of changes or replacement of frameworks used to construct a given layer.
  • Functionally isolated: Functionality should be partitioned according to logical function, enabling services to evolve independently of one another in response to ever-changing requirements without impacting other services.  

Components and System Decomposition
The main building block of the SOA is a software component or service. Software components are units of composition with contractually specified interfaces and explicit context dependencies. A component has the following attributes:

  • It provides services using well-defined interfaces, ports and protocols

It encapsulates state and behavior 
It depends only on a component framework or operating system to be started up and to communicate with other components

  • It can be constructed, tested, and deployed independently of other components

In general, there are two types of components:

  • Functional components – they realize designated business functionality
  • Infrastructure components – they do not introduce any business-specific functions but are required for functioning of the system (and are still independently deployable components) or support of enterprise concerns such as auditing or monitoring.

The approach for determining the scope of top-level components is based on the following:

  • High cohesion of functions within a given component – as e.g. in case of a security component or a client management component
  • External usability of a service – the determination of functional components is to include consideration of systems external to a given application that may use facilities provided by these components in order to execute specific parts of the overall business process.
  • Reduction of the overall number of components through abstraction and refactoring – For example, components in an application should consider abstracting small differences between related functions in a number of areas to provide a common customizable service or its reusable implementation. This effort, however, will be limited in practice by delivery timeframes and availability o
    f business specifications from potential clients outside the application project.  Refactoring existing code may be separate from service delivery.

Given that the architecture uses J2EE technology, software components are implemented as Enterprise Java Beans (EJBs) or Servlets. This choice leads to the following view of the overall system:

  • The actual implementation and functionality of an EJB or Servlet component is obtained from interaction of a number of instances of Java classes.
  • A business service is provided either by a single physical component or a group of interacting components.

The main elements of system decomposition are classified in the following:

  • Functional components

Infrastructure and ancillary components 

The system will also utilize a number of frameworks (persistence, presentation, workflow, etc…) and even though those frameworks will be important parts of the system they are not components in the sense discussed above. 

The rationale for the above form of decomposition is the following:

  • Focusing on functional services creates an architecture that can be understood by non-technical people. It facilitates mapping between business processes and technological infrastructure that supports those processes.
  •  It provides a natural unit of encapsulation that reduces dependencies and unnecessary interactions with other services or systems: service is the main unit of public reuse (follows functional decoupling)


Comments Off on Service Oriented Architecture