It is important to first staff off by a clear articulation of what SOA is and more importantly what service in SOA is. as you may notice in debates worldwide, this is a bone of contention which never has a real right answer. I do tend to think that after all the crap we have been on service granularity debate, we are now close to a clear reasonable definition and incidentally that definition is close to what Business thinks of in terms of service.
A classic definition of Business Service as businesses perceive "is a capability (standalone or choreographed in implementation) which delivers value to consumer (internal or external)". It is important to stress the word - "CAPABILITY" - as well as the fact that it delivers value to customers - internal and external. Note that at this time we dont make a distinction between whether it is external/internal - an internal capability to procure something is an internal service being provided by Procurement function to enterprise - may not have a direct bearing on an enterprise customer if the organization is say in Government business or in my case stevedoring business.
It is also understood that capabilities have to exist in hierarchy - either standalone - atomic (executed at one time by one function) or a choreographed capability - e.g. risk assessment undertaken by banks - it is an amalgamation of series of capabilities - by the person accepting the application, by credit risk functions assessing customer credit profile, market risks etc. Also note "Value" - this is sometimes causing of heartburn between EA groups and business. Every organization has a value chain and sometimes certain capabilities are core or in context of core and sometimes some capabilities are non-core. For example, Human Resource management in classic sense is a non-core capability to an organization running stevedoring business, but rostering of human resources for planning will still be "in context of core". The decisions on sourcing of these business services are taken later on, so at this time from business perspective, all of these are services.
Interestingly there are some connotations to business definition of service which are relevant to SOA. Say my
Most competitive businesses keep defining a service portfolio but also aggressively track the relevance and value of services.
The definition of software service is no different from the business service. There is a one to one correspondence to that definition in context of automation i.e. if you tell me that capabilities, business process (end to end value capability orchestrated/choreographed) is applicable.
The key characteristics of these services are : loosely coupled, networked, well defined contract, discoverable, standardized, Interface and implementation separation, platform neutral etc - all of which are fairly straightforward to understand
SOA then is a simple architecture style wherein software is delivered through services which mimic business capabilities. Some people may want to say that given the tectonic shift which SOA is brining to add policies, framework and process within the content centric aspect as highlighted by architecture.
Note that history and birth of this movement is entrenched in software development history.
SOA's core value is "ready to integrate", "reuse" and "agility to change". Incidentally an additional benefit of SOA is business process focus and its clarity to IT staff - making it the best possible tool in arsenal to bring IT solution and business teams together like never before. Given that most SOA projects programs enforce a burden on business to own up software services, the alignment keeps on increasing.
No comments:
Post a Comment