Showing posts with label Education. Show all posts
Showing posts with label Education. Show all posts

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, October 1, 2018

Non-technical skills software developers should have

Developers shouldn't only be about development. Read to understand why.

Being a software developer is challenging. But rewarding at the same time and we should be grateful for that. But how do we conciliate all the challenges we face?

For example, it's probable that you feel pressured with deadlines, education, your own professional development, keeping up with many new technologies. Not to mention social skills. Since most of us we spend most of the time in front of a computer, are we socializing enough with our co-workers, friends and family?

Have ever questioned yourself about:
  • your career
  • your finances
  • your personal life
  • your health
  • your mind, conscience and professional resilience

A Recommendation

If you like me, have questions about all of that, I'd like to recommend the book Soft Skills: The software developer's life manual where John Z. Sonmez, author of the blog, guides us on this excellent book throughout these topics.

What’s Inside

  • Boost your career by building a personal brand
  • John’s secret ten-step process for learning quickly
  • Fitness advice to turn your geekiness to your advantage
  • Unique strategies for investment and early retirement


Here's the book summary:
Soft Skills: The software developer's life manual is a unique guide, offering techniques and practices for a more satisfying life as a professional software developer. In it, developer and life coach John Somnez addresses a wide range of important “soft” topics, from career and productivity, to personal finance and investing, and even fitness and relationships, all from a developer-centric viewpoint.


Be sure that this book has insights for everyone. Personally, as an eager to learn person, I really loved his 10-step to learn process. I don't want spoil but it's an interesting technique to learn quickly and start producing faster than ever.

Hope you enjoy the book as I did!

See Also

Monday, August 27, 2018

Hello, Startup - A book for developers building their startups

Developers looking to build their startups should read this book

This is a book that I really recommend and wish developers and non-technical people would read: hello, startup. It has lots of insights not only on startups but also on careers, business, management, culture, handling success, failures and more, way more.

Quoting the author:
This book will teach you how to build products, technologies, and teams in a startup environment. It's based on the experiences of the author, Yevgeniy (Jim) Brikman, as well as interviews with programmers from some of the most successful startups of the last decade, including Google, Facebook, LinkedIn, Twitter, GitHub, Stripe, Instagram, AdMob, Pinterest, and many others.

If you're at all interested in startups, this book is for you.


If you're planning on building your own company, want to know more about the startup scene, is searching for answers regarding your current job and think that a startup may be your best choice, please take a look.

See Also

Monday, May 7, 2018

Microsoft Build 2018

Microsoft’s Build event starts today, May 7th, 2018. Worth watching for .NET developers.

The event is expected to reveal Microsoft’s focuses, focusing mainly on AI and Cloud.

This event is all about developers so it's highly recommended for everyone using Microsoft technologies and those who want to be update on latest developments, to watch.

Event Details

Microsoft Build 2018
Date: May 7th, 2018 Time: 8:30am PT, 11:30am ET
Event Page:

Watch it live

You can view it live on the url above or directly from the Youtube video below.

Monday, April 9, 2018

Skill Up: A Software Developer's Guide to Life and Career

A book every software developer should read.

I just finished reading the book Skill Up: A Software Developer's Guide to Life and Career by Jordan Hudgens.

If you are currently working as a developer (all levels), freelancer (or contractor) and/or want to build up on your career skills, you should read it. Here's the book description:
This unique book provides you with a wealth of tips, tricks, best practices, and answers to the day-to-day questions that programmers face in their careers. It is split into three parts: Coder Skills, Freelancer Skills, and Career Skills, providing the knowledge you need to get ahead in programming.

Tips for Developers

Here's a couple of quotes targeting developers that I enjoyed in the book:
  • Excellence is as straightforward as focused practice. Don't believe on the myth of genius developers;
  • When your working on something hard or are learning something new, remove any and all potential distractions, limiting the slot to around two hours.
  • Deep work is the ability to focus without distraction on a demanding task. 
  • A Research from about task-switching shows that it takes, on average, 23 minutes and 15 seconds to get fully back on task after being distracted. Keep focused!
  • Set small goals, you're less likely to put it off.
  • To think about the new concept instead of rushing through it. 
  • Keep stretching yourself by learning a new programming language or framework, teaching others or creating an open source library

Tips for Entrepreneurs

A few tips for entrepreneurs:
  • Use services like HARO to pair up with reporters and have your name out there.
  • Recruit other developers if you're working on something that's not in your domain of expertise.
  • Blogging is a great way to position yourself as an expert.
  • Try to avoid scope creep.
  • Starting over versus refactoring.
  • Basecamp and Freshbooks can be valuable tools for freelancers and entrepreneurs.
  • How to engage new clients.
  • LinkedIn and good old referrals are still strong networking tools, don't ignore them.

Career Tips

A few career tips that I liked were:
  • If you should learn how to code and how to learn from scratch.
  • What specialty should you take.
  • Which programming language.
  • Bootcamps and other ways to improve your programming skills.
  • Resume and salary tips.
  • Enterprise software job.


This book has tips for everyone. Don't forget that the life of a developer and/or entrepreneur is not easy. Coding is hard! Keeping up to date with libraries and techniques is hard! Dealing with clients is hard! So what can we do to keep up to date with all facets of our profession?

I personally enjoyed this book because some of the techniques/tips introduced here I was already using on my life (pomodoro technique, deep work, task switching, etc) and are things I always try to pass to my fellow developers when I can. Plus, the career tips on Part III were very insightful too.

Hope it has something that you're looking for too!


See Also

Monday, August 21, 2017

The Laws of security

Understand how important it is to understand the 10 Laws of security and their impact on development

Continuing on a previous discussion about the book Stealing the Network, How to Own the Box and your online security, I would like to follow up on a very interesting section of the book: the laws of security. But what exactly are they?

The Laws of Security

According to the authors, the 10 laws of security are:
  • Law #1: If someone can persuade you to run his program on your computer, it’s not your computer anymore.
  • Law #2: If someone can alter the operating system on your computer, it’s not your computer anymore.
  • Law #3: If someone has unrestricted physical access to your computer, it’s not your computer anymore.
  • Law #4: If someone is allowed to upload programs to your web site, it’s not your web site any more.
  • Law #5: Weak passwords trump strong security.
  • Law #6: A machine is only as secure as the administrator is trustworthy.
  • Law #7: Encrypted data is only as secure as the decryption key.
  • Law #8: An out-of-date virus scanner is only marginally better than no virus scanner at all.
  • Law #9: Absolute anonymity isn’t practical, in real life or on the Web.
  • Law #10: Technology is not a panacea.
If you are a developer, devops or sysadmin, I would like to ask you: have you seen any of these rules before?  

The Laws of Security and Developers

Now that we know these rules, in order to rethink them from a development standpoint, let's consider these questions:
  • Do we, while writing our code, think about how could make our code safer?
  • Do we, while reviewing other people's code, think about how to make our code safer or which are the vulnerabilities in it?
  • By knowing those rules, how could we protect our companies by writing safer code? Are we doing our best for them?
  • By knowing those rules, how could we write safer code protect our users from threats and even from themselves? Are we doing our best for them?

Unfortunately, the answer is probably NO for most of the above. Or maybe a false yes (I do but, you know, not exactly sure if it's right.) That's okay! Our objective here is to foster the discussion in the first place. Next, work on incorporating cybersecurity paradigms into our lives so that we these patterns, tools and techniques become part of our habitual skill set.


Security is hard. We need to disseminate this knowledge and educate our families, users, managers, co-workers and everyone else around us so they can be constantly thinking about risks and threats, how we can mitigate them and why we should be discussing them. We always think about threats in the real world so, why neglect the virtual one?

See Also

About the Author

Bruno Hildenbrand