Business Modeling and Outside-In SOA

Anybody who has ever attempted to teach computer programming to a room full of tech novices knows that some people easily get it, while others simply don’t. There’s something about the basic “do this, make a decision, then do that” execution flow of any program that is comes naturally to some, while other people simply don’t seem to be wired in such a way as to make sense of such algorithmic thinking. As it happens, the algorithm-resistant population is every bit as clever as the programming-friendly group; it’s just that they think differently about the behavior of systems and thus choose to represent them in different ways than their more technical peers.

The underlying observation here is that human beings are marvelously adept at representing arbitrarily complex concepts with a wide range of different kinds of models. In fact, our innate ability to model reality is so pervasive in our day-to-day lives that the modeling process tends to fade from our awareness. Nevertheless, whether in business or in any other aspect of our lives, we are actively dealing with the complexity that surrounds us by building internal models that represent various aspects of reality. Furthermore, the types of models we use are amazingly diverse, as each of us leverages different types of models for representing the full spectrum of experiences we encounter in our lives.

As organizations look to Service Orientation to provide best practices for leveraging information technology (IT) to provide agile resources for the business through the power of the Services abstraction, the ubiquitous, varied, and subtle nature of the human ability to model complex situations becomes a central concern. After all, the abstractions that Services represent are a type of model themselves, as are all the ways that people think about using Services in their business processes. Furthermore, the dichotomy between people who are comfortable thinking algorithmically and those that aren’t resonates well beyond the classroom, with the algorithmically inclined leaning toward careers in IT, while people who prefer other types of models gravitating toward business roles.

This natural division of aptitude presents a challenge for any organization implementing Service-Oriented Architecture (SOA), because Service Orientation brings together these disparate ways of thinking about modeling, and requires IT to support the variety of models that business people prefer. Indeed, technical approaches to business modeling have fallen short of addressing the needs of business people who tend to think in non-technical terms. As a result, learning how to accommodate the different ways that people in the organization think about both business and technology is a critical best practice in the Service-oriented architect’s toolbelt. Without this understanding, the business is unlikely to extract the value and flexibility from the SOA implementation that they desire.

Understanding Models in the Business World
Ask an average cubicle dweller who’s not in IT to break down what they do every day into its most basic elements, and you’re likely to solicit a list of human interaction-based activities that move information around: conversations, meetings, sending and receiving communications, reading and writing, and the like. Knowledge workers might throw in activities like analyzing or evaluating. Few business people, however, will reply that they spend their days executing business processes.

From the IT perspective, however, if you define a business process as “what a business does,” or even as “a set of activities intended to achieve a business goal,” then all the various activities that our cubicle crowd undertake fall into the category of executing business processes. In fact, ZapThink frequently espouses the perspective that the Service-oriented approach to business process calls for flexible business processes that respond to the way humans work, rather than processes that constrain humans to work the way the systems want them to work. The problem is, the various models IT uses to represent business processes — flowchart-based orchestrations, flexible choreographies, defined flows — are only a small subset of all the useful models that businesspeople might use to represent the way that they understand how the business actually works.

In fact, businesspeople have a rich, varied set of models for representing how they move information around: conversations, messages, documents, spreadsheets, Web interfaces, mind maps, flowcharts, agendas, schedules, calendars, and other loosely structured forms of information representation. To be truly successful with SOA, therefore, IT must support these multiple approaches for representing and exchanging information, instead of shoehorning business operations into an IT-centric representation of how techies think the business is supposed to work.

Taking Business Models to the Next Level with SOA
Models, of course, are core to architecture, and SOA is no exception. ZapThink’s SOA Metamodel consists of a number of different models, including the business model, which represents the requirements of the business, the Service model, which represents both the Services in production as well as the requirements for new or changed Services, as well as implementation models that represent the underlying technology that supports the Services abstraction. Of these, the Service model is what makes SOA unique, and implementing the Service model properly is the essence of effective SOA.

The best way to implement the Service model is through metadata: Service contracts, policies, Service composition logic, and other metadata that represent all the salient aspects of existing or required Services and their use in the organization. Metadata are the appropriate vehicle for such models, because metadata support declarative representations of dynamic configurations. This declarative nature of metadata, in fact, is an essential enabler of SOA, and one of the primary reasons that the prevalence of XML has provided the raw material that characterizes today’s SOA initiatives.

You might assert that the opposite of “declarative” is “programmatic,” where metadata implement declarative configuration while executable code supports programmatic logic. The context of the variety and subtlety of the human reliance on models, however, blurs the distinction between declarative and programmatic approaches. Clearly, if you’re writing Java or C# code manually, you’re behaving programmatically, while if you’re picking options off of pull-down menus on a Web page, you’re behaving declaratively. But what if you’re using an XML-based programming language like Water? The Web Services Business Process Execution Language (WS-BPEL, or BPEL) is similarly an XML-based execution language, as its name suggests.

Furthermore, a business user may be interacting with a fully declarative interface, but might type in some simple JavaScript or Visual Basic in a field to express some business logic. Indeed, while it’s possible for a declarative tool to support pull-down menus that can duplicate, say, a line of JavaScript, just how important is it to avoid typing in a simple script? Furthermore, it’s possible to argue that text-based programming languages are themselves a form of metadata that represent the underlying bytecode that the appropriate platform can execute.

Lest we allow this discussion to devolve into an unproductive battle over declarative vs. programmatic approaches, it’s important to realize that both techniques are models — and furthermore, represent only two among many different models people use for modeling the flow of information in the organization. Some people prefer to think programmatically, others favor declarative thinking, while still others would rather use a spreadsheet, rules engine, calendar, email client, or some other representation. Is typing a formula into a spreadsheet cell programmatic or declarative? Regardless of your answer, the point is that it doesn’t matter, since spreadsheets effectively represent certain information-related tasks consistent with popular, well-understood models for such tasks that the business uses every day.

The ZapThink Take
There is an essential lesson for the architect here: design is an outward-in process, not inward-out. All good architects begin with humans and what they’re looking for from the systems the architects are designing. Since Service Orientation requires an enterprise perspective on the interactions between business and IT, it’s essential for the Service-oriented architect to be able to wear the hat of a business architect, and consider all the various models that the business is apt to use to represent the capabilities both of the business and the IT that serves it.

Furthermore, there is also an important lesson here for technology vendors as well: SOA tooling must be as diverse as the business users who wish to use it. People may utilize any number of different tools that leverage numerous models to take advantage of the Services their SOA provides. Gone are the days where tools vendors can manufacture only hammers, and expect their customers to recast all their problems as nails. By abstracting the interaction between business and IT, the business now expects IT to take care of business however the business sees fit, and not vice-versa.