Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Service use, reuse and... business prohibition

user-pic
Vote 0 Votes

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:


  1. Business does not want to fund SOA initiatives because it does not see business value in them

  2. 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

  3. 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)

  4. 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).
Reference Lable.JPG

2 Comments

| Leave a comment
user-pic

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).

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more

Subscribe

 Subscribe in a reader

Recently Commented On

Categories

Tag Cloud

'Navigating the SOA Standards Landscape, 1471, abstraction, ACM, active service, Adaptive, ADM, adopt changes, aggregate service, AIA, Amazon, analysis, API, application, Application Integration Architecture, architect, Architect, architectural mission, architecture, Architecture, architercture, AWS failure, Azure, B-SOA, BAWG, BEI, Best Practice, bottom-up, BPEL, BPM, brokerage, Brokering, brokering, bus, Busienss, busienss case, business, Business, Business Architect, Business Architecture, business architecture, Business architecture, Business Architecture Working Group, business concerns, business data, Business Ecology, business efficiency, business model, business operational model, business organisation, Business Platform Division, business process, Business Process Designer, Business Requirements, business risk, business service, Business service, Business SOA, business value, business view, business-centric, Business-IT problem, BuTechCon, Canonical Schema, capability, Case, CBDI, CBM, Centralization, choreography, CIO, Cloud, cloud, Cloud Computing, Cloud of Clouds, COBA, Collaboration, collaboration, collaboreation, commodity, component, Composite Application, composition, concept, Conciliator, consumer, contract, COSMIC, cost, cost estimate, cost of ounership, cost of ownership, coupling, crisis, CRUD, culture, Cutter Consortium, data ownership, data service, data store, DDD, decision logic, decomposition, definition, demand, design, Design Pattern, development, discipline, distributed orchestration, Domain, domain, Domain Aggregate, Domain Events, Domain Service-Oriented Modelling, DOSOM, DOSOSM, driver, Dynamic Process Edition, EA, EC2, ecosystem, EDA, efficiency, end-to-end, enemy, enterprise, Enterprise, Enterprise Architect, Enterprise Architectural Framework, Enterprise Architecture, enterprise architecture, ERP, ESB, event, Event, execution context, Execution Context, expertise, explicit, failure, fake, feature, Flexibilit, flexibility, FPA, FSM, Full Functional Points, Functional Points, functionality, functionality model, future, Gartner, goal, Governance, governance, granularity, harmonization, Healthcare, how to, IBM, identiy credential, IEEE, IEEE 1471, IFPUG, implementation, implicit, intangible, intangible value, Integration-Oriented Architecture, intent, interface, interface orientation, Inventory, investment, IOA, IT, IT Architect, IT Operation Support, IT organisation, IT without the IT Department, ITIL, Java, Ladder to SOE, leasable Cloud, lease, Loose coupling, Lost in Translation, Malik, management, Management, Manifesto, market, MDA, Michrosoft, Microsoft, Mike Rosen, model, Model-Driven Approach, modelling, Navigating the SOA Standards Landscape Around Architecture, navigation, OASIS, OASIS SOA RA, OASIS SOA RAF, OASIS SOA Reference Architecture Foundation, OASIS SOA RM, ODBC, OMG, ONA, Ontology, OO, Open Group, Oracle, orchestration, organizational change, outsourcing, ownership, participant, pattern, patterns, people, planning, policy, principle, principle of separation of concerns, principles, Principles, priority, Private, Private Cloud, process, Process, process-oriented, process-orineted, process-service, project, Provisioning, Pub/Sub, Public, Public Cloud, Public Cloud Busienss Requirements, QCon, RA, RAF, re-composition, Real World Effect, Real World SOA, redundancy, Referemce Architecture, Reference Architecture, Reference Architecture Foundation for SOA, Reference Model, Registry, rent, rentable Cloud, Repository, reuse, RIA, risk, RM, ROI, RPC, rules engine, RWE, SCA, scalability, Schema, security, semantics, Service, service, Service Autonomy, Service Composability, service contract, Service Contract, service description, Service Description, Service Discoverability, Service Execution Context, service orientation, Service Orientation, Service Oriented Enterprise, Service Relative Autonomy, Service Reusability, service semantic, Service Separation of Concerns, Service State Management, Service Statelessness, service-oriented, service-oriented eco-system, Service-Oriented Enterprise, service-oriented enterprise, service-oriented environment, ServiceContract, seven properties that differentiate emergent architecture from the traditional approach to EA, shared interface, shared library, simple, situational, sizing, SLA, SO, SO environment, SO Principles, SOA, SOA Manifesto, SOA standard, SOA-RAF, SoaML, SOBA, social, social networking, SOE, SOEA, software, solution SOA, SOMA, Spring, stakeholder, standard, Standard, study, subject, Summit, supply, supply chain, support, system, T-SOA, tangible, tangible value, Technical, Technical Architect, Technical Architects, Technical Architecture, technical capabilities, Technical SOA, technology, Technology, tendency, The Open Group, TOGAF, TOGAF 9.0, top-down, transparency, UI, UI Mediator, unstructured, use, Value Chain, Value Network, Value Networks, view, view model, viewpoint, vision, VNA, VPEC-T, WCF/WF, Web, Web 2.0, Web Service, Web Services, WebSphere, WS-CDL, WSDL, ZapFlash, ZapThink,

Monthly Archives

Blogs

ADVERTISEMENT