Showing posts with label Nick Gall. Show all posts
Showing posts with label Nick Gall. Show all posts

Sunday, May 10, 2009

SOB - Service Oriented Business

I was having lunch with a friend and he asked me: "What is a simple definition for SOA that I can tell people when they ask?"  I thought about that and all the answers I came up centered around "How do we build it."  

When I googled it, I got lots of answers, but they were very technical in nature or used service in the definition:

Oasis: A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. citation


IBM: Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. 

Gartner: An application topology in which the business logic of the application is organized in modules (services) with clear identity, purpose and programmatic-access interfaces. Services behave as "black boxes": Their internal design is independent of the nature and purpose of the requestor. In SOA, data and business logic are encapsulated in modular business components with documented interfaces. This clarifies design and facilitates incremental development and future extensions. An SOA application can also be integrated with heterogeneous, external legacy and purchased applications more easily than a monolithic, non-SOA application can. Citation

None of these definitions were something I could memorize and regurgitate when a vice-president asked "What's this SOA thing?"

My definition is simple: "SOA is a way of organizing work that maximizes the consumer / provider metaphor"  A friend suggested I replace "metaphor" with "relationship."

As I was thinking about this definition, I was studying agile programming and there was a reference to the type of company: Functional-oriented vs. project oriented were what the book was referring.  My brain said, "What about service-oriented?"

Can we make a service oriented business (SOB)?  Certainly we have thought of that acronym about employees of a business who believes incorrectly that they are service-oriented.  But can we actually make a business that is completely service-oriented in the consumer / provider metaphor?  What would such a business look like?

Obviously at the top are services that are provided to other entities which they (asuumeingly) pay to consume.  Internal to these services, some work is accomplished.  But probably there are also underpinning services as well.  Services that we rely to make our service perform, stocked, etc.  And those services have underpinning services and so forth.

But if we consider SOA as maximizing the consumer / provider relationship, we could consider the underpinning service as its own business.  A business that "sells" its own products/services.  As a network of these arise, we can see the value matriculating from the end-consumer through our network of inter-related services.

What I find interesting about this concept is that it is value based.  A service invests its income in providing its customers what they want.  I know we have hear the "treating the other employees as customers" rhetoric hundreds of times.  But if we truly created a business as a network of services, would that change?

One other interesting thought that I have about this network of services.  It is ripe for outsourcing.  If we divided a company into logical semantically accurate functionality [work] and consider the "service" as an internal provider of that work and then we found out an external party can offer that same service at the higher value / cost matrix.  Wouldn't that inspire better investment into that service internally?

Said a different way.  Couldn't this help us meet our goal of All work that is necessary for a business to operate should be provided by an entity whose core competency is doing that particular work.

Just some things to think about.


Saturday, April 05, 2008

What does everyone keep considering WS-* as SOA?

I was reading Dana Gardner's blog on WOA will soon eclipse SOA as most impactful business transformation agent. I am confused why there is even a challenge.

Even at Gartner's Gartner Application Architecture, Development & Integration Summit Dec 2008 in Las Vegas had two men I highly respect Roy Schulte and Nick Gall (blog) had a point-counterpoint discussion about WS-* vs. REST. Although it was very fun to listen and participate, I believe that when statements about WOA replacing SOA doesn't seem to jive with me.

To me, SOA is more about take functionality and making it abstract, network-able and find-able. I believe that it's goal is to abstract functionality to the level that business people can understand and use it. That is why SOA is an incredible partner with Event Driven Architecture, BPM, BAM, Mash-ups, etc. When a business person (I would dare say the new "programmer") can understand the command of our new paradigm, productivity and effectiveness will go through the roof.

Perhaps the discussion focuses more around which is a better protocol for getting at the information. REST or WS-*. In that context, there is a lot of worthwhile debate. But I don't think an answer either way would make "WOA replace SOA" I think they are on different layers of abstraction.

I read a presentation of Nick Gall's (don't have the reference) and it said "We made software because hardware was too hard. Now software isn't soft enough. What is softer than software?" This is the problem I want to solve. I believe that the coordinated application of EDA (CEP), SOA, BPM, BAM in concert with a business awareness found in Enterprise Architecture will lead us down to the solution of Nick's challenge.