Self service IT Requirements: service orientation

Self Service Platforms often provide a lot of possibilities and features, but not all of them are necessary to end users in all situations. Therefore, it should be possible to disable features if they are not required. Disabling features should not affect the platform itself. This approach is also described as Service Oriented Architecture (SOA). (Jossutis, 2007) defines SOA as the following:
 

“Service-oriented architecture (SOA) is a paradigm for the realization and maintenance of business processes that span large distributed systems. It is based on three major technical concepts: services, interoperability through an enterprise service bus, and loose coupling.” –  (Jossutis, 2007)

 (Jossutis, 2007) describes 3 main aspects of SOA: services, interoperability and loose coupling. A service can handle different things such as providing simple read or write operations or more complex functionality that might be used in workflows. Services are normally described in an abstract way, which should help bridging the gap between IT and Business. In a self Service Platform, different services enables us to simply disable services that are not necessary, add new services to the platform or enable existing services. As stated earlier in this section, adding or removing services should not affect the platform in any kind. To achieve this, it is necessary to decouple the services.
Another key concept of SOA is loose coupling, which basically states that services should continue to work even if other services are missing and that services might not know about other services. Loose coupling also means that dependencies should be removed. If one service is updated to a new version, all other services that might interact with the now updated service should still be able to work without any modifications. This requires a very abstract way of communication: messaging. Messaging via an Enterprise Service Bus improves interoperability for system integration. Services now simply don’t communicate with each other directly but they rather post messages to an Enterprise Service Bus. The Enterprise Service Bus keeps the message alive until someone (typically a service) processes the message. Services usually don’t know about the service they are interacting with since it is like in a fabric: Person A leaves a message that the new tools are ready for pick-up. Person B that is in charge for picking up tools sees the message and brings the Tools to another department. The communication is much more asynchronous now, since the service simply doesn’t know when the task will be processed. This type of communication is very similar to the communication used by people on smartphones/mobile phones. Person A sends a text message to Person B and Person B will eventually reply (or maybe not) to Person A. Synchronous communication would now be if Person A simply phones Person B.  (Miller & Cardoso , 2012) also describes SOA as a key driver for Internet-based self Services in their work on SEASIDE.
Image Copyright: Intel Free Press