A Guide to Technical Architecture

Ready to Customize Your Software?

Reach out to us at any time.

Although most people would never consider building a house without first engaging an engineering architect, many start a software project without using a technical architect and are surprised when the project encounters problems. Similar to a building blueprint showing the framing, plumbing, and electrical plan so the crews know what to put where, a software project needs a technical architecture plan that lays out all of the pieces of the application, the connections, the data, the features.

“By failing to prepare, you are preparing to fail.” –Benjamin Franklin

Technical architecture—which is also often referred to as application architecture, IT architecture, business architecture, etc.—refers to creating a structured software solution that will meet the business needs and expectations while providing a strong technical plan for the growth of the software application through its lifetime. IT architecture is equally important to the business team and the information technology team.

Technical architecture includes the major components of the system, their relationships, and the contracts that define the interactions between the components. The goal of technical architects is to achieve all the business needs with an application that is optimized for both performance and security.

IT architects plan for things they know are coming in the future and for things they don’t yet envision or dream. Taking the time to design the architecture at the start will prevent major design changes, code refactoring, and expensive rework later in the project.

Shared information technology language

Let’s start with definitions of what you need in the information technology world and then dive into the different types of technical architecture you need depending on the scope of your software project.

Unfortunately, like most things in technology, words evolve and change meanings over time. Establishing a few common terms will help us examine different IT architecture needs.

Application: An application is a set of functionalities that has been created to solve a business problem. We now see most of those in the forms of phone apps but there are usually web and desktop components to many software applications.

Artifacts: Any tangible item created to help design, build, and maintain software. Examples of artifacts are requirements, project plans, data flow designs, and test cases. These items help describe the intent, function, and history of the code.

Data: The attributes that describe different things. Data is stored in and retrieved from a database, which is often located in a data center. Good practice is to model the data in a way that represents real life and real work so it is not only obvious where things are but it is also easy to enhance the data we are storing when the item changes. One example would be a User. We can store all the data about a User together. Their name, email address, etc. are all data attributes of a User.

Information: Let’s distinguish data from information by defining information as a collection of data that when put together have meaning. For instance, if we type a user (e. g. customer, employee, etc.) or put a Customer together with their Orders, we are creating information that tells us a story about our Customer.

Security: At a high level, security focuses on making sure people cannot do things they aren’t supposed to be doing protecting privacy across the entire network. The process of preventing privacy issues across the network for those using the systems is a high priority.

Infrastructure: The servers, computers, network switches, cabling, etc. that software may use to talk to each other.

Server: A machine (whether real or virtual) that we can control, install software on, connect to a network, and is used the run software. Servers usually run software for multiple people at the same time.

Service: The various software running on a server are services, meaning, we can ask them to do things for us like calculate, get data, schedule shipping, etc.

Cloud: The cloud is a modern-day take on infrastructure. The cloud contains servers and services. Many clouds provide many commonly used services, so developers do not need to code them.

Enterprise: An entire organization or ecosystem, commonly all the information technology software utilized for the entire operations of the company.

The role of the technical architect

Now that we have some common terms, let’s look at defining an architect. An architect takes responsibility for the overall direction of a technology project. The architect has an approach to how they will design the technical architecture and how the software development team will build the software.

Think of the technical architect on a high level looking down at the city as it is built. They have an overall perspective that no one else can have; they see the building as a building, not as the parts.

To achieve success, the technical architect will need to consider and understand the software system through the eyes of each of the system stakeholders including:

• End user view. Technical architecture must consider the design and user experience in order for the application to be intuitive, secure, reliable, and provide excellent performance.
• Marketing and sales team view. This team is always focused on the external customer experience and the market value they may need to understand competitive features, time to market, integration with other products, overall cost. Also, they will be asking for early application images and prototypes to begin conversations with customers.
• Development team view. Those focused on designing and building the products including the business analysts, software developers, and quality assurance analysts will want clear requirements, easy to read use cases, consistent design, and reusable patterns. Responsible for the implementation and deployment of the systems, each developer uses resources to prevent issues.
• Organizational team view. The system administrator, project manager, and product owner will focus on the predictability and traceability of this build, as well as the management, support, security, and maintenance of the day to day operations of the system well into the future.
• Business management view. Often considered the funding arm, these folks want the biggest bang for the bucks they are investing in the software. They depend on the technical architect for a clean, cost effective build that meets each business ask and is delivered in alignment with the marketing and sales team’s planning schedules.

The technical architect communicates directly with all teams staying aware of changes in order to implement them in a technically sound and cost-effective way. The architect will build and maintain technical architecture artifacts that use the thinking of the various stakeholders and provide a vision and approach for the information technology system.

What kind of a technical architect do I need?

If you searched software or technical architecture in any job site, you would find several different specialties within the technical architecture space.  Let’s look at a few of the more common types of technical architects.

Application Architect

An Application Architect is concerned with a specific application (or app). This person is focused on a specific application at a time, but they do everything about that application (even if they need help from the other technical architects). The Application Architect understands the business problem thoroughly and is making software to address that problem. They are focused on the software they are building and talking to the other things provided by the Solution Architect.

Data Architect

A Data Architect is defining the data and information needed to store and retrieve in order to provide the value of the solution. Without proper data-level technical architecture, systems depend on increasingly powerful servers to use brute force to access data. This ultimately leads to a solution that does not scale (allow growth in number of users and features). As much as 95% of performance issues can be traced to poor Data Architecture.

Cloud Architect

The Cloud Architect is a person that understands the services provided by various cloud providers and the best way to utilize those services for web-based applications. In addition, they need to make sure the solutions under their care can move to a new cloud with as little pain as possible (usually through encapsulating the use of the Cloud Services into objects the application calls so the application doesn’t call the services directly and repeatedly).

Solution Architect

A Solution Architect puts the applications, data, infrastructure, networks, servers/services, cloud(s), devices, and security together to create the answer (the “solution”) to solve the problem at hand. Their view will provide strong understanding about the resources needed for implementation, the standards the project is using, and the physical and web components. They are a person that knows at least a little about each discipline so they can make sure the solutions work together as a whole.

Enterprise Architect

The Enterprise Architect is the architect of all of the technical architects. When you build applications for a living, you see a lot of commonalities between applications. The Enterprise Architect is setting the direction for all of the software across the organization’s ecosystem. The Enterprise Architect is a collection of all the good and bad experiences they have had with all kinds of technology, techniques, approaches, processes, etc. They have often functioned as many different types of architect and will have strong opinions about the right and wrong ways to do things. We are best advised to listen. They have already lived pain that we want to avoid.

When do I need technical architecture?

Both technical architecture for software development and building architecture share the answer to this one—before you start building. You need to design a basic technical architecture plan before you begin writing code.

Designing the technical architecture of your application from the start will help you make the correct fundamental structural choices to positively impact the quality, scalability, and longevity of the overall system.

The technical architectural model will be used to guide decisions and to mitigate risks as the system is being built. Artifacts from individual applications and solutions are rolled into the enterprise architecture for your organization.

If your current software project is to add new features and functionality to an existing technology system, you will want to start with a review of any existing technical architecture documents and an analysis of the applications. Next, you will want to look at the new items and create a plan for integrating into the existing system. Taking the little bit of time to analyze at the start will save you time, frustration, and expensive rework later.

The larger your technology footprint is, the more important architecture becomes. When you reach the level where your software spans your entire enterprise with a mix of off-the-shelf applications and custom developed software, you will want to have an enterprise architectural plan ensuring your enterprise functions at the highest levels of productivity, security, and efficiency.

Enterprise architecture for the future

Enterprise architecture takes place today but prepares for many tomorrows. The enterprise architecture documents are updated with each new application connected to your organization’s system. It becomes a living artifact maintained regularly by enterprise architects.

When it is time to develop new logic to solve the next problem or introduce a new product or technology to your existing systems, the team can return to this architecture framework document, which allows for safer changes, better requirements management, and an overall healthier ecosystem.

“When you’re finished changing, you’re finished.” –Benjamin Franklin

Businesses do not have the luxury of resisting change. Customers change, competitors change, technology is constantly changing. Software and systems need to be able to adapt to the change.

The better the enterprise architecture is built and maintained, the easier it is to understand how changes will impact applications. Teams that can make intentional decisions can build without worrying that a new implementation will negatively impact other components.

The developer can make product upgrades that improve a process, solve an issue, or utilize data without worry that a deployment will break other functionality in the app for the user. Functional architecture and peace of mind are close companions.

Ten benefits to technical architecture

Whether you are building a new software product, expanding a current application, or integrating several systems together, a strong enterprise architecture plan can improve quality, reduce risks, and save money. When used properly and consistently, business architecture artifacts facilitate communication between business and development teams. They encourage informed decision-making before building system components. As teams review the technical architecture documents, they can discuss a wide variety of concerns to ensure the system addresses the different viewpoints and business objectives. The advantages of using a technical architecture plan are:

Affordability

A technical architect can ask questions of the business team to make certain each decision is intentional, understanding is shared, building blocks are in place, and the benefits match the costs. Or, if these objectives aren’t being met, solution architects can suggest another alternative that would save time and money while still providing the business value within the applications. Use of technical architecture is also the first defense against redundancy and overlap of the development team tasks.

Security

Data needs to be protected from people that want to do it harm. From preventing data breaches that allow unauthorized access to personal data in your application to protecting your customers from privacy issues, security measures must be taken to protect your data. Differing interfaces for external and internal users will have security needs that must be understood and documented by your solution architects. Having an enterprise architectural plan provides the overview needed to see potential vulnerabilities.

Quality

An informed and intentional technology architecture with forethought and planning improves the overall system quality, enhancing performance, security, reliability, and interoperability of applications. Each decision for your business architecture is important to ensure the users enjoy the systems and can interact without questions or confusion. Technical architecture ensures that communication across the information technology system and the teams is focused and success-driven.

Performance

You want your application to run quickly and easily. After all, users are notoriously impatient. To ensure a short response time and a high throughput both now and in the future, you need strong enterprise architecture principles, especially in the data design of your applications. A streamlined application that allows each process to move from point A to B without unneeded detours will perform quickly and cleanly in every deployment.

Adaptability

Connecting to other systems, changing interfaces, and adding in new logic rules will all be easier for a developer to complete since the technical architecture creates clear separation of issues. With reliable IT architecture, you improve leadership’s ability to understand and make informed future decisions and the developers’ ability to add features with minimal impact to the rest of the app.

Productivity

Without a central solution architecture document, teams rely on a variety of ways to get started with making updates to additions. Some will read old, but related, requirements. Developers open the code and look around. Using a solid structure rooted in enterprise architecture makes it easy to find what you need, improve understanding, and add new features.

Code Maintainability

The developer you have today will not be the same one you have five years from now, but your well-architected application will be still working. Existing and new development team members will find the software easy to maintain, support, and advance while adhering to quality standards set within your enterprise architecture artifacts.

Scalability

A software system that will not grow with your business quickly becomes a liability, not an asset. Your system needs to be architected for the future with scalability in mind. The enterprise architecture will need to easily handle an increased amount of work over time. The fun part is that while we can talk about where we think the application is going to go in the future, we are usually wrong and need to make other decisions based on user/customer feedback. Envisioning that future and protecting our investment is what scalability is all about.

Compatibility

We now live in a world with so many different devices. Different screen sizes, network interfaces, input modes, bandwidth, web apps, desktop applications, operating systems, etc. Technical architects guide how to make all these components work well and interact with the user in a way that is not only useful but also pleasant.

Diagnostics

Technical architecture acknowledges that something is going to go wrong at some point in any application and puts the right diagnostics in to identify and solve problems from the start. When a problem occurs, you want to have the building blocks in place to get your systems back up and running quickly.

Architecture leadership

Strong architectural leadership is essential for business, especially for businesses who rely on software to delight their customers. However, attracting and retaining technical architects with the right technical skills and computer science background can be both challenging and expensive. Finding a leader who is equally fluent in business strategy and technology architecture principles and can see the big picture while organizing the little details may prove difficult. One solution is to utilize a custom software company with expertise in enterprise architecture. This partner can maintain your enterprise architecture artifacts and provide the level of time you need for the scope of the work you have on your plate. If you have a large team, they can work closely to support your IT leadership. If you have no team at all, they can provide technical team members for you. If you are somewhere in between, a good custom software partner will have their enterprise architects work with you to provide the resources you need in conjunction with your IT calendar while keeping your enterprise architecture in line. Often this type of partner costs less than a full-time, in-house architect. If you would like to learn more about Geneca’s business architecture services, contact us with any questions. We can help you seize digital business opportunities and succeed in your implementation of application architecture.

FAQS