Enterprise SOA

Why does modeling matter? Isn't it just another form of coding?

Modeling is as old as computer programming itself. The first time a programmer added a parameter or two to his code, he created a model. While using modeling to configure and design software is nothing new, it is important to understand how modeling manifests itself at multiple levels, in a variety of forms within ESA, and not just as code. ESA shifts the burden of application development off the backs of IT and onto the shoulders of the emerging business analysts discussed earlier. To enable that shift, business analysts will need models that not only envision code, but also trace the flow of data through business processes, visualize the business objects in which transformations take place, and then finally use modeling tools to produce the code that makes all of this possible. Let's walk through each type of model.

At the highest, most abstract level is process component modeling, where complex business processes are unpacked into functional components that represent business objects and services, such as a purchase order connected to another similarly large financial component. These models don't specify the process automation itself, just the components needed for carrying out that automation. This kind of modeling is how the structure of a business is captured.

After that, business analysts zoom into each process component to orchestrate the process flow and the individual business objects and services comprising that flow, creating a model that's even more detailed. But it's still not a complete picture of the underlying automation, which is what's specified in the code inside those business objects.

In each instance, the models operate at differing degrees of abstraction from the actual code. A low-level specification model is essentially another form of coding in which changes to the model or the code are automatically reflected in each other because the specificity in each is roughly equivalent.

A high-level specification model manipulates components larger than simple code—the business processes within a process component, for example. These models exchange the flexibility of a low-specification model for the simplicity of fewer objects.

Other kinds of models include pattern-based models—which provide large assemblies of model components as a jumping-off point for additional configuration and which can be low- or high-level specifications—and requirements models, which are the most powerful of all. In requirements models, instead of a user expressing how she wants something done, the model takes an expression of the user's goals and simply creates the solutions.

To imagine the differences in scope between each kind of model, picture a chef in a kitchen instead of a business analyst hunched over a screen. In a low-level specification model, the chef works alone, using a recipe as his simple model. In a high-level specification model, the chef commands his assistants to produce dishes with a few alterations: make this one spicy, that one sweet, and grill the meat medium rare. A pattern-based, high-level specification model would have the chef ordering his staff to produce a five-course meal in which they substitute a dish or two—salmon for veal, perhaps. And whether they knew it or not, the patrons in the dining room would embody a requirements model at the moment they placed their orders. They know what they want, and now they will wait for their meals to appear from the kitchen.

Modeling is used throughout ESA to create the simplicity and flexibility required for widespread use by nontechnical users and to increase the productivity of technologists. It will be impossible for most businesses to realize the full potential of ESA without the ability to have business analysts lacking specialized knowledge in IT rapidly configure business processes. Several of the challenges mentioned earlier in this chapter—such as the looming proliferation of UIs—will be addressed by spreading the work of building these interfaces across hundreds or even thousands of suddenly empowered enterprise architects wielding simple modeling tools. Such tools already exist in the form of SAP NetWeaver Visual Composer, which was first designed as a high-level specification modeling environment.

Modeling tools use composition languages that represent the relationships among business objects, services, and the applications providing functionality, all of which are then translated into executable code. Modeling tools present to their users a visual representation of the composition language that is even simpler than the composition language itself. While displaying the data of an entity service embedded in a UI table may have a lot of plumbing buried under the service, a visual development environment simplifies that complexity down to the act of joining one object to another with a certain type of connector. The composition language used to represent that connection is much more complex, and the executable version has still greater complexity, but all of this is hidden from the business analyst who may be configuring a piece of software.