Accompanying the Model Accelerator – we’ve also released an eBook: “Designing Solutions using the Service-Oriented Analysis and Design Model Accelerator”. The eBook is a FREE download. In addition to providing details on the Model Accelerator – the eBook discuss SoaML, the Business Modeling Profile for UML, the importance of architecture and aligns with Rational SOMA.

If you’re interested in PBE, SOA or both – take a look at the Model Accelerator and the eBook.

And coming out in the near future is the Cassandra-Hadoop Application Accelerator. Another automation – this time with a focus on creating Big Data\NOSQL solutions.

First, I’ve been working on a new course: Essentials of Agile Modeling. We’re starting online deliveries of the course starting in December. Open enrollment and private onsite deliveries will also be available. Agile Modeling is a great companion to our PBE efforts. We model what’s needed for understanding and communication – while keeping things as simple as possible. PBE can assist in helping to keep things simple for the modeler – encapsulating details, reducing the amount of details that need to be modeled, and providing a vocabulary that incorporates best practices.

The second link is to a blog posting that I helped to write over at AppFusions. The post is titled “Patterns, Maven, SDK, AUI, and Atlassian…Awesome“. Within the PBE book the examples tend to highlight the pattern capabilities of the IBM Rational platform. However, as we call out in the book – the PBE ideas, practices, guidelines and patterns are applicable to a wide range of tools. So this is a nice post in that it highlights work being done in creating pattern implementations for extending the Atlassian toolset. In addition – the tool used for the pattern implementation is Maven. Great stuff – and exciting to see PBE continue to gain momentum!

• Library
• Wizard
• Framework
• Best Practices document
• Design document
• Pattern specification such as Enterprise patterns, GoF patterns, IBM Patterns for e-
  Business
• Pattern Implementation
• Code Sample

With so many choices for creating a reusable asset – where should we make our investments? Should we invest in any and every opportunity for creating a reusable asset? No, of course not, the obvious answer is that we have to be selective. We have limited time, money and we need to focus on delivering software solutions – not just reusable assets.

So we need to be more selective – but how do we choose which assets to invest in? What criteria should we use? We can start with some general criteria:

• What is the impact for each reuse of the asset?
• How many times will the asset be reused?
• What is the cost to create the asset?

While this provides a good starting point – its rather simplistic – and assumes that all types of reusable assets are the same. We’ve already talked about different reuse styles – and as expected, this also has an impact on our investment decisions.

So let’s add some more criteria to our decision making list:

• How much customization is required per reuse of the asset?
• What is the cost to customize per reuse of the asset?
• How consumable is the asset?

This adds an interesting and often overlooked dimension to the asset creation discussion. When creating an asset we need to consider the consumability of the asset. Customization of the asset not only adds time and cost to the reuse scenario, but also introduces additional friction into the reuse effort. This friction, where the end user not only needs to understand the asset, but now also needs to customize the asset increases the risk that the asset will not be reused.

We end up needing to find the right balance between fit to purpose and the cost to reach that point. Some assets cost little to customize as they provide little support for customization. However, the user essentially has to use the asset as-is. Other assets can be highly customized – they can be made to fit a wide range of situations. We are provided with a great amount of flexibility in how we reuse the asset. But that increases the cost of reuse – and also often leaves the user confused about the “right” way to use the asset.

Written documentation – whether it is best practices, designs or pattern specifications – fall to the high end of the customization cost spectrum. These types of assets place a high burden on the asset consumer and cost the most to customize as they are applied.

Libraries fall on the other end of the spectrum, with almost no customization per reuse. Frameworks fall in the middle of the spectrum. Pattern implementations, such as those built using JET, fall in-between libraries and frameworks. They are provide points of variability – ways in which we can tweak the pattern as it is applied. This allows us to customize the reuse – yet as the asset support customization and guides the user in the customization effort cost is minimized and flexibility is optimized.

What kinds of assets do you use within your organization? What criteria do you use when creating reusable assets? Are you finding the right balance between customization and flexibility?

If you are interested in trying it out for yourself, you can download the necessary components using the Downloads section to the right – and grabbing PBE-Case-Study-v1.00.zip and consulting the CaseStudy-Readme.pdf. The book itself has a number of chapters that walk through the creation of this automation.

Lee.

As discussed in the IBM Redbook “Strategic Reuse with Asset-Based Development”, there are 4 styles of reuse:

1. “Black Box: An asset that is not altered by the Asset Consumer
2. Gray Box: An asset that is modified using parameters
3. White Box: An asset whose internals are modified by the Asset Consumer
4. Glass Box: An asset that exposes internals for evaluation and browsing purposes”

With Black Box reuse we only look at the integration points and external API provided by the reusable asset to integrate it with our other components. We don’t need to modify or fully understand the internals of the asset to integrate it into our application. “White box” reuse it is quite the opposite, we need to modify/adapt and/or understand the internals of the reusable asset to be able to reuse it and integrate it with our application. Gray Box is interesting in that it provides us with a combination of Black and White Box (hence the name). For the most part, the asset is not modified – yet it provides use with the ability to adjust the use of the asset via parameters. In this way, the asset is designed to be customized for the specifics of the situation. The last category, Glass Box, is more of a derivative of Black Box in the sense you cannot modify it, you can only look inside for education purpose. Being able to look inside helps you to understand the asset with the goal of improving the reuse experience.

Let’s take a look at some examples to make these concepts more concrete. First let’s start with Components. White Box or Black Box reusable assets? Components can be both, but usually they are more on the Black Box side of the spectrum. If we plan to integrate a logging component or even a billing component we don’t need to understand how they have been coded or how they work internally (even if sometimes it is better to have this understanding) nor do we need to modify the component’s inner elements. All we need is an understanding of the API to be able to know how to use it and how to integrate it with our other components.

The dividing line between White Box and Glass Box reusable assets is sometimes fuzzy. For example, the majority of open source components are provided with their source code. However, although you can modify the code (that will make it a White Box reusable asset) the code is most often used to help understand how the component works – making it a Glass Box reusable asset.

Next, let’s take a look at frameworks. What type of reuse does a framework provide? White box? Black Box? Frameworks are more on the White Box side. Some parts of the framework are of the Black Box kind, but overall the framework needs to be instantiated, fine-tuned to our specific needs to be of any use to us. And you definitely need to know and understand the internals of the framework to take best advantage of the features it provides.

And where do patterns stand? The answer to the questions is not as simple as it may appear. The part that adds complexity to the discussion is the recognition that patterns can be either a specification or an implementation. So perhaps it is better to restate the question – where do pattern specifcations stand? And, where do pattern implementations stand?

Pattern specifications are an example of the White Box style of reuse. A pattern specification provides a blueprint to help you apply the design proposed by the pattern to your own context. You need to understand the pattern internals and even fine tune them to be able to correctly apply the pattern to your context.

In the case of a pattern implementation, hopefully you’ve guessed that they are Gray Box reuse. As mentioned earlier, Gray Box can be thought of as a combination of Black Box and White Box reuse – providing us with the best of both approaches. We get the “drop-in and use” line of thinking associated with Black Box, but we also get the ability to make the asset fit the specifics of our situation. You don’t necessarily need to fully understand how the pattern implementation works and you definitively don’t want to modify its internal. The parameters defined in the input model allow you to adapt the pattern to your needs. We have a balance between adherence to the best practice\intended solution against customizability.

And as we wrap things up, this idea of a balance between adherence to best practice vs. customizability is key. When deciding about which style of reuse to use in a situation, we need to consider this balance. Our decision will impact the cost of developing the asset, the effort needed to use the asset and also the overall success of the reuse. Providing our users with a Black Box style asset when they need a solutions that require a high degree of customization is a path to failure. Providing an asset that uses a White Box approach to a community that lacks the expertise in the domain is another example of a situation that is unlikely to end well.

As we create reusable assets we need to understand the content that we are packaging, the user community, their skills and how the asset will be used. With this information in hand, we can select a reuse style and take another step forward in a successful reuse program.

We’ll be helping our customers to use Bots in realizing this vision. A bot, simply put, is an automated agent that acts on behalf of a user. We’ll be creating bots using a number of mechanisms – the more prominent ones include Patterns, DSLs, and Wizards.

We’re starting our efforts with a focus on service delivery – consulting, coaching and training. We have a great leadership team in place and have big plans for our future.

If you’re needing assistance in learning more about PBE, or need some help putting PBE into practice – give us a call, we’d be happy to help! We’d also be happy to talk about the bigger picture of driving Velocity through Automation, Reuse and Agility.

Thanks!

Lee.

One pattern-specific approach to consider is the Pattern Instance Notation (PIN). It is still in its early days, but work is progressing on promoting this approach (including standardization\integration via the Object Management Group). Let’s take a look at this notation.

Starting with the simplest case, the following image shows the use of PIN to denote an instance of a pattern.

If we take things a step further, we specify the pattern and its associated roles, as shown in the next figure.

Within our solution we would then connect elements to the roles that they fulfill. PIN keeps things simple and focused on the relationship between the pattern, its roles and the solution elements that bind to those roles.

If we have compound patterns, we can use PIN as shown in the next figure.

If desired, UML can be used within the construct to provide further details on how the solution is realized.

To better understand how a pattern would be modeled using PIN, let’s take a look at a specific pattern – the Subsystem Façade pattern. As you’ll recall, this is a pattern that we identified, designed and developed in the PBE book. The following diagram shows how we’ve modeled the pattern using UML.

And here’s how the same pattern would be represented using PIN.

If you’d like to draw some of your own diagrams using PIN, there is a stencil available for use with OmniGraffle.

Additional Details on PIN can be found in

• Jason McC. Smith, The Pattern Instance Notation: A Simple Hierarchical Visual Notation for the Dynamic Visualization and Comprehension of Software Patterns, Journal of Visual Languages and Computing (2011), doi:10.1016/j.jvlc.2011.03.003.

• “The Pattern Instance Notation: A Simple Hierarchical Visual Notation for the Dynamic Visualization and Comprehension of Software Patterns” by Jason McC. Smith as published in the Electronic Communications of the EASST Volume 25 (2010) – Proceedings of the Workshop Visual Formalisms for Patterns at VL/HCC 2009.

Thanks to Jason for his input on this posting, allowing reuse of his sample images depicting PIN notation and access to the PIN stencil.

1. Added links from the concepts, tasks, and guidelines to the summaries of the PBE Patterns and Guidelines.

2. Fixed a few typos.

A download of the updated source has been made available (v1.01). Please drop myself or Celso a note if you have any suggestions on enhancements for the practice.

Thanks!

If you’ve not yet visited Art of Software Reuse – it’s definitely worth taking a look. I’m currently reviewing a short ebook that they’ve published looking at Agile Software Reuse.