Posted on

Gestalt Principles

  1. Similarity: Elements that look similar are perceived to have the same function.
  2. Proximity: Elements that are close together appear to be more related than elements that are spaced farther apart.
  3. Common Region: Elements located within the same area are perceived to be grouped together.
  4. Closure: Humans subconsciously ‘complete’ the ‘incomplete’ objects or scenarios they see or perceive
  5. Continuity: Elements that are in same line, or curve are related

(there are more…)

Posted on

Bias! in Psychology

  1. Confirmation bias :- Your prior (vague) knowledge or beliefs influence your judgement. You think you know this already. because of preconception
  2. False consensus bias :- Believing your own choice as a choice of group. Overestimating that a large number of people will agree to your judgement
  3. Recency bias :- You subconsciously believe that the most recently/last heard/discussed idea is the best
  4. Primacy bias :- You tend to believe/recall what you heard first (may be from a first speaker) is the best. You don’t remember or don’t care what later said because the first speaker made strong points.
  5. Implicit bias :-  You subconsciously choose a set of people to interview, because you are comfortable with them.
  6. Sunk cost fallacy :- You will tend to keep the same ideas/work/investments, because you already invested in it.

Theme source: UX Design course by Google

Posted on

IBM Enterprise Design Thinking–Notes from co-creator

Framework

The problems and solutions are an ongoing conversation of, the continuous cycle which consist of: Observe, Reflect and Make.

Principles

  • Focus on user outcomes (Pur users first. Measure by how we fulfill user’s needs. Know the difference between users and clients.
  • Restless reinvention
  • Diverse Empowered Teams

Keys

Three techniques for diverse teams to reflect together as we move from idea to outcome.

  • Hills – Statements of intent written as meaningful user outcomes.
  • Playbacks – Bring stakeholders into the loop in a safe place to ell stories and exchange feedback.
  • Sponsor Users – Real world users, who contribute their domain expertise to your team.

Observe: Ask each other

1

Reflect:  Ask each other

2

Make: Consider these questions

3

Posted on

Is the choice of programming language important for Microservices?

An answer of definite YES or NO is highly irrelevant here, because a Microservice can be written in any programming language which supports some communication end point, such as API.

A Microservice is an application architecture style and the programming language used is just one element of it. Let us revisit Martin Fowler’s definitions from 2014,

…a particular way of designing software applications as suites of independently deployable services

…developing a single application as a suite of small services, each running in its own process

…which may be written in different programming languages and use different data storage technologies.

Not all Microservices need to follow all the characteristics defined by all the experts in the field, but at least we have to make sure it is not violating any characteristics.

There are different deployment options available such as Kubernetes, or Azure Container Service. They use a concept of removing-the-bad, and spin-up-new containers. To support this process, it is important to make sure our microservice applications are independent and stateless to avoid any application crashes or malfunction.

Coming back to our question of programming languages, while we can use any languages or technology stack for writing Microservices, it is always good to keep these points in mind while selection:

  1. If not necessary, try to avoid languages which requires a virtual machine to run..such as JVM for Java. Some memory resident platforms require some bootup and killing time which can delay the instance creation and  destroy. Found Go handles is better.
  2. Smaller the better, the container size matters. Some languages require a bigger library to be accompanied to have the application work properly, but it makes the container size bigger.
  3. Application performance – some programming languages are faster for some operations compared to others

Well, it all boils down to the functional and technical requirements, and I do believe that the selection of programming language is not crucial for most cases. Upon Google research, it is also found that people rely/biased  on their own skillset to build Microservices, than making the choice-of-language a problem in front of them, which makes this question a low priority concern.

Read about Microservices here – https://martinfowler.com/articles/microservices.html

Posted on

What is Microsoft Cloud Adoption Framework?

Microsoft Cloud Adoption Framework is basically a collection of guidance, best practices, tools and techniques to be followed by various technology business and technology stakeholders in the organization  to make sure they build and maintain the best possible platform which ensures security, governance, scalability and other non functional requirements aspects.

While cloud adoption gives 80%+ of benefits compared to the traditional, or legacy on-premise data center infrastructure way of life, as a public platform, it also introduces few points of concerns to business leaderships such as Security. Years back when the cloud service platforms were initially introduced, the banking and other financial firms had trust issues because there were multiple levels of organizational hierarchy to be convinced and technical knowledge level is different from person to person. But today, it is not anymore an issue because we have multiple cloud providers in the market providing cutting edge solutions to solve each and every problem of the customer and no significant breaches were reported, and more importantly the cloud literacy level of people also rose.

Here is where the Cloud Adoption Framework plays its big role in helping people, process and the technology. It defines a clear and practical roadmap to the cloud that is foolproof and quick enough to give businesses the expected result and smooth transition.

Below are the main stages in the roadmap  as per Microsoft Cloud Adoption Framework:

image

  1. Define: We start the journey by defining a business case, followed by a cloud adoption strategy. We set our vision, key drivers, objectives, and justification inline with the organization vision and other aspects such as financial and technology parameters.  We set the expectations and document the need at this stage. The motivation for a cloud adoption decision could be because of upgrading technology, business expansion, cost, reducing complexity, operational efficiency, customer experience, faster time-to-market, or business agility.
  2. Plan: Create the cloud adoption plan. This is one crucial phase where we have to plan the communication model, security, monitoring etc. Cloud readiness and adoption plan will be crystal clear at this point. Most cases would require a platform/application/infrastructure assessment and gap analysis for effective planning, especially for enterprise level applications. It is recommended to have an incremental implementation approach for larger projects. Approaches taken for migration for each application or service could be different. Several approaches are in consideration such as Rehost (lift-and-shift), Refactor (like splitting functionality to multiple chunks for maintainability), Rearchitect (like converting monolith to microservices architecture for scalability), Rebuild (dump unused functionality/applications and build new), and Replace (discard the old applciation and make everything new). For the business continuity, you might also plan to have the coexistence of legacy and new platforms for a short/evaluation period, not just to evaluate the efficiency, but also to help the staff and customers a smooth transition.
  3. Ready: We set the stage, aka Landing Zones and prepare other cloud infrastructure dependencies here.  This phase also includes the validation of the architecture, and patterns & practices.  As part of the process, team will address the issues identified while gap analysis, prepare team (eg. by providing training), and establish mitigation/support options.
  4. Adopt: Action phase! We do the migration/modernization of platform and depended applications. We also may do the cloud native transformation if planned earlier. Migration to PaaS services or introducing DevOps/DecSecOps/DevSecTestOps can be in the scope.
  5. Govern & Manage: Time to set benchmarks, compliance, rules, protocols, risk tolerance levels, mitigation plans, monitor, audit, and manage. Governance & Manage are not really phases, but a continuous monitoring and improvement process.

Read more on the Microsoft Cloud Adoption journey here:

Posted on

15 benefits of embracing Microsoft Power Platform

Find some of the benefits of Microsoft Power Platform.

  1. Self-Service for Easy Adoption and Use
  2. Can be used by most kinds of users (business, executives, developers, BAs)
  3. Rapid prototyping (no need to remake)
  4. Saving time for development
  5. Reducing third party dependency
  6. Integration with third parties, especially Microsoft tools such as one drive, excel, teams
  7. Device compatibility (work across devices)
  8. All Enterprise Business Processes in a Single Platform
  9. Compliance, Governance, Scalability, Security, Disaster Recovery
  10. No software upgrade, patching headaches
  11. Microsoft Advantage
  12. Office 365 Integration
  13. Enterprise Scale
  14. Large set of connectors (data source support)
  15. Serverless