Domain Analysis Key To Systematic Reuse

November 26, 2010

Domain analysis is a foundational capability required for effective systematic reuse. Why? There are a lot of applications your teams are working on and the common theme among them most likely is the fact that they are in the same problem domain. In order to truly bring down cost of new applications and services, it is critical that the domain is understood and modeled appropriately. Here are some specific strategies to make this idea operational:

  1. Account for domain analysis and modeling in your iteration planning. Domain analysis is necessary to understand the nuances and variation points that an application/service/process needs to realize. Discovering the right variations requires time and interactions with business stakeholders and subject matter experts.
  2. Aspire for a core set of business object definitions that can be shared across business processes and service interfaces. Without appropriate data governance, domain knowledge will either be inaccurate/incomplete or worse duplicated in an inconsistent fashion. As the number of customer interfaces increase for your services, the domain inconsistencies will lead to greater point-to-point integrations and complexity.
  3. Align overall architecture with domain variations. Your domain is rich and complex but probably varies in a known set of ways. Additionally, what varies isn’t uniform and the rate of change across these variations aren’t identical. This is significant because the variations in the domain need to be captured in your overall architecture. Products/applications in the domain need to share a common architecture – only then can components integrate and inter-operate and systematic reuse will take hold. Constantly evaluate the need for a new version of a core business entity and associated classes to manage the entity.
  4. Refactor constantly to get to intention revealing design and code. As Eric Evans illustrates in Domain Driven Design, intention revealing code is easier to understand and evolve.  It also makes it easier to address new business requirements – as the design/implementation are closely aligned with the business domain, the quality of communication (referred to as ubiquitous language) and the ability to change it both increase significantly.

This isn’t an exhaustive list – instead, it is meant to highlight the need for placing the domain in the middle of every design, architecture, and implementation decision your teams make.

Design and Process Criteria for Investment in a Reusable Asset

October 29, 2009

Making the right decisions in the middle of an iteration or release cycle is risky and needs good judgment. Investing in a reusable asset is no exception.

What can help you take decisions on whether it is worth investing the time and effort for making a software capability reusable? The single most important factor is business relevance. Is the capability a priority for your business? Even if it is not a priority, is it one for the medium or long term? If the answer to these questions is no, you shouldn’t invest valuable resources into making your capability reusable. Yes, if it isn’t relevant, it needn’t be reusable. Assuming a capability is business relevant, there are several considerations you can think about:

Design Considerations:

  1. Do you have user stories that either directly or indirectly requires this capability? For instance, if you have a login customer user story, and you don’t have a customer component, this is an opportunity to create one. In the same vein, the login customer story itself might have variations. What are the different kinds of login that you need to support? Username/password, username/password/special verification text, email/password, username/random set of questions, username/defined set of questions etc.
  2. Do you understand the extent of variability that is required for the asset? Consider the ratio of the features that vary a lot vs. the overall functionality.  Even if you end up with a gross, high-level percentage it will help you during design.
  3. Consider specifically the aspects that vary and the number of variations you need to support. This is very critical to plan for the reusable asset. Remember, you are pursuing iteration not perfection! Draw a distinction between the variations that are an absolute must vs. ones that can be built over time. If you look back at the first point, maybe your business only needs the simple login using username and password. In that case don’t rush into building in variation support. On the other hand, if they come back and ask for multiple kinds of login you can always refactor to support variability.

Process Considerations

  1. Will the capability add significant schedule or technical risks? If so, you need to make this transparent and get clarity from your sponsors. You can explain the rationale for investing in a reusable capability if there is business relevance. Similarly, if schedule risk is unacceptable or you have other higher priority assets to build, refactor, etc. then add this asset to the refactoring list and revisit later.
  2. Will the capability introduce deployment changes? Does it need an additional resource such as a database, a configuration file, or is dependent on an external service provider? In that case you will want to run it by your production support and operations partners and get their buy-in.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Application Transformation via Reuse

October 17, 2009

Pursuing reuse is a journey, a continuous effort towards making enterprise applications and processes more agile and maintainable. Here is a simple diagram on how reuse can aid in application transformation. This isn’t a layer diagram – the intent is to show how an app goes from being monolithic to increasingly modular leveraging multiple categories of reusable assets. You can extend this to show how SOA & BPM efforts start to redefine the notion of an application from being a stovepipe to one that leverages a collection of carefully designed service capabilities.


As your systematic reuse efforts mature you will find it increasingly easier to update, extend, and refactor applications. You will start to recognize duplicate code, redundant functionality, and components that can be modified for reuse.  Every application will end up with a mixture of application specific code, domain-relevant (vertical) and domain-agnostic (horizontal) reusable assets. These reusable assets can be utility classes, domain specific libraries, service capabilities, and business process flows.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Systematic Reuse Success Factor #5 – Manage Domain Complexity

October 16, 2009

Your domain might be complex and rich in variations that need to be supported. Trying to capture all the complexity is neither pragmatic nor feasible given the constraints you might be under. Instead, focus on the essential complexity. In addition, it is unlikely that your business supports all the variations in your problem domain.  Fortunately most domain variations are expressed as user stories and you can look for patterns across iterations and releases to get a better understanding. Deciding the sub-set of complexity to manage is an art and you will need to continually collaborate with folks on your team on this.

I use a set of simple categories to look for areas that have essential domain complexity. This list is by no means comprehensive but it gives you a sense of what could drive complexity.complexity

  • Data capture: the system might have multiple user roles and the kind of data, the validations/rules that execute on them all vary
  • Geography: variations based on geographic regions/countries/states including differences in language, date/time formatting
  • Combination of product features (also called as bundling): variations to support different product flavors (for instance basic supports features X, Y, and Z, professional supports features X, Y, K, and premium supports A, X, Y, and K).
  • Entitlements: variations in access to different parts of a system and perform varying tasks. Related to user population and transaction behavior as well.
  • Transaction behavior: variations in transaction behavior in terms of monetary limits, approvals/validation rules, how business exceptions are handled
  • Channel (also called as distribution channel or sales channel): product availability, feature availability, security, customer support, frequency and kinds of marketing communications etc.

Next time you examine a user story place it in light of your domain categories. Is it a recurring pattern across iterations? If so, you should add it to your systematic reuse roadmap. Don’t panic if managing domain complexity doesn’t influence your design from day one. Nothing here is about embarking on a big upfront design effort to manage all this complexity. You should differentiate between awareness and action. Your increased awareness of your domain will help you align your systematic reuse efforts with business aspirations and iteration goals. Think of this as your refactoring guide that helps you make surgical changes to your codebase.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Key Differences between Vertical and Horizontal Reuse

October 13, 2009

In an earlier post I had introduced the idea of horizontal and vertical reusable assets. In this post I want to compare them so it is easy to differentiate one from the other:

Characteristic Vertical Reuse Horizontal Reuse
Applicability Only for applications within a specific domain or closely related domains. This is the primary focus when building product lines Applicable across the board for applications regardless of domain. These assets typically tend to be utilities that are generic to multiple applications.
Domain relevance High Low and can be non-existent
Availability outside the firm (i.e. commercial and/or open-source solutions) Low. Domain specific assets tend to be unique and create value by differentiating your firm from its competition. Hence, availability outside the firm tends to be low. High. Domain agnostic assets don’t tend to be unique to a particular organization. E.g. logging or simple data transformations etc.
Potential to create competitive advantage High. Low
Asset Variability Varies from well-defined to open-ended depending on the complexity in the domain. Variations typically aren’t well understood and even if they are, they may not be accurately captured in reusable assets. Tend to be more well-defined than open-ended. Reason? Variations are well known, tend to change less over time, and have been analyzed several times.
Key stakeholders Has to be a combination of business stakeholders and technology. Business knowledge is fundamental to capturing domain variations and relationships and technical expertise is necessary to produce executable software. Tend to be primarily technology. Some assets may require operations or production support teams to provide input as well. E.g. your firm may have a logging or error handling standard that the reusable asset needs to adhere to.
Relationship with SOA & BPM These assets are typically business services, data services, business rules, etc. These assets are typically utility services.

With lower levels of reuse across multiple applications you might be asking yourself if it is a good idea to focus on vertical reuse. My recommendation would be a resounding yes. Vertical assets are unique to your organization. They can be invaluable investments for your firm and require more than just technical expertise to create.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Systematic Reuse Success Factor #4 – Domain Context

October 10, 2009

There isn’t one right way to build reusable software assets. Your business goals, technical environment, iteration and release plans all contribute to both the timing and nature of design decisions. Refactoring existing code to meet business goals is also context driven. Consider:

  1. What product features typically go together?building blocks
  2. Do certain features vary more than others across products?
  3. Is it possible to vary a product feature at runtime or design-time?

All these questions guide design. For instance, if the goal is to support variability at runtime you could support adding new parameters and changing existing ones without code changes or application restarts. As you work on design, keep your domain relevant variations at the back of mind!

Take an example of a widget shop that needs to market its widgets. The user story is to produce different marketing labels based on widget type. There could be several variations to support – frequency of changes to label information, number of words, language, data formatting, mixture of static and dynamic messages that make up a label etc.

Depending on the complexity of your domain, the features could vary simultaneously or in isolation. Consider some of these variations and their impact on design.

#1 Label contents are only static content – you could use a single LabelGenerator using a file configuration.

#2 Label contents are a mixture of static and dynamic content – LabelGenerator now needs two sub-components – a StaticContentGenerator and a DynamicContentGenerator.

#3 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. – In addition to the content generators you need an internationalization component that can support multiple languages

#4 Label contents are a mixture of static and dynamic content. Static content is multi-lingual. Date and currency formatting varies based on country – All components of #3 plus a DateFormatter and CurrencyFormatter based on locale.

Next time you start a project, understand more about the drivers for change in your problem domain. Your domain and the associated context should drive reuse. The more you understand the drivers the easier it is to decide what and how your software assets need to be reusable.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Refactoring To Reuse #3

September 25, 2009

#3 Separate Formatting from Core Domain Entities

You may have a core set of classes or services that represent the domain. These classes need to relate to each other cohesively. In the same vein, they should avoid getting too bulky with functionality that isn’t aligned with the business domain. What could they be? Classic examples include data access and remote host connectivity. Also common are formatting logic that is specific to a business channel or view. I talked about decoupling connectivity earlier so in this post I will expand on formatting logic and is a continuation of the earlier post on formatting. Just like any other aspect of your design you can make formatting as complex as you need. The key thing is to encapsulate formatting into its own layer and not let it pollute your core domain entities. This layer might vary by locale (internationalization), distribution/marketing channel (retail branch, online web, kiosk etc.), file format (HTML, PDF, XML), and device or medium (print, web, mobile devices). Even if you have a simple formatting requirement it makes sense often to isolate the logic away from code that does complex calculations and/or executes business decisions.  At the very least, you can create a FormatUtility class to move formatting code there. It would be better to identify the formatting logic and identify an interface to create. You can implement the interface for a specific need and evolve it over time.

Let’s say you have a class that execute business decisions and also contains formatting logic to create data into a text file as a comma separated value (CSV) file. Refactor the file creation out of this class. Look closer on what exactly the formatting is doing. Is it changing values from numeric to text? Is it changing values from non-compliant value to a standard one? Is it doing locale-specific formatting? So, this code may not just be writing to a text file but transforming data and then writing to a file. You want to reuse the transformation logic as well – if you end up writing an XML document instead of a text file you will need this piece of work again. Now, the file creation logic itself can be reused. It may not need to know that a particular process or function is creating it. This will be useful if all your files have standard header records or place specific processing instructions in them for consuming applications. If there isn’t any, don’t refactor this yet. Finally, the text file format may vary – today it is CSV and you might need fixed width. If you have a definite need you can have the file writer take additional configuration information (e.g.  field name and width for a row).

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Refactoring To Reuse #2

September 5, 2009

#2 Separate Presentation From Domain Entity

Many projects that you undertake might have a presentation component to it – it could be a browser based app, thick client on a desktop, or even a kiosk-type interface. Regardless of specific the presentation technology, you have to ensure that your domain or business logic is effectively decoupled from the user interface code. This is in fact the foundation of the Model View Controller design pattern. You can move business logic in the model layer, presentation logic in the view layer, and the glue code that orchestrates across user actions and domain entities into the controller layer. Often times this separation might not reveal itself in a clean way. In those cases it is important to refactor the code appropriately.

Here is an example – say you have a class named Organization which holds a collection of Units and a collection of Employees. For the sake of integration ease, the Organization class contains a toString() method that generates HTML markup code that formats an Organization object into a neat nested table structure. If you change the way the markup is generated or change rendering output format from HTML to PDF you will end up touching the Organization class. Not a good idea from a reuse standpoint. You want Organization to be about the business entity and nothing else. The fact that it was generated for a web application should be decoupled from the core domain object. You can refactor this class in a number of ways. One way to refactor would be to remove HTML code from the object’s toString() method and move it to a OrganizationFormatter class. This new class could be in a new package structure that is specific to a presentation. If you envision need to support multiple formats you can make OrganizationFormatter an interface and have multiple implementations – a HTMLFormatter, a PDFFormatter, and so on. Based on need a SimpleFactory can be used to return the appropriate formatter at runtime to generate the output. Regardless of the format, you can reuse the Organization class as-is.

Another case where this is needed is when your domain entities make assumptions about the user interface layer. This would require refactoring for enabling reuse as well – will elaborate on this in a future post.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Look beyond the immediate requirement

May 6, 2009

You will rarely get a requirement that covers a wide gamut of your particular problem domain. Instead, you will get requirements for reusable assets in bits and pieces. It is in your team’s best interest to look not just at the immediate need. Look for domain relevant reusable assets that are related to your immediate requirement. Notice that I am not advocating building things that are nice to have! When you take time to understand domain relevant assets you will be surprised how effective you will get with incremental development. You will do work that is aligned with your business vision and throw away less code.

Take an example where the requirement is to provide a credit card authorization service for a customer. You can just build that one service of course and that would be fine for your project. But if you step back and consider the domain, maybe you identify that the credit card authorization is just one kind of funding. There could be debit card, traveler’s checks, or even electronic fund transfer capabilities that are required for the future.

Now, should you be building a credit card authorization service or an authorization service with credit card being one of the mechanisms?

You can enhance the authorization service by adding new capabilities over time. By creating modular interfaces new authorization types can be gracefully added.  The service could interact with different authorization providers based on customer characteristics or traffic on the service or meeting specific service levels.  Or it could use a set of business rules based on type of product being purchased or place of transaction etc. The bottom line – the capability will be able to encapsulate a myriad other domain-relevant functions offering opportunities for reuse in many places.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: