SOA: The good, the bad and the ugly

What's good and what's not so good about SOA

Service Oriented Architecture (SOA) is currently a hot topic and to be fair this style of architecture has some qualities that are very good. But with the good come some characteristics that are bad and even a few that are ugly.

Jens Andexer (andexer@uk.ibm.com), Executive IT Architect, IBM

Jens AndexerJens Andexer is the an executive IT architect with IBM's SOA Advance Technologies Group and is architecture lead in Sub-Saharan Africa He has been developing software all over the world for over 25 years ,specialising in financial systems, public sector, banking, and insurance. Starting his career as a PL/I maintenance programmer, Jens has gone on to have leading architect rolls in many large and complex software development projects. After a mid-career M.Sc. in computer science (software engineering), he joined IBM in 1998 and now brings his experience in host technologies, software development, and software maintenance to SOA customers in Europe and Africa.



Willem Bekker (willem.bekker@standardbank.co.za), Head of Architecture Initiatives, Standard Bank

BekkerWillem Bekker is currently the Head of Architecture Initiatives at Standard Bank. Willem has a B.Sc and more than 15 years experience in IT of which 12 is in the ERP Technical space. Willem has developed a reputation as a "Turn Around" agent by applying his abilities to optimizing investments in Information Technology to improve Business efficiencies.



06 November 2009

Also available in Chinese

Introduction

IT strategy expresses how IT departments intend to support the delivery of corporate strategy. Fundamentally this means organizations need their IT departments to run daily operations efficiently and allow new products and services to be made operational quickly and cheaply. Service Oriented Architecture (SOA) is good at this but it is no nirvana.

The table below highlights a sampling of the good, the bad and the ugly business aspects of SOA are described.

Table 1. Good Bad Ugly
Good Business Implications of SOABad Business Implications of SOAUgly Business Implications of SOA
Agility - SOAs allow business processes to be developed more quickly and it allows them to be changed more easily. This allows organizations to adapt to changes in their business environment more rapidly. This translates into a real market advantage since it allows products and services to be brought to market more quickly than competitors.Change in the organization structure - At the heart of every SOA is a Centre of Excellence (COE). The COE is a new entity that controls the technical development of the SOA and provides expertise to the rest of the organization. The SOA COE is a new addition to any organization and hence its introduction can lead to conflict when it is resourced and when decisions made here effect the rest of the organization. It's not easy - Transforming and organization to become services oriented is not easy. The transition is to a SOA is characterized by an evolution and not a revolution. Organisations that have traditionally been organised as silos my 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 - A closer cooperative relationship between business and IT removes traditional barriers the hindered the IT implementation of business requirements. The footprint of a service in the business domain is a business function and it is described in business terms. The details of its implementation are hidden.Change in organizational power structure Placing the ownership and control of services into the domain of business changes the power structure in organizations. This is typically met with resistance from those who have a vested interest in keeping the status quo. Change in culture - A SOA represents more than a change in technology. Attendant to this type of transformation comes a change in an organization's culture as it becomes value driven. The organization must learn what it means t 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 - Typically any SOA is associated with a rethinking of business processes. This business process reengineering is an opportunity to optimize how the organization operationally is going about its business. Doing a good job of this reengineering can make a significant improvement to a business's operational efficiency. New challenges for business - Business must get more involved in giving direction to IT. Business lines must take ownership and responsibility for 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 adherence to good software engineering practice in SOA allows IT to be more responsive to business needs. Time to market for products and services is shortened and the cost of development and change process is reduced.IT landscape becomes more complex before it can become simpler - SOA is enabled with a set of technologies like a business process execution engine and ESB. 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 can not appear simpler. The introduction of the service allows the complexities in the IT to be a secret. Consumers of the services need to know nothing about what goes on inside a service. As a result any rationalization that takes place in the back end can be hidden behind the service interface. Technology alone will probably not show value - A SOA that focuses on infrastructure and technology is likely to fail. A SOA initiative is founded on the promise of delivering business value more quickly and more cheaply than before. A 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 recognised as business value when it accelerates operationalising business requirements or reduces the cost of operational systems by allowing their rationalisation. Technology focused initiatives typically do not do this.
Data Unification - The service interface provides an opportunity to unify characteristics of the data so that service interfaces consume data that adheres to a unified data model. Common here means common:
  • Structure - the structural relationships between elements is the same so that for example an address consistently consists of a house number, street, city, region and post code.
  • 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. For example the concept of a customer might be hits on a web site in contrast to a set of owners of accounts.
  • Format - how data is represented is important. Dates that are formatted DDMMYYYY must not be confused MMDDYYYY.
  • 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. In some cases attributes are updated by the front end system in real time. However, some attributes are only updated periodically by batch operations.
  • 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
No One view of data - Standard interfaces for services require a common view of the data. This common view typically does not exist and trying to develop it often shows how disparate views in the organisation may be. Unification may not be possible - To get all the characteristics of data consistent is seldom possible. Beyond the issues above are the ever present problems associated with "dirty data". 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 technologies and principles used to enable a SOA make monitoring business processes easier. This type of monitoring allows feedback from daily operations. This feedback can be used to measure how well the organization is doing against its strategic goals

Traditionally business processes (BP) and presentation logic where all written into the same programs that contained business logic. The best one could hope for was that the different types of logic where at least grouped together but even this is often not the case. The upshot of this is that it makes monitoring of categories of logic very difficult. For example business processes could only be monitored as part of the application since it could not be separated out.

SOAs, typically come with a business process execution engine. The introduction of this technology encourages business process logic to be located in one spot. Having the BP logic in one spot makes BP monitoring possible without the need to have the BP logic in the application logic. This is not unique to a SOA but the technology used to enable a SOA along with the discipline that comes from SOA's good software engineering practices make it easier in a SOA.

Monitoring complexity - Developing a monitoring model for business processes that feeds back to organizational goals is a significant piece of work that requires specialist skills.
Leveraging operational systems - A SOA uses operational systems to supply the business functionality for services. This means that the investment in existing systems can be used by repackaging it into services.Technical misfits - In some cases operational systems do not relent easily to being repackaged as is the case when the structure of business functions does not match the requirements. For example if a transaction to add a new customer has a commit point after the name and address has been added to the customer data base and a second commit point after the security data has been added then these two operations are inexorably linked. Changes may be needed - In some cases operational systems may need to be changed. When the changes need to be made in ERPs vendors are reluctant to make these changes. If the organization decides to make the changes in house the maintenance cost must be considered in the funding of the service.

Summary

For SOA to be a success, business and IT must align there purpose and objectives. IT driven SOAs fail because they are perceived as a change in technology that has no direct benefit to business. The case for SOA must strengthen the organization's existing goals and strategy and this goes beyond an IT centred approach. This represents a culture change to where business expectations drive the priorities for IT which when coupled with a culture of co-operation between business and IT lays the ground work for success.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=444235
ArticleTitle=SOA: The good, the bad and the ugly
publish-date=11062009