 |
The critical aim of the service-oriented architecture is to bring services to the business enterprise. In the world of enterprise architecture, the service is defined as a unit of functionality packaged for convenient and consistent use. While this definition is accurate as far as it goes, it leaves unstated a concept which is implied but not often explicitly seen during the design of the SOA. Notice that the definition says that the unit of functionality is “packaged for convenient and consistent use.” What is unstated here is used by who or what. Just as that who or what is not an explicit part of this definition, it can very easily not be an explicit part of the design. What we are trying to do here is make a common sense and yet much ignored point about this “who and what.”
The “who and what” of course are the business enterprise processes. The service cannot become a service without something to be served. In order to understand how the service is to be used, we must first understand the processes that are to be served. Gaining this understanding is a step that is very often ignored or given short shrift in the process of SOA design.
The problem we are considering is a subtle one because it is an opportunity lost in the architecture design process. It has to do with the fact that the architecture design has most often turned on the assumption that the functionality currently being offered to the enterprise through the IT system represents the sum and substance of the functionality needed by the business enterprise. That might be essentially true in some cases, but unless we engage in a detailed examination of the business processes themselves we cannot know how large an opportunity to serve those processes we might be missing. It is a mistake to treat the enterprise business processes as a black box and infer their service needs from the service functionality currently being offered.
This inference of service needs can cause us to lose focus on the basic meaning of a service. A well-designed set of functionality needs something more than efficient and uniform packaging in order to become a service. That set of functionality is only a service in so far as it actually serves a process. The concept that can be lost in the typical SOA design process is exactly that. A service must serve a process. To the extent that it does not, it is a set of functionality that defies its own name. To the extent that it provides functionality that is not needed by the enterprise business processes or fails to provide functionality that is needed by those processes, it is not truly a “service.”
The implication of this issue is that we can be sure that we are providing the right set of functionality to make up the needed services only after we understand the enterprise business processes that they will serve. Each process requires functionality in order to accomplish its purposes. To truly understand what functionality is required by a process, we should begin not with the functionality currently being provided to the process but with an understanding or “map” of that process.
If we fail to come to that understanding, there are a number of consequences that may arise. To the extent that our failure to understand the processes causes us not to deliver the needed functionality, the processes may fail or at least fail to operate as efficiently as they might.
Another very interesting and counterproductive consequence is what might be called Guerrilla IT. Business process owners that are faced with a real, or even perceived, deficit in service functionality coming from the new architecture will defensively attempt to find that functionality elsewhere. This often becomes an effort to procure or develop functionality in a one-off attempt to fill the gap. Underserved business process owners have even been known to approach customers to raise funds with which to develop the functionality needed to serve those customers. Needless to say, this runs counter to the whole idea of the advantages of a service-oriented architecture. Certainly nothing in the development of the service-oriented architecture should act to encourage this piecemeal development of service functionality.
In order to avoid the subpar performance or failure of the enterprise business processes due to the inadequacy of the new SOA and/or the inefficiencies involved in individual processes seeking one-off solutions for missing functionality, the SOA design must get a handle on the shape and content of the business process layer. This means that a map of that layer has to become a new starting point for the SOA design.
The construction of a service-oriented architecture should begin with a detailed mapping of the business process layer. This is where model-based systems engineering can begin to offer a lever for the architecture development. Using a solid middle-out modeling approach leveraged through a powerful modeling tool, it is possible to develop an executable model of the process architecture. This architecture offers the key to understanding the enterprise business process layer.
By looking at the model of the business processes, it becomes readily apparent what functionality is necessary to promote the efficient and effective delivery of those processes. This understanding can be compiled into a set of requirements which then becomes the basis on which the SOA can be constructed. Now, instead of a mere inference of the required service functionality based on the current service functionality, the architecture can use a model of the process layer from which to derive the requirements for the service functionality.
These requirements create a picture of the service functionality that will be required to truly “serve” the business processes. Just as in the traditional process, the services chosen or developed for the service layer are offered to the enterprise process layer. The difference in this case is a high degree of confidence that is possible because of the requirements development flowing from the middle out model of the process layer. The middle out modeling process and the strength of the modeling tool used drive the quality of the model and therefore the quality of the requirements.
The greatest benefit comes from a service-oriented architecture where the service functionality answers the real and present needs of the enterprise business process layer without misfits or disconnects. Using these tools and methods for model-based systems engineering provides a powerful lever to the service-oriented architecture design process. The modeling tools and techniques of MBSE have supplied the “missing link” in the SOA development process.
