If you look for a great book on how to deal with the implementation and adaption of an Service-Oriented Architecture the book SOA for Profits is what you are looking for. The book was published back in 2007 but is still highly relevant. The focus is on handling the needed interaction with stakeholders to collaborate and define what have to be done and when it should be delivered in order to work around a burning platform for applications.

“The basic Concept is that all IT is composed of services” – Bieberstein et al (2007, p. 17).

Eventually the enterprise’s technical architecture will be compatible with an SOA typology and as such it might enable the enterprise to make use of the benefits, however, the benefits can only be achieved through the engagement of the various departments and decision-makers that makes use of the services that the IT department can provide them with.

“Above all, Service Oriented Architecture is not only a development within the domain of IT, it also has a far reaching impact on the organization makes use of it” – Bieberstein et al (2007, 17).

By saying this it seems like the approach to Service-Oriented Architecture will involve much more effort and many more resources and stakeholders than what is firstly expected. The various departments outside the domain of the IT department would have to be involved in the transformation. This means that the development of the transformation program includes the development will become much more complex and the effort of communication will become increasingly difficult.

Assuming that the Service-Oriented Architecture program is much more than the programming exercise and technology adaption exercise the importance of technology, the organizational aspects of the organization will become of a much higher priority. This means that new strategies would have to be dealt with as well.

“Indeed, the organizational aspect is of decisive importance” – Bieberstein et al (2007, p. 17)

It is in my opinion not a particular smart thing to assume distance the IT department from the other departments in an organization since it will only lay the foundation for the development of a stovepipe culture. Bieberstein et al (2007) doesn’t share this particular view and as such they make use of the notion of business and IT. In this case it can be unclear who the business is, however I presume it is safe to assume that the business is sales, operations, communication & marketing, call centers and a like. There are different levels also that would have to be taken into consideration e.g. those stakeholders who develops the strategy. The “business” would have to be engaged and Bieberstein et al puts emphasize this in the two quotes below.

“Another essential precondition in the implementation of Service Oriented Architecture is to start with the business” – Bieberstein et al (2007, p. 19).

“Indeed, the organizational aspect is of decisive importance” – Bieberstein et al (2007, p. 17)

Clearly the implementation of an Service – Oriented Architecture is not without consequence and as such the primary problem is the recalibration of the social structure of the enterprise. Likewise is the sharing of a vision for SOA probably very difficult since not every individual in the “business” will invest time in understanding why they would have to define services or why they should collaborate with the IT department on anything. It will prove much more difficult if the IT department hasn’t been able to get the basics right in the past. In other words the Chief Executive Officer, The chief architect and the various other managerial positions within the organization would have to go on the upfront with communication and networking in order to ensure progress.

You can’t escape SOA

The authors present the concept of the SOA typology as inescapable.  The big vendors of enterprise-oriented software have already implemented the capabilities of SOA – protocols that enables the application to work with an enterprise service bus (ESB). As a result most enterprises will overtime experience that their applications will be made compatible with the SOA typology out of the box and as such it could be a waste of resources that the organization doesn’t make use of its technical capabilities. As such Bieberstein et al argues that it will become more likely that organizations will implement SOA like systems and eventually adapt the form of architecture. This the authors express in the quotation below.

“SOA is inevitable in the long run. An increasing number of major suppliers and end-user organizations are applying SOA. This means that more and more software and hardware is being based on SOA, that an increasing amount of functionalities are being made available as services, and that a growing number of chains and co-operative endeavors are being structured in a service-based manner. This, sooner or later, there will be no escape.” – Bieberstein et al (2007, p. 37)

You can’t escape SOA because the ecosystem (suppliers and to some degree customers) expect your organization to make use of services.  With this in mind Bieberstein et al (2007, p. 55) states that the two most important functions to be deal with in implementation of SOA is enterprise governance and enterprise architecture.

The organization has to emphasize the implementation of SOA on the foundations of the progress of the enterprise architecture program. In their effort to implement SOA the stakeholders would have to collaborate extensively on defining, scoping and implementing SOA in the context of how the organization works. Enterprise architecture is to some extent the framework for the governance of the SOA Without governance the effort of implementing SOA will not succeed. The purpose of governance is partly to navigate the complexities of the ever-evolving IT-landscape (Bieberstein et al, 2007, p. 58).

Consequences by implementing SOA

The organization would have to deal with the consequences of implementation of SOA. A SOA project (and later on a program) is resource demanding, since it would have to allocate the time of enterprise architects, SOA specialists, business architects and business partners. Likewise will the SOA project allocate time from various stakeholders outside the IT department since they would have to be educated on defining business services that would be used to model the technical services upon.

The allocation of resources means that the organization would have less access to deal with projects that might be within the sphere of development with architecture. The major issue is the concept of opportunity costs and as such it would become a necessity to deal with the problems that arise from not being able to allocate all available resources. Bieberstein et al mentions the consequences on page 34 to 35 where they mention the consequence of the adjustment to business processes, governance of architectural process changes, IT development related to the processes and administration of process changes. Likewise will the SOA approach lead to a need for retraining of IT personnel and training of the stakeholders outside the IT department. In this context it become much more interesting to convince those decision-makers who are in charge of the budgeting to allocate resources to fund the training activities along side the need for new tools to govern the services.

Business Vision

In order to deal with the implementation of an SOA based typology it would have to be dealt with the articulation of a business vision. Bieberstein et al (2007, p. 23) named it the SOA business vision and it consists of five stages as listed below:

1. Reason has to come from both within and outside the organization (p. 31) and the legacy systems in the organization’s IT – landscape can prove to be a great platform for engaging in change. Bieberstein et al sees this as “.

2. Benefits have to be identified and the benefits would have to be articulated as specifically as possible (p. 31). Bieberstein et al sees this as the “why” question.

3. Definition is the “what” question and is according to the authors just as important as the “why” question to answer in order to articulate the SOA business vision

4. Consequences by implementing SOA are many e.g. training of the individuals within the enterprise, opportunity costs, acquisition of new tools

5. Implementation is the last of the five phases and includes the implementation of wrappers, protocols, ESB, business services, XML protocols and standards and the implementation of the organizational structures.

The core to implement a SOA typology in an organization is to have defined the proper SOA business vision and engaging the right stakeholders. Governance is a must and Bieberstein et al indicates that the framework Dynamic Architecture.

Dynamic Architecture

The approach to Dynamic Enterprise Architecture  (Abbreviated Dynamic Architecture) is a framework that focuses on the process of architecting. The scope of Dynamic Architecture is to focus on issues that aren’t a part of a speedy defensive strategy that demands the resources of the IT department to deliver it-based solutions and likewise it isn’t based upon an offensive strategy that demands development of applications or services needed to gain market share.

Conclusions

All in all, the book “SOA for Profits” is a great book dealing with the organizational challenges for implementing SOA. Many ideas presented in the book are necessary in order to gain the true potential of an SOA since it would take the development of systems and integration to the various organizational aspects of development e.g. the transformation of stovepipe orientation to a holistic process orientation. SOA is inescapable and eventually most organizations would have to adapt applications that have been optimized for a typology based on SOA.

The primary challenge to gain profit (or harvest advantages) by applying SOA is through the maturation of the organization and through the departments that collaborate on dealing with the data and functions needed in order to make the technical and business processes deliver the full potential.

Sources

Bieberstein, Norbert. Berg, Martin and Ommeren, E., SOA for Profits, 2007.