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?
Leave a Comment » | 
Collaboration, General, Reuse | Tagged: Collaboration, software reuse, systematic software reuse | 
Permalink
Posted by vijaynarayanan
December 7, 2012
Heard a very interesting talk by Mr Sharad Sharma titled “Surfing The Innovation Waves” that puts in context the nature of innovation happening in the marketplace and the contextual forces behind the changes. He talks about adopting the
“hobbyist temperament” and gave several examples of people in the edges of industries disrupting the establishment. The key behavioral traits he mentioned are as follows:
- Stepping outside one’s comfort zone
- Having an internal compass – “i got to excel.” Don’t rely on external cues and rely on self-mastery instead.
- Get comfortable to stand out and be an underdog.
- Persisting in face of adversity. Even if you are right, it doesn’t matter till you are able to go past the criticisms that will keep coming
He then expanded on a New Age Code of Conduct - keeping in line with the idea of the hobbyists and people who are innovating at the margins. He talked about volunteers, poeple are doing it for others like themselves and participating in creating and growing “Creation Nets”. The Creation Nets are going to be the wave of the future where many people sharing a common cause will come together and contribute to innovation via rapid and effective collaboration. Community activity is key because the world is much too complex and you have to collaborate with others for innovation to happen both within and outside the organizational boundaries.
This new code of conduct has particular behaviours that he recommends:
- Setting others up for success. Form of servant leadership – make it your job to help others around you get to their goals. Evolving shared aspirations is very important
- Make sure you give more than what you take – effect of the commons. Amplification of co-operation is key and if you don’t invest in public good, collaboration isn’t sustainable. Academic institutions take an active role to play in public good creation.
- Say what you mean, do what you say. Allow for trust bonds to be formed – cannot allow duplicity. Without trust, no creation nets are possible and effective collaboration isn’t an option.
- Make mistakes. Make them fast and recover quickly
- Don’t wait for instructions – just make it happen. Pick the challenge that catches your fancy and start working to happen. Pull based model and not a push based model. I will do this with the best of my ability. Focus on excellence.
The talk is definitely worth the time in full – do see it online here: http://www.iimb.ernet.in/node/3164
1 Comment | General, open source | Tagged: innovation, risk taking | Permalink
Posted by vijaynarayanan
August 11, 2012
When building reusable components, you want to allow rapid component discovery, assembly, and testability. Without these characteristics, it will become difficult for developers to use the reusable components in a productive manner. Below are five things to do to accelerate component adoption:
- Provide examples on how to wire the reusable component with widely used proprietary or external frameworks
- Make it easy to use sensible defaults with frequently used features – if almost every application needs a particular feature, why not make it the default option?
- Open up the source code and invite feedback and improvements – chances are high that your development community has tons of ideas to make use of reusable component in new and innovative ways
- Engage early in the development lifecycle – don’t want till the very end to evangelize / educate teams about the component – actively and continuously engage with the developers to look for integration opportunities
- Tie code review feedback to component adoption – spotting code that has traits such as duplication, inefficiency, unmaintainable? Treat every defect as an opportunity to remove technical debt and increase consistency
These are by no means exhaustive and key is in performing them in a disciplined manner project after project.
Leave a Comment » | General, Reuse | Tagged: refactoring, software reuse, systematic software reuse, technical debt | Permalink
Posted by vijaynarayanan
July 1, 2012
In the zeal to create a reusable component, you should be careful not to over-engineer i.e. pursue perfection. The functional needs have to be at the core of the reusable asset’s ability to solve a particular problem. When in doubt, remember that as time goes on, the team will learn the nuances of the problem domain and will be able to make better design decisions. Explore the domain with the team rather than force a solution. How exactly do we do that? We can:
- Practice creation of simple, domain-aligned abstractions
- Continuously validate the domain with functional experts in the team
- Consciously exclude aspects of the domain that aren’t relevant / well understood when defining reusable components
It is critical for the team to discover and stumble upon reusable assets – rather than big design up front efforts lasting for months. Keep it agile and continuously evolving and improving.
Leave a Comment » | General, Reuse, agile | Tagged: agile, Design, domain driven design, software reuse | Permalink
Posted by vijaynarayanan
May 27, 2012
Working with clients who are consuming your services? Here is a mini-checklist of questions to ask:
- While executing request/reply on the service interface is there a timeout value set on the call?
- Is there code/logic to handle SOAP Faults /system exceptions when invoking the service?
- Is building service header separated from the payload? This will facilitate reuse across services that share common header parameters
- If there are certain error codes that the calling code can handle, is there logic for each of them?
- Is the physical end point information (URL string for HTTP, Queue connection and name for MQ/EMS) stored in an external configuration file?
- Is UTF-8 encoding used while sending XML requests to the service i.e. by making use of platform-specific UTF encoding objects?
- If using form-encoding are unsafe characters such as ‘&’, ‘+’, ‘@’ escaped using appropriate %xx (hexadecimal) values?
- While processing the service response is the logic for parsing/processing SOAP and service-specific headers decoupled from processing the business data elements?
- Is the entire request/reply operation – invocation and response handling logic – encapsulated into its own class or method call?
- While performing testing, is the appropriate testing environment URL/queue manager being used?
- Is a valid correlation id being used in the service request? This is very essential for aynchronous request/reply over JMS (JMS Header) or HTTP (callback handler)
Leave a Comment » | General, SOA | Tagged: checklist, messaging, service orientation architecture, services, SOA, systematic reuse, web services | Permalink
Posted by vijaynarayanan
January 7, 2012
Systematic reuse in the context of enterprise integration provides several benefits:
- allows the team to evolve consistent set of data interfaces across integration efforts – if multiple systems need to integrate with yours, can you define a generic data model for your domain-specific concepts? This could be file layout(s), service interface schemas, or platform specific APIs
- enables common interfaces for domain specific services and business processes
- integration points often need cross-cutting concerns such as logging, transaction management, exception handling, etc. that can be reused
- reusable utilities can help with support and testing tools – for instance, reply failed messages, drain message queues/topics, generate high volume test data, etc.
Question is – are your teams taking advantage of integration points? or is each integration point implementing identical or similar functionality in an inconsistent fashion?
Leave a Comment » | General, Reuse | Tagged: EAI, integration, integration points, software reuse, systematic software reuse | Permalink
Posted by vijaynarayanan
December 24, 2011
Service driven systematic reuse takes conscious design decisions, governance, and disciplined execution – project after project. In order to sustain long running efforts such as service orientation, it is critical to track, report, and get buy-in from senior management in the organization. So what metrics are useful? Here are a few:
- Total number of service operations reused in a time period
- Total effort saved due to systematic reuse in a time period
- Number of new service consumers in a time period
- Number of new consumer integrations in a time period (this includes integrations from both new and existing consumer
- Service integrations across transports/interface points (for instance, the service operation could be accessed SOAP over HTTP, or as SOAP over JMS, or REST, etc.)
What metrics do your teams track?
Leave a Comment » | General, Reuse, SOA | Tagged: metrics, service metrics, service orientation, service reuse, SOA, systematic reuse | Permalink
Posted by vijaynarayanan
April 13, 2011
Wrote earlier about the importance of refactoring and continuous alignment within the context of systematic reuse effectiveness. Reducing technical debt is an integral aspect of refactoring. This post provides tips for reducing technical debt in your software assets:
- Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)
- Minimize similar solutions for slightly varying business processes and instead create common process flows
- Loosen tightly coupled integration/transport logic with business logic
- Provide consistent strategies for implementing cross cutting concerns
- Replace tactical implementation for a problem that has a better open-source alternative
- Eliminate redundant approaches for managing configuration information
- Harmonize multiple, incompatible interfaces and make them more domain relevant
- Minimize excessive coupling with a particular technology/implementation stack
- last but not the least – create a comprehensive suite of automated tests
Are there similar themes in your development efforts? What steps are you taking to ensure technical debt is addressed?
Leave a Comment » | agile, General, Reuse | Tagged: agile, configuration, domain driven design, loose coupling, refactoring, software reuse, systematic software reuse, technical debt | Permalink
Posted by vijaynarayanan
September 8, 2010
As a follow up to the earlier post on using freemarker, here is an example of creating RSS 2.0 feeds using a freemarker template. This FTL will work assuming there is an input javabean that has a collection accessible via getItems() and returns a list of Item objects. Each Item would have a title, description, link, and last modified date properties as shown below:
<rss version="2.0">
<channel>
<#list items as myitem>
<item>
<title>${myitem.title?html}</title>
<description>${myitem.description?html}</description>
<link>${myitem.link}</link>
<pubDate>${myitem.lastmodifiedDate?datetime}</pubDate>
</item>
</#list>
</channel>
</rss>
Leave a Comment » | General, open source | Tagged: freemarker, software reuse, templates | Permalink
Posted by vijaynarayanan
August 14, 2010
There is a reason why your team builds software – most likely, you are either building a product for external customers or supporting technology solutions for internal stakeholders within the organization. Systematic reuse cannot be achieved if we focus exclusively on technologies. Focus on capabilities, more specifically, business capabilities instead.
This is a simple but significantly useful perspective to adopt. Capabilities are tangible units of functionality – regardless of implementation technologies used or systems that they are part of. When capabilities are identified, you can make more informed decisions about whether or not it is a reuse candidate. This is also handy every time there is a discussion on which part of a functionality should reside in a server component or a presentation component etc. Capabilities, when aligned with business needs, gives you the right level of abstraction when considering refactoring efforts. Are we refactoring the right capabilities from a legacy codebase? is this a capability that is useful as-is or is it only relevant within the context of a specific business process? is the current implementation assuming (aka coupling) too much about a business capability?
These are extremely relevant questions – and notice how we haven’t talked about technology implementation decisions. That is on purpose – if we are not careful, impatient technology choices could adversely constrain business capabilities. Once you are clear on the capabilities – technology decisions and need for variability, agility, and other quality attributes can be made appropriately.
Leave a Comment » | General, Planning, Reuse | Tagged: business capability, implementation, software reuse, technology strategy | Permalink
Posted by vijaynarayanan
