Hiring a top Application Architect likely means you’re building something big from the ground up. You need someone who can help navigate your SaaS product’s foundational technology stack.

I’m an Application Architect with over 20 years of experience building web applications in the cloud.

In this article, I will show you why starting your project off on the right foot means hiring an experienced Application Architect. People like me will not only save you from a myriad of technical headaches in the future, but we can save you a boatload of money later on as well.

An architect is there to help not only steer your dev team into making the best technology choices for your product, but help you future-proof your business’ technology for the growth of your company.

Why Do I Need an Architect?

The most often asked question I get is: Can’t my current development team just build my app for me without an architect?

The short answer is yes, but ONLY IF you hired a team with the right experience! If you hired new or mid-level or offshore devs to build your signature product, you are going to be saddled with TECHNICAL DEBT that you may have a really hard time retiring later on.

The goal is not to incur tech debt to begin with.

Technical Debt is EXPENSIVE to retire, and the bigger your project, the more money it’s going to cost you later on.

What Is Technical Debt?

Technical Debt is basically code or some technology within your application that really needs to be redone, re-written, or replaced, because it’s sub-par for a variety of reasons. The dev team didn’t use proper OO principles or patterns and thus your code is not extensible or not very DRY. They selected a bad framework that will be unsupported in a few years. They chose the wrong programming language for your use case. This list of reasons can be lengthy as to why technical debt shows up.

Mostly technical debt is the result of NOT having a real architect involved in building your software. It is the result of INEXPERIENCE and inexperienced developers making decisions about the technology stack who have no business making such foundational decisions for your company’s most prized possession—your software products.

However, and all too often, non-technical leadership just allow the dev team to make foundational technology decisions, decisions you should not be allowing them to make as a business owner and/or stakeholder in a software product.

Case In Point: I was once contacted by a recruiter who wanted me to literally re-write a small business’ SaaS application because their client’s first team saddled them with Python as their core technology language. Now they were having a really hard time finding Python developers within their budget to maintain the software. If you’re building a small business SaaS application, Python is the wrong language to use for that purpose.

Yes, you can write web apps using Python, but should you? Not for your signature customer-facing product you shouldn’t. Yes people do it; but they really should be using something else besides Python.

Python’s superpowers are better suited to data modeling and higher math were precision is paramount. Writing an application in a language most suited to this particular business’ needs is where the previous inexperienced dev team failed. They simply wrote the application using what they learned in college instead of what would be best for the company.

Now the business was saddled with a whole application of “technical debt”, debt that was so bad the company was now going to have to PAY TWICE to have their signature app utterly re-written from the ground up in a language better suited to its needs.

This is one of many reasons why you should not use your dev team to make such foundational business decisions. Make no mistake, your tech stack is a very serious BUSINESS DECISION.

As developers we like to use what we know, not what’s best for the company.

Often times newer developers (people who have not been programming for at least a decade within the enterprise) will select technologies they think are “high key” awesome and have really hip wiz-bang features that all the cool kids are using. But most of this “fad-tech” will most likely be deprecated / unsupported and gone in 5 years.

You do not want your company saddled with this kind of short-lived fad technology.

Case In Point: I joined a team at Disney who had several applications they were maintaining. One of the devs was really young, barely 25, and had just graduated from intern to web programmer. But because he was “cast” (an actual Disney employee as opposed to the more experienced contractors), he had assumed the very senior position of team lead even though he was fresh out of tech school.

Unfortunately, he selected a bunch of technologies that were ill-suited to what we really needed within the group. Don’t get me wrong, the guy was a good programmer and he was fast. But his inexperience saddled us with technologies we began despising as time went on. A couple years later he was promoted to another area of the company, but all of us were still stuck maintaining his bad decisions.

An architect will examine your business, your use cases, your business models, even your technical budgets; and then come up with the BEST POSSIBLE technologies suited to your business and product with the least amount of tech debt at the lowest possible costs.

The architect is really there to save you money and rescue your company from ugly technical headaches BEFORE they can become expensive tech debt later on.

Types of Architects

There are a number of differing sub-classes of IT Architects, people who specialize in various aspects of running mostly large enterprises. The CTO (Chief Technology Officer) is at their heart a multi-disciplined IT Architect who should have at least some experience in the various responsibilities of IT architecture as it relates to the core business or product. Most CTO’s are what we would call Enterprise Architects, people who are moderately to very experienced in the knowledge of development, but mostly are there to steer the ship from a technical and executive team perspective.

For the purposes of this article, I’m basically going to just focus on what some would call the Solution and/or Technical Architect, because in many ways, these two positions, while they can be distinct for large enterprises, are often the same person in smaller enterprises, larger companies, and startup ventures.

What Does the Architect Do?

The Architect is responsible for establishing the direction and core technical strategy for your product.

In this article I’ll mostly be talking about SaaS (Software as a Service) products, but the product can be anything from a mobile app to a new credit card that requires a finely tuned web portal for users to manage their account.

1. Communication

The biggest part of the Architect’s role is to communicate to the executive and management stakeholders what will be required to fulfill the business strategy for the product. The architect needs to be part of the meetings held by executive management so they can best understand the direction of the company and its product.

Architects assist in communicating technologies to the executive team in ways they can understand; and then communicating to the development team how the executive team’s vision can be created in technology and code.

2. Technical Direction

This aspect of an IT Architect is CRITICAL in making sure your SaaS product and company are not saddled with a core technology stack that will be expensive to remediate later as the the company grows and the product matures with new features and functionality.

The architect will likely set not only the products’ but the company direction for the technical stack, such as: LAMP, .NET, Node.JS, Java, or whatever. If you’re a CEO and your whole company is based on the Windows server architecture sitting within Azure, it’s probably not a good idea to hire a LAMP architect with AWS experience. More about this later in the article …

3. Implementation / Documentation

Your Architect is also responsible for implementing or assisting in implementing various technologies in-use within your technology stack. From SysOps to the UI and UX, and even assisting with the design of the application. Your architect should be familiar with most of the current tools used in modern application design and deployment.

Part of the role of the Application Architect is to create or oversee the creation of the documentation of the application you will be building. In this sense, your architect needs to be able to write and write well for different audiences, one is the business, the other is the technical team.

4. Risk Assessment

Technology Risk is more than just security and keeping the bad actors out of your application. It’s also managing risks that pertain to the Iron Triangle of software development:

Good. Fast. Cheap. Pick any two.

Better than 70% of all software projects fail. Why? Because developers are not concerned with the costs involved with technology selections. They just code what they’re told to and they use what they know.

Your architect needs to be familiar with things like SLC (software life cycles) and how those tech stack selections will streamline and benefit the dev team and stakeholders to reduce the myriad of risks to the company as a whole.

Failure can mean that the software took too long to build and caused huge cost overruns. Failure can also mean that the MVP (minimum viable product) is still missing some key features management really wanted within the first release.

Managing these various “risks” is part of the job of the Application Architect.

5. Hiring Lead Developers

Pulling your architect into the hiring of experienced leads is a good idea so that the architect and team leads can create the necessary synergy among the less experienced people. If you have team leads who are in conflict with your architect, that’s never a good situation.

Case In Point: Just this month I was contacted by a big company who needed an architect to “green field” (re-write) an aging application written in .NET. All of their tech stack was .NET but I am not a .NET resource. They kind of sprung this .NET stack on me at the last minute. I told them I was not the best fit for their team but they were insistent about interviewing me anyway. I shrugged and said okay because it was a really cool kind of company and I really liked their product.

But in the end, they kind of wasted my time. I didn’t get selected and I knew I wouldn’t. I could tell I wasn’t the best fit for them because they already had an installed team of .NET people. I wasn’t going to try to tell these people to abandon ship on a tech stack they already knew and knew well.

They say the best architects don’t care about the tech stack, that they are tech stack agnostic, so to speak. While this might seem all erudite in theory, it does NOT work in the real-world because you have people already steeped in the technologies they know and know well. Your architect, and team leads, and the rest of the dev team, need to all be on the same page with the technology stack for maximum productivity.

Cool & Sexy Versus Maintainable

In the IT world these days you will hear of all kinds of really super cool technologies that everyone is using, stuff like: Angular, React, Tailwind, Sass / Less, TypeScript, CoffeeScript, GraphQL, No-SQL, …

Stop.

If you hire me as your Application Architect we will not be using any of those “really super-cool” technologies. Any real architect won’t do this to you.

Why?

Because sexy tech created by bored engineers at Google and Facebook and Twitter is not going to translate into easily maintainable code for you 5 to 10 years down the road. Maybe it will still be around, but the chances are it will be history.

None of us has a crystal ball.

And that new-fangled glitzy fad-tech you just added to your technology stack will become unsupported in just a few years as the next glitzy hip piece of shiny new tech comes along that will be all the rage with the cool kid bloggers—or whatever hip new name they’ll be calling themselves in 5 years.

These new technologies are or often become what I call “fad tech”. For example, these “flavor-of-the-day” UI frameworks that get updated practically every other month, often with no backwards compatibility, really do nothing but saddle your technology stack with unnecessary code bloat without delivering any real benefit or value to the product.

I’ve written a few articles on Medium about these frameworks in the past and why enterprises should not be using them.

The life cycle of software, IF it is well-written, can easily last 15 to 25 to 50 years. I know, I’ve seen it. The core code within these long-lived tech stacks didn’t have all of the cool, wiz-bang frontend UI frameworks. These applications didn’t need them, which is the point. Even .NET is a defunct framework that Microsoft has now abandoned in favor of .NET Core, which means at least some of your code is now going to be unsupported. Python 3 broke all kinds of things to the point where code was not backward compatible.

Upgrading typically causes technical debt you weren’t expecting. But your architect will be able to navigate around these tech debt issues with the least amount of cost.

A well-written, future-proof codebase will still be working decades from now with very little maintenance.

Case In Point: Several years ago I was interviewing with EA (Electronic Arts). During the interview I was amazed but also inspired to hear that EA (or at least this technology group within EA), was abandoning ship on all of the new UI frameworks and instead moving forward with developing all of their apps using what we call just plain Vanilla JavaScript. Wow. It was startling to me at first, but EA had finally decided that all of the “flavor-of-the-day” UI frameworks were EXPENSIVE to maintain and really delivered little to no value in terms of the product’s UI. Actually, these frameworks were costing the company huge dollars in trying to find people to maintain the various UI stacks.

Every single day, I have tech recruiters filling my inbox with emails that read with desperation! “We need an Angular dev with 5 years of experience!” Yea, good luck finding that person. These UI frameworks are often new and installed by people who likely didn’t have all that much experience using them. This tech debt is now huge and the company needs someone to fix their now expensive problems.

Your Application Architect should be able to see through the smokescreen of fad-tech to deliver a rock-solid technology stack that will be both easy to maintain but also supportable decades into the future.

Who Does the Architect Report To?

Architects are people who need to understand the business you’re in. The people best suited for the architect to report to are those who can give the architect the best understanding of the business model, customers, how revenues are earned, etc.

Usually, this is someone within the executive team:

• For large and medium-sized enterprises, the architect typically reports to the CTO or an Executive VP  or Executive Director of Engineering.
• For large to small businesses who may not have a dedicated technology person within their team leadership, the architect needs to be talking directly with the business owners and/or product owners of the company.
• For small business and startups, the architect will be a member of the core management team and will wear quite a number of hats as Enterprise, Solution, and Technical Architect.

When Do I Need To Hire An Architect?

The best time to hire your architect is preferably BEFORE you begin the project. But most of the time this doesn’t happen. The architect is brought in as a kind of afterthought to help assist in giving direction to the dev team after a lot of technology, including the wrong technology, has already been (badly?) selected and developed.

That being said, the BEST time to hire an architect is NOW. Even if your project is 20% or 50% complete and is beginning to show signs of being slow, the code is brittle, or even suffering from outright failure in terms of how it’s actually working under load.

That’s okay. I have come into many projects partway through and had to work with the dev team to clean up technical debt that never should have been there in the first place. It’s what happens. That’s why we’re here.

Most companies who see the need for an architect will advertise something like: “Application Architect needed for .NET tech-stack.” These are the ones I see the most. Maybe the .NET tech-stack wasn’t the best choice for your company? In any event, your architect really needs to be the person helping you choose the right tech-stack for your company and products.

The sooner you bring in a real Application Architect, the less tech debt you will have to retire later on.

What Does An IT Architect Cost?

Think of an IT Architect as a senior member of your management team who specializes in keeping and maintaining your software in tip-top shape and performance. Not all developers have this kind of experience or skills. Note that most IT Architects will also have deep business and even entrepreneurial experience with startup companies, like I do.

Depending on your technical needs, an architect will typically run about 50% higher than a senior developer costs. Again, this cost can vary depending on the size and maturity of your business, the location of the architect (think the difference in the costs of living in New York versus Orlando), your SaaS products technical needs, and of course your application’s budget.

 

Can I Hire an Architect Part-time?

The short answer is yes, but I do not recommend that. Your Application Architect needs to be in the loop with management and the dev team constantly. Would you be a successful business with only a part-time COO? A part-time CEO? Again, the position of Architect is or should be a member of your core product management team in addition to your technical team. That really is our core job. Without out us, technical debt will creep into your technical stack, debt that could cost you a lot of time and money later on to retire.

 

---

Real-world Business Case: Narware Technologies

TIGER™ Development Platform

Here’s the part of this article where I give a shameless advertisement for myself and the TIGER Development Platform I built for clients to kickstart their applications.

Last year, I was hired by Narware Technologies to assist in architecting their core technology stack. Based on their needs for API and data integration, I introduced the management team to my TIGER Development Platform, a fully-functional and integrated LAMP technology stack that would be easy for them to leverage for their core SaaS features.

Narware’s SaaS product is a platform to manage small to massive webinars in a way that is guaranteed to increase sell-through by 15% to 30%. It’s an amazing product that integrates seamlessly with your favorite CRM and webinar providers.

TIGER is my goto platform because it already has multi-tenant SaaS functionality built right in and working out of the box. TIGER literally saved Narware months of coding and tens of thousands of dollars in development costs. The offshore team was already familiar with the technologies in use and didn’t have to learn something from scratch.

I built TIGER for my own pet projects, but now I’m using the platform to rocket-launch my clients’ own enterprise-class SaaS products as well. TIGER rocked it for Narware’s core SaaS platform and it can work just as well for your AWS-based SaaS application too!

If you hire me as your architect, you get the TIGER Platform at no cost to your company.

---

 

Conclusion

If you’re starting a new business or creating a new business unit around a major piece of software like a SaaS app, and you want your core technology stack to be affordable and maintainable, architects like me can get you from start to finish with exceptional results.

Application Architects are more than just developers on steroids, we have the business experience and knowledge to help you navigate the technology waters and build an application that is both cost-effective and more importantly maintainable by just about anyone with current skillsets.

Do you need an experienced architect? Feel free to contact me about your project.

 

---

Up Next …

---