June 12, 2016
Managed platforms are quite effective in providing a host of benefits. There is quite rightly a strong focus on the core value, offering that a platform provides. To increase the odds of success with your platform, focus on building a broader ecosystem.
What do I mean by a broader ecosystem? Here are a few things to consider:
- Co-creation: enable your client developer community to create capabilities for the platform. Design, publish, and evangelize APIs that allow them to extend and contribute to the platform. You can start simple via interfaces or have a full-fledged Plugin mechanism. Either way, ensure there is a well defined process to assess the fit, maturity, and platform integration. More importantly, ensure there is an easy way to allow contributors to test their creations. You can provide utilities that works with common testing frameworks such as JUnit (e.g. Rule that encapsulates complexities with using the underlying Platform APIs, bootstrapper classes that initialize / shutdown platform APIs, etc.)
- Enterprise Integration: Make your platform work out of the box with existing platforms / standards within the enterprise. Specifically for areas such as authentication / authorization, alerting / notifications, instrumentation, discovery, etc. Taking optionality away from your clients is a very good thing in this space. They can save costs as these things work natively – no need to worry about creating, testing, and integrating. Obviously, if something doesn’t exist and needs to, co-create it with your clients if that can be done as part of a business deliverable!
- Documentation: Platform teams must make client-facing documentation a priority. Think about making your firm’s developers more productive. Make it easy for them learn the core concepts and API constructs to get up and running on the platform. Provide API documentation (such as Javadocs), cheatsheets, user manuals, and code examples that demonstrate typical usage scenarios.
- Support Tooling: Getting clients to self-serve via enterprise-approved tools will be extremely important for their day to day experience interacting with the platform. Think about logging, remote debugging, tracing, reconstructing incident state, etc. and provide integration with tools that they are already familiar with for existing apps. You may not need to or want to expose too much here but constantly think about native integration that is presented in a manner that makes it easy for clients to get to the root cause. If they keep calling you to troubleshoot issues, that is time to introspect and improve!
- Community Events: provide opportunities and channels for your clients to communicate not only with the platform team but also with each other. Having regular meetups – from simple introductions to joint design / contribution reviews and updates – are very effective. If there is a broader community to rely on, clients can help themselves and learn from each other on an ongoing basis.
May 13, 2013
Here are five questions to ask your teams to increase reuse effectiveness when evaluating a functional requirement:
- Is a requirement already met within the application or platform or is this the first time?
- If the capability already exists, does the current implementation provide the right extensibility? Often, existing code would need refactoring to meet a slightly varying set of requirements when compared to the original one. Take this as an opportunity to tease apart the abstractions necessary to capture the variations. What’s common and what’s truly different is the key aspect to figure out.
- Which other team or application has encountered this functional requirement before and how did they solve it? If you aren’t sure, ask around!
- Do we truly believe we are the first ones to stumble upon this need in the team/department/division/the firm? Try “laddering up” – as the Heath brothers call it in their latest book Decisive – incrementally and deliberately extract the key aspects of the problem you are trying to solve and look for places where solutions already exist.
- If you find existing code to meet your need – evaluate it with a critical eye towards non-functional needs. Is it performant enough to meet the needs of your use case? does it provide adequate extension points / hooks to integrate with the rest of your application? is it a library or a hosted service? If hosted, what is the resiliency and availability strategy?
Too often, there is a bias towards implementing from the ground up due to either lack of time (don’t want to find out if other implementations or existing solutions exist and if they do, would they fit) or lack of trust (don’t want to use this team’s software or codebase or don’t trust that the quality of the implementation).
These aren’t exhaustive – what other questions come to mind?
February 17, 2013
Want to envision, design, and implement reusable software components that your development community will enthusiastically adopt? Co-create! Here are 5 tips to leverage co-creation when driving systematic reuse initiatives:
- Have an idea that applies to multiple projects? Get the project leads to co-ordinate and align resources and partner with developers from both teams to develop the design
- Share the source code of all your reusable components so every developer in the team can see under the hood how the component works and how it can be improved
- Work hands-on with developers when defining classes, external interfaces, etc. – not just via block diagrams but actual code. Pair program and show them how to think using abstractions, what aspects of the design to make extensible and the rationale for it, etc. – you’ll be surprised how effective this is and how much all parties learn from the process
- Share the big picture – every time and across every project – developers and development managers need to be convinced that their contribution aligns with the overall technical strategy. This should also highlight why a shared component’s test coverage and robustness needs to be high and continuously improved
- Use design reviews, code reviews, and retrospectives to continually look for ways to collaborate and leverage each other. See boiler plate code that can be better encapsulated, or missing tests, or a smarter algorithm – get your hands into the code and work with the concerned developer. They will appreciate why you want them to use a particular design pattern or think about a problem in a certain way. Added bonus – just like item #3 – every participant will learn from the exercise.
Finally, co-creating reusable components greatly reduces friction associated with having to implement a design that was mandated. You want passion and enthusiasm from the dev community – not compliance!
October 25, 2010
In order to get critical mass for reusable assets, they have to be created and evolved in a collaborative manner across development teams. How can we enable co-creation? Several specific strategies can help:
- Share the source – ever wondered why open source projects succeed when in-house efforts haven’t? Sharing the source code behind reusable assets makes a world of difference. It increases transparency (with respect to capability, behavior, and quality) and provides an opportunity for the developer community to participate in the analysis, design, and implementation activities. More importantly, it enables teams to modify the source per their specific needs and allows them to submit/merge the changes with the main build.
- Provide detailed documentation for reusable assets that are both available, in-progress, and planned for the future. It can come very handy when there is a design decision to make in a project – time and time again, you will realize the greater the information on existing assets, the easier it becomes to enhance/change them and combine them in new and innovative ways.
- Explicitly seek participation and design input when creating/updating a reusable asset. This not only increases buy-in from the tech community but also provides new ideas, concepts, and problem solving techniques that the entire department (even an organization) can benefit from.
- Encourage questions, specially from new members and junior developers – welcome the most basic questions about the reusable asset inventory. Make sure an environment where open, honest exchange of ideas is taking place constantly. Good ideas come from several places and it is critical that developers don’t feel alienated or ignored due to lack of knowledge about one or more reusable assets.
- Seek out subject matter experts – several developers and business analysts are essential to increase domain relevance, and domain alignment for reusable assets. Pretending to have all the answers or feigning perfection will only reduce the quality of reusable assets and ultimately prove detrimental to reuse objectives.
Several systematic software reuse efforts fail to get off the ground – it isn’t because of inadequate domain variations or severely limiting technology constraints – due to lack of grassroots appeal among the technical community.
Co-creation addresses several issues at once: it exposes developers to high quality coding practices, increases awareness of available assets, and provides a controlled environment to experiment and evolve reusable assets.
November 5, 2009
If you want to kill the potential for systematic reuse, all you have to do is think only about your silo and not about anything else. This silo could be many different things and in each case it inhibits reuse as well as the effectiveness of your team as a whole. Here are some specific examples:
- At the enterprise level, silo thinking can introduce very many inefficiencies and redundancies. Silo thinking will optimize solutions for a specific project at the expense of the overall firm. For example, say you have a reusable asset for calculating taxes and a new project re-implements the tax calculation business logic all over again. Or they ignore existing software infrastructure and introduce a new vendor product. This may help a specific project but adds cost and complexity to the enterprise.
- Silo thinking specific to an application means potentially reusable assets are not created and existing reusable assets are not leveraged. Think about the application’s needs to get reference data or connect with external systems or format data per a destination’s specific needs. Is your application using reusable assets? If not, is there an opportunity to create one by building or refactoring?
- Silo thinking specific to a team typically results in lack of reuse across projects that impact multiple teams. Do other teams in your department/division/organization know what reusable capabilities exist? do they know the overall reuse roadmap and how that aligns with business objectives? can they contribute towards growing the asset base?
- Silo thinking specific to a person typically results in solutions that don’t benefit other developers in the team. Maybe you have a neat utility that makes it easier to fetch correlated data across multiple data sources. Or you wrote a neat script that validates system variables or smoke tests key functionality. If they save you time and effort, why not share them with your team? Two immediate benefits will happen: other developers will start saving time as well increasing the team’s overall productivity. You will start getting constructive ideas on making these solutions better.
Have you noticed these? how do you encourage solutions that go beyond a specific silo’s needs?
Like this post? Subscribe to RSS feed or get blog updates via email.
August 4, 2009
Tip #16 – Work with multiple stakeholders not just development
Systematic software reuse is a complex and challenging journey. Many of us in technology think of reuse from a developer standpoint. This is only part of the story. The success of reuse efforts often hinge on more than developers and development practices. You need to recognize the other stakeholders in this journey – they include system analysts, production support staff, information modelers, technical leads, and most importantly executives and development managers. Unless you have management support it will be tough influencing many projects in your organization. In the same vein, unless your reusable assets are supported in a production environment you cannot garner the required credibility of consumers and partners within your organization. Before you rush to buy the latest greatest silver technology silver bullet that will take you to the promised land of systematic reuse recognize that there isn’t one. It is a collaborative, incremental, and iterative effort requiring technical excellence, diplomacy and negotiation skills, and continuous communication. All these ideas apply whether your reusable asset is a library, framework, or service capabilities in a SOA context.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
July 18, 2009
An often overlooked aspect of systematic reuse is integration of reusable assets with applications, processes, and services. Most teams focus on building a large inventory of reusable assets – services, objects, frameworks, domain specific language libraries. While that is necessary it is not sufficient for succeeding with systematic reuse. One essential ingredient is ease of integration. What do i mean by that? Specifically:
- Evaluating the requirement and making a determination whether an existing asset can fulfill the need (as-is or with modifications) or a new one needs to be developed.
- Address risks with integrating with a reusable asset (meeting SLAs, solution complexity, etc.)
- Sharing information on available interfaces (is there a java interface? a web service?)
- Providing code samples and integration design patterns
- Provide comprehensive list of error codes and error handling recommendations – if a service throws a particular error what should the consumer do? are there specific business errors or data validation errors that the consumer needs to be aware of?
- Ensuring the consumer doesn’t starve the reusable asset’s resources. This is essential for services based reuse where multiple consumers are invoking the same service capability.
- Assistance with testing the integration (provide test data, unit test code, as well as utilities to test response time/throughput)
You can build up a service catalog and magically hope to achieve high degree of reuse and you will most likely be disappointed. Bottom line – reach out to your consumer and help them succeed. Make it easier for them to evaluate, integrate, and test. Slowly but surely your teams will start coming to you as opposed to you trying to ‘sell’ them on the value of reuse!
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :