SOA: The Good, the Bad and the Ugly

Posted by Boris Lublinsky on Nov 18, 2009

Sections

Architecture & Design,

Enterprise Architecture

Topics

SOA ,

Business Process Management ,

Business

Tags

Business/IT Alignment ,

Business Architecture

 

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.

1. Back to top

   Dire Conclusions

   by Paul Korney

   The silence on this post is deafening... maybe because there is nothing to argue about. In that case, what conclusions should draw? I see that
   1) Few organizations today are positioned to be successful with SOA,
   2) Few existing SOA efforts will deliver value to their organizations.
   OK swell... what do we do?
   1) If I'm a CIO, I want to quickly kill any project or purchase associated with 'building an SOA' that has no direct business unit sponsorship or near term bottom line value.
   2) If I'm managing such a project, I need to quickly get close to the business units and the above CIO (probably bypassing my direct management in the process) and convince them of the near term value. I probably have to change the project scope to get there, but at least I have a chance of winning this way.

   Reply

2. Back to top

   Re: Dire Conclusions

   by Jean-Jacques Dubray

   Paul:
   
   just like anything IT does, SOA is not that easy, not a silver bullet nor does it deliver magical results. If you combine this with the typical vendor games and tricks (Oslo being the last example), the typical analyst ignorance and the usual pundit FUDing dog and ponny show, you probably get quite a bit of fatigue.
   
   Lots of people have done SOA and continue doing SOA and people are tired of this type of discussion. I am.

   Reply

3. Back to top

   Re: Dire Conclusions

   by Paul Korney

   Jean-Jacques,
   
   >> Lots of people have done SOA and continue doing SOA...
   
   I keep hearing this, but I just haven't seen it. Given the organizational and cultural issues mentioned in this article (all of which I have seen repeatedly) I have to ask who these people are and how their IT organizations work. The fact is, most SOA information comes from vendors, analysts and pundits, not IT customers. Show me a business unit manager or CEO from a large org that says they have obtained value from a SOA effort.
   
   >>...and people are tired of this type of discussion. I am.
   
   I guess if we were seeing only the most backwards of organizations failing at service orientation, then I would agree. But the fact is, tiresome as it may be, most organizations are having difficulty. This isn't a problem with SOA itself, but with the difficulties organizations have with providing what SOA requires to be successful.
   
   Personally, I would like to see more discussion around this topic; if another forum is more appropriate than InfoQ, please point it out.

   Reply

4. Back to top

   Re: Dire Conclusions

   by Jean-Jacques Dubray

   Paul,
   
   I don't know your background but I speak and contribute to our customer's SOA every day and I don't see much fatigue or doubt there. I do see a lot of things that could have been done far better, if only the analysts, pundits and vendor knew what they were talking about. Vendors could have also helped with better products and not changing direction every release, let alone product names or "branding".
   
   For me the problem is right there, SOA changes many things, yet few people understand the changes. Most people I see are building their SOA at the "data access layer" rather than at the "business service layer". When you combine these two things, you realize that lots of organizations could feel the pain if a) they don't assess these changes correctly (SDLC, Governance, programming model and factoring of the business logic) b) they built their SOA at the wrong level.
   
   Again, nothing I see in the literature, vendors, analysts... would help a company avoid that. I do see some haha moment when I am given the time to explain these issues and some of the possible solutions.
   
   Feel free to continue the discussion: jdubray -at- gmail.com
   
   JJ-

   Reply

5. Back to top

   Re: Dire Conclusions

   by Sony Mathew

   Dubray,
   Are you saying that in your experience SOA is more successful as a Data Access Layer rather than that a Business Service layer?

   Reply

6. Back to top

   Re: Dire Conclusions

   by Jean-Jacques Dubray

   No, I am saying that most people construct their SOA at the level of the DAL rather than the BSL. This is, IMHO, a mistake.
   
   JJ-

   Reply

7. Back to top

   Re: Dire Conclusions

   by Sony Mathew

   I agree..

   Reply

• Older >