Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

ONA as the Key to the Service-Oriented Model of Business Organisation

user-pic
Vote 0 Votes

A friend of mine once told me that the concept of Service-Oriented model of Business Organisation described in my book "Ladder to SOE" is not realistic because it is not based on business processes, that such model may not be effective in an enterprise.

Well, this is a serious charge. I've decided to pay more contribution to this topic in my next book. Unexpectedly, I have found a 'support' - these days Dr. Laurence Lock Lee published his work "Organisational Network Analysis - beyond Business Process Mapping", which consummates with a very similar organisational concept while approaching from the absolutely different direction.

When analysing traditional Business Process Mapping method Dr. Lee says: "Total Quality Management, Lean Manufacturing, Six Sigma, Business Process Reengineering all have the "Business Process" as their centre of attention for business improvement. When we try and unpack the "Business Process" term we find its usage often stretches far beyond the technical workflow processes ideally addressed by Business Process Analysis Techniques. For instance, are the subtle negotiations between a sales person and a client adequately captured in a process map? What about the interactions between a caseworker and client? "

We know that there are many businesses whose model does not fit well with traditional business process chain - such businesses incorporate users and customers, who cannot be controlled, as well as the human processing element that tends to be relatively variable within the business process. To some degree, these alternative business models include business process chain but the latter is not the conductor any more. Dr. Lee notes: "Subjecting these alternate business models to traditional process analysis and analysis techniques is essentially a misuse of resources." The business models with significant human factors require for the analysis more than BPM can provide - the additional methods are Social Network Analysis (SNA) and Value Network Analysis (VNA).

One of the major results of presented work is the conclusion that a view on the business organisation from the perspective of the business role can combine the best from the individual-centric view of SNA with the tangible and intangible value flow of the VNA; Dr. Lee has called this role-centric view the Organisational Network Analysis (ONA). The core element of ONA is the relationships and dependencies between the business roles in the organisation. Figure 1 illustrates the positioning of ONA between SNA and VNA.

Figure 1.

Explaining how a Role-centric analysis work, Dr. Lee writes: "Typically a role will be seeking value from other roles and in turn other roles may be seeking value from them. If we look at the strength of demand and supply around a node we can effectively do a value "mass balance" to identify whether a particular role is a "value source" or "value sink". This "value source" - "value sink" concept is illustrated on Figure 2.

Figure 2.

Dr. Lee continues: "The nodes are sized by the relative number of connections they have. The thickness of the line shows the relative strength of dependence. Value sinks are roles that tend to "demand" more from others than they "supply" to others. Alternatively the opposite is the case for value sources. A simple interpretation could be that value sinks are bad because they take more than they give, so we need to work on these. More subtly however, strong value sources could also be bad if the demand on the source is due to a lack of capability to efficiently service the demand. And perhaps a lack of capability could be due to a reluctance to draw knowledge from other sources. "

Well, you can say that these analysis methods are interesting but how do they relate to Services Orientation and Service-Oriented Enterprise (SOE)? The three words are the keys to the understanding the answer to this question: 'capability', 'demand' and 'supply'. In ONA, a role represents a business capability that may be in demand from other roles and, simultaneously, this role may appear as a provider or supplier to other roles. Don't we have an ideal description of the service relationships here? We will return to this obvious analogy in a moment but now let's put some attention on the consequences of the Organisational Network Analysis.

Dr. Lee has conducted a case-study and completed: " What is immediately apparent is the difference between the ONA map and the formal organisation chart as well as a typical business process-mapping chart. It is nowhere as neat or structured and there are a lot more connections shown [M.P.: in ONA]. While we can see some patterns where activities are tending to cluster along service lines, the connections between service lines are not very crisp. So which of the formal Organisation chart, the business process map or the ONA map do you think is closer to reality?" Then he says: "Business process mapping, when used for business improvement exercises, are meant to represent how a business currently operates. The analysis of the "as�is" situation is then meant to provide the opportunity to design more efficient processes from which the "as�is" processes can be adapted or even removed to achieve a higher performance organisation. But what if the "as�is" representation is only a poor reflection of what is really happening? "

In a few previous publications I suggested that a process-centric view on the business organisation actually obfuscates real business functionality picture by the operational details. For an enterprise to clearly recognise what functionality is the most important for it with regard to given state of the market, physical operation and subordination structures do not help much while orientation on service un-covers real business needs. Dr. Lee supports my statement when he clearly confronts operational 'as-is' processes with "what is really happening", i.e. with the market's demands and related corporate business needs.

Now, I can really summarise: the ONA Role is the mirror of the SOE Service - both are about business capabilities, both abstract operational business processes into the business function, both relay on the collaboration with the peers in delivering their own tasks (vs. supervisor-subordinate relationships), both aimed to the solving business tasks.

Also, I've found the 'value source / value sink' analysis of ONA very interesting and potentially useful for one of the most difficult service design tasks - service granularity. If a service granularity (I deliberately avoid talking about Service Interface because a service can expose an interface of any granularity constrained only by the granularity/scope of the service itself) if too coarse and the service encapsulates too many functionalities, it can become a huge value source and, potentially, a bottleneck to the entire system. If the service granularity is too fine, it is likely to be encapsulated by a relatively stable intermediary service orchestration (an aggregate service) and will not be used by many others outside of this orchestration. However, as a service, this fine-grained service must be treated as an independent application providing a little value for the system as a whole while sucking the maintenance resources.

Obviously, in SOE, we cannot predict what level of granularity will be in demand in Business in the future. So, we need to go with Spline Tactic but armed with ONA we can more effectively tune our business structures and, correspondingly, corporate investments into the business functionality.

Book Announce.JPG

2 Comments

| Leave a comment
user-pic

Why make it so complicated .

You are just describing the other 'services' that are not captured by the services in pure processes.

Idef0 for example long ago modelled all services and they are the totality of services that SOA facilitates in software structures.

Business process (eg BPM) do not include all services and therefore cannot fully feed a comprehension SOA approach.

Sorry, Graham, I have not understood the first part: "Why make it so complicated .

You are just describing the other 'services' that are not captured by the services in pure processes."

What pure processes capture services? Which pure process is not a service itself?

I am saying that software structures are not only the structures where SOA Services exist. This is the major point of SOA being in Business and IT simultaneously.

Which BPM you mean: management, modelling, monitoring?.. You are saying "Business process ...do not include all services and therefore cannot fully feed a comprehension SOA approach" - I do not understand the argument: why the condition of "all services" is so important for qualifying for SOA approach? Again, I am not talking about bpM, I am talking about BP - Business Process, which is nothing more than a business service to the consumers of the process.

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