Posts Tagged 'SOA Governance'

SOA has a bad friend: EAI

One of the typical mistakes regarding SOA is to consider this approach just a new kind of Enterprise Application Integration (EAI) solution.

I will try to analyze the main differences between SOA and EAI.

  • Scope: EAI is typically an IT only project, SOA should involve business people and IT specialists
  • Goal: the goal of an EAI initiative is to solve the application integration problems. The  goal of a SOA initiative is to better execute, track and monitor business processes that use business services.
  • Means: EAI employs a bus (integration broker) in order to integrate the existing application silos – that remain at their places. SOA aims to break the walls of applications silos that hinder the flow of business processes and to create composite applications.
  • Benefits: EAI unifies the message transport middleware and brings simplification and reduction of technical latencies. SOA brings to agility in the creation, execution and the modification of business processes through the reuse of functional capabilities (services),
  • Topology: EAI has – conceptually – an hub & spoke topology (it aims the unification of the integration tools, although some integration brokers have a distributed technology). SOA has a distributed, enterprise-wide conceptual model (although many vendors push to a centralized, proprietary solution).

Unfortunately many managers treat SOA as a technical project, this bring to EAI solutions based on the SOAP protocol and do not gain the business benefits of SOA.

SOA projects should be considered strategic initiatives, obtain some senior management buy-in and involve business people, as well as middleware experts, software analysts and data administrators. Their success should be measured by business KPI, like shorter time-to-market for new products or shorter execution time for end-to-end processes.

 

SOA Governance: SOA requires changes in IT organization

Silos are not an accident, they exist for at least two reasons:

  1. The organization units (i.e. departments) managers tend to defend the ownership on the software applications that cover the processes falling under their competence. Unfortunately many E2E processes trespass the organizational borders of a single unit.
  2. In software development projects, the project manager (PM) success is measured with two simple KPI: time-to-delivery and development costs. This brings the PM to aprioristically refuse everything that is not under its direct control. Even the most open minded manager will try to avoid the use of shared facilities (like virtual servers or SOA services) because he perceives those facilities as potential threat to the achievement of his goals.

The behaviour of both kinds of managers are justifiable and often forced. However it brings to the building of silos to the detriment to E2E processes execution.

time-to-delivery and development costs. This brings the PM to aprioristically refuse everything that is not under its direct control

The project manager success is measured with two simple KPI: time-to-delivery and development costs. This brings the PM to aprioristically refuse everything that is not under its direct control

 

Enhancements in E2E process executions, reuse of common assets (like SOA services), more agility, cannot be achieved if “vertical drivers” that bring to silos are not balanced by “horizontal drivers” that aim the reuse of shared assets.
The enterprises gain savings and agility in  the mid-long term when a reuse policy is enforced

The enterprises gain savings and agility in the mid-long term when a reuse policy is enforced

Organizations must commit a different organizational unit, with no vertical interest (i.e. SOA centre of excellence, the Enterprise Architecture team) to pursue an enterprise-wide reuse strategy. This unit must have the power to contrast vertical interests when they are counterproductive for the whole organization.

The role of SOA Governance

The role of SOA Governance

The life-cycle of software initiatives must be re-examined in order to allow the “horizontal unit” to look for reuse opportunities, to suggest best practices and to check for the rise of new silos.