In an earlier post I introduced the SOAD Model Accelerator and the associated eBook. We’ve continued to create supporting material for the Model Accelerator including a set of videos that we’ve recently posted, including:
Model Report Demo: This video covers three reports that are provided in the Model Accelerator: Goal-Service Model, Service Litmus Test, and Pattern Instances. These reports leverage the information captured in UML models – information captured via the use of automated patterns (and some manual modeling). Highlighting the value of capturing design in models rather than in just a picture (how do you report on elements in a picture?)
Business Modeling Patterns: This video looks at how we can apply a set of UML Patterns focused on Business Modeling along with some of the associated model constraints. The Model Accelerator provides 15 patterns supporting SOAD efforts, spanning Business Modeling, Service Identification and Service Specification. Future videos will show the patterns from Service Identification and Specification.
Over at The Emphasys Group – we’ve recently announced the release of the Service-Oriented Analysis and Design Model Accelerator. The Model Accelerator brings together a collection of automations including patterns, constraints and reports to support the design of SOA solutions.
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.
A short post today containing a couple of links…
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!
When we consider a reusable asset – the net can be cast quite wide. Almost anything could be a reusable asset. For instance, a reusable asset could be a:
- Best Practices document
- Design document
- Pattern specification such as Enterprise patterns, GoF patterns, IBM Patterns for e-
- 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?
I created a short video showing the use of the Subsystem Facade pattern within Rational Software Architect.
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.
PBE is closely related to Asset-Based Development (ABD) – simply put, patterns are a specific kind of reusable asset. However we need to be aware of the different approaches and styles of asset reuse. Understanding the styles of reuse is an important consideration in building a successful reusable asset. Select the wrong style for your asset and you jeopardize the success of your initiative.
As discussed in the IBM Redbook “Strategic Reuse with Asset-Based Development”, there are 4 styles of reuse:
- “Black Box: An asset that is not altered by the Asset Consumer
- Gray Box: An asset that is modified using parameters
- White Box: An asset whose internals are modified by the Asset Consumer
- 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.
After a little more than 11 years with IBM, I’ve made a move to a new organization – The Emphasys Group. At The Emphasys Group, my focus will be on helping our customers to drive Velocity through the application of Automation, Reuse and Agility.
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.
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.