Showing posts with label Tips. Show all posts
Showing posts with label Tips. Show all posts

Monday, July 17, 2023

How to transition from Software Development to Architecture

Transitioning from software development to software architecture could be a great career progression for experienced developers. Learn how.

Image One Way, Alt Way
Photo by Brendan Church on Unsplash

When looking for the next step in their career, senior software engineers (or tech leads) have usually three paths before them: become increasingly more technical (aka. principal/staff engineer), move to a managerial position (Head of Engineering, Engineering Manager) or become a Software/Solution Architect.

In this blog post, we will explore how developers can successfully transition from software development into architecture.

What's required from an Architect

Before deciding if you really want to become a Software/Solution Architect, I recommend investing a decent amount of time reading about the role and comprehending everything that's expected from an architect in the context of a technology project (it's a lot!).

That said, transitioning from software development into architecture may not be the natural progression for most developers. While software development focuses on coding and implementation, software architecture takes a broader view, encompassing system design, scalability, long-term planning, a lot of communication and a lot of interpersonal skills. Not everyone will fill those gaps.

That said, the transition will be hard for most, especially for introverts, as it will require a shift in mindset, a huge ramp up to learn new skills and a growing focus on developing soft skills. Not everyone will be comfortable with that.

Transitioning from Development to Architecture

But if you are one of the brave ones who aspire to move into architecture, I have prepared this guide to help. So let's review the essential steps to help you successfully transition from software development into architecture.

1. Understand the Role of a Software Architect

Before embarking on the transition, it's crucial to understand the responsibilities and expectations of a software architect. A software architect is responsible for designing the overall structure of a software system, including making high-level decisions around the technology stack, system components, and interaction patterns. Architects need to balance technical considerations with business goals, scalability, maintainability, and performance.

I've spoken in detail about what's expected from a modern Solution/Software architect in a previous article, please read it here.

2. Expand Your Technical Knowledge

To become a successful software architect, you will need a much broader understanding of technology. This includes learning new technologies, frameworks, design patterns, cloud, tools, databases, keeping up with modern trends (like AI, IoT and Crypto), and gradually understand different technologies in different domains.

You will also be required to learn about best practices, scalability techniques, regulations, security, compliance and industry standards. This broad technical expertise will be immensely valuable when assessing the trade offs or your decisions, which will have a huge impact in your architectural decisions.

3. Enhance Your System Thinking

Transitioning to software architecture requires a shift from code-centric thinking to system-centric thinking. You will have to start viewing software systems as a single unit, learn to zoom out from the code/unit level and understand how different components and dependencies of a solution interact with each other.

You will be required to go much deeper (and wider) by assessing which programming language, database, cloud platform, and architectural style (ie., microservices, event-driven architecture, and domain-driven design) will fit better in your solution.

You will have to consider scalability, fault tolerance, performance, security, and other non-functional requirements. Develop the ability to break down complex problems into manageable components and design solutions that meet the system's architectural goals.

4. Gain Experience in Designing and Documenting Architectures

Additionally, it will be necessary to practice your architectural skills, a lot! Seek opportunities to design software systems, collaborate with colleagues or contribute to open-source projects that involve architecture discussions.

Practice documenting your design decisions, architectural diagrams, and system documentation. By going through the process of design and documentation, you will gain experience in communicating your architectural vision effectively.

Architectural Katas are a great resource for you to practice your skills.

5. Develop Soft Skills

Software architects not only design systems but also collaborate with stakeholders, developers, and project managers. Effective communication, leadership, and negotiation skills are vital for successful architecture transitions.

You will be required to grow your ability to express complex ideas concisely, listen actively, and adapt your communication style to different audiences. Cultivate your leadership skills by taking initiatives, guiding discussions, and mentoring other developers.

6. Seek Mentorship and Learning Opportunities

Learning from experienced software architects can greatly accelerate your transition. Seek mentorship from architects in your organization or join professional communities, forums, or meetups where you can connect with architecture practitioners.

Engage in conversations, ask questions, and learn from their experiences. Additionally, attend conferences, workshops, or online courses that focus on software architecture to deepen your knowledge and expand your network.

7. Embrace Continuous Learning

Software architecture is an ever-evolving field, with new technologies and approaches emerging constantly. Stay up-to-date with industry trends, read books, follow architecture blogs, and engage in discussions on social media platforms. Embrace a growth mindset and continuously learn and adapt to new technologies and architectural paradigms.

Given the extensive technical and non-technical skills required from a modern architect, we prepared this detailed guide describing what our architects should know, and guide them on the learnings they’ll need while working on their professional development plan.

Final Thoughts

Transitioning from software development to software architecture is an exciting career progression that requires a shift in mindset and the acquisition of new skills. By understanding the role of a software architect, expanding your technical knowledge, enhancing system thinking, practicing design and documentation, developing soft skills, seeking mentorship, and embracing continuous learning, you can successfully make this transition.

Remember, becoming a proficient software architect takes time and experience, so be patient and persistent in your journey. Good luck!

See Also

Monday, June 12, 2023

Different Types of IT Architects

There is a lot of ambiguity and even misinformation regarding the role of an IT Architect in a software project. Let's understand the differences between them.

Photo by Medienstürmer on Unsplash

There is a lot of ambiguity and even misinformation regarding the role of an IT Architect with regards to their participation in software projects.

Since the responsibilities of an IT Architect differ between organizations, I prepared this article to explain the particularities of different architecture roles, and bring clarity to those looking to work as professional IT Architects.

How Architecture varies per organization 

Due to differences in scale, complexity and organizational structure, Software Architecture varies significantly between small and large organizations.

Usually, large Enterprises have a more structured model for Architecture, and it's common to have a clear distinction between the different roles. In those organizations, it’s common to have different individuals performing different (and more specific) roles, with their titles aligning to their duties. Most of them, you will see in this article.

In smaller organizations though, very commonly Architects end up performing a combination of all of these roles (if not all at the same time for a given project). The name of the roles varies per organization, with the most popular being Solution, Cloud, Technical or Software Architects.

However, regardless of the size of the organization, architects are expected to do much more that just performing the tasks described in the job descriptions.

Which is why architects should broaden their skills as much as possible in different domains. Tough task, but will get you prepared to anything your employer (and clients) request from you. Make this a marathon, not a sprint.

With that said, let’s review the differences between the main types of architects as it relates to projects in technology.

Different types of Architects

Let's jump directly to the most common roles in architecture. Currently in the marketplace, they are:

  • Enterprise architect
  • Solution architect
  • Software/Application architect
  • Data/Information architect
  • Security architect
  • Cloud architect
  • Technical Architect
  • Principal Architect

So let’s review them.

Enterprise Architect

Enterprise architects are responsible for the technical solutions and strategic direction of an organization. They must work with a variety of stakeholders to understand an organization's market, customers, products, business domain, requirements, and technology.

From a broad perspective, enterprise architects are the most business oriented, and consequently, less technical in nature.

Solution Architect

A solution architect converts business/technical requirements into a solution architecture. They work closely with business analysts, product owners and technical people to understand the requirements in depth, so that they can design a solution that satisfies those requirements.

Solution Architects are the most hybrid role in this list. Solution architects are required to have great technical and business skill, making them a perfect fit for any project in technology.

Software (Application) Architect

Software/Application Architects focus mainly on the software architecture. They ensure that the requirements for their application are satisfied by the design of that application and serve as a liaison between the technical and non-technical staff working on an application.

Application Architects are involved in all the steps in the software development process.

Software/Application Architects architect and recommend solutions for new/existing/legacy technologies, as well as evaluating alternative approaches to problems and proposing solutions to existing problems.

Data (Information) Architect

Data Architects are responsible for designing, deploying, and managing an organization's data architecture.

Data Architects usually focus on data management systems, and their goal is to ensure that the appropriate consumers of an organization's data have access to the data in the right place at the right time.

Lastly, Data Architects are responsible for all of an organization's data sources, both internal and external. They ensure that an organization's strategic data requirements are met.

Infrastructure Architect

Infrastructure Architects focus on the design and implementation of an organization's enterprise infrastructure. This type of Architect is responsible for the infrastructure environment meeting the organization's business goals, and provide hardware, networking, operating system, and software solutions to satisfy them.

Security Architect

A Security Architect is responsible for an organization's computer and network security. They build, oversee, and maintain an organization's security implementations.

Security Architects must have a full understanding of an organization's systems and infrastructure so that they can design secure systems.

Cloud Architect

A Cloud Architect is someone who is responsible for an organization's cloud computing strategy and initiatives. They are responsible for the cloud architecture used for the deployment of software systems. An organization that has someone who is focused on cloud architecture leads to increased levels of success with cloud adoption.

The responsibilities of cloud architects include selecting a cloud provider and selecting the model (for example, SaaS, PaaS, or IaaS) that is most appropriate for the organization's needs.

Cloud Architects create cloud migration plans for existing applications not already in the cloud, including the coordination of the adoption process. They may also be involved in designing new cloud-native applications that are built from the ground up for the cloud.

Technical Architect

Technical Architects are another very technical role in Architecture. They develop the technical strategy for a project, making sure that the technical solutions meet the requirements of the customer and the business.

Technical Architects are also responsible for the long-term technical vision of a software solution. They evaluate new technologies and architectures to ensure the system meets the customer’s needs and is cost effective. Additionally, they are responsible for the development and implementation of standards and procedures to ensure the quality of the solutions.

Technical architects are very similar to Application/Software architects. Most likely, most people wouldn’t be able to differentiate them.

Principal Architect

Finally, Principal (or Lead) Architect. This role is usually more related to the leadership performed by the person (in this case, an Architect), than to specific tasks. However, it's expected that the Principal (or Lead) Architect usually possesses the widest knowledge within the team including Solution, Enterprise, Software and Cloud architecture.

Principal Architects frequently oversee and lead the design and development of projects from both a technical and managerial standpoint. Common tasks attributed to them include project leadership, design, planning, governance, team and client engagement.

Finally, principal Architects are expected to have exceptional technical, inter-personal, management, executive and sales skills. After all, they usually interact with a high level audience, including C-level executives.


On this article we presented a quick overview of the different types of IT Architects. Due to differences in scale, complexity, organizational structure and even how roles are defined, Architecture in the context of technology can (and will) vary significantly between organizations.

However, regardless of the role you execute in your organization, keep your skills sharpened by broadening your knowledge as much as you can in different domains. Tough task, but will get you prepared to anything your employer (and/or clients) request from you.

See Also

Monday, February 20, 2023

My Journey to 1 Million Articles Read

Writing a tech blog is a fun and rewarding experience. On this article, I will share what I learned after publishing more than 100 articles during the last 5 years

Photo: Christopher Gower on Unsplash

I have been working with technology for more than two decades now. As an avid reader and a tech enthusiast, having my own professional blog is one of the best ways to share what I learn and to give back to the community.

In this article, I will review my experience as a blogger after 5 years of work and more than 100 articles published.

The beginning

As most blogs, this one started off small. During the first year it had no more than a few page views per day. Personally that didn't mattered as my my goal was never to make it a successful product. For me, it was a tool to share what I learned with a greater audience and hopefully inspire others to be better at their jobs.

Little did I know how incredible this journey would eventually become...

As I persisted on the work and wrote more (and better) articles, SEO started to pick up. It didn't take long for this blog to gain traction, be quoted, linked to, and even referenced by search engines on specific queries.


Today the blog has surpassed half-million visits and just keeps growing. On peak days, it has more than 10k visits. What an achievement for such an unpretentious work!

However, for different reasons I can't write as frequently as I would like to. But still, having this channel to communicate to a wider audience inspires me to keep working on it. And I'm not stopping any time soon!

What I learned

So what did I learn during this time?

First off, writing a technical article is no simple task. I usually spend a decent amount of time researching the topic in question before writing the very first sentence. During this phase, I collect as much information as I can, to then organize my thoughts in order to convey the message in a meaningful way. During writing, I carefully enrich my articles with the most relevant material to make the reading experience as fulfilling as possible.

Second, blogging requires a great deal of personal commitment. Be prepared to dedicate a significant amount of your personal time on it. I write most of my articles during my leisure time which may be a concern for some. But rest assured, the benefits definitely outweigh the drawbacks!

Third, persistency is key. For any work to thrive, it's important to have a solid goal and stick to it. Improvement is exhausting. It’s okay to enjoy when you don’t excel. Stick to your plan and don't give up!

Finally, the benefits for you, the writer, are much bigger than you think. Here are some of the benefits I realized during this time:

  • You have the chance to help others
  • You connect with the community and build great relationships
  • You get more prolific technically. Meaning that you'll increase your productivity, confidence, improve your problem solving skills and consequently achieve better output in your work
  • You can translate your ideas into paper more quickly and with greater clarity
  • You end up writing and communicating better - which are great assets for your professional progression!
  • You learn and retain more on the topic discussed
  • Depending on how deeply you explore a particular topic, you can eventually become an SME on it.
  • And of course, with all of that, greater professional opportunities will come.

What next?

As I prepare for the next 5 years and continue on my journey to reach 1 million articles read, this blog remains an exceptional avenue for inspiration and experimentation.

Starting today, my focus shifts to the challenges, practices, trends, technologies and complexities of the enterprise. And the reason is simple: there is now a rich ecosystem of tooling and documentation ready to address technical requirements with little customization while the most important part − focus on business and customer needs − remains obscure and in second plan for most.

Final Thoughts

Hopefully at this point you understand how a professional blog could help your career. Despite requiring some personal commitment, for me, keeping this blog alive has been an amazing journey and I’m excited to keep working on it for as long as I can.

I hope this article inspires you too on any meaningful work to help those around you.

Further Reading

To celebrate this important milestone, I've listed below some of the articles that I loved writing during the last 5 years. Some of them may not be as recent but still, there's always something that you can learn from it.


Development Methodology

General Technology


📫 Reaching out...

Lastly, if you have any questions, don't hesitate to reach out to me on Twitter and/or LinkedIn 😊

Thursday, October 1, 2020

Building and Hosting Docker images on GitHub with GitHub Actions

Building Docker images for our ASP.NET Core websites is easy and fun. Let's see how.
Photo by Steve Johnson on Unsplash

On a previous post we discussed how to build our own Docker images from ASP.NET Core websites, push and host them on GitHub Packages. We also saw how to build and host our own NuGet packages in GitHub. Those approaches are certainly the recommended if you already have a CI/CD implemented for your project. However, for new projects running on GitHub, GitHub Actions deserves your attention.

What we will build

On this post we'll review how to build Docker images from a simple ASP.NET Core website and setup continuous integrations using GitHub Actions to automatically build, test and deploy them as GitHub Packages.


To run this project on your machine, please make sure you have installed:

If you want to develop/extend/modify it, then I'd suggest you to also have:

About GitHub Packages

GitHub Packages is GitHub's offering for those wanting to host their own packages or Docker images. The benefits of using GitHub Packages is that it's free, you can share your images privately or publicly and you can integrate with other GitHub tooling such as APIs, Actions, webhooks and even create complex end-to-end DevOps workflows.

About GitHub Actions

GitHub Actions allows automating all your workflows such as build, test, and deployments right from GitHub. We can also use Actions to make code reviews, branch management, and issue triaging. GitHub Actions is very powerful, easy to customize, extend and it counts with lots of pre-configured templates to build and deploy pretty much everything.

Building our Docker Image

So let's quickly build our Docker image. For this demo, I'll use my own aspnet-github-actions. If you want to follow along, open a terminal and clone the project with:
git clone

Building our local image

Next, cd into that folder and build a local Docker image with:
docker build . -t aspnet-gitub-actions
Now confirm your image was successfully built with:
docker images

Testing our image

With the image built, let's quickly test it by running:
docker run --rm -d -p 8080:80 --name webapp aspnet-gitthub-actions
Browse to http://localhost:8080 to confirm it's running:

Stop the container with the command below as we'll take a look at the setup on GitHub:
docker stop webapp
For more information on how to setup and run the application, check the project's README file.

Setting up Actions

With the container building and running locally, it's time to setup GitHub Actions. Open your repo and click on Actions:
From here, you can either add a blank workflow or use a build template for your project. For our simple project I can use the template Publish Docker Container:
By clicking Set up this workflow, GitHub will add a clone of that file to our repo at ~/.github/workflows/ and will load an editor so we can edit our recently created file. Go ahead and modify it to your needs. Since our Dockerfile is pretty standard, you'll only need to change the IMAGE_NAME to something adequate to your image:

Running the Workflow

As soon as you add that file, GitHub will run your first action. If you haven't pushed your code yet it'll probably fail:
To fix the error above, go ahead and push some code (or reuse mine if you wish). Assuming you have a working Dockerfile in the root of your project (where the script expects it to be), you should see your next project being queued and run. The UI is pretty cool and allows you to inspect the process in real time:
If the workflow finishes successfully, we'll get a confirmation like:
Failed again? Did you update IMAGE_NAME as explained on the previous step?

Accessing the Packages

To view your Docker images, go to the project's page and click on Packages link:
By clicking on your package, you'll see other details about your package, including how to pull it and run it locally:

Running our Packages

From there, the only thing remaining would be running our recently created packages. Since we already discussed in detail how to host and use our Docker images from GitHub packages, fell free to jump that post to learn how.

Final Thoughts

On this post we reviewed how to automatically build Docker images using GitHub Actions. GitHub Actions makes it easy to automate all your workflows including CI/CD, builds, test, and deployments. Hosting our Docker images on GitHub is valuable as you can share your images privately or with the rest of the world, integrate with GitHub tools and even create complex DevOps workflows. Other common scenarios would be building our images on GitHub and pushing them to Docker Hub or even auto-deploying them to the cloud. We'll evaluate those in the future so keep tuned!

Source Code

As always, the source code is available on GitHub.

See Also

Monday, May 4, 2020

Configuration in .NET Core console applications

If you search the official .NET documentation, you will probably not find much information on how to add config files to your .NET Core console applications. Let's learn how.
Photo by Christopher Gower on Unsplash

With the release of .NET Core 3.1, Microsoft changed a few things in how we access configuration in our files. While with ASP.NET documentation is really solid and scaffolding an ASP.NET Core website should include all the dependencies to get that right, the same does not happen with Console Applications. On this quick  tutorial let's see how we can replicate the same setup for our console apps.

Why replicate ASP.NET Configuration

The maturity that the .NET Core framework achieved includes the configuration framework. And all of that, despite the lack of documentation, can be shared between web and console apps. That said, here are some reasons why you should be using some of the ASP.NET tolling on your console projects:
  • the configuration providers read configuration data from key-value pairs using a variety of configuration sources including appsettings.json, environment variables, and command-line arguments
  • it can be used with custom providers
  • it can be used with in-memory .NET objects
  • if you're developing with Azure, integrates with Azure Key Vault, Azure App Configuration 
  • if you're running Docker, you can override your settings via the command line or environment variables
  • you will find parsers for most formats (we'll see an example here)

The Solution

So let's take a quick look at how to integrate some of these tools in our console apps.

Adding NuGet packages

Once you create your .NET Core app, the first thing to do is to add the following packages:
  • Microsoft.Extensions.Configuration
  • Microsoft.Extensions.Configuration.Binder
  • Microsoft.Extensions.Configuration.EnvironmentVariables
  • Microsoft.Extensions.Configuration.FileExtensions
  • Microsoft.Extensions.Configuration.Json
Next, add the following initialization code:
var env = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
var builder = new ConfigurationBuilder()
    .AddJsonFile($"appsettings.json", true, true)
    .AddJsonFile($"appsettings.{env}.json", true, true)

var config = builder.Build();
If set, the env var above will auto-load the configuration as per the environment variable ASPNETCORE_ENVIRONMENT that comes preset on a new ASP.NET Core project. So for dev, it will try to use appSettings.Development.json sticking with appSettings.Development.json if the former doesn't exist.

Creating a configuration file

Now add an empty appSettings.json file in the root of your project and add your configuration. Remember that this is a json file so your config should be a valid json document. For example, to config file for one of my microservices is:
  "MassTransit": {
    "Host": "rabbitmq://localhost",
    "Queue": "hildenco"
  "ConnectionString": "Server=localhost;Database=hildenco;Uid=<username>;Pwd=<pwd>",
  "Smtp": {
    "Host": "<smtp-server>",
    "Port": "<smtp-port>",
    "Username": "<username>",
    "Password": "<password>",
    "From": "HildenCo Notification Service"

Parsing the configuration

There are two ways to access the configuration: by accessing each entry individually or by mapping the whole config file (or specific sections) to a class of our own. Let's see both.

Accessing config entries

With the config instance above, accessing our configurations is now simple. For example, accessing a root property is:
var appName = config["ConnectionString"];
While accessing a sub-property is:
var rmqHost = config["RabbitMQ:Host"];

Mapping the configuration

Despite working well, the previous example is verbose and error prone. So let's see a better alternative: mapping the configuration to a POCO class that Microsoft calls the options pattern. Despite its fancy name, it's probably something that you'll recognize.

We'll also see two examples: mapping the whole configuration and mapping one specific section. For both, the procedure will require these steps:
  • creating an options file
  • mapping to/from the settings
  • binding the configuration.

Mapping the whole config

Because our configuration contains 3 main sections - MassTransit, a MySQL ConnectionString and a SMTP config -, we'll model our AppConfig file the same way:
public class AppConfig
    public SmtpOptions Smtp { get; set; }
    public MassTransitOptions MassTransit { get; set; }
    public string ConnectionString { get; set; }
SmtpOptions should also be straight-forward:
public class SmtpOptions
    public string Host { get; set; }
    public int  Port { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
As MassTransitOptions:
public class MassTransitOptions
    public string Host { get; set; }
    public string Queue { get; set; }
The last step is binding the whole configuration with our config:
var cfg = config.Get<AppConfig>();

Accessing Configuration Properties

With the config loaded, accessing our configs becomes trivial:
var cs = cfg.ConnectionString;
var smtpFrom = cfg.Smtp.From;

Mapping a Section

To map a section we use the method .GetSetcion("<section-name>").Bind() present on the Microsoft.Extensions.Configuration.Binder NuGet package that we added earlier. For example, to map just SmtpOptions we'd do:
var mailOptions = new SmtpOptions();

Making it Generic

Turns out that quickly the previous procedure also gets verbose. So let's shortcut it all with the following generic method (static if ran from Program.cs):
 private static T InitOptions<T>(string section)
    where T : new()
    var config = InitConfig();
    return config.GetSection<T>(section);
And using it with:
var smtpCfg = InitOptions<SmtpConfig>("Smtp");

Reviewing the solution

Everything should be good at this point. Remember to leverage your options classes along with your Dependency Injection framework instead of accessing the IConfiguration for performance reasons. To conclude, here's our final program.cs file:
static async Task Main(string[] args)
    var cfg = InitOptions<AppConfig>();
    // ...

private static T InitOptions<T>()
    where T : new()
    var config = InitConfig();
    return config.Get<T>();

private static IConfigurationRoot InitConfig()
    var env = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
    var builder = new ConfigurationBuilder()
        .AddJsonFile($"appsettings.json", true, true)
        .AddJsonFile($"appsettings.{env}.json", true, true)

    return builder.Build();


On this post we reviewed how to use the ASP.NET tooling to bind and access configuration from our console applications. While .NET Core matured a lot, the documentation for console applications is not that great. For more information on the topic I suggest reading about Configuration in ASP.NET Core and understanding .NET Generic Host.


See Also

About the Author

Bruno Hildenbrand