Functional Decomposition

How can a large business problem be solved without having to build a standalone body of solution logic?

Problem To solve a large, complex business problem a corresponding amount of service logic needs to be created, resulting in a self-contained application with traditional governance and reusability constraints.
Solution The large business problem can be broken down into a set of smaller, related problems, allowing the required solution logic to also be decomposed into a corresponding set of smaller, related solution logic units.
Application When applied in support of service-orientation, this pattern is carried out through the application of a combination of other design patterns.	Impacts Increased design complexity and governance challenges.
Principles n/a	Architecture Service

Table 7.1 – Profile summary for the Functional Decomposition pattern.

Problem

Most business tasks or business processes requiring automation constitute large problems.

The accepted approach to solving a large automation problem has been to build an application. Prior to the advent of distributed computing, custom developed applications were primarily designed as monolithic executables; single, self-contained bodies of solution logic.

Figure 7.4 – One approach to solving a large problem is to build a large body of solution logic.

Repeatedly solving large problems by building monolithic solution logic results in an enterprise comprised of single-purpose applications residing in siloed implementation boundaries.

For many organizations such environments have posed significant challenges associated with extensibility and cross-application connectivity. Furthermore, a siloed technology landscape can become bloated and expensive to maintain and change. So much so, that many of these applications have remained in contemporary technical environments as entrenched legacy systems that continue to inhibit the overall evolution of the enterprise.

Solution

The Logic Decomposition pattern is essentially an application of the separation of concerns theory. This established software engineering principle promotes the decomposition of a larger problem into smaller problems (called concerns) for which corresponding units of solution logic can be built.

The rationale is that a larger problem can be more easily and effectively solved when separated into smaller parts. Each unit of solution logic that is built exists as a standalone software program responsible for solving one or more of the identified, smaller concerns (Figure 7.x). This design approach is well established and forms the basis for previous and current distributed computing platforms, including service-orientation.

Figure 7.5 – Distributed computing is based on an approach where a large problem and its corresponding solution logic are decomposed.

Application

This pattern is essentially realized by carrying out the separation of concerns in support of service-orientation. A primary means by which service-orientation is distinguished from other distributed design approaches is the manner in which the separation is carried out.

Many of the patterns documented in this catalog as well as the principles described in Part III solve specific problems and raise particular issues, all of which tie into how the actual separation needs to be carried out.

The end-to-end application of this parent pattern therefore needs to be based on a process that realizes a separation of concerns in combination with other key patterns and principles. Appendix X provides highlights of the service modeling process for this purpose. The starting point is the preliminary identification of individual concerns and corresponding solution logic units.

Impacts

Distributed solution units require individual attention with regards to interconnectivity, security, reliability, and maintenance in order to ensure that each chain in the link of runtime activity processing is and remains adequately reliable and self-sufficient.

An environment consisting of a large amount of smaller software programs therefore imposes more design complexity and governance challenges than one comprised of a single monolithic application.

Relationships

On a fundamental level, one could argue that Functional Decomposition forms the basis for all of the patterns in this catalog or in any pattern catalog dedicated to the design of distributed solutions.

But when identifying direct relationships, the only pattern that qualifies is Service Encapsulation (primarily because it pattern immediately follows Functional Decomposition in the Basic Service Design Pattern Language sequence).

Essentially, Functional Decomposition partitions solution logic into granular parts in support of Service Encapsulation during which each of these parts is assessed for its suitability to be part of a service.

Figure 7.6 – This displayed relationship (as repeat of Figure 7.x) simply establishes how the reasoning behind decomposing functionality is to make the decomposed parts available for potential service encapsulation.

This pattern is essentially an expression of an established software engineering theory known as the separation of concerns. On its own, this pattern is therefore not unique to service-orientation. However, how this design pattern is always applied in conjunction with several of the upcoming patterns and it is how the pattern is ultimately carried out that distinguishes how the separation of concerns is accomplished in a manner specific to service-orientation.

Case Study Example

Case study content is not available on this Web site.