In my last post we discussed business capabilities and how they form the basis of how we identify candidate business services. But what is the physical manifestation of a business service? Once we've determined the boundaries of our business services and their responsibilities, how do we go about implementing them?
A business service is realised as a set of business processes and business rules, the people that perform those processes, the applications leveraged by those people in support of their roles in those business processes, the information leveraged by decision makers within those business processes, as well as the information as inputs and outputs of those processes, the semantics and structure of data held within the service, and the technology platforms on which the IT systems supporting the business service execute.
Business processes in different services coordinate their activities via business events. These business events define the interface (or service contracts) between business services.
A business service may contain no IT systems whatsoever. Where there are IT systems supporting a business service, they may not at all support the interface with the rest of the business. A business event may be realised by a simple telephone call or a memo sent between people participating in different business services.
Where IT systems do support the interface with the rest of the business, we have software components in different business services exchanging data. In the SOA style of architecture, this data exchange is performed by way of exchanging explicitly defined messages in conformance with a service contract.
Where we design our software components around business services (rather than taking the JBOWS, Service Oriented Integration or Layered service Model approach), business events are realised as event messages published onto our service bus. The technical service contract then consists of the schema of the messages published by the service onto one or more topics.
Inside the boundary of our business service, we may have one or more software components that exchange data via messages. For example, a smart client application supporting a business service may interface with one or more back end components using SOAP based messages.
These interactions that occur behind the service boundary are an implementation detail of the service itself. These design aspects are local to the business service and as such do not influence the business service contract or play a part in the broader architecture.
In conclusion, the way in which business services are manifested in terms of IT systems depends on the flavour of SOA chosen. By aligning our technical service contracts with business services and business events we achieve considerably better structural alignment between the business and the IT systems that support it.
Sunday, July 13, 2008
Implementing Business Services
Subscribe to:
Post Comments (Atom)
11 comments:
Great post Bill.
You made the following comment:
"For example, a smart client application supporting a business service may interface with one or more back end components using SOAP based messages."
My interpretation of this is that you're suggesting that lower level interfaces may be exposed "behind" the business service that ultimately lend support.
Using the Insurance vertical, would it be a correct example to say that your smart client above might be a simple CRUD app that allows users to update the set of business classification codes or underwriting rules?
If so, I might be inclined to think that we've created an Entity Service - which is a concept coming from layered architecture. However (and this is my real point here), it seems that what your suggesting is that these behind the scenes services should only be used in such a way as to support the business service they are implementing. In other words, the "Entity Service" that is provided for updating business classifications should not be used (directly) by a different business service. An indirect method, such as placing new business classifications on a Topic for consumption is more appropriate.
Have I missed the mark here?
Hi Troy,
You're right on the money. This argument very much comes down to our definition of a service.
Strictly speaking, a service is simply an autonomous coarse grained unit of logic that exposes functionality by way of exchanging messages conforming to an explicitly defined service contract via its endpoints with constraints imposed on consumers by service providers by way of policy.
As such, the concept of a service (and by extension SOA) is equally applicable both in the software domain and the business domain.
In the business domain, a service pertains to an autonomous business function - like Sales for example.
A business service may be implemented with or without software components. A business service contains business processes, during the execution of which we have the raising of business events.
There are many ways these business events may be propagated to their subscribers. It could be completely manual (e.g. putting a document an in tray), or it could be electronic (via the service bus).
Where a service contains one or more events that are propagated electronically, we have software components involved.
The point is that a service is not necessarily either manual (executed by people) or software (executed by computers). It is often both.
A business service is named as such as the function it performs pertains to an autonomous business function that supports other functions within the business. Its service contract is expressed in terms of business events and it aligns directly with the business.
We also have services that do not directly participate in the broader business architecture.
These services as you say support software components behind the service boundary. An example is software services that support a smart client application.
I wouldn't personally classify these services as entity services however. Entity services by definition have no business logic.
We really want task-centric services supporting our smart client applications. Each service operation in this case supports a specific atomic task performed by the user.
In some circumstances this may be a simple CRUD operation. But more often than not you'll find business logic being executed by the service (such as validation, workflow, and publishing messages onto the bus).
As you say, these task-centric services should not be used directly by software components in other business services.
Business services communicate only by way of event messages pertaining to business events defined in the business architecture.
Now, what do we call services the sole purpose of which is to support something like a smart client application? Well perhaps we could call them application services. They are services that support an application as opposed to the business at large.
Cheers,
Bill
Bill,
Thanks for the reply. You're right - Entity Service wasn't exactly the right term since there's usually some business logic involved. Application Service sounds just fine :-)
I definitely agree with your broader definition of Business Services - Service Orient or Be Doomed! is a great book that addresses this well.
Another question comes to mind here though: Is it necessary to have a service interface (via a set of Application Services implemented as SOAP/REST) between clients and the underlying data store that the Business Service depends upon?
Extending the insurance example further, we might have lots of what I can "reference data" to maintain - things like coverages along with their options and limits (which all happen to vary by state here in the U.S.).
Is it necessary to maintain an Application Service abstraction here? In other words, would it be a mistake to write a support application (or use some legacy code) that hits the underlying database directly? It would seem that this would be acceptable as long as the integrity/autonomy of the overall Business Service is maintained. It seems like extra overhead to develop some of these support services when I might be able to quickly generate an application using technologies like Grails, Rails, Seam, etc...
Thoughts?
Hi Troy,
You ask a lot of good questions, which is really appreciated. Keep those questions coming! :-)
To answer your question, it is not at all necessary to encapsulate data stores within a business service with a SOAP or REST service interface.
One point to note here is that a business service may in fact contain many physical data stores.
This could take the form of many database instances, documents, text files, queues, topics or any other persistent stores.
The form of underlying data store(s) is an implementation detail of the business service.
The key is that ideally business services do not share data except by way of message exchange.
Furthermore, you can have many different applications supporting a given business service if that is appropriate for the business processes that execute within it.
So indeed, you certainly can have applications that manipulate data in databases within a business service directly without going through a service interface. In fact, this is quite common.
The only time you need to surface functionality through SOAP/REST "application services" is when you are trying to expose functionality through multiple applications (user interfaces), or when you are trying to expose this functionality as part of a larger composite application.
Obviously if you want the same functionality surfaced through multiple applications, you need to have each of those applications interface with a common back end component.
If you want to produce a composite application that brings together functionality from multiple business services into a unified user experience, then you will again need to separate your UI onto a separate tier to make that possible.
Regards,
Bill
This is really informative as well as an interesting post to read. Thanks for the good info! The ideas and insights are very worth reading.
Very thorough and informative article related to business! Thank you for sharing this information.
thue dj choi nhac tai ha noi
This is such a great resource that you are providing and you it away for free. I love seeing blog that understand the value. Im glad to have found this post as its such an interesting one! I am always on the lookout for quality posts and articles so i suppose im lucky to have found this! I hope you will be adding more in the future...
new company set up in singapore
Interesting blog, after reading this blog I got more information regarding company formation in Singapore. It is helpful to many of us.
company formation in Singapore
Car wash is one of the services that car owners are most interested in. Because it ensures that the car is always clean and kept new. Car Care Ware is a blog that helps you l things about car cleaning products, equipment, and processes.
https://www.folkd.com/user/carcareware
https://3dwarehouse.sketchup.com/user/093856e6-a114-44c9-85cc-1c5f18f0efcb/Car-Care-Ware
https://getpocket.com/@carcareware
https://ello.co/carcareware
https://angel.co/u/carcareware
https://www.behance.net/carcareware
https://www.brusheezy.com/members/carcareware
https://forum.cookierun.com/user/carcareware
https://buddypress.org/members/carcareware/profile/
https://www.kongregate.com/accounts/carcareware
https://500px.com/p/carcareware?view=photos
Thanks for your wonderful blog and great post. Here at Shreecaterers, our caterers and business Wedding Planners in Bangalore are specialists in putting together the most ideal food and service package for your wedding day. Brahmin Wedding Planners in Bangalore | Brahmin Marriage Contractors in Bangalore | Brahmin Wedding Caterers in Bangalore | Tamil Brahmin Wedding Caterers in Bangalore
Thank you for sharing this great piece of content. You have given so much information on how to implement business services. Looking forward to seeing a similar type of article in the future. Best Auditing Firms in Dubai / VAT Services in Dubai / VAT Registration in Dubai / VAT fine reconsideration
Post a Comment