March 5, 2011
Pursuing systematic reuse the agile way? This primer will cover a variety of design practices to help your development teams. It covers:
- Building reusable assets from existing applications
- Designing new reusable components and services
- Design patterns, product line practices, and more!
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:
- 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.
- 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.
- 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.
- 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.
October 1, 2010
SOA Adoption Using Agile
Part 2 of a two part Article series on SOA adoption is up on the SOA magazine. The first part is here.
August 18, 2010
SOA Adoption Using Agile
Part 1 of a two part Article series on SOA adoption is up on the SOA magazine
August 15, 2010
I have heard some variation of the following line from developers, technical leads, and architects – “we want to make things more reusable, but we don’t have the time.”
There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:
- is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
- is the capability making something incredibly hard/defect prone simpler and/or easier?
- is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
- is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
- is the capability only available in a particular technical platform but is solving an often needed problem?
- is it automating boiler plate code generation or preventing defects?
- is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.
This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.
August 1, 2010
Here is a free e-book on getting started with systematic software reuse. It introduces software reuse, risks with reuse and how to address them. Also includes an example roadmap that can be used as a reference. Enjoy!
July 14, 2010
Code reviews can be extremely effective driving systematic reuse. To be sure, there are multiple objectives with code reviews (e.g. adhering to naming standards, detect defect, write consistent comments, etc.). Additionally, they can help with reuse in the following ways:
- Reviews happen prior to code being placed in production – they give you a chance to extract, build, or integrate reusable assets.
- Code reviews often identify opportunities to refactor – refactoring to reuse. Have you ever had a review where someone said, “you know what, you should talk to Joe, since he is building a similar thing…” or “…we should use the existing service for implementing this story.”
- Reviews help discover reusable assets – you might include classes and interfaces (not necessarily neatly demarcated) – in a component that can really be split up into two or more components. It may be appropriate to slice up the logic to ensure the existing component isn’t too monolithic
- Reviews are very effective in preventing defects – with reusable assets, quality is everything and the act of reviewing them is critical to their stability and production-readiness. These can be extended to unit tests and documentation as well.
- Reviews are a neat opportunity to communicate to at least a sub-set of the team what reusable assets exist and how they can be leveraged. Often times, when assets are mentioned as-is, they may not be that well received. Place them within the context of a real project, a real deliverable, and a tangible need – now the communication is much more effective.
As more developers pitch in and learn from each other, the reviews will become a critical part of how you develop and evolve reusable assets.