Welcome!

IBM Cloud Authors: Pat Romanski, Elizabeth White, Liz McMillan, Yeshim Deniz, 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
    To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
    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...
    A valuable conference experience generates new contacts, sales leads, potential strategic partners and potential investors; helps gather competitive intelligence and even provides inspiration for new products and services. Conference Guru works with conference organizers to pass great deals to great conferences, helping you discover new conferences and increase your return on investment.
    Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
    We are seeing a major migration of enterprises applications to the cloud. As cloud and business use of real time applications accelerate, legacy networks are no longer able to architecturally support cloud adoption and deliver the performance and security required by highly distributed enterprises. These outdated solutions have become more costly and complicated to implement, install, manage, and maintain.SD-WAN offers unlimited capabilities for accessing the benefits of the cloud and Internet. ...
    Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
    SYS-CON Events announced today that Silicon India has been named “Media Sponsor” of SYS-CON's 21st International Cloud Expo, which will take place on Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA. Published in Silicon Valley, Silicon India magazine is the premiere platform for CIOs to discuss their innovative enterprise solutions and allows IT vendors to learn about new solutions that can help grow their business.
    DXWorldEXPO LLC announced today that "IoT Now" was named media sponsor of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. IoT Now explores the evolving opportunities and challenges facing CSPs, and it passes on some lessons learned from those who have taken the first steps in next-gen IoT services.
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.