Quote of the day!

This is one of the key takeaways for me whenever I attend any leadership training on emotional intelligence

Do you need to refresh your 'data' of Master Data Management (MDM)

Do you need to refresh your 'data' of Master Data Management (MDM) experiences as a Data or Integration Architect, then just spend some time and read the following:

https://www.dataqualitypro.com/blog/beginners-guide-to-mdm-master-data-management

https://blog.stibosystems.com/the-complete-a-z-of-master-data-management

https://blogs.informatica.com/2020/02/10/master-data-governance-8-best-practices/

https://dwbi1.wordpress.com/2015/02/13/estimating-the-size-of-dimension-and-fact-tables/

https://profisee.com/master-data-management-what-why-how-who/

https://profisee.com/data-governance-what-why-how-who/

As an architect, a readily available template for doing the comparative tool's analysis
https://go.profisee.com/master-data-management-software-evaluation-template

Some more bonus tips from my experiences are:

To move faster with your Data Ops, you need to have well-defined data ops process with tools or platforms which suits your needs, it could be the data virtualization tools (for example, Delphix or Informatica, etc.)

Have buy-in from an executive sponsor within your organization to have a Data Governance initiative or forum who defines the policies, principles, master data hub technology & enabling technology, and data quality measurement

Also, choose a very good governance tool like Collibra (which can simplify your work for Data Governance related tasks at one place)

Focus on the following aspects during the Data Governance guild, such as

• MDM Strategy
• Governance groups
• Policies and rules
• Procedures and processes(life cycle of the data)
• Tools and systems
• Training and engagement
• Audits, and metrics 
• Measure and track the maturity, and then iterate

Bit more specifics on the functional Data aspects, such as

• Data modeling
• Data integration
• Data matching
• Data quality
• Data stewardship
• Hierarchy management
• Workflows
• Data archival and purging
• Data regulations and compliance with security requirements

As part of your MDM strategy, you need to look into all three pillars of master data management, such as

• Data origination
• Data management
• Data consumption

The more highly available system means that the less downtime you have to deal with

The more highly available system means that the less downtime you have to deal with...

Imagine,

The five nines, 99.999 availability means ~5 mins of downtime a year
The four nines, 99.99 availability means ~ 50 mins of downtime a year
The three nines, 99.9 availability means ~9 hours of downtime a year
The two nines, 99 availability means roughly 3 and half days of downtime a year

So, why are we concerned about the downtime? the more downtime you have means the less you attract your customers as I presume most of the systems or applications are accessible 24/7 and it means that round the clock!

We might be thinking that - oh, yeah - we have good ample of downtime in our hands to deal with it, but believe me, if you don't design the system very well with right practices and processes in place then it would be very hard to even achieving the two nines availability too, so, you have to really work very hard and smart to deal with it in an effective manner.

Some tips to utilize the downtime effectively for your systems or platforms are:

1. Make sure to eliminate any single point of failures; Especially handing with the third party API endpoints or dependent systems those are not in your control by having right retry frameworks and circuit breaker patterns
2. Observability and Monitoring with clear alerts and notifications in place
3. Have an efficient CI/CD pipelines with right checks on various stages of your configured environment to stop promoting the bad code (faulty code which has issues, and it can be performance issues as well)
4. Have well-defined deployments and the changed code propagation with
1. Blue-green deployments (having two identical production environments, one is blue and other one is green)
2. Canary deployments (by routing smaller traffic to the new changes and slowly increase the traffic)
5. Encourage A/B testing within your product features release where you are not sure on some of the features; also, promote canary releases too
6. Lastly, try to have a very diligent process by imagining all dimensions how your system can fail with scenarios(and that has come from your proactive resiliency testing activities) so that you have right tools to troubleshoot, tune and respond for any unknown hardware or network failures 

Love you forever... 25 years of Java, and the 25 greatest apps ever made... oh my!

The 2020 year started with bad note and everything around me with Covid-19 and the current situation is really bad, and yet, there is something I can celebrate with my work and my past experiences in this year of 2020... Java turns 25 years as a programming language, and still many enterprises and engineers do use for their day to day work and scalable platforms.

Of course, there is a lot of continued love for Java and the 25 reasons behind it are:

1. Backward Compatibility
2. Maturity
3. Constant Improvement
4. Balance
5. Standards
6. Write Once Run Anywhere
7. Performance
8. Memory Management and Garbage Collection
9. Observability and Management
10. The Java Virtual Machine (JVM)
11. Other JVM Languages
12. Libraries and Frameworks
13. Build Tools and Dependency Management
14. JUnit and Automated Testing
15. IDEs
16. Community
17. People
18. Javadoc and Documentation
19. Open Source
20. Free
21. Object-Oriented
22. Evolution and Adaptation
23. Focus on Readability
24. Language Features
25. The Future 

Now, the 25 greatest Java apps ever written are available here... some of my favorites are:

• Wikipedia Search: using Lucene and Elastic search capabilities are written in Java
• Hadoop
• Machine Learning
• My old sweet memories with 'Java Applets'
• Eclipse and IntelliJ IDEA
• Jenkins
• The first app server I used 'Weblogic'
• Most frequently used IoT solution at home with Samsung mobile-tab-smartTV etc, that is none other than 'SmartThings' from Samsung... oh my, lovely!

Sources:

Link1: https://blogs.oracle.com/javamagazine/the-top-25-greatest-java-apps-ever-written

Link2: https://blog.jetbrains.com/idea/2020/05/25-things-we-love-about-java/

Prioritizing your product roadmap

Techniques for Prioritizing your Product Roadmap

1. User Feedback and Behavior

Your customers are a great source of information to help you prioritize product initiatives. This prioritization method entails looking at customer requests and feedback to identify trends. What features or improvements do customers request most often? Are the customers making those requests high-value? Are they coming from a group of customers who are likely to churn?

You can also go beyond simply listening to what customers say and actually see how they interact with your product. Session recordings can help you identify frustration points (E.g. thrashed cursor or Rage Clicks) or “sharp edges” within your product to find opportunities to improve. If a particular area of your product is a frequent source of frustration, it may be worth prioritizing.

When to use:

Looking at user feedback and behavior can help you better understand the value of an existing list of initiatives.

2. Value versus Complexity

The value versus complexity model for feature prioritization takes a rather popular business decision making quadrant and helps apply it specifically to product decisions. Through countless conversations with product managers, we’ve learned that this method is fairly common due to how easy it is to apply.

You start with a list of potential features and estimate their potential business value as well as the approximate amount of complexity and effort involved to build them. Then, you plot each initiative on a grid like the one above.

The features that land in the high value/low complexity section are your “low hanging fruits” features that are a good starting point. On the opposite end of the spectrum, the low value/high complexity features are probably not the highest priority to work on.

When to use:

The value versus complexity quadrant is a good prioritization technique if you need a quick way to compare a list of features based on quantitative estimates. It also is a good tool for explaining the why behind product decisions to stakeholders due to its visual nature.

3. Weighted Scoring

With ProductPlan, product teams can use a weighted scoring model for their prioritization decisions.

A screen capture of ProductPlan's weighted scoring in action.

The weighted scoring model is similar in nature to a value versus complexity prioritization model. You can use scores to assign different weights to different strategic benefits and then weigh them against costs.

In the example above, we’ve assigned weights across a series of benefit categories which tie directly into business objectives. Then we did the same for costs, looking at implementation costs, operational costs, and also considering risk in our example matrix.

From there, we assigned scores to these categories for every feature on our list to prioritize. Based on the weights we assigned to each benefit and cost, we were able to reach a quantitative score and rank for each initiative on our list.

When to use:

Weighted scoring models are useful for product teams who need to make objective decisions about feature prioritization and need to consider multiple factors in those decisions.

4. Buckets (Kano model)

Many people elect to use a “bucket” approach to feature prioritization, more formally known as the Kano Model. Most of the time, this model is used to understand the relationship between customer delight and product function and use that information to prioritize a balanced roadmap.

Using the Kano Model, features are categorized in the following buckets:

• Threshold features: the functionalities that you simply need in order to sell the product.
• Performance features: features that help ensure customer satisfaction increases.
• Excitement features: Features that yield an extreme amount of customer delight. They may not be “necessary” features, and your customers might not even notice if they weren’t there but their mere existence creates “delight.”

When to use:

The Kano model is useful for teams with various differing objectives who need a way to keep a balance between all of them.

5. Buy a Feature

Playing a round of “buy a feature” can help you understand how important specific features and functionalities are to stakeholders and even customers. The process is simple but can be a fun activity for getting your team involved with the prioritization process. Start out by making a list of potential features and giving each one it’s own “price.” You can come up with the prices based on the estimated costs associated with developing each feature.

Once you’ve created a list of features and their prices, hand out Monopoly money or some other “currency” of your choice and have your participants purchase the features they want. Most likely you’ll see some people putting all of their “money” on a single feature while others spend their feature allowances on multiple items.

At the end, you’ll have a list of prioritized features.

When to use:

Buy a feature is a technique that’s best to use when you need a quick, interactive way to understand where a group of people see the most value across a list of features.

6. Opportunity Scoring

Opportunity scoring is a method often used to identify opportunities to better meet customer needs. This customer-centric prioritization approach takes into consideration two factors: feature importance and satisfaction with the existing solutions. You start by asking customers to rank or score the importance of a list of features. After that, you have them rank or score their level of satisfaction with the feature.

Based on these inputs, you can generate a list of opportunities: features with high importance scores and low satisfaction scores.

When to use:

Opportunity scoring works well when you need to determine where to make incremental improvements to a list of pre-existing features based on customer satisfaction.

7. Affinity Grouping

Affinity grouping works best when done as a team activity, and it can be a rather fun one at that. Start by having everyone write down their ideas on sticky notes and put them on a flat surface. After you’ve come up with a decent amount of ideas, you work with your team to group similar ideas together. At the end, the team gets together to rank or even vote on each group.

When to use:

Affinity grouping is best used by teams who are collaboratively trying to come up with a general direction. This sort of brainstorming helps teams figure out what they should build.

8. Story Mapping

Story mapping is commonly used to define tests and minimum viable products (MVPs). There are several resources available out there about story mapping best practices, so I’ll share just a high-level overview. It is basically a visual way to develop your product backlog and delineate sprints.

To conduct a story mapping session, you start by creating task-oriented user story cards. Then, you group them together into categories and work each category into a step by step workflow. Once you’ve created these workflows, you can prioritize each group. After this, you can break down the workflows into either releases or sprints.

When to use:

Story mapping is great when you need to take larger concepts and break them down into workable tasks. It’s useful for determining what your MVP will look like and identifying the releases that follow.

Smart Roadmap Prioritization Means Smooth Sailing

Captains may be the ones steering the ship while standing at the helm, but they can’t see everything from there. That’s why they listen to their crew, who can share what they see and know to give them better perspective.

Listen to your team, be open to hearing multiple opinions. But also be objective and mission-driven with your plan. Get the full story before you make decisions.

Remember: your product roadmap is no place for emotional decisions. But under pressure, it’s difficult to completely remove emotions from decisions. That’s where objective product roadmap prioritization frameworks come into play.

Source: https://blog.fullstory.com/8-ways-to-prioritize-product-roadmap/