What is Architecture and why do I need it?


We’ve probably all heard the word Architecture tossed about in software development conversations numerous times, and many of us likely imagine this word to mean, uber software development, or what someone perched in the ivory tower does who, one day, will solve all our software woes in a grand flash of brilliance. Is that really Architecture?

Nope. Not even close.

Imagine “the ideal software company”, with an IT department full of great software engineers, network gurus, database wizards, and product owners. We’d love all these talented individuals to be spending their entire day creating better software – adding value by making customers happy, and seizing the next market opportunity the moment it arises. What an amazing software company that would be!

However, my experience in the trenches has shown – instead of creating business value, many organizations are spending a great deal of time maintaining their systems, fixing bugs, and reacting to unplanned outages. The defect lists continue to grow while the time to deliver valuable new features to the market increases with each release, and the development teams begin to push back, saying ‘No’ to key business requests because implementation is deemed too costly or difficult. Meanwhile, the little time actually spent on new development is used to create features, improvements, or pet projects that often don’t add real value to the business.

This scenario describes the realized byproduct of what we call technical debt as it accumulates within an organization over time. Like financial debt, this technical debt encumbers an organization, sapping energy, focus, and valuable resources which should be used to move the business forward instead of just keeping the lights on. Technical debt is accrued by making expedient, but suboptimal technical decisions along the way – decisions which do not meet the organization’s real business needs. Most organizations are unsure how to pay down this debt, so they can return to a more cohesive, and effective delivery vehicle.

Unfortunately, these systems were built, and this technical debt was incurred by highly-talented engineers, many of whom probably have Architect on their resumes. Certainly, this negative outcome is not on purpose, or by ignorance. In fact, it seems like this scenario just happens, and is a very common growing pain of many IT organizations. So why does this happen if we hire great people?

Enter Architecture.

The purpose of Architecture is to align the efforts of IT resources to create systems which meet the needs of the business. So how do the wrong decisions get made, and how can Architecture lead to realignment and “paying down” technical debt?

Often market opportunities lead an organization to continuously drive new functionality as quickly as possible. This is understandable as a growing company fights to compete in the market and meet customer demand. Often this rapid creation is done at the cost of sacrificing non-functional qualities (the ones the customers don’t see) of the system. The organization chooses functionality over non-functional qualities. Qualities such as:

  • How easy is the software to maintain?
  • How fast can it be changed?
  • How many users can we handle at one time?
  • How hard is it to get a report about usage within the system?


There are many other examples of non-functional qualities, and every organization has different needs which must be considered. Depending on the answers to these non-functional questions, an organization’s systems will need to be designed and built in radically different ways!

Eventually, the business will likely begin to experience serious problems related to one or more of these non-functional qualities: skyrocketing maintenance costs, increasingly frequent system outages, or agonizingly slow response times, to name a few. When asked to address them, the engineering department may respond like this, “If we do that, we are going to have to completely rewrite our XYZ system!”

Sound familiar? I hear this concern from most organizations I engage with. We don’t blame the highly skilled engineers. We realize we have simply lost the forest for the trees. Those engineers are amazing at making systems do what is required. However, in many cases it seems that nobody has taken the time to clearly define these non-functional requirements.

It is usually at this growth point within an organization where people begin to realize the cost of not considering these qualities greatly outweighs the management of them. A holistic approach is needed to ensure the business needs are fully understood, and the delivery pipeline within the IT department can successfully meet those needs.

This is where Architecture become so important. Since we now know the answers to those quality questions will likely have a radical impact on system design, we’ll leverage Architecture to evaluate those quality questions and create a complementary holistic design. Architecture is the management of these quality attributes, the subsequent system design, and oversight of execution which will meet the organization’s specific business requirements.

How aligned is your IT department with the needs of your organization? How prepared are your systems to address new business drivers and opportunities? Have you considered having an Architect help analyze those needs to help manage the risk of your delivery pipeline?