Section 3.16. How will governance function within ESA?

3.16. How will governance function within ESA?

Historically, governance issues have boiled down to a battle between control and reduced costs via synergy on the one side and flexibility and needs for specialized support on the other. Highly centralized governance policies have been successful in enforcing standards, preventing redundancies, and thus driving down costs, but have also paid a price in responsiveness. The more concentrated governance becomes, the more project managers and line executives (or any other precursor to business analysts) are straitjacketed by inflexible policies. Every IT organization faces this tradeoff: suffer in response times now, or face the consequences of a sprawling, out-of-control environment later. Which one will it be?

ESA promises to ease the pain either way, because of its standards and services-based approach, where the repository and platform stand in for the central authority while modeling and recomposition grant considerable latitude to business analysts and other tactical users. In Chapter 17, we explain how ESA makes this "federated" approach possible by abstractionpower users have a high degree of control over their composite applications, while the central authority retains ownership of the platform. Even in custom application development requiring new components to be built, the nature of the repository calls for an orderly process to certify those components as standards compliant and govern their eventual reuse elsewhere within the platform. (Or the reverse could occur. The central committee could decide the new component is redundant and force the development team to reuse a similar, existing component instead.) There is much less danger of the spaghetti code conundrum that bedevils current architectures.

This decouplingof tactical use and strategic oversightalso frees operational units from a single approach to deploying IT. Just as ESA loosens the organizational constraints imposed by classic siloed applications, it also creates an opportunity to apply governance on an ad hoc basis. By clearly demarcating governance "domains" that stipulate which operational units are subject to which guidelines, the historical friction between business reality and a generic governance scheme is mitigated. In other words, your sales and marketing department is free to deploy new composite applications at a pace and under the guidelines that it sees fit for its own operations without worrying about or even pausing to consider how this might affect the rest of the business. Just as application logic is decoupled from business logic with ESA, so is governance decoupled from the institutional structure.

Of course, this creates its own organizational challenges. In addition to the traditional governance committee overseeing service and platform integrity, the company and the CIO must now address the issues of how much authority to cede to business analysts and their superiors, the size and boundaries of governance domains, and who is entitled within each domain to influence, consult upon, and ultimately make the final decision on governance. A tradeoff still must be made, this time between flexibility and organizational complexity.