Tag Archives: service

Inside of a Dog, it’s too Dark to Read: SOA and Business Variation

Groucho Marx once famously said “outside of a dog, a book is man’s best friend. Inside of a dog, it’s too dark to read”

The amusement is that the word “outside” is semantically ambiguous. What’s less funny is the SOA Manifesto stating that they will follow the principle of “Pursue uniformity on the outside while allowing diversity on the inside.” Much like the Groucho Marx quote, the antecedent for “outside” is ambiguous. Outside of what?!

Groucho_Marx2
(Picture of Groucho Marx looking a bit like Ron Schmelzer)

Why is this statement problematic?

First and foremost, I chastise this statement because it is sloppy. Sloppy architecture is what got us into this mess in the first place. But more importantly, this statement reflects a narrow, IT centric view of the scope of Architecture which leads down a dangerous path. Complexity theory has a term called a “holon”. A holon is something that appears to be a whole–yet is a part of something larger (e.g an organism is part of a biosphere). By confusing the antecedent for “outside”, the SOA Manifesto focuses on the holon of the service interface. If so, the reworded principle would be “Pursue uniformity on the outside (of the service interface) while allowing diversity on the inside (of the service interface).” The problem with this statement is that it ignores the concept of diversity on the outside (of the service interface).

Diversity on the outside solves the business complexity problem
Lest you think I’m splitting dog hairs here, why is this of any importance?

Because everyone is presently overfocused on the complexity of the IT Supply rather than the complexity of Demand on IT. The business is driven to compete, innovate and requires Internet style services that scale and can be consumed on any device in any language, anywhere and any time. They demand self-service, personalized, localized, mass-customized and differentiated customer experiences, and they require access to the same information whether it’s in a customer contact center, on a web browser, an internal application, on a mobile device or at a branch office. Business demands complex consumption patterns on the outside of the service interface.

By ignoring the consumption pattern diversity, attention is only drawn to the IT problem of managing complex IT supply. One of the biggest flaws in SOA implementation, and arguably the reason why Anne Thomas Manes declared “SOA is Dead” is the lack of connection between SOA and the business solution. The ability to dynamically compose solutions into composite applications, mash-ups or business processes using business services is the central underpinning for agility and business transformation.

Managing Business AND IT Complexity
This requires the ability to solve the problems of Business Complexity and IT Complexity. Services are just tools that allow you to trade consumer complexity for trust, thereby improving manageability. Processes are tools that take full responsibility for complexity, thereby enabling optimization. The primary function of Services in this context is to manage the interaction between two specialized organizational subgroups. This allows one group such as business unit to consume the services of another group say, IT without having to know the gory details of the implementation of the service. Insulating the business from the complexity of IT is helpful, since the IT subgroup is highly specialized and therefore hard to understand. However, two implications arise, firstly that the business group is also highly specialized and therefore complex. Secondly that IT cannot abdicate its responsibility for IT Process, unless of course it is prepared to outsource the service. The provider view of a service is process-oriented, only the consumer view of service is service-oriented.

The “new normal” Business Environment
A good example of this complex consumption pattern is Software AG’s recent partnership with Tom Tom Work–who are now able to offer fleet management as-a-service to their business customers. The ability to offer outsourced transportation and logistics management enables Tom Tom to provide a new differentiated service on top of the core competencies of their organization, namely location-based services. The power to dynamically recombine core capabilities into new product and service offerings while simultaneously offloading non-core competencies to partners reflects a “new normal” business environment. Complexity should be seen as a function of specialization, and organizations should identify which sources of complexity they want to embrace through process-orientation, and which sources of complexity they want to eschew through service orientation. Eschewing complexity through service-orientation requires the discipline of segmenting specialized Enterprise subgroups and actively deciding whether your organization wants to invest in world-class processes or divest services to outsourcers. No single person in the Enterprise can understand the total complexity of the value chain, but this does not lead to weakness as long as you can align internal and external subgroups through trust or by developing a trusted framework of operation.

Trusted Frameworks

A trusted framework allows you to manage complexity housed in many discrete silos without requiring explicit trust between specific providers and consumers. By externalizing trust into policies that are uniformly enforced, we create a trusted environment. An example is automobile traffic. Automobile traffic is exceedingly complex, and no single driver can understand what is in the minds of all the other drivers. In fact, when one goes on the road, it is not because one trusts each and every driver explicitly, rather that there are enforceable rules of the road that have been declared and enforced. Individual trust relationships between drivers is not scalable. So a driver trusts in the framework of policy enforcement. Similarly, trusted environments hold the key to enabling spontaneous networks of collaboration between Enterprise subunits and external partners and suppliers.

As such, the business and IT functions need to develop a framework of trust that creates the possibility of continuous improvement–an evolutionary paradigm that at the Enterprise scale requires continuous measurement, continuous optimization, continuous alignment and continuous collaboration. If SOA and Enterprise IT are going to bury their heads on the “inside of a dog”, it will be much too dark to read the intentions of the business.

My 2 cents,
Miko

Incoming search terms:

Posted in Cloud | Tagged , , , | Comments Off

ESB Hate Storm

Lots of hate for the ESB lately.

Everything from Joe McKendrick’s E-s-Busted to Dave Linthicum’s ESB Hurting SOA, we are in the midst of a full-fledged backlash.

I’m certainly sympathetic to these views. The SOA “patient” is already pretty sick. Years of Tribal IT battles, “quick fix” technology solutions that dont interoperate and create more hassles than they fix, project funded IT driven by inconsistent objectives and just plain years of abuse. This after years of “waxy IT buildup” leaving the communications “arteries” of the company rigid and atherosclerotic. Business units are demanding solutions to Business Process problems and quick fixes that existing IT infrastructure can’t support.

Any “expensive cures” for this patient steals valuable money from proven technologies that might have a chance to save the patient. So if some vendors have exploited the pain of this sick patient, I can see why there’s so much anger in the blogosphere for this approach.

The big problem with ESB isnt that it’s of no use. as Lori MacVittie pointed out, ESB exists for good reasons.

The big lie:

The problem is that ESB by itself was sold as a “magic cure” for:

1) Silos, and

2) BPM (Business Process Management)

So along comes this “doctor” called Enterprise Service Bus. All you have to do is take the magic ESB treatment and years of architectural degeneration will be cured… right? Wrong! And the backlash against the ESB “quack doctor” begins.

The “Magic Cure for Silos” Enterprise Architects Rejoice!

Why are people so angry about this? Well, first of all, the ESB “doctor” is guilty of some amount of malpractice. The word “Enterprise” as applied to Enterprise Service Bus is really as descriptive as adding the word “Enterprise” to any piece of software that isnt Enterprise just to make it sound more serious. See, the problem is that this “Bus” wont take you downtown. It wont take you out to the suburbs. You have to change busses 10 times just to go down the street! Proponents of the ESB originally sold the “bus” as a single conduit that ran all the way across your enterprise. Frankly, this just never happened. Getting business units to “standardize” on a single vendor for ESB just hasnt been realistic. Why is this? Because every vendor has an “ESB” and some vendors have 3 or more ESBs (!) So you have an ESB slabbed on top of your Enterprise Apps from Oracle or SAP. You have an ESB from your app server vendor. You have ESBs from your integration vendor. So you end up with a half dozen different brands of ESB all over the place. So people are angry because the “Enterprise” in ESB never happened. This basically means that business unit silos are unaffected by ESB for the most part. All sales teams look for the “Enterprise License” for the products, so why not try to sell your product as a solution for an “Enterprise-wide problem”.

The “Magic Cure for BPM” Business analysts Rejoice!

The second expectation that really wigged people out was the concept of Business Processes orchestrated on top of an ESB. People had this great concept that you could take an ESB product to a business person and some standards based orchestration language like BPEL. BPEL was oversold, I think it must have been the “Business Process” in “Business Process Execution Language” that fooled people. Setting the expectation than an ESB by itself can solve the BPM problem is just naive. If you peel back the onion and look at “orchestration” flows within the ESB, you are looking at integration-logic, not the kind of logic that business people use to solve business problems.

So what’s the reality here? Reality is that you need to accept the fact that, while useful, the ESB was never designed to solve either of those problems. If you were conviced those problems would dissappear when you bought your ESB, sorry guy, you should have read the fine print. ESBs are actually pretty handy for solving integration problems. Should we throw out our ESB? No–just because an ESB is a poor environment inside of which to do BPM and a poor environment to eliminate Enterprise Silos, it happens to be a good environment within which to implement “Business Services”. Don’t think of an ESB as the thing ABOVE the services playing any kind of architectural role: think of the ESB as another kind of app server, and therefore a place inside of which you create and implement a service. Is BPEL a reasonable choice for implementing a service? It’s a little functionally limited, but sure, you could do it. So if you put the ESB in its proper place BELOW the business service interface, you can be made happy again. Leave the Enterprise Architecture and BPM to the other systems please.

So how do we go forward from here? Well, first of all give up on solving Enterprise Silo problems by either forcing a single brand of ESB across all silos or trying to program BPM in your ESB. There is no magic cure.

The (non magical) Solution

If you want to solve the problems of Enterprise Silos, you need a way to federate policy and enforce it across silos. This is what SOA Governance solutions ought to do. Get a SOA Governance solution. Is this enough? No! You also need Enterprise Architecture competency. You need a SOA Competency Center. You need to actually do the work.

If you want to solve the problem of BPM, get a BPMS. Will that please the business by itself? No! You also need to align processes with IT capabilities (services anyone?). You need to ensure that process models can be monitored with a Business Activity Monitoring (BAM) solution and you need to make adjustments (process optimization) over time. You need to do the work.

Sorry, like heart disease, you may need to make lifestyle changes. The shiny ESB you bought unfortunately wont get you all the way there. No wonder you’re mad.

My 2 cents,

Miko

Posted in Enterprise | Tagged , , , , , , , , , , , , | Comments Off

Business Service Transcends Component, Process and Event Patterns

This is pretty much a word-for-word transcript of an interview I did with IT-Business Edge about Web Oriented Architecture (WOA) and Service Oriented Architecture

http://www.itbusinessedge.com/item/?ci=41736

It reads a bit eccentrically because it’s a literal transcript, but if you know the SOA world pretty well, it gets my point across about what a Business Service is and how it transcends components, processes and event based architectural patterns.

Posted in Enterprise | Tagged , , | Comments Off