What is a service (Part II)

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.