Forem: Matt Warcholinski

From Monoliths to the Cloud: Unlocking the Power of Cloud-Native Development

Matt Warcholinski — Tue, 06 Jun 2023 09:23:15 +0000

In the realm of software engineering, a compelling trend has emerged that is reshaping how applications are built and deployed: Cloud-Native Development. This approach leverages the transformative capabilities of cloud computing, allowing organizations to unleash unprecedented scalability, agility, and efficiency. In this article, we explore the essence of cloud-native development and its impact on the software landscape.

What is Cloud-Native Development?

Cloud-Native Development is an architectural paradigm that embraces the inherent advantages of cloud computing. It involves designing and building applications specifically for deployment in the cloud environment. Unlike traditional approaches, cloud-native applications are born in the cloud, taking full advantage of cloud services, infrastructure, and APIs.

The Pillars of Cloud-Native Development:

Cloud-Native Development rests on three fundamental pillars that define its core principles:

Scalability and Elasticity

Cloud-native applications are designed to effortlessly scale horizontally. By leveraging auto-scaling capabilities and elastic infrastructure provided by cloud platforms, applications can dynamically adapt to varying workloads, ensuring optimal performance and resource utilization.

Resilience and Fault Tolerance

Resilience is a critical aspect of cloud-native development. Applications are built to withstand failures and gracefully recover from disruptions. With the help of cloud-native architectures such as microservices and containerization, individual components can be isolated, enabling fault tolerance and minimizing the impact of failures on the entire system.

Automation and DevOps

Automation is at the heart of cloud-native development. By embracing DevOps practices and adopting continuous integration/continuous deployment (CI/CD) pipelines, organizations can automate application delivery, testing, and deployment processes. This automation streamlines the software development lifecycle, reduces manual efforts, and ensures rapid and reliable application updates.

The Benefits of Cloud-Native Development

Embracing cloud-native development offers several compelling benefits for organizations:

Agility and Time-to-Market

Cloud-native development empowers organizations to rapidly respond to changing market demands. Leveraging cloud services and infrastructure, developers can provision resources on-demand, rapidly iterate, and release new features and updates. This agility accelerates time-to-market, fostering innovation and competitive advantage.

Cost Optimization

By leveraging cloud resources, organizations can optimize costs by paying only for the resources they consume. The elasticity of cloud infrastructure allows for scaling up during peak demand and scaling down during periods of lower usage. Additionally, cloud-native architectures promote efficient resource utilization, reducing unnecessary overheads.

Scalability and Flexibility

Cloud-native applications are designed to scale seamlessly. By harnessing the power of cloud platforms, organizations can effortlessly handle surges in user traffic, ensuring a smooth user experience. Furthermore, cloud-native architectures facilitate flexibility, enabling the adoption of new technologies and services without significant disruptions.

Ending thoughts

Cloud-Native Development has emerged as a transformative force in software engineering. By harnessing the power of the cloud, organizations can build highly scalable, resilient, and agile applications. The benefits of cloud-native development extend beyond technical aspects, unlocking new possibilities for innovation, cost optimization, and business growth. Embracing this trend can position organizations at the forefront of the ever-evolving software landscape, ready to face the challenges and opportunities of the digital age.

How to Use Metrics to Increase Your Team’s Performance

Matt Warcholinski — Tue, 06 Jun 2023 08:50:35 +0000

Setting a target on a metric won’t change people’s behavior, they will only learn to game it

There are various metrics currently used to measure the development team’s performance, process, the health of the code base, or the health of the product overall. The problem is that there is no single metric that matters, regardless of what you hear about any of the available metrics, all of them are good and bad at the same time.

The thing is: any given metric, used in isolation, tells only half of the truth, at best.

Yet, it is very common, too common, to set a target on a given metric.

The problem is not a young one, there is even a law called Goodhart’s law that says:

"When a measure becomes a target, it ceases to be a good measure."
The issue boils down to this:

if you set a target on any given measure, people will eventually game this metric to achieve the target. It will not be the leap in performance that happened, it will simply be a change in how people report performance.

Yes, this also applies to KPIs.

Treat the metrics as the product’s EKG results

There are many “articles” claiming that this or that metric is bad.

Velocity: bad.

Cycle time: bad…

The problem is that all of them are good when you know how to use them.

Treat your metrics like a doctor would treat an EKG or lab test results. If they find any potential indication of an underlying problem in your results, they will most likely try to confirm it with other tests, and if the problem is confirmed, they will propose a solution. However, it wouldn’t be of any use for a patient if they were told: “lower your blood pressure.” What they would want to be told is what changes they should introduce into their lifestyle to achieve the desired outcome.

That’s the way you should look at metrics as well.

Start using metrics to your advantage by applying the 4 golden rules

1. Never trust a single metric to give you the full picture

Using one metric can be deceiving because in order to understand what one metric tells us, we will potentially need another metric.

An example of this may be a Velocity of a Scrum team measured by a summary of Story Points delivered per sprint alone. What if the amount of points is stable, yet the number of stories/tasks is dropping with every sprint? What if the cycle time or a lead time is rising simultaneously? Is everything still all right?

2. Keep metrics objective by not setting targets on them

Instead, observe them, interpret them, and compare them against each other.

If you find an undesirable trend or a pattern, implement a change in your process, then observe if anything improves.

3. Not everything is worth being measured

One of the metrics, not worth tracking are lines of code written per day. Although this metric may seem like a straightforward measure of productivity, it fails to take into account the quality and efficiency of the code and can even incentivize developers to write unnecessary or redundant code to meet an arbitrary quota.

4. There’s no one-size-fits-all when it comes to metrics

Different organizations and different products will need different metrics. The best way to find your perfect fit is through experimentation.

Here are a couple of suggestions of metrics that often prove handy in analyzing a team’s performance:

Velocity and/or cycle/lead time + throughput for changes — this combo will help you better understand how many changes your team processes in a given time period.
Change failure rate + bugs per period/cycle time — these metrics will allow you to better understand how the quality of the delivered code changes throughout the project’s lifetime.
Pull requests cycle time and/or pull requests cycle time per service/part of the repository + pull requests per developer per iteration + code review cycle time — this set will give you a better understanding of how ease of introducing new features or technical debt changes throughout the project.

Get to know your metrics before introducing them to the project

The better you know the metric, the more insight you will draw from its analysis, and the more precisely you will be able to identify areas for improvement. Learning the ins and outs of the metrics will also allow you to avoid common mistakes that could distort the data and lead to the wrong conclusions being made.

Why BizDevOps (DevOps 2.0) Is Not a Mere Trend

Matt Warcholinski — Fri, 15 Apr 2022 14:42:35 +0000

BizDevOps, or DevOps 2.0, is a buzzword that’s been flying around for a while.

But what exactly is BizDevOps, and why should it be of your interest?

Let’s start by establishing the facts.

The brief history of BizDevOps

For a long time, software development teams worked in isolation from business and operation teams.

The business team used to pass documented product requirements to the development team, which translated them into code. The code was later handed off to the operations team to get deployed.

On the upside, each team had specified responsibilities, and the scope of work was clearly defined. On the downside, the feedback loop and time-to-market were very long, and the product wasn’t exactly as expected.

After a while, the DevOps philosophy became a thing and divsion between development and operations dissipated. Software improved in quality and speed of delivery. However, the challenge of delivering business value remained.

In 2020, during Devopsdays oNLine conference, Henk van der Schuur, Customer Director at Schuberg Philis, highlighted the need for a better solution:

“DevOps needs a sequel. Doing ‘just the DevOps trick’ alone isn’t going to cut it anymore. Business wants to be involved. BizDevOps is about organizing a short time-to-value, and it actually reduces risk as it allows things to fail early, and to fail fast—together with the business.”
— Henk van der Schuur, Customer Director at Schuberg Philis

And so the BizDevOps movement began.

BizDevOps brings value that no other approach could

BizDevOps gathers all the people interested in building a product under a common goal — to deliver the right solution to end-users.

It brings the benefit of:

reduced hand-offs
shorter feedback loops
faster decision-making

As a result, bugs are identified quicker, changes implemented more efficiently, and the results assessed more frequently to enable immediate course corrections.

The role of a business team broadens and evolves from specifying requirements to closely collaborating with development and operations teams.

But BizDevOps brings value not only to business. Developers start taking part in strategic planning and have more decisive power and ownership over the project.

The whole team regularly evaluates risks and seeks opportunities with the ultimate goal to modify the product’s vision and adapt it to users’ needs even more accurately.

“The BizDevOps view of work culture requires that you continually review past results, are ready for change, and agree on whether collaboration and product creation are moving in the right direction.”
— Michał Baćkowski, Delivery Manager at Brainhub

How to implement BizDevOps?

The process of implementing BizDevOps should begin with inviting business stakeholders to take part in the development process and discussion about the product vision, goals, and priorities. Your team needs a common goal, a clear process, and mutual KPIs.

How can you make this happen?

We dedicated a whole section to this topic in an article “BizDevOps – a Bridge Between Business and Tech”, that presents BizDevOps in an approachable and actionable way.

Information Architecture Definition, Roles, Strategies and Resources

Matt Warcholinski — Thu, 20 Dec 2018 16:59:35 +0000

As with more and more popular concepts such as user experience, user research, usability testing, there are also other less familiar ones:

Information Architecture (IA).

What is the difference between them?

Information architecture is the art of organization of information on a website, mobile or web application, so using it the web site will be simple and intuitive.

This term is closely tied to the concept of user experience (UX), which is a collection of impressions while using a digital product. Experience does not end only at the time of interaction, but also after its occurrence.

IA in a nutshell

The Information Architecture is more about the structure of the entire website or application, while the UX relates to the user impressions and experiences.

In practice IA is reduced to organizing information, that is: categorizing content, creating a consistent navigation, site map, and naming individual content groups. It is also the skeleton of the whole project, on the basis of which you create further views, visual elements, interactions or functionality.

IA allows the user to reach the content easily, without much effort. The inadequate structure of the app will discourage him and frustrate.

The organization of information in an online product itself depends on the users’ needs, but also on business priorities. For example, the structure of the information in the case of a blog or a landing page will look very different.

The role of Information Architect

The IA designer is a complement to the design team. His main tasks are research, navigation, data modeling and labeling. He often uses tools such as card sorting, usability tests, stakeholders and user interviews.

The IA architect is responsible for how a user will navigate through the web product and reach the relevant information. The way in which users will use an application or website depends largely on how information is presented and organised.

Why is Information Architecture important for business?

In order to take care of a well-designed information architecture, you should answer to questions:

How do you organize and divide information?
How do you present information?
How do you communicate the way you navigate through the app?
How will the user navigate in the application?
How will the user look for information?

The components that make up a good IA are:

Organization system
Labeling system
Navigation system
Searching system

In summary, a well-designed information architecture is an intuitive and efficient user experience. For this reason, not only UX skills are necessary to create a good web product, IA skills are equally important. Only then can it be possible to create a project meeting the users’ needs.

Tools and templates to help you create an IA

On the market, we find a lot of tools for creating an information architecture. The simplest views can be created using tools such as Microsoft Visio.

Also useful are applications for creating diagrams or mind mappings, such as:

The way we present information architecture itself depends on our preferences. We can do this by using the mind mapping tools. This way we can effectively visualize the information architecture along with its flows.

We can also present information architecture as a simple diagram. This version will work well even with very large pages or applications.

Diagrams are often used for site maps that are based on a previously created information architecture.

How to create an information architecture for a website?

If you want to design an effective information architecture that will make your site more useful and legible, then you need to go through the stages of the design process.

User research

Work on information architecture should begin with user research and analysis. An important part of this process is to understand the needs and problems of product users and to reconcile them with the business goals. We can use a number of tools for that purpose: card sorting, user interviews, focus groups or surveys.

Navigation

The next step is to define the navigation, the hierarchy of the individual pages, and to design how and when to display them. At this stage, we can use programs for mind mapping or diagrams for that.

Labeling

Once we've developed the information structure, it's time to name the sections and pages so that they are understandable to the user. They also make it easier to navigate the page.

Wireframing

The next step is to make wireframes that will be based on IA. By using them, we define a visual hierarchy of information on the page as well as connections between subsequent views of the application.

Why and when to create an IA for your digital product?

Creating an information architecture is not always needed. Of course, in any case, we can do it and it will be helpful, but it isn't required eg when we create a simple page with a few subpages or a landing page.

The importance and value of information architecture will be recognized by designing an extensive website or application. In that case, it is worthwhile to work on Information Architecture at the beginning of the design process - after recognizing the users of the product, but before creating wireframes and mockups.

The first work should include structuring the information on the page, developing navigation and naming the labels. The next step should be to test the IA on the users, eg using card sorting.

Books and resources about Information Architecture

If I woke up your interest in the topic of Information Architecture you can dig deeper with the following books and resource I recommend:

Information Architecture: For the Web and Beyond [book]
Chris How - Digital Experiences and Information Architecture [youtube video]
Information Architecture. Important Part of Design You’re Probably Overlooking [article]
How to Assess the Maturity of Your Information Architecture [article]

Originally published as "Information Architecture Definition, Roles, Strategies and Resources" at Braihub.eu/blog