IT responses to Sarbanes-Oxley

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Victor Bennett, IBM WebSphere Sales Executive, IBM
Bob Cancilla, Senior Systems Engineer, IBM

15 Sep 2005

from The Rational Edge: In connection with the 2002 Sarbanes-Oxley legislation, IT organizations within public companies are now subject to public audits, with control requirements for application change management as well as application and data security. In clear, understandable language, this article explains the ins and outs of these requirements and suggests ways that organizations can achieve compliance efficiently and cost-effectively through the use of automated tools.

If you work for a public company -- or do business with one -- you have probably encountered some of the controls mandated by the Sarbanes-Oxley Act of 2002, often referred to as SOX. This legislation makes officers of public companies personally responsible not only for the company's financial statements, but also for putting proper controls in place to ensure the statements' accuracy. Failure to comply carries criminal liability as well as the penalty of public exposure.

In the wake of the huge corporate scandals of recent years that spurred passage of SOX -- Enron, Adelphia, WorldCom, Tyco, and others -- most of the media attention was on company managers who allegedly either misappropriated corporate funds or manipulated financial statements. However, in some cases, IT personnel were also implicated in schemes to manipulate computer-based records.

Although the law contains not one word about IT, computers, or technology,¹ audit firms have begun including IT organizations in their investigations. These firms recognize that SOX is not just about having proper financial controls; it is about protecting stockholder assets. These assets are subject to operational problems, including IT risks such as system disasters, security breaches, and so forth. In this article, we will explore some ways IT organizations can comply with SOX regulations and help protect their company's interests. Let's begin with a brief look at the law's provisions.

Disclaimer: IBM's customer is responsible for ensuring its own compliance with legal requirements. It is the customer's sole responsibility to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer's business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.

SOX provisions and enforcement

The Securities Exchange Commission (SEC), the agency responsible for enforcing SOX provisions, has mandated that companies disclose in their public quarterly and annual reports any "material defects" in their controls that an external auditor identifies and refuses to certify.² The SEC can criminally prosecute any executive who fails to comply with this mandate.

Perhaps an even more important player than the SEC when it comes to SOX is the Public Company Audit Oversight Board (PCAOB), which grew out of the legislation. In effect, the Board is a nonprofit public corporation formed to oversee public accounting firms that audit public companies.

Charged with developing auditing standards for member firms, the PCAOB collects membership fees based on number of clients. Any rules it writes must be voted on and approved by the SEC. The PCAOB is obligated to review its member firms' audits and report contrary findings to the SEC, which may either levy fines or suspend membership for non-compliant firms.

KPMG was one of the first members to incur penalties under these provisions -- more than $10 million in sanctions.³ Later, Fannie Mae's CEO, Franklin D. Raines, resigned amidst allegations of improper controls and reporting issues arising from SOX audits and oversight reviews.⁴ Clearly, the PCAOB is not afraid to exercise its enforcement powers over even the largest public accounting firms.

In the past, the Big 4 accounting firms⁵ offered a vast array of corporate financial services relating to taxation, investment, securities, and other financial concerns. Audit clients were free to purchase any of these services, which often resulted in conflicts of interest. Now, PCAOB rules bar these firms from providing virtually all services except auditing. In addition, companies must change auditors annually to ensure that personal relationships between the audit firm and client management do not compromise auditor objectivity. Specifically, the audit firms are prohibited from engaging in consulting activities related to computer systems and controls compliance.

Back to top

SOX and IT concerns

Some of the most infamous cases involving allegations of wrongdoing by corporate executives include accusations that IT staff members manipulated data, modified programs, and ignored basic system controls in order to supply incorrect data for financial reports and audits. As a result, the PCAOB has mandated that public audits encompass IT controls, even though the legislation does not specifically mention them.

Following studies on proper controls and audit standards, in 2004 the PCAOB defined minimum control requirements for two IT areas: application change management and application and data security. Web-based applications were excluded from scrutiny, as were general IT governance, networks, and other security and controls issues.

We will summarize these control requirements below.

Application change management

The following control procedures must be in place, and the IT organization should produce and retain supporting evidence.

1. Document all change initiatives. User management must sign off on user-initiated changes, and IT management must sign off on IT-initiated changes.
   
   
2. Establish a standard procedure for accepting, approving, and prioritizing changes. The organization should document decisions made via this process.
   
   
3. Document user and technical requirements for each change. The amount and content of the documentation will vary according to the change's complexity.
   
   
4. Perform testing at a level appropriate to the change's complexity. Obtain sign-off indicating acceptance of the change, from user management for user-initiated changes and from IT management for IT-initiated changes.
   
   
5. Authorize the move to production. A manager, rather than the programmer responsible for the change, must authorize this move. This manager should review the project folder prior to the move to ensure that it contains elements specified in procedures 1 through 4 above. The organization should produce and distribute a report of all production moves to appropriate IT management on a regular basis. Produce the report at intervals that permit efficient and effective management review.

Application and data security

1. Establish formal procedures for system access. Remove access for terminated employees and other system users who no longer need access. Also, establish a process for changing access when employees change job responsibilities; a best practice is to delete the employee's former access privileges and create new ones. This prevents people who transfer around the company from gaining "super user" access.
   
   
2. Base access to applications and data on job responsibilities. Allow access to production data only through appropriate applications. Permission to directly update data must be approved by either user or IT management. Log all grants of access and their purpose for management review on a regular basis -- not on an exception-only basis.
   
   
3. Enforce segregation of duties controls through application access privileges. In an insurance company, for example, a claims adjuster should not be given policy coverage change access, and a policy processor should not be given claim payment authority. No IT personnel should be granted access privileges that would allow him or her to act as a user on production systems.
   
   
4. Restrict access to processing and data storage hardware to those whose job responsibilities require it. Establish environmental controls to the extent practical, given the operation's size and location.
   
   
5. Establish a backup schedule for all critical production data. Store backup media away from the live data they represent, preferably in an off-site location. Restrict access to the backup media as appropriate. All business units should work toward completing formal disaster recovery and business continuity plans. Those with such plans should test and adjust them periodically.
   
   

Under SOX regulations, an audited company must also declare its current IT exposures in writing. In addition, the company must describe what controls are in place to protect against harm from such exposures as well as procedures to detect anomalies in their controls.

In 2004, other SOX regulations affected IT as well. For example, accountants and others had to document the source of all data used in their spreadsheets. Companies with a content management system that could archive computer reports and trace data sources were at a great advantage.

In the future, SOX is expected to extend its regulatory reach to Web and client server applications. That means companies will need to establish extensive documentation, testing, and control procedures for all applications, both financial and non-financial. New regulations will also likely target computer operations and procedures for scheduling batch jobs, managing problems, and remediation. Disaster recovery operations will be a particular focus, largely because of the December 2004 COMAIR disaster, in which more than 1,000 aircraft operated by this Delta Airlines subsidiary were grounded because of a computer system failure. And finally, in a meeting with the SEC earlier this year, the PCAOB discussed the desirability of using COBIT as a standard IT controls framework; several large audit firms have already agreed to do so.

Back to top

The cost of SOX

SOX compliance is placing a huge financial burden on public companies. According to British Telecom's (BT) chairman, Sir Christopher Bland, his company spent the equivalent of more than $19 million on initial SOX compliance. A 2004 survey by Korn/Ferry International found that US businesses spent about $5.1 million on average complying with SOX in the first year, and $3.7 million every year afterwards.

And, according to a survey and article posted by the New York State Society of CPAs,⁶ SOX compliance for 2005 will collectively cost companies over $5.8 billion. In fact, the cost of SOX is so significant that many smaller public companies in the $150 million to $500 million annual revenue range are withdrawing from the market and going private to avoid being forced to comply.

Most articles about SOX costs talk about the direct costs of adding or reallocating resources for internal audits, engaging consultants, and other measurable costs. However, organizations are also incurring substantial indirect compliance costs. As audit firms adopt the COBIT framework as a standard for IT auditing and compliance, many companies are concerned that compliance costs will become an even greater financial burden.

For most companies, the greatest expense will be in transforming poorly documented, inefficient manual processes with high-risk exposure into well-documented, compliant processes. Automating such processes is one way to reduce both costs and threats. Software such as IBM WebSphere's WBI Modeler (see Appendix A), for example, not only allows companies to document and improve processes, but also to simulate possible process changes to gain greater efficiency and adjust to market demands. WBI Modeler generates BPEL code to create Java code, and helps transform manual processes into fully automated ones that reduce human error and opportunities for corrupt practices. WBI Modeler and other WebSphere products also provide the "glue" IT organizations need to integrate disparate systems into one virtual system.

Back to top

How are IT organizations responding?

So far, the responses of IT organizations to the new demands of SOX compliance have varied according to the amount of staff resources at their disposal. Large organizations (200 plus staff members) rely mostly on human resources and manual procedures; they are eliminating non-essential services to free up staff time for SOX compliance. Mid-size organizations (20 to 200 staff members) are looking more to automation to contain staffing levels, although some staff increases may be unavoidable. Small organizations (20 or fewer staff members) rely heavily on both automation and consulting to compensate for managerial deficits in knowledge and experience.

All of these IT organizations are adopting one of two basic approaches to SOX compliance.

Wait until you have to do something

Many organizations are doing nothing; they are waiting until they are confronted with a specific audit recommendation. Then, they will be under the gun to remediate. Unfortunately, these companies will face ongoing compliance issues and continue to find themselves in an emergency response mode for years to come. In the long term, this is the least cost-effective way to approach compliance. Corporate management in these firms will likely appoint new IT directors periodically, in hopes that they can solve these problems with a simple personnel change, but playing catch-up on compliance issues will be a constant drain on the bottom line.

Institute proactive IT governance and controls automation

More progressive companies are taking a more proactive role; they have begun implementing new compliance-oriented policies and procedures while leveraging automation opportunities to streamline their operations. They are employing existing automated tools in new ways and purchasing additional tools that can help them perform compliance-related functions without increasing head count. Overall, this approach should result in business practices that are more effective as well as compliant.

The possibility of a mandate to adopt a controls framework, such as COBIT or ITIL, is a key issue for many forward-thinking IT shops. ITIL focuses on technical controls and specific procedures for security, network operations, system operations, and system software controls. COBIT includes ITIL procedures in its framework but also focuses on IT governance and consideration of enterprise business needs.

The key goal of COBIT is to implement measurable metrics that non-technical business executives can assess to ensure that IT investment is adequate (but not excessive), and that IT business applications support the enterprise business plan. If COBIT becomes mandatory, then many organizations will be forced to move from CMM Maturity Level 1 to Levels 2 and 3. Some Level 3 shops will move forward to Level 4. In COBIT language, "optimized" processes are automated processes with active control and metrics measurement facilities. Tools such as those in the IBM software development platform -- the full suite of Rational, Tivoli, WebSphere, and DB2 tools -- can help companies create a COBIT-compliant environment and higher process maturity levels (see Appendix A). They enable companies to stay ahead of the curve when it comes to SOX regulations instead of playing catch-up or being placed behind the 8 ball.

Back to top

SOX compliance in action: A model enterprise and subsidiary

For a real-life view of how companies are dealing with these new regulations -- and those they anticipate -- let's look at the measures one large public financial services company adopted to comply with SOX during 2004 and 2005.

Like many public corporations, this one owns and operates a number of semi-autonomous companies to maintain liquidity and flexibility. In effect, the parent corporation functions as an investor, giving its specialized subsidiaries a large measure of autonomy through local governance. Return on investment is the measure of success; if a subsidiary fails to meet expectations, it is likely to be sold or liquidated.

Although SOX legislation makes no specific demands on such subsidiaries, public auditing firms typically treat subsidiaries contributing at least 5 percent of the parent corporation's revenue just as they would the parent, subjecting them to the same audit guidelines. In addition, they insist upon placing subsidiary disclosure statements in the parent company's 10Q or 10K. This means that thousands of small-to-medium companies owned by public parents are affected by SOX. In 2005, the regulations will extend to foreign companies in which a US public company either has a significant investment or exerts financial control over the foreign operation.

Top-down commitment

When this model enterprise was informed in January 2004 that it would be subject to SOX compliance audits that included both financial and IT controls, it decided to create a SOX compliance team, headed by the company's VP of Internal Audit reporting to the CEO, CFO, and corporate audit committee. In his annual video address to employees, the CEO emphasized that every person had to do everything required to comply with the law. The company also purchased consulting services to help implement an enterprise-wide SOX compliance initiative encompassing its forty-two autonomous subsidiaries; this included a series of briefings and training on SOX compliance.

Subsidiaries prepared the necessary statements about their application change management and application and data security controls, and submitted them to the parent company's SOX compliance officer. Then, they were audited by a team of internal IT auditors and an outside IT auditor.

Solving IT compliance issues

Now, let's narrow our focus to the issues of one subsidiary -- a regional insurance company. Although the auditors rated this company's control procedures as acceptable, the IT organization had limited ability to detect deviations from procedures in several key areas. As many companies have similar issues, it is worth examining how our model subsidiary went about resolving them.

System access controls. Of the 750 people who had system access, the audit noted, two of them were no longer with the company. In fact, both had been contract employees, not permanent staff members. The remediation for this finding was to implement an aggressive policy of automatically disabling user profiles that had no activity for thirty days. In addition, the IT organization identified all managers responsible for granting access to the company's computer systems, and then instituted automated procedures to notify the appropriate managers that a profile had been deactivated and would be deleted if no response was received within thirty days.

Development project documentation. The company had an extensive policy regarding maintenance of development project files and documentation for initial user requests, authorized executive approvals, scheduling, prioritization, and IT acceptances. However, there were inconsistencies in documentation for requirements, unit testing, system testing, user acceptance, and deployment. Also, in certain cases, development managers made technical changes to programs or other resources and then implemented those changes in the production system.

The auditors mandated that the organization either assign production deployment to a separate production control group or institute automated verification that the person who made the changes did not also initiate production deployment. The company decided to remediate with two steps.

• First, the IT organization produced a report of all development requests completed in the prior month and then charged an administrative assistant with ensuring that all required documentation was in the project files. This included a report produced by the company's automated change management system, verifying that the person moving an object to production was not the developer who created or modified that object.
  
  
• Following her review, the assistant completed a written statement certifying that she had checked all closed projects for compliance. She listed exceptions and noted whether the responsible parties had provided documentation supporting the deviation. If the proper documentation was missing, the offender, the offender's manager, and the CIO were notified; a warning letter was also placed in the offender's personnel file, stating that future deviations would result in termination.

IT data access. The auditors discovered that certain IT staff members modified production data, either to remediate a production problem caused by a program defect, or, in certain cases, to act on behalf of a user department; some were also doing processing on behalf of the user community. In one case, a team was remediating erroneous transactions received during the night from a third-party vendor.

Fortunately, the organization was using IBM iSeries hardware as its primary production platform, which journals all database modifications. It put an automated mechanism in place to examine the journals daily and produce a report listing all changes to production data by IT personnel. This report is distributed to all managers, who must file a detailed report describing the change, the reason for it, and who made it, and contains a signed authorization by the user community to make the change. These reports, along with supporting documentation, are maintained by a production control person, who reports undocumented exceptions to the CIO. Then, the CIO can initiate disciplinary action if the change cannot be documented and authorization cannot be substantiated.

Backup and recovery. The auditors noted that the manual procedures typical of most mid-size Windows, Linux, or Unix shops -- or any shop other than zSeries, for that matter -- were unacceptable. In this instance, the procedures could not confidently confirm that backups were successfully completed, sent to the off-site storage vendor, and returned to inventory as scheduled. The auditors also questioned the validity of the company's manually maintained tape library inventory.

To correct these problems, the company purchased IBM Tivoli's TMS product for the Windows environment and the iSeries BRMS product. They also modified both their automated and manual procedures to ensure that they were meeting audit requirements.

Creating a compliance infrastructure

The auditors considered all of these findings serious enough to report to the corporate audit committee and flag for re-audit and remediation. This led the subsidiary to appoint one of its IT managers as a SOX compliance officer and allocate the resources required to correct the problems. When a re-audit was conducted at the end of the year, the report contained only minor recommendations for improvements, mainly in the area of development change management.

The audit also led to a thorough review and revamping of other areas. User managers conducted a comprehensive review of system resources accessible to all users and then took measures to certify selective user access to specialized functions, such as setting up vendors and authorizing vendor payments. This required several months of work by the IT and user community, and managers throughout the company helped to implement new semi-annual review procedures that would ensure compliance.

During this period, SOX compliance efforts at this subsidiary -- including documenting and self-auditing -- were consuming up to 25 percent of total staff time. At a post-audit steering committee meeting, corporate managers expressed concern about the impact on productivity and the organization's ability to meet business objectives. The committee authorized the IT SOX compliance officer to study current resource requirements and make a series of specific recommendations to reduce the human effort required to comply with current and future SOX requirements.

One recommendation was to implement IBM Rational ClearQuest to facilitate automated management of IT service requests. Although known primarily as a software development change management system, Rational ClearQuest has powerful forms creation, workflow, and tracking functions that give organizations great flexibility to automate document creation, approval, and tracking throughout the company. The subsidiary decided to use it in several areas to help reduce manual reviews and reporting.

The committee also authorized an aggressive program to study and extend the use of several Tivoli products and to review a number of Rational products that may facilitate development documentation, testing, and control of the company's WebSphere- and WebSphere Portal-based initiatives. In general, the committee continues to look to software as a first step and considers adding human resources as a secondary measure. Like most wholly owned subsidiaries, this one is extremely cost conscious.

Back to top

Postscript

After completing the audit and remediation audits described above, the subsidiary's CFO and CIO decided that it was not acceptable to be at the auditors' mercy. They appointed an IT compliance officer who began to study SOX, the PCAOB, and the directions being taken. This officer concluded that the only way to stay ahead of the auditors and avoid future problems was to adopt the COBIT framework and strive to meet CMM (Computer Maturity Model) Level 4 (Managed). He joined the ISACA (see References), downloaded the COBIT framework, launched an evaluation to identify his organization's deviations from the COBIT framework, and made plans to remediate.

There are two parts to successful compliance. The first is understanding what procedures and documentation must be implemented; the second is using the right software to facilitate the implementation. IBM Rational has software tools that can help organizations satisfy every part of the COBIT framework. They can provide an automated and integrated solution that facilitates the self-audit and review steps mandated by auditors for SOX compliance. Although the software itself will not make your organization SOX compliant, it can automate steps in the compliance process and help offset productivity losses associated with manual controls implementation. In the long run, it is an investment that helps bring compliance costs under control and pays for itself many times over.

Back to top

References

COBIT -- An IT controls framework supported by the Information Systems Audit and Control Association (ISACA) http://www.isaca.org/Content/NavigationMenu/Members_and_Leaders/COBIT6/COBIT_Publications/COBIT_Components.htm

ISACA (http://www.isaca.org/) sells a membership for $155 per member that includes PDF versions of the framework and supporting documents. An interactive CD-ROM is available for $300. The ISACA offers training and certification testing on the COBIT framework and IT auditing generating additional revenues.

ITIL -- Another IT controls framework, published by the Office of Government Commerce of the United Kingdom http://www.ogc.gov.uk/index.asp?id=2261

The OGC, or Office of Government Commerce (http://www.ogc.gov.uk/), sells a series of books, interactive CD-ROMs, and other publications about implementing the ITIL framework. The books are available only at bookstores, but the CD-ROMs are sold exclusively on the OGC's Web site. The book sets and CD-ROM sets each cost approximately $2,000.

The well-respected AICPA, or American Institute of Certified Public Accountants (http://www.aicpa.org), has opened a new class of membership to non-accountants. It sells books, papers, and other publications to these affiliate members. The AICPA publishes the COSO (Committee of Sponsoring Organizations of the Treadway Commission) general controls framework. It also publishes guidelines for SOX audits and PCAOB compliance.

There are official Websites of the PCAOB, Securities & Exchange Commission, and several news and information sites dedicated to SOX:

SEC: http://www.sec.gov/
PCAOB: http://www.pcaobus.org/

PricewaterhouseCoopers survey on the impact of Sarbanes-Oxley: http://www.fei.org/download/SarbanesComplianceTLrev_7_14_04.pdf

Computer World features on SOX: http://www.computerworld.com/governmenttopics/government/policy/story/0,10801,96724,00.html
http://www.computerworld.com/news/special/pages/0,10911,2025,00.html

USA Today article: http://www.usatoday.com/money/companies/regulation/2003-10-19-sarbanes_x.htm

Information Week article: http://www.informationweek.com/story/showArticle.jhtml?articleID=56900101

Back to top

Appendix A: IBM automated support for compliance controls

Back to top

Appendix B: Text from SOX legislation

SEC. 302. CORPORATE RESPONSIBILITY FOR FINANCIAL REPORTS.

(For complete text of the SOX legislation, see http://www.sec.gov/about/laws/soa2002.pdf.)

SEC. 302. CORPORATE RESPONSIBILITY FOR FINANCIAL REPORTS.

(a)REGULATIONS REQUIRED. -- The Commission shall, by rule, require, for each company filing periodic reports under section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 U.S.C. 78m, 78o(d)), that the principal executive officer or officers and the principal financial officer or officers, or persons performing similar functions, certify in each annual or quarterly report filed or submitted under either such section of such Act that --

1. the signing officer has reviewed the report;
2. based on the officer's knowledge, the report does not contain any untrue statement of a material fact or omit to state a material fact necessary in order to make the statements made, in light of the circumstances under which such statements were made, not misleading;
3. based on such officer's knowledge, the financial statements, and other financial information included in the report, fairly present in all material respects the financial condition and results of operations of the issuer as of, and for, the periods presented in the report;
4. the signing officers --

(A) are responsible for establishing and maintaining internal controls;

(B) have designed such internal controls to ensure that material information relating to the issuer and its consolidated subsidiaries is made known to such officers by others within those entities, particularly during the period in which the periodic reports are being prepared;

(C) have evaluated the effectiveness of the issuer's internal controls as of a date within 90 days prior to the report; and

(D) have presented in the report their conclusions about the effectiveness of their internal controls based on their evaluation as of that date;

5. the signing officers have disclosed to the issuer's auditors and the audit committee of the board of directors (or persons fulfilling the equivalent function) --

(A) all significant deficiencies in the design or operation of internal controls which could adversely affect the issuer's ability to record, process, summarize, and report financial data and have identified for the issuer's auditors any material weaknesses in internal controls; and

(B) any fraud, whether or not material, that involves management or other employees who have a significant role in the issuer's internal controls; and

6. the signing officers have indicated in the report whether or not there were significant changes in internal controls or in other factors that could significantly affect internal controls subsequent to the date of their evaluation, including any corrective actions with regard to significant deficiencies and material weaknesses.

SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS.

(a) RULES REQUIRED. -- The Commission shall prescribe rules requiring each annual report required by section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 U.S.C. 78m or 78o(d)) to contain an internal control report, which shall --

1. state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and
2. contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.

(b) INTERNAL CONTROL EVALUATION AND REPORTING. -- With respect to the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer. An attestation made under this subsection shall be made in accordance with standards for attestation engagements issued or adopted by the Board. Any such attestation shall not be the subject of a separate engagement.

Back to top

Notes

¹ See http://news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf

² See Appendix B for text of key sections of the law affecting public corporations:
Sec. 302. Corporate responsibility for financial reports
Sec. 404. Management assessment of internal controls

³ See http://www.orrick.com/fileupload/373.htm

⁴ See http://www.newsmax.com/archives/articles/2004/12/16/155518.shtml

⁵ Deloitte & Touche; PricewaterhouseCoopers; Ernst & Young LLP; KPMG

⁶ http://www.nysscpa.org/cpajournal/2004/1104/perspectives/p6.htm

About the authors

		As the IBM WebSphere sales executive for the Americas, Vic Bennett is responsible for WebSphere sales on the iSeries and Linux platforms. Previously, he held a number of executive sales and marketing positions at IBM, including WebSphere worldwide sales executive, director of iSeries software marketing, director of eServer SMB solutions marketing, and director of pSeries solutions. His extensive experience in SMB sales and marketing includes positions encompassing channel sales, business development, operations, training, solutions development, and middleware. He joined IBM twenty-seven years ago as a procurement and industrial engineer for the General Products division.

		Bob Cancilla is a senior systems engineer with the IBM Rational desktop tools organization. Currently, he is working on a series of IBM Press books designed to help business systems developers with no formal computer science training adopt and leverage Rational desktop tools and technology. New to IBM, he was an insurance industry IT executive for thirty-four years. He also published four books and wrote a monthly column for an industry journal.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top