IBM Cloud Authors: Yeshim Deniz, William Schmarzo, Elizabeth White, Karthick Viswanathan, Pat Romanski

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.


  • 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.

    @ThingsExpo Stories
    The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
    DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of bus...
    With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
    DXWorldEXPO LLC announced today that "Miami Blockchain Event by FinTechEXPO" has announced that its Call for Papers is now open. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to info@dxworldexpo.com. Financial enterprises in New York City, London, Singapore, and other world financial capitals are embracing a new generation of smart, automated FinTech that eliminates many cumbersome, slow, and expe...
    DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
    DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    DXWorldEXPO LLC announced today that ICOHOLDER named "Media Sponsor" of Miami Blockchain Event by FinTechEXPO. ICOHOLDER give you detailed information and help the community to invest in the trusty projects. Miami Blockchain Event by FinTechEXPO has opened its Call for Papers. The two-day event will present 20 top Blockchain experts. All speaking inquiries which covers the following information can be submitted by email to info@dxworldexpo.com. Miami Blockchain Event by FinTechEXPO also offers s...
    With tough new regulations coming to Europe on data privacy in May 2018, Calligo will explain why in reality the effect is global and transforms how you consider critical data. EU GDPR fundamentally rewrites the rules for cloud, Big Data and IoT. In his session at 21st Cloud Expo, Adam Ryan, Vice President and General Manager EMEA at Calligo, examined the regulations and provided insight on how it affects technology, challenges the established rules and will usher in new levels of diligence arou...
    Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    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...
    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.
    The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
    Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
    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.
    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.
    As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...
    Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    Cloud Expo | DXWorld Expo have announced the conference tracks for Cloud Expo 2018. Cloud Expo will be held June 5-7, 2018, at the Javits Center in New York City, and November 6-8, 2018, at the Santa Clara Convention Center, Santa Clara, CA. Digital Transformation (DX) is a major focus with the introduction of DX Expo within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive ov...