Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Why Service Orientation is so difficult to Business?

user-pic
Vote 0 Votes

First of all, I have to admit that the question is ambiguous. Why is it difficult and what, actually, 'difficult' means? For the sake of this post, I would define 'difficult' as the absence of massive and almost immediate acceptance of the Service Orientation concept among business people, which leads to the need to discuss it again even after several years of intense publications in the business media. I think I have found a few answers that endorse the statement of difficulty as well as a few arguments that challenge this statement.

The first answer that ratifies the statement of difficulty is reputation. Service Orientation, being known as SOA (while these are not the same things), is originated in IT and traditionally carries the 'difficulties' of IT in the Business eyes.

The second answer is semantics. In the business terminology, to my knowledge, a word 'service' is associated with 'product', with the things provided to external consumers. At the same time, there is a strong belief that within the enterprise Business deals (almost exclusively) with processes, which is not necessary true if we take a close look at it.

The third answer comes from the holy grail of 'operational model' that is treated as an essence of the enterprise value. Many believe that the operational model is the root for everything in the enterprise and even a distinguishing factor outside of the enterprise, which is naïve if not wrong.

So, there is a long and, probably, painful way in front of those who want to clean out the concept of Service Orientation from narrowed views and pre-justice to uncover its real value to Business. The concept of Service Orientation is a way of thinking a bout the things as well as a perspective for analysis and usage of the things and their relationships. We have heard many times how Business management swore it took servicing consumers as the highest priority while inside the company the same management appeared holding a self-centric position pushing internal consumers to consider the constraints of the providers. In other words, even if we were able to explain Business the value of pure Service Orientation, it would require serious shift in mind to accept external rules of service for internal relationship.

Currently, the internal relationships in Business are based on an 'operational behaviour'. The driver of the majority of events and business activities is "how we are doing things in here". If a business process has a glitch, the process manager requires excuse on the basis that a sub-process of its sub-process has failed. It is unclear why internal consumer of this process has to suffer and always 'share the pain' of the process manager. Just recall what would be done to that process manager if the glitch would 'happen' to an external consumer, i.e. when'service behaviour' would be expected.

I have seen a few examples (unfortunately) where divisions in the company worked with each other based on contracts like SLA. The products in these cases were in essence the collaborations of internal services. These services had different implementations and many of them utilised processes and sub-processes. However, the management and delivery 'minds' were set to target the outcomes rather than ordered activities, i.e. processes. The latter did matter, definitely, but they didn't over-shadow the goals and reasons of why particular processes existed.

If we look closer at how the enterprise business moves from one state to another, it would not be difficult to find that there is a common gap between the setting strategic goals and following business activities. In too many organisations, the declaration of the strategic goals is immediately followed by the question 'How we gona do it?' and the construction process starts. On the way, a lot of questions come about what was actually meant by new strategic goals. The gap, that I mentioned, is in the lack of real understanding of what the task and sub-tasks were about while 'how to' had started already.

The gap has the consequences: business units usually try to tailor the strategic requirements to the existing processes with as minimum as possible changes for them. From one hand, it is a good practice that utilises existing assets; from another hand, it may become a stopper for the company because if new things fit not that well into existing processes and operational structure, the mentality of stability and robustness associated with the process-based operational will resist changes and can lead to tempering the strategic goals.

To build service-oriented solutions, Business should accept that the 'way how we doing things' is the subject of frequent and urgent changes nowadays. If Business provides for services, the operational model may not be the dominating factor of business mind any more. Services are about capabilities, business functionality and Real World Effect resulted from the service execution. Conceptually, services encapsulate processes and this allows to satisfy both internal and external business consumer needs.

Very valuable analysis of many organisations, performed by Dr. Jeanne Ross with colleagues and published in 2006, was based on the business practices observed for previous 10 years. The analysis allowed to summarise the experience of the most successful companies of that time. Today, the economical and market conditions have changed so significantly that this requires a revision of the recommendations. In particular, the increased pace of the business reaction to the changes in the external (new regulations and laws) and internal (new sources of work forces with much more diversified culture and skills) environment calls for re-thinking the role of process-based operational model; the enterprises now are viewed and distinguished in the market not by how they work but by what they provide to the customers and how quickly they do it.

There is a break in the business integrity when an enterprise must to switch from internal processes to external services. The more adequate and agile model is the one that allows delivery of external services via compositions and re-compositions of internal service. Since services do not expose their internal dependencies and constraints, encapsulation of internal services by an external service is much less risky to the business than the same exposure performed by processes (it is next to impossible selling your internal process to the external customers; customers do not want to deal with your ordered activities and problems).

This, to make Service Orientation really available to Business, they have to get their mind 'out of the box' of process-based operational model and put WHAT before HOW in their daily practice.
Reference Lable.JPG

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