Welcome!

IBM Cloud Authors: Elizabeth White, Yeshim Deniz, Pat Romanski, Liz McMillan, Stefan Bernbo

Related Topics: IBM Cloud

IBM Cloud: Article

Discovering and Documenting Business Application Patterns

Discovering and Documenting Business Application Patterns

This month we'll look at pattern discovery in more detail by continuing to examine a business application pattern we discovered and documented. Our focus isn't on creating formal patterns, but on capturing, refining, and sharing the knowledge gained during development. We'll discuss the steps we went through as we discovered and captured our pattern. As we progress through the steps, we'll show you not only what we learned as we captured this pattern, but also things we learned as we captured other patterns.

In Part 1 we identified the problem - managing configurable balance information in the area of warehouse management, and the candidate pattern - encapsulating the criteria for the balance information in the ProductBalanceMapKey class, as shown in Figure 1.

Now we'll look at the refinement of the candidate pattern as we applied it to the problem of managing configurable balance information in the area of financial accounts. In Part 3 we'll look at applying this pattern (with others) to the construction of applications, components, and Web services.

The Second Problem
The second time we encountered the problem of managing configurable balance information was in the area of financial accounts. We needed some way to manage cached account balances - the value of a particular account (or set of accounts) for a particular set of criteria. For example, when you go to the bank to check on your savings account you want to be able to quickly get the balance - you don't want to wait while the bank adds up all of the transactions for your savings account. While this example is simple, the requirements for account balances in general are quite complex.

One of the first obstacles we had to overcome was the fact that the domain experts talked about financial account balances in terms of a set of base balances - the balance of each account for each period. They didn't think the balances needed to be configurable. In this case, an implementation had, over time, become their view of the requirement. Once we overcame this problem we discovered that the true requirement defined a need for even more configurability than was the case for product balances. The requirement was that balances for a set of complex criteria needed to be retrieved rapidly. Noncached balances would either be derived from existing balances or would be calculated from the raw transaction information. Understanding the actual requirement enabled us to provide a solution that allows the user to maintain just the specific balances they need for their particular business and to add more as needed. This means that the application (or customer) can make the trade-off between storage and update cost versus time for retrieval.

The Solution
Applying these requirements to the candidate pattern led us to refine it and also to identify another pattern. We're going to focus on what happened to our candidate pattern.

Just as was the case with product balances, account balances have a number of criteria over which balances could be kept. The account balances criteria included:

  • Account: The requirement was that balances be specified at the granularity of the codes that make up the account. For example, an account could be made up of the following codes: major code, minor code, product, and salesperson. Balances could then be specified for a subset of salespeople and a subset of the products.
  • Prime currency: The currency in which the transaction occurred. The requirement was that individual currencies or sets of currencies could be specified.
  • Fiscal period: The year can be broken into multiple fiscal periods. For example, the year may be broken into four periods (one per quarter). The requirement was that balances could be specified for individual periods, sets of periods, and ranges of periods.

    For illustrative purposes we'll just look at the account as a whole (i.e., ignore the codes). For example, we could have a set of financial transactions like those shown in Table 1.

    Our prior solution is nearly sufficient here - change CachedProductBalances to CachedAccountBalances and ProductBalanceMapKey to AccountBalanceMapKey. The key difference is that for account balances we need to be able to do more than simply turn criteria on and off (i.e., an inUse array on CachedAccountBalances isn't enough). Instead we need to be able to specify the criteria in more detail. For example, we want to be able to cache the balances for a specific account (Savings) or accounts (Savings and Checking), rather than be forced to cache balances for every single account, as would be the case if we reused our original solution for product balances. We may even want to cache them for specific ranges of criteria (e.g., fiscal period 1 through 2).

    In Part 1 we introduced the inUse array to determine, when updating and retrieving cached balances, which criteria were applicable and to replace the unused criteria with a placeholder. In this case we need a more complex array that can handle the transformation and management of the criteria. However, we still want our CachedAccountBalances class to do this without becoming entangled in the specific criteria being used. We met this requirement by introducing something called a specification key - a key that specifies a set of criteria. In order to be able to talk about the other keys (such as the AccountBalanceMapKey) we identified these as access keys - keys used to access information. The specification key contained the specification for each criterion and could transform an access key for use with a particular collection of cached balances.

    At this point we identified the cached balances candidate pattern. In this pattern, as shown in Figure 2, we have a CachedBalanceSet that contains a set of balance values (CachedBalance) associated with access keys (AccessKey) that are specified by a specification key (SpecificationKey). In order for the CachedBalanceSet to be able to work with the keys without knowledge of the details, AccessKey must support equals and SpecificationKey must support convert (taking an AccessKey and returning a converted one). In other words, AccessKey and SpecificationKey declare interfaces that at this stage in the definition of our candidate pattern would then be implemented by domain-specific subclasses (e.g., a SpecificationKey subclass that supports specifying financial account balances, and an AccessKey subclass that is used to manage the various account balance criteria such as fiscal period and account code).

    At this point, our first thought was to tie the key pattern and the cached balance patterns together. However, we ultimately chose to separate them into two distinct patterns since we have found that it is easier to later combine patterns versus trying to split them apart. In fact it may turn out that one of our candidates is in fact a pattern while the other isn't (or isn't worth turning into one). In our case we kept them separate because the key pattern - allowing algorithms to work with criteria abstractly, and the cached balance pattern - maintaining balance information over a specified set of criteria, met clearly different objectives and requirements.

    Focusing on the key pattern, we realized that while each key (access and specification) could be written for a particular use of the pattern, we could provide an implementation of the core part of the function. (Such an implementation is often called a mini-framework or framelet.) To do this we created a new abstraction. This new abstraction, called a keyable, allowed the key to work with its criteria generically, thus eliminating the need for domain-specific implementations of AccessKey and SpecificationKey. An AccessKey was made up of AccessKeyables and a SpecificationKey was made up of SpecificationKeyables.

    Each keyable defined an abstraction that declared the methods used for AccessKey and SpecificationKey. For example, AccessKey supports equals by comparing the AccessKeyables in the same position by using their equal method. If every AccessKeyable is equal, then the entire AccessKey is equal. Specific AccessKeyable subclasses provided their own implementations of equals to support this algorithm. This change to our candidate pattern had a nice side effect - by transferring the domain-specific responsibility from the Key classes to the Keyable classes, we were able to create a group of generally reusable Keyable classes (e.g., DateKeyable, PeriodKeyable, StringKeyable) that could be assembled to meet many different domain requirements. However, this approach also led us into a trap that we'll discuss below.

    In this particular case, we decided to provide a reusable implementation of the pattern. In doing so, we provided a family of keyable subclasses that handled the majority of the different types of criteria. This was both a good and a bad idea. It was a good idea because providing prebuilt, partial implementations helped to enforce consistency in the use of the pattern; it allowed all uses of the pattern to take advantage of performance improvements in the base implementation; and it made the pattern attractive - a lot of the work was done for you. It was a bad idea because we ended up capturing and documenting the implementation and not the pattern. This was a problem because it made it very difficult to adapt the pattern to new situations - instead of adapting the pattern to the problem, we ended up adapting the problem to the pattern. In our case we exacerbated the problem by naively documenting the implementation as if it were the pattern. Had we clearly separated the pattern and implementation from the beginning, it would have been much better.

    Once we identified this pattern, we needed to go back and determine if we should update our implementation of the CachedProductBalances. The main thing to keep in mind is that it is not necessary to make this sort of update. Rework takes time, so assume you won't make the update and convince yourself you should. While there are many considerations when making this decision, we found that the key ones were:

  • Pattern completeness is a key consideration: Make sure that the pattern is refined enough that you won't have to go back and reapply it again.
  • Consistency is a very good reason for going back and making the change: Consistency makes code easier for customers to consume (especially in the case of a framework) and easier to maintain. However, in many cases it is better to leave completed code alone and use the pattern from this point forward.
  • Unrealized requirements occur when the original requirements aren't complete: Often we would go back to the domain experts with the refined pattern and explain the refinements added due to the new application. This would make them realize that either they hadn't completely stated the requirements, or they had limited their requirements by what they thought was possible (i.e., what had been done before). Be careful, though, that you don't influence the answer, since you don't want to add unnecessary complexity.
  • Risk includes a number of things: One is the pattern completeness described above. Others are things like your development schedule and development team. It is never worth missing a critical deadline just to replace completed code!

    Remember that a pattern may never be complete. It may continue to be refined as each new use is found. Even in our example, where we spent a lot of time refining, documenting, and implementing the pattern as part of the second use, we didn't identify everything. As we continued on the project, we not only found other similar uses, but also found new and unexpected places where the pattern could be used.

    We discovered that in many of these new cases we didn't have to update the core pattern, but instead added implementation notes that addressed applying the pattern in these particular cases. However, keep in mind that the capture of workaday patterns doesn't require formal documentation. Document only as much as you have to. Document enough to ensure you don't lose what you've learned and enough to enable the intended pattern consumer to benefit from what you've learned. You can always formalize it later.

    Summary

  • Make sure you are working with requirements and not a particular implementation.
  • Watch out for new candidate patterns. Don't combine candidate patterns too early.
  • Don't forget that your candidate still may not be a pattern (or a pattern worth capturing). You may need to wait for another occurrence to prove or disprove this point.
  • Be careful about providing reusable implementations of patterns (i.e., framelets).
    -Don't forget that the implementation is not the pattern.
    -Don't forget you can use the pattern without using the implementation.
    -Clearly document what is the pattern and what is the implementation.

  • Ask yourself, before reapplying the pattern
    -Is the pattern ready to be reapplied?
    -Do you need to reapply for consistency?
    -Does the refined pattern expose unrealized requirements?
    -Is it worth the risk in delaying and/or destabilizing existing code?

  • Recognize that refinement of the pattern may continue indefinitely.
  • Document only as much of the pattern as is necessary.

    Now that we've refined and captured the pattern, next time we'll look at applying the key pattern and cached balances pattern (with others) to the construction of applications, components, and Web services.

  • More Stories By Brent Carlson

    Brent Carlson is vice president of technology and cofounder of LogicLibrary, a provider of software development asset (SDA) management tools. He is the coauthor of two books: San Francisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey). He also holds 16 software patents, with eight more currently under evaluation.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
    Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in development and launches of disruptive technologies to create new market opportunities as well as enhance enterprise product portfolios with emerging technologies. His most recent venture was Octoblu, a cross-protocol Internet of Things (IoT) mesh network platform, acquired by Citrix. Prior to co-founding Octoblu, Chris was founder of Nodester, an open-source Node.JS PaaS which was acquired by AppFog and ...
    The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
    Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...