Home > Articles > Software Development & Management > Architecture and Design

  • Print
  • + Share This
This chapter is from the book

Pioneering Solutions

We close this chapter on a cautionary note. Early explorers drew maps of the territories they became familiar with and drew dragons in the unexplored corners of these maps, warning those later map readers to beware of those unexplored spaces. Even worse, many explorers never even reached their goals: Columbus was seeking Asia when he found the Americas, and numerous explorers sought unsuccessfully for the Northwest Passage that would provide a North American route from the Atlantic to the Pacific.

The relevance here is that there are many types of applications for complex-event processing that have been well explored. If you are working in one of these areas, the problem is well defined, and implementing your solution will be a straightforward engineering exercise. If, however, you are working in an area that is not well defined, one in which the analytical approach for either situation recognition or action determination has not yet been established, proceed with caution. Some (but not all) of these areas are true research topics—you need to invest a little time in determining whether or not your particular problem is well defined before you commit to building a solution. Remember, it took more than 400 years to find the Northwest Passage!

How can you tell when you are on safe ground? Ask yourself the following questions:

  • Is the information related to the problem understood well enough to create a quality information model (including relevant state information)?
  • Is there a well-defined (i.e., measurable) set of criteria that defines the situation that needs to be recognized?
  • Are there well-defined triggers that identify the points in time at which the situation recognition analysis will be performed?
  • Is the information necessary for this recognition analysis readily accessible?
  • Is there a clearly articulated approach for using the available information to recognize the situation?
  • Is there a well-defined (i.e., measurable) approach for responding to the situation once it has been recognized?
  • Is the reference information needed for determining the response readily accessible?
  • Does the business value of the resulting situation recognition and response capabilities warrant the investment in the solution?

If you answered yes to all of these questions, you are on solid ground. If you answered no to any of them, you may be plowing new ground. You need to eliminate this uncertainty before you commit to producing a solution. Focus your initial efforts on developing the answers to these questions, with particular attention to the last one: Is the result worth the effort? Then, and only then, should you commit to building a solution.

The riskiest question in the list is the first: What is it that you are trying to recognize? Define your goals based on solid analytical results and beware of open-ended criteria. For example, you are never going to recognize all forms of financial fraud: The bad guys are constantly inventing new ways to scam the financial system and circumvent the checks currently in place. Identifying fraud, in general, is not an achievable goal.

On the other hand, there are specific behavior patterns that fairly reliably indicate that there might be fraud in progress. An analysis of login patterns might identify these behavior patterns, and the recognition of these patterns as they occur is definitely a well-defined and measurable goal.

If you find yourself waving your hands as you attempt to get specific about defining your recognition goals—stop! You are treading on thin ice. Do your analytical homework and convince yourself that you can be precise about what is to be recognized.

  • + Share This
  • 🔖 Save To Your Account