Featured articles - Does Constant Change Equal Constant Risk in Your Enterprise?

November 2008

Constant change means constant risk to the enterprise architecture unless it's planned and governed correctly.

IT planning takes place in a rapidly changing business environment and involves an overwhelming volume of data -- hundreds of applications and many thousands of artifacts in multiple locations. Complex interdependencies between distributed specialists, critical business processes, IT support services and the underlying technical infrastructure can be significantly disrupted by isolated actions and incidents.

Constant change -- organizational, technology (e.g. SOA, cloud computing), processes - means that the IT landscape and interrelationships between business, information and technical architecture layers are undergoing constant transformation. Without centralized planning, things can quickly go very wrong putting the enterprise under unnecessary and sometimes unlawful risk.

To make matters worse, many organizations struggle to meet the IT planning challenge with Microsoft Office tools. Subject matter experts own fragments of technical information while organizational and functional data is maintained in ad hoc databases that lack the GUI and visualization tools needed to show relationships between data classes (business, technical and financial information). An EA (Enterprise Architecture) inventory that provides a one-world and up-to-date view about the constantly changing current, future and planned landscape for all stakeholders involved in the planning process significantly mitigates the risk of ill-informed decision-making.

This article examines three situations in which organizations may be at particularly high risk:

1. During the project approval process
2. When dealing with regulatory compliance
3. During mergers and acquisitions.

A section follows each scenario EA best practices on how to mitigate risk during those times.

Scenario One Risk: Project Approval Process

The typical project approval process is fraught with risks. Here are some common mistakes that increase these risks:

• The lack of correct process in place leads to projects that are approved with no certainty over the financial costs of the project.
• Not having the right architectural governance within the organization increases the risk of project failure.
• The lack of transparency and due process in selecting project portfolios means that decisions are sometimes made based on whether a project is favored rather than whether it is business critical.

Given these risks, it is crucial that organizations find a means to prevent them. This requires architecture health and risk checks and setting milestones at which the project receives a "go" or "no go." Processes should be put into place to ensure that a project business plan is completed and is comparable. All stakeholders should be involved in the process and the individuals with approval power should be mandated to carry out due diligence. Such due diligence should be transparent to others so that it is clear why a solution was chosen over another.

Best practices in other industries, such as manufacturing, demonstrate that a key success factor is transparency and comparability of the information from suppliers and partners. In IT this implies comparability not just in terms of deliverables and business benefits but also in terms of its architectural fit with the existing IT landscape. A centralized planning system allows for competing solutions to be proposed and cross-compared on level playing terms in terms of criteria such as their architectural risk and standards compliance.

The biggest issue during project approval processes is that individuals typically underestimate time, costs and effort. Often times, they don't look at the impact a new project has on other existing or planned IT implementations. For example, a new solution being reviewed might use a technology that your organization plans to take out of lifecycle in two years. Is that acceptable? Or another project might include technology that conflicts with your existing data warehousing strategy. If so, you might not be able to analyze that information or it could cost a good deal more money to do so. In fact, the biggest cost incurred is often when project managers have to pay for the development and maintenance of interfaces required for disparate systems to communicate with one another.

By documenting portfolio decisions and the decision process behind them, organizations can better determine which approved projects are priorities in an organization's business strategy. This avoids pet projects getting forced through because sponsors must defend decisions in a logical manner.

An example of a company that has a good handle on projects is a well-known financial services firm. Its CIO Office oversees project costs, architecture conformity, IT security and business case and relevance. Since initiating its enterprise architecture management program, if these factors aren't up to standard, projects don't proceed. One of its priorities has been to reduce the number of interfaces between applications and so it has standardized on certain applications. As a result, it has cut costs and implementation time sharply.

Scenario Two Risk: Compliance with Regulations

A number of compliance issues such as Sarbanes-Oxley (SOX), Information Technology Infrastructure Library (ITIL) and International Organization for Standardization (ISO) have created havoc within organizations. They've created risks such as the following:

• There is a risk that auditors may not sign-off on compliance and processes that are not repeatable. This results in high cost to mitigate the risk and to get an auditor to sign-off.
• In addition, the annual extra effort and stress de-motivates and burns-out staff and incurs high over-time costs.

back 1 2 forward