IT Service Search: How to Choose the Ideal Partner

Software projects usually rely on a team with different roles, such as the examples listed below:

• Commercial Manager;
• Project Manager;
• Business Analyst;
• Systems Analyst;
• Software Architect;
• Systems Developer;
• Test Analyst;
• Configuration Manager;
• Quality Analyst;
• Measurement and Analysis Manager;
• Among several others that could be mentioned here.

It is a fact that any of these roles, even without direct responsibility for the subject, has already had some contact with the concept of SOA (Service Oriented Architecture). This architecture has been approved, envisioned, and referenced whenever a solution is designed, whether it is new or evolving.

What is the proposal?

The proposal of maturely and stably solving problems such as integration, reusability, decoupling, and scalability, among many others, is very attractive from both a technical and functional standpoint. However, it requires an in-depth study of its architecture and, above all, of the environment in which it will be implemented, since in the end, one must deliver a composition of services which will be nothing more than existing functionalities, reorganized in such a way as to respect the patterns of the implemented architecture (SOA), sharing common features across the various specific solutions of each business area.

During the implementation of this service-oriented architecture, considerable time must be spent precisely on identifying these services in order to achieve the actual benefit proposed by SOA.

Among the various techniques and theories of service identification, I would like to outline a small set of best practices, or considerations to be made during the execution of this activity. These suggestions were compiled from work carried out across different clients and varied needs.

Principle of simplicity

Just as in any solution definitions, whenever something becomes complex, the probability that we are following an incorrect path is high. This philosophy also holds true for service identification in SOA; that is, there are no infallible identification rules or ones that fit all cases. Therefore, it is very interesting to start from a simplified view and work with the fact that identification rules will be modified as work evolves and matures.

A practical way to start is by answering questions such as:

• Which business solutions are already integrated today?
• Is the project willing to modify part of the involved solutions in order to adapt to SOA, or must the implementations always be external to the solution, working together to integrate with the defined platform?
• Will there be integrations external to the business (the internet, for example)?
• Is there Functional Requirements documentation for each product involved? This is very crucial for the responsibility definition stage.
• Is there already any mapping between business units?
• How will we organize the identified services? There are standards for documenting and registering services, and registering them depends on the tool chosen as the bus. It is important to start organized to avoid excessive revisions later.

Keep the business in mind

Service identification directly depends on analyzing the representation of the business in system form. Therefore, having a good understanding of the data model of each solution involved in the integration is much more important than knowing the technical implementation of that solution. For this reason, this step should always be carried out in conjunction with someone who holds knowledge of the functional requirements and the data model of the solution, since this context contains the most useful information for defining how many, which, where, or where the identified services will reside. It thus becomes somewhat obvious—yet worth mentioning—that business modeling (BPM) applies perfectly as reference material for service identification.

To better understand this association between services and functional requirements, one can operate as if systems were people, and services were tasks performed by those people, where each person must be responsible for a certain set of information and, consequently, perform tasks requested by other people, maintaining the information for which they are responsible.

Emulate DDD (Domain Driven Design) concepts

Taking advantage of the connection between business, people, and information responsibilities, I strongly suggest reusing the concepts defined by domain-driven projects.

These concepts dictate that a system should be built by defining the domain of information for which it is responsible, completely isolating access to that information. Thus, any and all access to this information can only be made through the defined system; therefore, no information is obtained, modified, or deleted except through functions available in the system that masters the knowledge of how to maintain such information. The main characteristic of projects following these concepts is that, even modules within the same system must implement this division of responsibility by information domain. The image below simply demonstrates this separation of responsibility by information domain.

Observing the image above, one can easily identify the existence of a service candidate, which in this case is the service that maintains customer information. The use of concepts like DDD is not very common or fully implemented, so very few systems offer such simple and direct service identification. However, we can take the lessons learned from DDD concepts to look at the existing systems in our environments in order to separate the data domain that each understands and maintains, and from there assign responsibilities and begin identifying our services.

Assignment of responsibilities

In my view, the most important task in the service identification process is assigning responsibilities to each of the involved systems. This is because, from the moment it is identified that a system is responsible for certain information, the need for services that must be offered to other systems making use of this information becomes clear. Within the responsibility assignment stage, one can also separate information used solely to complement the system’s internal model from information that must be shared among other models belonging to different domains.

In short, a simplified workflow for service identification could be:

Conclusion

Services can be identified in a simplified manner, since the information necessary for their identification already exists and simply needs to be analyzed. Regardless of the strategy adopted (following theory, defining a custom one, or learning on the fly), this work must be taken seriously because it is responsible for making proper use of the service-based integration structure. In other words, it makes no sense to have a service bus that is technically optimal but used incorrectly, with poorly defined or poorly utilized services.

Service identification should always be done by a team and not by a specific individual, as it requires varied knowledge (technical, analytical, and business-oriented). Identified services undergo continuous evolution as the solutions comprising them mature and the business they represent grows. Even when based on a list of steps, it is necessary to study each situation to uncover specific needs that may require a differentiated strategy.

It is also important to remember that this is merely a suggestion to kick off service identification work and the implementation of a service-oriented architecture. If we go into details, we will discover that there are rules or standards for segregating services, or for defining contracts available in each service. It is worth noting that the results obtained—such as quality and the reusability of the service unit among other applications—make business units (services) interoperable and more flexible, adapting to business changes more agilely.

Start with a project that presents lower risk, perform a complete study of the business unit, and implement it. In the end, take away the lessons learned and increase the complexity of implementing the concept.

SOA – Service Oriented Architecture