A couple days ago I presented my ideas in "Creating Service-Oriented Enterprise" to the IASA UK meeting. One of the topics that caused a 'hot' discussion was how to deliver the message about services to the business ears and hearts. Should IT change the way it works with Business or Business has to change?
This is a 'bearded' topic but with emerging stress on business services and extending SOA into the business world, it gets new priority. Particularly, the solution I proposed in the presentation and in my book 'Ladder to SOE' is about the change in the Business organisation.
We hear several slightly different claims with regard to Business and services:
- Business does not want to fund SOA initiatives because it does not see business value in them
- Business Unit (BU) management does not want to fund SOA initiatives because potentially created services may be used by other BUs 'for free', i.e. other BUs would benefit financially just out of using the services in spite of the service results
- Business Unit (BU) management does not want to fund SOA initiatives because potentially created services may downgrade the importance of business activities performed by this BU and threaten the BU well-being (somebody may be done redundant if automated services replace manual work)
- Business Unit (BU) management does not want to fund SOA initiatives because potentially created services may facilitate an idea in the higher management heads that this BU may be merged with other BUs based on the capabilities of automation. This consideration is much closer to the reality because the higher business management situates in the hierarchy the more it operates with the notion of business functions/services than with the operational processes.
There are, probably, other reasons exist but, as you see, in 3 cases out of 4 we have a conflict of interests between individual (BU/manager) and group (enterprise) interests. Thus, the problem with acceptance of service orientation is not in what and how IT says about it but in the basis of the relationships, more accurately - in the gap in the relationships, between Business and IT.
I do not see disappearance of this gap until the Business actions (including business requirements to IT) would not directly examined against corporate business objectives and goals. We know from our daily experience that a perfection of a part does not necessary mean the benefit for or the perfection of the whole. That is, a well-being of one BU may not necessary contribute into the well-being of the company. This BU well-being hides behind its business value proposition in the Value Chain concept. But is it really that valuable if one ring in the cast iron chain is made of gold?
The Value Chain concept fits with a process-centric business organisation very well. However, in the dynamic environment, the process concept of robustness, immutability does not play well. To guarantee that the process is in the good state, all potential disturbances that can affect this state have to be eliminated. One if the way to implement this principle is to own or control/command everything the process depends on. At the same time, the process 'does not care' about anything which is outside of it; the process is self-centric entity. Since majority of BUs implement one or another business operation or process, the process-centric mentality prevails in the Business interactions with IT.
The common logic is: "If what I am doing (process) delivers a business value, it is good enough reason for me to exist". Well, if the business model is just about adding 'a value', this logic works. However, if the business model demands 'the value', the enterprise can find that this logic is not "good enough reason for me to exist". The situation where 'the value' is required usually associates with the proactive behaviour of the enterprise in the market. If the market changes quickly and the Value Chain based business model sits (or executes the same things in the same way) and waits for another value to come, this model is looking for troubles. According to GE's Jack Welch "When the rate of changes outside exceeds the rate of changes inside - the end is in sight".
I think that the solution of the IT-Business problem around services (as well as the Business-Market problem around business services) is in the conversion of the business model into the business service model based on the Value Networks concept (the extension of the Value Chain concept). If the BU were accountable to the Corporate for their services to other BUs and, consequently, to the clients and customers, the problem of services would disappear because the BU had to operate in the service-orientated manner by itself.
I've explained one of the potential means of how to make BU service-oriented in the 'Ladder to SOE' but here I would like to put your attention on the process-service issue in the described context. When a BU is valued by its service results, the worthiness, importance of its processes finally renders its real role as an implementation of the service, and nothing more. In the service-oriented business environment, it does not matter how hard/well the BU has worked if its results are not competitive with analogous results inside or outside the company. It will be clearer what real value is delivered by the BU if a manager of BU1 may find that the results of the BU2 are less satisfactory to the BU1 need and it is better/cheaper to just buy them from the outside than use them from the BU2.
Service-oriented model and related behaviour in business appears as much more adequate to the changing external environment. This is because service orientation, in essence, is exceptionally flexible and allows adapt changes via re-composition rather than via new development and modification. That is, the service orientation assumes and promotes cheaper and faster reaction to the changes, offers higher business value proposition in the changing environment than the process orientation and can even save an organisation during a crisis or downtime.
Summarising, I can say that the solution of the IT-Business problem about SOA and services is in the transforming Business into service-oriented business or enterprise (SOE).













Hi
I'm researching about service identification and specification in SOA What
is the difference between SOA and CBSE?What's difference between service
and component?I know component contains some services but for
identification of them the path is the same.
I don't know ,can I
say my research is about Service Identification in SOA and then refer
to researches about CBSE .Then someone might ask me what is difference
between SOA and component based software engineering?
Service in SOA requires much more consideration than components in CBSE. The standards for SOA services may be found in OASIS, OMG and The Open Group (http://www.ebizq.net/blogs/service_oriented/2009/10/navigating_the_soa_standards_into_the_failure.php)
From the engineering perspectives, components are not obliged to be compliant with SO Principles though many of them are shared. Wikipedia says: “Components are considered to be part of the starting platform for service orientation throughout software engineering, for example Web Services, and more recently, Service-Oriented Architecture (SOA) - whereby a component is converted into a service and subsequently inherits further characteristics beyond that of an ordinary component� – and I disagree with this explanation. Particularly, Web Services are NOT components, they are interfaces; it is not easy to convert a component into SOA service because of the same incompliance with SO Principles. Do not believe those who says that a legacy app. With Web Service interface is a SOA service – it has nothing to do with SOA and remains the legacy app with one more interface.
One of the major differences between components and SOA services from the engineering perspective (we would need to apply all business considerations talking about SOA services at large) are in the principles of Service Composability, Service Execution Context, Standardized Definition of Service Contracts, Service Relative Autonomy and Service Relative Autonomy that are not usually applicable to the components during the development and run-time (http://www.ebizq.net/blogs/service_oriented/2009/02/principles_of_service_orientation_reviewed.php).