Section 12.1. Stakeholders and Potential Conflicts of Interest

12.1. Stakeholders and Potential Conflicts of Interest

Before introducing SOAs at the enterprise level, we need to examine who the different stakeholders in the SOA are within an enterprise and the potential conflicts of interest that you must overcome to ensure a successful introduction of new technical standards and architectures at the enterprise level.

Figure 12-1 provides an IT-centric view of key roles and relationships in an enterprise. The CEO and the board of directors are responsible for high-level strategic decisions, which often will have a direct impact on IT as well. Similarly, business units drive functional requirements, and we can often observe that they present the IT department with conflicting requirements because their interests are not necessarily aligned.

Figure 12-1. Enterprise hierarchy and potential conflicts.

The CIO is often caught between these conflicting interests because investments in infrastructure are often harder to justify to business people than concrete business applications that have a measurable return on investment. CIOs thus need good arguments to defend these investmentsbecause IT is typically a cross-sectional function, it is limited by other business decisions. There is a number of major obstacles to investments in IT infrastructure such as SOA, including:

• The difficulty of providing predictable and verifiable returns of the investment that are plausible to the top management and other non-technical stakeholders

• Frequent changes in functional requirements and business strategy, which have a direct impact on the IT strategy

• Divisional interests and the mentality gap between IT and operative units

• The "not invented here syndrome" often found in IT organizations

The return on investment (ROI) is a major key performance indicator (KPI) for the board to approve major investments, including IT infrastructure expenses. This is typically a hard sell for three reasons:

• The return of infrastructure investments materializes in higher process efficiency and smaller future investments. However, many of today's controlling systems are not able to attribute efficiency gains to the infrastructure measures, and you can never be sure what your investments would have earned if you hadn't made the major investment.

• IT infrastructure projects have a history of unfulfilled promises, so decision makers are very critical to any kind of return calculation. For example, initiatives such as CASE, EAI, or workflow management that claimed various measurable benefits often failed to achieve them.

• Management often tends to favor short-term benefits over long-term investments.

After executives have made the most strategic decisions, it is up to the business units and the related IT projects and departments to implement systems that meet business requirements. The day-to-day interaction of business and IT people has traditionally been difficult. Business people might have a hard time understanding why technical issues are so complicated, while IT people often struggle with understanding not only certain business decisions but also the actual business itself. You can often observe a "conceptual gap" between the business and IT worlds. Typically, business requirements and the underlying technologies are extremely complex and dynamic, requiring a large number of specialists who have slightly different understandings of the environment and often differing agendas and perspectives. External consultants (strategic, business, and IT consultants) and product and service vendors with their own agendas add to this complexity. All of this increases the difficulty of matching functional requirements to a technology platform.

CIO and technology architecture boards often have different interests from individual projects, and different business units might have different IT organizations with conflicting interests as well. These conflicts can have various reasons. A good example is that of a large retail bank (name withheld), which bought a small investment bank in the late 1990s. Whenever the global CIO tried to define a company-wide standard, for an application server or a communication middleware for example, the CIO of the investment bank found a reason to use a different technologymainly due to reasons of ego rather than good technical reasons. These disagreements took place at the executive level. The global CEO was prepared to allow the investment banking unit to take certain liberties and bought into the investment bank CIO's argument that the investment business had very different technical requirements from the retail bank. The results were incompatible systems, increased project costs, and increased software license costs.

Technology and architecture boards aim, for example, to introduce standards that allow for reuse of technology and applications. Project managers, on the other hand, often have a bigger interest in getting their projects out the door instead of investing the time to examine reusability. In these cases, it is often not a matter of reasonable decision-making but rather a question of who has the power to enforce a particular course of action.

Similarly, project managers and operations managers can have conflicting interests. How fast the project delivers certain business functionality often measures the success of a project. Consequently, speed is the major concern of a project manager. Looking into the Total Cost of Ownership (TCO) is the responsibility of an operations manager. The TCO is largely determined by characteristics such as systems management integration, exception handling, maintainability, and CPU resource consumption. Obviously, none of these characteristics that contribute to a reduced TCO have any positive impact on project costs or development time. On the contrary, all these characteristics require time and money from a project point of view.

Finally, a word on the "not-invented-here" syndrome. A significant portion of IT projects fail to deliver the required business functionality because they reinvent their own middleware (the famous "let's just quickly build an object-relational wrapper" comes to mind). There seems to be a tendency among IT people not to trust other people's technology, which hinders the successful introduction of technology standards. Furthermore, many IT people seem to feel more comfortable focusing on complex technical concepts rather than on complex business logic, thus distracting them from the more pressing issues at hand.

To conclude this discussion on stakeholders and conflicts of interest, it is necessary to examine projects that cross enterprise boundaries, as depicted in Figure 12-2. After all, this vision underlies many of the current trends in the development of enterprise softwarean agile enterprise that is closely connected through technology and business with suppliers, partners, and customers in a completely flexible manner.

Figure 12-2. Cross-enterprise processes dictate the complexity of adjusting the IT infrastructure.

This basically means that processes, structures, and standards developed to establish an SOA within an enterprise ultimately also have to be applied to projects reaching across the enterprise boundary. If it is already challenging to align all departments of an enterprise in this respect, it is clear that problems are likely to proliferate if several enterprises are involved.

However, the basic picture does not change much, regardless of whether different departments or different enterprises are involved. One major distinction is the lack of a well-defined hierarchy across organizations. If there is substantial disagreement among different departments within an enterprise, the dispute can usually be resolved by a management decision at the lowest hierarchical level responsible for both departments. In these cases, commitment from top-level management is crucial to the success of an SOA.

If similar differences occur between departments of separate enterprises, though, there is usually no common management level with the authority to resolve the issue. Nevertheless, the establishment of clear processes and structures, such as boards spanning several enterprises, is a good strategy for the minimization of potential disagreements.