After splitting the global term Service into three main categories (Business, IT and software), I’ll focus on type of services that we should define while creating our software services in this post. I didn’t spent an effort on type of services for nothing. The reason that I did it is obvious (at least for me), Software services aren’t a target or a goal they are just a mean to reach IT and business services (it goes without saying that the IT service Perouse is to serve business services)
Functional Services: The first type of services are the reflection of business services on software services. I call those services “functional services”. Those services composed from information processing, business logic and a workflow to be able to computerize all or part of business services (as defined by the business). Lets break “functional services” elements:
- Information: each service deals with data that need to be processed in one way or another.
- Business Logic: the way that certain data is being processed is usually coded into dedicate components that deals with the data.
- Workflow: functional services usually include several roles in the enterprise that carry on the work. As a result a logic regarding the flow of data between those roles is needed . This logic can be decision points as well as mail exchange and data exchange between different forms that the users are working with (as part of the functional service).
As we will see later on, functional services are the higher granularity of services and they composed from other software services. Another characteristic of functional services is that there aren’t any templates that enforce service interfaces to be certain (we’ll see it while we’ll deal with information services). Each service represent different business service with different needs and data to get as an input ad to hand over as output.
Information Services: those services are all about manipulating data. Information services must follow predefined service patterns that should be enforce to each information object that was defined by the enterprise. Usually those pattern are:
- Get data from information object:
- All data
- Just IDs by criteria
- Perform predefined actions (CUD and business logic) on information object
- Get Data from other information object by predefined association
The most important rules here are: to map the right information objects, to define patterns that will enable to manipulate and read data in any way and to make sure that all implementation of information object really done following the pre-defined patterns. Following those rules will enable you to build the functional services from collection of information services. It also will be useful for visual services as we’ll see shortly. And the most Important point is that such way of working will enable you to keep supporting the business through changes with minimum effort.
Visual services: Last but no least we have the visual services. Having all of our enterprise information ordered into information objects we what part of the data that we collected to have the same look and feel regardless where this data is displayed (different forms, application and even technology). This rule is mostly fits information items (such as phone numbers, addresses, names, etc’), but it can also applied to information objects. To be able to impose this requirement Information objects need to expose predefined visual services that not just return the data but also in a way that we want the data needed to be displayed. Regardless to say that visual services might use Information services in order to get data and that Functional services might use visual services to display data in uniform way.