News

Build Enterprise SOA With Rich Metadata

• By Lee Thé
• 07/30/2007

The Object Management Group's recent BPM Think Tank conference had a lot to say about service-oriented architecture (SOA). A highlight was David S. Frankel's presentation on model-driven business process platforms. Frankel is SAP Labs' lead standards architect for model-driven systems, and he brought his expertise to bear on both the promise and the considerable obstacles involved in scaling service-oriented architectures (SOA) in the enterprise.

According to Frankel, it's no longer good enough for applications to embody well-validated, accepted business processes. Now, innovative business models and associated processes define an enterprise's competitive advantage. Great products must be supported and enabled by great business models. And simply following a business process defined elsewhere leads to commodity processes, just as "me-too" products become commoditized.

Frankel advocates outsourcing nonunique "commodity" business processes so that an enterprise can focus on its core business processes -- those that are unique to the company and central to its profitability. You need flexibility in designing and executing innovative business processes, as well as for the value networks needed to access mission-critical, non-core processes.

Accomplishing this feat requires raising the level of abstraction in the technical platform stack, so that your company's business expertise can interact more dynamically with those processes. Traditionally, that stack has consisted of middleware and transaction systems atop a database management system (DBMS) and network systems, atop the operating system and the machine level.

Frankel proposes two layers above the traditional business process platform: an application platform comprising reusable, executable enterprise application services, and, above that, composite applications embodying custom business processes and analytics.

Composite apps combine processes formerly treated separately. Examples include procure-to-pay, order-to-cash and manufacture-to-inventory. One composite app may integrate applications providing product descriptions, parts inventory, supply chain price look up, a product-price optimizer, seller's auction, and manufacturing planning and production.

But currently there's an "abstraction gap" between application models for such processes and what's needed to compile those models in a way that the middleware and transaction systems can understand. You need model-driven tools that empower the business process expert. The goal is to support business process models with direct model execution and composite application model compilation into composite applications.

Frankel is talking about creating what is essentially a library of reusable, executable services -- not just a random collection of services, but one that fits together within an architecture.

Getting there will not be an easy transition. It could make the last jump (middleware) look like a cakewalk in comparison, just as raising the abstraction level for development languages above the third generation (3GLs) is harder than the last jump to 3GLs. Semantically thin specifications reach their limits in the quest for semantic interoperability on top of syntactic interoperability. Collaborating parties need a common understanding of the contract of a service. You can't rely on informal conversations among people, especially since those collaborating in a worldwide enterprise might not speak the same human language. And you face the challenge of finding suitable services to compose, with suitable functional behavior as well as quality of service. Moreover, configuration/version/dependency management problems don't go away. In fact they can even get worse.

You need a rich metadata environment to assist humans using the business process platform, especially when it comes to specifying constraints and providing inferences.

Specifying constraints is tricky. Invariants have to specify service messages and data types as precisely as possible. Preconditions and postconditions must do the same for service operations and functional contracts, and they're more numerous than invariants. You must use machine-readable, declarative constraint languages. You must also learn to specify quality of service (QoS) requirements and capabilities as precisely as possible.

None of this is new. So the jump isn't conceptual so much as in being so demanding at the execution level.

Inferences identify candidates or flag potential problem combinations. Inferences don't have to be 100 percent certain to be helpful. They just have to help the human involved in the process decide what to do, record the decision, show prior decisions to the next human and learn from the process. Inference engines need to be formally grounded. This requires languages for expressing metadata.

Frankel provided examples of an abstract business information model from an IT viewpoint with an invariant rule, and of an abstract model of a business service with preconditions and postconditions. He did both using unified modeling language (UML) but stressed that other modeling languages could work as well. The invariant rule showed how you'd prevent a bank customer from withdrawing more money than the balance in a checking account. The second example was related, showing preconditions requiring sufficient funds in the checking account to support a transfer from a checking account to a savings account, and that both accounts must belong to the same customer. The postconditions required that the balance of the checking account is reduced from its original amount by the amount of the transfer, with a reciprocal rule for increase in the savings account.

Moreover, for a composite application to work, these conditions must be independent of the implementation technology.

Frankel stressed that the success of next-generation tools will depend on providing metadata across the lifecycle, such that "model-driven" will mean "metadata driven" (with traceability). That's the only way to ensure that the modeling tools that business process experts use will produce usable SOA-based applications. You need a common, standards-based metadata management infrastructure across the board. This infrastructure should include business process models, service-level agreements, composite application models, warehouse star schema, operations metadata, service definitions, platform-specific component descriptors, operational RDB schemas and deployment metadata.

So yes, business process platforms are coming. The transition will be gradual but powerful. Model-driven tools are important for making the platforms usable. And they will provide business value today, with more to come later on. However, configuration management is a huge problem with composite applications, and it must be faced head-on. Metadata-rich environments and formal grounding are needed to manage the complexity. So practitioners and would-be practitioners must educate themselves continually. Only enterprises whose practitioners do so will remain sufficiently agile to prosper in this century.