Time Has Come for the IT Process Engineer

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Much has been written about the need to balance people, technology and processes in order to generate repeatable results that can be optimized. There is a wealth of resources ranging from books to consultants, all ready to assist with the human element as well as the technology side of the equation.

The same cannot be said for IT processes, for recognition of the lack of process maturity in most IT organizations is relatively new. While software engineers, network engineers and various security certifications have become prevalent, there has been no evolution of IT process engineers who are trained to focus on the glue that binds everything together. Perhaps this profession’s time has come.

Professions

What constitutes a profession? The Cognitive Science department at Princeton defines a profession as “the body of people in a learned occupation; an occupation requiring special education.” When we look at the relatively poor state of process design in IT today, doesn’t this reflect a lack of specialized knowledge about processes? Wouldn’t there be a benefit to having specialized knowledge about IT process design and subsequent optimization?

For many of the similar reasons that we instituted software engineering and evolved that profession, we must develop curriculums and certifications to support the need for IT Process Engineers (ITPE) to aid organizations. We must evolve IT in order to meet increasingly strict regulations needed to support the parent organizations.

Formalization of Processes

One of the first steps needed on a process improvement journey is to actually codify processes into documentation and then ensure that standards are followed. By manual auditing and the implementation of automated detective controls, we strive to ensure that what is documented is actually being followed.

It is very important that there be mechanisms in place to allow for natural evolution to take place and revise policies and procedures to reflect what is needed in a controlled manner. In other words, policies and procedures need to be under formal change management with submissions, review and approval just like any other asset in IT.

With this said, an ITPE is not an auditor. From a control perspective, auditors must not create the processes that they audit. They can, at best, offer advice about the effectiveness of controls present in the processes. But the other stakeholders must draft the policies and procedures, and this increasingly requires specialized knowledge about best practices.

Best Practices

The ITPE would be immersed in the best practice domains for which he/she is responsible.
One may be heavily involved with change management and need to be versed in ITIL. Another ITPE may be involved with development and should be knowledgeable in the SEI’s CMMI and project management, be it PMI and/or PRINCE.

Regardless of the discipline involved, the ITPE must be versed in control theory in order to support the organization not only in process improvement but also in regulatory compliance and interfacing with auditors.

For example, the ISACA’s COBIT framework provides 318 detailed control objectives that require each organization to develop the necessary processes as well as documentation to support controls. In some organizations, the numbers of policies, work instructions and so on necessary to support those 318 detailed control objectives have numbered from approximately 2,000 up to 5,500. These are huge numbers and there needs to be an architect coordinating efforts.

The ITPE would work with the relevant teams to ensure that best practices are appropriately coupled with the necessary controls and reflected in the processes and related documentation. The ITPE would help with process design and documentation, but ownership should be held by the stakeholders and validated by regular audits carried out by internal audit. Bear in mind that from a separation of duties perspective, and auditor cannot create the processes that he/she must then audit.

This whole process is far from a one-time project as everything will continue to change. With constant change in mind, some organizations may retain one or more ITPEs full-time; others may bring in contractor ITPEs during regularly scheduled process reviews. For example, management may decide that there should be process reviews annually and that processes be reviewed after an audit finding or other issue indicates that processes need to change.

Summary

Quality must be built into the products and services that IT delivers. Poor service levels and bad security are indicative of process immaturity. IT needs effective processes that are formalized, optimized and routinely reviewed to ensure quality.

The ITPE’s role would bridge industry best practices into organizations that cannot afford to fall behind for a number of reasons, including security, regulatory, and achieving organizational objectives regarding competitiveness. The intent is not to add another bureaucratic layer, but to create a role that is both empowered and educated to help all of the relevant stakeholders design, document and maintain IT processes.