(sorry, the message was sent prematurely)
... Second, existing applications and even newly built applications are not services unless the "design principles that guided how an IT" are principles of service orientation. An application with Web Service or REST interface is just the same application with a new interface, it does not become a service because of the interface. Moreover, SOA does not " focus on individual applications" but on the functionality; it is an implementation of SOA deals with individual applications that are seen as information resources rather than potential services.
Third, it is a seldom case there applications may be combined into service(es); usually the applications and data sources are kept outside of services as their/shared resources. Services own functions, not data resources; this gives them full business and technology flexibility. If people need just data, they should use database drivers on HTTP steroids, if they want. Service usually form a service (not interface) layer above applications. This gives the services ability to use alternative (redundant, competing) applications providing the same functionality. This decouples services from existing enterprise application landscape and makes applications a second class citizens - if the application or related team does not meet the needs of the service, it moves to another application/source. The service become the Master and the application becomes the Servant.
Forth, the statement "services centered around a business process" is simply wrong. Business process is a business service to its consumers. Services are centered around their own functionality only. If a service is realised by a business process, i.e. this is an orchestrating service, its functionality is the process logic. Everything else this orchestrating service obtains from engaging other services, which might even not knowing that they serve an orchestration or a business process. Business process is a type of implementation of a service, nothing more. Moreover, a business process is only the logic of process; everything else - actions and their providers - are arbitrary if they provide needed intermediary results.
3. Yes, service interfaces are API, but this is the only one point of interception. API does not necessary represent a service; a service is not recognisable behind an API. API allow avoid/ommit services altogether. API have nothing to do with service orientation except being a description of the programmatic point of access to the service. Comparing API with services is like comparing apples and oranges (hoth have drupels).
4 "Both SOA and APIs purported to focus IT on delivering consumable services related to a business process" - wrong, API purpose is to focus IT on delivering applications first; everything else is optional. We are back to the Application world becuause it is easier to developers to understand (much easier than services). Also, applications, with no doubt, sit in IT while services more and more shift into Business, outside and without IT. What is going between services and API is very similar to what happened to ESB: from an enterprise independent components (proto-services) (v. 1 and 2) they finally were transformed into simple objects (v3) that were very familiar to developers. IT eats services for breakfast.
5. "SOA presumes that an IT department carefully manages and curates access to the services it delivers" - this is inaccurate note: business service servs business consumers. The latter carefully select which provider to deal with. API do not have such business accumen. Yes, they are more open (and easy for developers) and more dangerous (to the business consumers). Example: Cloud APIs have demonstrated on several occasions how the public Cloud providers set up the company businesses - there were no consumer-centric Service Contracts.
"SOA mirrors integration efforts of years past, where access was created on an as-needed basis, and generally only between trusted and well-known partners" - this is true while APIs(whithout such trust) are simple traps for the businesses.
APIs will move further until business take services out of the IT domain ander the business ownership and supervision. This is the way to go for SOA (which I write in my last book about with regard to Business Architecture).
Best regards,
- Michael Poulin
----- Original Message -----
From: Mike Poulin
Sent: 05/07/14 09:38 AM
To: Ken Laskey, Peter F Brown
Subject: Re: [soa-rm] Interesting article on SOA and APIs
My take is different.
1. Patrick Gray (the author) points that it is IT is in the focus and that IT is creating the services, "I have long advocated viewing enterprise IT as a series of business services that IT designs, builds, and maintains." I believe that this is the mistaken statement. In Business Services, IT has nober 2 role if any. A lot of Business Services exist with no IT involvement.
2. "Until fairly recently, advocates of this view would generally suggest IT implement Service-Oriented Architecture (SOA), a series of design principles that guided how an IT organization designed, built, and maintained applications. Rather than a focus on individual applications, SOA suggested that multiple discrete applications and data sources be combined into services centered around a business process." First, IT is not only one who implements Service-Oriented Architecture
----- Original Message -----
From: Ken Laskey
Sent: 05/06/14 09:53 PM
To: Peter F Brown
Subject: Re: [soa-rm] Interesting article on SOA and APIs
I understand his distinction but I see a different pattern.
To begin with, every service needs an API or a combination of endpoint and defined information exchange that essentially defines an API. And, of course, every API provides access under certain circumstances. So the question cannot be one or the other.
It is interesting that the difference noted is really one of control, with services being connected with more stringent control. Now there is nothing inherent in services that requires this control. Moreover, I believe the idea of control, under the fancy title of governance, traces back to the day we admitted that dynamic composability was too hard and we had to find a use for all those shining new registries. The registries were then billed as the ultimate governance tools — follow my rules or I won’t let you into my registry! The fear of a Wild West of providers giving options and consumers making choices led to long approval processes that did more to paralyze the service ecosystem than make it “run right”. The pushback was then just to post APIs in a less controlled space.
So the difference is looking into two mirrors, one full of fingerprints and another with a fine layer of dust. Which one gives the better reflection? Take your choice.
Ken-------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
”Using Information Technologies to Empower and Transform”
200 S Barrington Ave., #49719
Los Angeles, CA 90049, USA