May 31, 2016
I wrote earlier about easing integration when providing reusable software assets. In this post, will elaborate on specific techniques for driving platform adoption & their rationale. Recognize that most developers who will evaluate your platform are trying to solve a specific business / functional problem. They want to quickly ascertain if what you are providing is a good fit or not. Instead of convincing them, help them arrive at a decision. Fast. How exactly do you do that? Here are a few ideas:
- Provide details on the kinds of use cases your platform is designed to address. Equally important is to be transparent about the use cases that you don’t support. Not now and never ever will.
- Create developer accelerators – e.g. a Maven Project Archetype or a sample project to try out common functionality
- Identify areas where developers can extend the platform functionality – how will they supply or override new behavior? How will you make it possible to inject, easy to test, and safe to execute? There are lots of techniques that you can use but first you have to decide to what extent you want to allow this in the first place.
- Make your platform available in “localhost” mode – i.e. conducive for use with the IDE toolset. This is more challenging than what it sounds – e.g. if your platform isn’t modular, making it work in local mode will be very challenging. Ditto if your platform relies on external services / connectivity / data stores, etc. that aren’t easily replaceable with in-memory / mock equivalents.
- Allow developers to discover your platform via multiple learning paths. Some might want to explore using a series of Kata lessons that tackle increasingly complex use cases. Others might be looking for answers to a specific problem. You need a user guide, code kata, examples, and more importantly, you need to make them easy to access.
- Identify which areas of the platform adoption curve are the most time consuming and figure out how to reduce if not eliminate them entirely. For instance – does your platform require an elaborate onboarding process? Are there steps that can be deferred till production deployment?
May 29, 2016
Managed platforms are a very effective and pragmatic way to drive systematic reuse across an organization. Managed platforms can provide a number of benefits ranging from simplified developer experience, out of the box productivity components and tooling, and most importantly, a whole host of non-functional concerns being addressed in an integrated fashion. Good managed platforms exhibit some common traits. They:
- Solve a specific problem really, really well
- Are easy to signup, develop in, and use via a developer SDK
- Provide a number of integrated components that address specific pain points
- Are extensible and provide clear and safe injection points via a public, published, well maintained API
- Free the developer from having to procure hardware or orchestrate deployment activities
- Make it easy to report bugs, fixes, and contribute enhancements
The best part of managed platforms? They can dramatically alter the productivity curve for your development teams. Every developer doesn’t have to worry about high availability, horizontal scaling, capacity management, public APIs, version management, backward compatibility, and ongoing care and feeding of core reusable components. The platform provides value and more specifically peace of mind via powerful abstractions.
This isn’t an exhaustive list but given the general push towards cloud based architectures, good platforms will give your teams much more than just reuse! I will elaborate on each of the above traits in follow up posts.
May 28, 2016
Although starting from scratch is simpler when building reusable assets, reality is that you are probably maintaining one or more legacy applications. Refactoring existing legacy assets has several benefits for the team. Here are a few:
- The refactoring effort will make you more knowledgeable about what you already own
- Will help you utilize these assets for making your systematic reuse strategy successful
- Saves valuable time and effort with upfront domain analysis (of course this is assuming what you own is relevant to your present domain)
- Make your legacy system less intimidating and more transparent.
- Provides the opportunity to iteratively make the legacy assets consistent with your new code
If you cannot readily identify which legacy module or process is reusable you have two places to get help – your customer and your internal subject matter experts. Your customer can help you with clarifying the role of a legacy process. Likewise, your team probably has members who understand the legacy system and have deep knowledge of the domain. Both of them can guide your refactoring efforts.
The act of examining a legacy module or process also has several benefits. You can understand the asset’s place in the overall system. The existing quality of documentation around this asset and usage patterns can be understood as well. Now, you can make an informed opinion of the current state of what you have and how you want to change it. Before making any changes though it helps to consider the next few moves ahead of you. Ask a few questions:
- Is the capability only available in the legacy application and not in any other system that you active maintain and develop?
- Is it available only to a particular user group, channel, or geography?
- Is the capability critical to your business sponsor or customer? If so, are they happy with the existing behavior?
- How is the capability consumed currently? Is it invoked as a service or via a batch process?
- How decoupled is the legacy capability from other modules in the application?
These questions will help you get clarity on the role of the legacy asset, its place in the overall application, and a high level sense of the effort involved in refactoring it to suit your requirements