Once we understand what is SOA and its principles, the next question is How to apply SOA to a standard organization?
Well, what SOA tries to say to a big organization that has a large number of systems with a high level of integration (remember the spaghetti dish), is, Stop turning a blind eye! That spaghetti dish is also your business!
What we mean by this sentence is that companies add new systems on demand as their business grows. In this scenario, the typical way to proceed is to add new systems and configure all the integrations needed with the current systems of the company. This way, little by little, the number of systems grows until they achieve the spaghetti dish.
What is wrong with this scenario is the thinking that interconnections do not play any role in the company business, but only play the simple role of an information socket. At this point, all the interconnections of the company have enough dimension and impact on the business that they should be treated like another part of the business.
SOA tells the company that all that system connections is a business that has to be managed. The company must go deep inside the spaghetti dish to understand the business behind it. Then, that business must be digested to turn a large number of wires between applications into business services. The beautiful thing about this is that after taking a look at these system connections and discovering the business behind them, the business that we find is the essential business of the company, which defines its identity and what the company is and does.
Once we realize that, let's see how we can bring SOA to our company.
The very first step to do this is service prospection. In service prospection, we look deep inside the connection network to look for the business behind it and turn it into business services. We need to know which systems produce information and which ones consume information. This analysis can be made with the following two strategies:
- Bottom-up: This approach starts analyzing the integration from the point-to-point connection (bottom) existing between the systems, building the integration map. These connections are linked together to result in another one in a higher level of abstraction, which will be the very first candidate services. We iterate several times over these connections/services, building high-level services according to the SOA principles until we achieve the business services (up) of the company.
- Top-down: This approach is the opposite of the bottom-up approach. It starts designing high-level business services (top) according to the business expert. Starting from that point, we iterate over them, increasing the level of detail in each iteration and splitting them according to the SOA principles. We stop when no new services result from the previous iteration (down).
Take a look at the following diagram:
Neither of the strategies are perfect and each one has its pros and cons. The top-down approach is theoretical and lacks the real-world vision, while the bottom-up part is data or real world but does not consider the business theory. Finally, each strategy has its advantages and disadvantages; so, the best practice is to apply both the approaches and stop where they both meet.
For example, we start by defining the high-level business service (top) and identifying the point-to-point connection (bottom); these are the ideally desired business services for the business. We follow this by adding detailed information to top-level services and splitting the services into other services that compose them. On the bottom level, we link or compose the services to generate higher-level ones; these are real-world services that currently form the business. Both the processes continue iterating until they meet each other at a point, where both the processes merge, obtaining the final set of detailed business services. These are the candidate services that have the ideal or desired vision of the business, but use the real-world services that are part of the current business.
These groups of business services will be the SOA catalog. The catalog is a registry where we can find, at the very least, the following information:
- The available services
- The services in progress
- Relationships between services
- Detailed information about each service
Once we have the service catalog of our future SOA organization, the following steps do not differ much from other typical IT projects:
We will start with the analysis phase where we determine what to do in each service. In the first iteration, part of this analysis has already been done during the service prospection.
This is followed by the design phase, where we define how to do it in detail. Then, services are implemented according to that detailed design and tested to move them to the production environment of our company. Finally, we are in the maintenance phase, where we control and monitor the business.
There is a new phase that is called SOA Governance, and it is present in all the services. The aim of SOA Governance is to define policies, standards, principles, and processes to uphold the SOA principles; in other words, its role is to ensure that SOA benefits the organization.
Once again, there's nothing new here; governance is a term from politics that is applied to the IT world, but instead of controlling and managing a country, it controls and manages the service catalog of the SOA organization:
The last element needed to build our SOA organization is the component that enables the consumer to discover which services are available in the organization, their functionalities, and how they can consume them; this component is known as the Universal Description, Discovery, and Integration registry:
So now, we are ready to turn our standard organization into an SOA organization.
