SOA, The Good - The Bad - The Ugly

Jens Andexer Executive IT Architect @ IBM and Willem Bekker, Head of Architecture Initiatives @ Standard Bank created this comparision chart that does a great job to outlining the benefits, challenges, and pitfalls of moving toward a Service Oriented Architecture within your company. From my experience I have found that this information is very true. Here is a link to the original article. I have included the matrix in my blog for my personal future reference. The credit for the article goes to Jens and Willem.

Good Business Implications of SOA	Bad Business Implications of SOA	Ugly 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.