ServiceTechMag.com > Archive > Issue LX, March 2012 > Patterns and Principles in the Real World - Part II

Bookmarks



Patterns and Principles in the Real World - Part II

Published: March 23, 2012 • Service Technology Magazine Issue LX PDF
 

Abstract: The second part of this two-part article series uses symbolic notation to apply principles and patterns to a use case. It proposes an approach that starts with meta-questions and ends with more detailed questions that equate to design patterns. Using as an example the design of a claims service, it suggests a methodical approach to identify design patterns that support a service-oriented architecture. To read the first part of this article series, click here.


Introduction

In the first part of this article series, we tried to come to grips with the human element of creating and delivering a successful SOA by focusing on the necessity of strong leadership. In this part, we'll apply two principles to building a claims service using patterns and the notation that was outlined in the first part of this article series [REF-1].


Questions

Embrace boldness and scorn perfectionism to get take-off velocity. A successful SOA sometimes means jumping into the deep end of the pool to master WSDL development and XML schema in particular. In terms of tools, there are many simple, robust vendor and open source drop-and-drag products.

An approach that spins wheels is to observe a strict waterfall methodology where we freeze progress while we try to answer all questions. However, asking lots of questions often raises yet more questions. This is at the heart of building our SOA.

Someone asked the poet Gertrude Stein on her deathbed, "What's the answer?" She replied: "What's the question?" Often we don't need more answers but just better questions. Are our foundational assumptions sound? Is there different or new information or alternative assumptions that could change our SOA? The best way to evaluate SOA readiness is by getting credible answers to the following questions:

  • How well prepared is our organization to embrace significant change?
  • Do we know where our business rules are?
  • Is our data flexible and do we trust its quality?

In TOGAF, these questions are raised during the preliminary phase where in general terms of who, what, where, why, and how are defined [REF-2]. We have answers to some those questions in the form of patterns. TOGAF architectural development is incremental and iterative. Thus, adjusting patterns as we think through the implications of our architecture is necessary. We should capture our understanding of the patterns in a metadata dictionary. This will let us cross-reference by keyword problems, solutions, impacts, extensions, and applications, leveraging that knowledge for future development.


Patterns

To get our claims service project shovel-ready, we still need do some blueprinting. Here's the big picture:



Figure 1 – Service-Oriented Enterprise Architecture and Claims Service Diagram.


This presentation layer has internal and external users who interact with functions that services deliver – using laptops, workstations, or mobile devices. Among those services is a new claims service. Consumption channels might include Jservices, business-to-business interfaces, and Web Services for Remote Portals. Business rules are stored in the business process management layer. Here's an example of a rule: "Is the claim greater than $5,000? If not, review the claim. If so, perform a fraud check and then review the claim." The enterprise service bus is middleware that provides choreography and orchestration between services, both atomic and compound, from the service registry. The ESB is a compound pattern that has service brokers, asynchronous queuing, and intermediate routing patterns. Data services render data from relational databases and business intelligence data marts.

A use case for a claims service might be someone who wants to know about a claim status. A single claims service could be reused across multiple systems and departments. The client, the billing department, the fraud department, adjusters, investigators, and agents can cross multiple systems to have one version of claim information.

As we develop our case, we'll use our new notation to express a preliminary solution. A redundant column translates the statement to make the notation clear.

Consider this work flow:




This flow mirrors the process that firms have used for the last century to process claims. The difference is that now an automated, reusable, loosely coupled, autonomous, and discoverable service facilitates actions from the moment that the customer submits the claim.

We're always struggling with complexity. But there's no need to boil the ocean if we approach our questions using the Descartian method [REF-3]. We work on the simplest questions first, rather than the most important ones, and then build on those answers to address the more complex questions.

Our approach is to first frame meta-questions. These are broad questions that have more probing secondary questions that in turn have tertiary questions and corresponding patterns. Meta-questions include the following: What are the inventory issues? What are the service issues? What are the data issues? A question predicates each pattern. In other words, the pattern is the answer to the question. We distill the pattern by using this template:




One meta-question asks: How does one service interact with another service? Using our notation, we write: S _ Claims _ Interacts _ S _ Payments. Canonical Protocol, Canonical Schema, and Schema Centralization are among the patterns that answer this question.

Here's how we summarize those patterns:




This reduces to a single statement: S _ Claims _ Canonical Protocol, Canonical Protocol, Schema Centralization _ S _ Payments

As we deepen our mastery of patterns, as they relate to SOA principles, we tie them to domains within our architecture, such as messaging and governance, and extend or combine them into composite or compound patterns. These patterns become the building blocks for our SOA.

(See Appendix A for candidate patterns for our claims service.)


Rendering a Solution

At this point, a holistic solution starts to emerge to support our claims service and enterprise SOA. To complete the solution, we should do the following:

  1. Outline our architectural vision using statements based on our candidate patterns, as this example shows:




  2. Explore the universe of all known patterns including patterns informed by other principles, RESTful patterns, and Java design patterns.
  3. Harmonize our selection of patterns to the business requirements and to each other. This means dropping or adding patterns, creating composite or compound patterns, inventing new patterns, and filling architectural gaps that lack patterns.
  4. Systemize all patterns within conceptual, logical, and physical domains in accordance with our business requirements and platform constraints.

This completes the preliminary phase of TOGAF with enough information to commence concurrently other phases of the Architecture Development Method to support the construction of our SOA.


Conclusion: The Purple Bullfinch in the Lilac Tree

"Words strain," T.S. Eliot, the Nobel prize-winning British poet, wrote.


Crack and sometimes break, under the burden,
Under the tension, slip, slide, perish,
Decay with imprecision, will not stay in place,
Will not stay still.


The SOA architect knows the tension of words and meaning, and perhaps the answer is in another of his poems where we must


Delight in sense, in learning and in thought, Music and philosophy, curiosity,
The purple bullfinch in the lilac tree,
The tiltyard skill, the strategy of chess,
Love in the garden, singing to the instrument,
Were all things equally desirable


Leadership, principles, patterns, notation, questions, learning, curiosity, skill, and strategy are some of what it takes to architect service technologies in the real world.


Appendix A: Selected Design Patterns

Primary Meta Questions

These are broad questions about the relationship of our intended SOA design characteristics to inventory, service design, and service composition.

Secondary Meta Questions

These questions are addressed by one or more pattern, as follows:




Tertiary Design Pattern Questions

We are considering patterns from two of the eight principles:

  • The Service Discoverability principle (SDP)
  • The Standardized Service Contract principle (SSCP)

The keyword column helps tie one pattern to other patterns that might be associated with that class of patterns, such as all inventory-related patterns. The claims column shows possible patterns that may advance our design. The number in the claims column of this chart is the number of the pattern in the next table on selected design patterns.





Selected Design Patterns

We discussed patterns one through three earlier in this paper.

Inventory Implementation




Inventory Governance




Service Contract Design




Capability Composition




Service Messaging Patterns





References

[REF-1] Erl, Thomas, et al., "SOA Design Patterns", Prentice-Hall, 2009, pgs. 111-693. www.soabooks.com/patterns

[REF-2] The Open Group, "Using TOGAF to Define and Govern Service-Oriented Architectures", 2011, pgs. 17-28, https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g113

[REF-3] Wik, Philip, "Effective Top-Down SOA Management in an Efficient Bottom-Up Agile World (Part 2)", Service Technology Magazine, May 2010, http://soamag.com/I39/0510-3.php


Acknowledgements

I wish to thank the following individuals who reviewed and critiqued my paper: Steve Wisner, Director, IT, Genworth Financial and Errol Ryland, Director, MSS Technologies, Inc.