BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News SOA: The Good, the Bad and the Ugly

SOA: The Good, the Bad and the Ugly

This item in japanese

Bookmarks

 

As we have reported many times before, one of the main prerequisites of SOA success is alignment of purpose and objectives between IT and business.In their new article,IBM’s Jens Andexer and Willem Bekker from Standard Bank provide some samples of the good, the bad and the ugly business aspects of SOA .

They have structured their SOA business impact analysis in several categories:

  • Agility
    • The good: Through supporting faster delivery of more flexible business processes, SOA provides organizations with a better adaptability to changes in their business environment and consequently provides a real market advantage
    • The bad: SOA implementations often require the introduction of a new entity - Center of Excellence (COE) - providing technical expertise to the rest of the organization. Introduction of COE can lead to conflict with the rest of the organization especially when it comes to resource allocations and decision impacting the enterprise as a whole.
    • The ugly:
      Organizations that have traditionally been organized as silos may need to change their structure to take full advantage of becoming services oriented. This shift can be complex, expensive and there is no shortage of opponents to the change.
  • Alignment
    • The good: By aligning IT service functionality with business functionality and describing it in business terms, SOA facilitates a closer collaborative relationship between business and IT.
    • The bad: By placing the ownership and control of services into the domain of business, SOA changes the power structure in organizations, which can create a resistance from those who have a vested interest in keeping the status quo.
    • The ugly: An SOA implementation requires changes (often drastic) in organization’s structure.
      The organization must learn what it means to be agile and how best to exploit this agility for itself. The ugly truth is that this is one of the most difficult lessons to learn.
  • Business Process Improvements
    • The good: An SOA implementation typically involves some level of process reengineering which provides an opportunity to improve business' operational efficiency.
    • The bad: This creates new challenges for a business, which must get more involved in designing services and their enhancements hence initiating the development and change cycle as they will drive this process.
      This is not a role typically filled by business lines and will make for an uncomfortable change.
  • Flexibility
    • The good: An SOA implementation is virtually impossible without adherence to good software engineering practice which allows IT to be more responsive to business needs through shortening time to market for products and services and reducing the cost of development.
    • The bad: On one hand, the introduction of services allows to hide the back-end behind the service interface, thus creating a more stable environment for service consumers. On the other hand, an SOA implementation typically relies on a set of technologies like a business process execution engine or an ESB, etc.
      Adding technology to an IT landscape does not make it simpler even when the advantages out way the costs. But just because the IT landscape is more complex does not mean it cannot appear simpler. The introduction of the service allows the complexities in the IT to be a secret.
    • The ugly: An SOA initiative is founded on the promise of delivering business value quicker and cheaper than before.
      SOA that is too technology focused is unlikely to deliver on that promise since they will not show value in terms business people want to see it. Flexibility is only recognized as business value when it accelerates the operationalising of business requirements or reduces the cost of operational systems by allowing their rationalization. Technology focused initiatives typically do not do this.
  • Data Unification
    • The good: The introduction of interoperable services provides an opportunity to create a unified data model for an enterprise. Unified here means common:
      • Structure - the structural relationships between elements is the same
      • Semantics - semantic refers to the meaning and use of the data. Data must have a consistent meaning and must not be used in a way that can be misleading.
      • Format - how data is represented is important.
      • Type - A type is determined by the representation of data and the set of behavior that can be performed on it.
      • Timing - Timing refers to when an attribute is updated.
      • Life cycle - under what circumstances data is add to data bases and when it is updated and when and how it is finally deleted from data bases.
    • The bad: Such unified data model typically does not exist and trying to develop it often shows how disparate data in the organization may be.
    • The ugly: Getting consistency over all data characteristics is rarely possible:
      Dealing with the inconsistencies is one of the great challenges of designing service interfaces. The ugly truth is that a uniform service interface is very difficult to build.
  • Operational Monitoring
    • The good: SOA principles naturally lend themselves to simplification of business processes monitoring which can be used to measure how well the organization is doing against its strategic goals.
    • The bad: Developing a monitoring model for business processes that influences back the organizational goals is a significant piece of work that requires specialist skills.
  • Leveraging Operational Systems
    • The good: In most cases an SOA leverages existing operational systems to implement the business functionality for services. This means that the investment in existing systems can be used by repackaging it into services.
    • The bad: Operational systems might not lend themselves easily to being repackaged as services.
    • The ugly: In some cases operational systems may need to be changed or additional logic/implementations might be required.

In order for SOA to be successful it is not enough for IT to introduce a set of SOA technologies. It has to be driven by a set of concrete business goals and expectations and coupled with a culture of cooperation between business and IT.

Rate this Article

Adoption
Style

BT