What is technical architecture, and do I need it for my software project?
Although most people would never consider building a house without first engaging an engineering architect, many start a software project without use of 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 is 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 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 the technical architect is to achieve all the business needs with an application that is optimized for both performance and security while planning for things they know are coming in the future as well as for things they don’t yet envision or dream. Taking the time to design the architecture at the start will save major design changes, code refactoring, and expensive rework later in the project.
Business first
Without a business need, there is no reason to build software. Software solves problems–that is the reason for it to exist. Architecture development starts with the business need at a high level. The need provides the basis for the technical architecture planning. The focus on business outcomes should be top of mind while designing the entire solution. In fact, the organization of the technical architecture should reflect the organization of the business.
This might seem like common sense, but often the technical architect is excluded from the early business meetings and then enters the conversation too late to truly learn the need and use his or her technical expertise to answer questions and suggest solutions to build efficiently and cost effectively. Architects and developers love the “how” side of solving problems and failure to include the IT team early eliminates strong thinking from a different perspective that can have a meaningful impact on the architecture and the end solution.
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 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. 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. On example would be a User. We can store all the data about a User together. Their name, phone number, 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 the technical architecture will be designed and how the software development team will build the software. Envision 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.
In order 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 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 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 built or purchased that is connected to your organization’s system. It becomes a living artifact maintained regularly. When it is time to develop new logic to solve the next problem or introduce a new product or technology, the team can return to this architecture framework document allowing 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 worry 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. Architecture and peace of mind are close companions.
The role of the enterprise architect
The work of the enterprise architect and the leadership of the information technology department is challenging in nature. Depending on the size of the IT department, these leaders may be responsible for the management of complex technology frameworks with a myriad of criteria–different types of data, various business processes, concurrent projects with scope and budget concerns, and overall resources management. In a smaller organization, the enterprise architect may still code regularly. In a larger company, he may oversee architects who oversee tech leads adding complexity to the chain at every level. What can happen innocently and too easily is the architect gets excluded from the business conversations in order to respect his or her time and things begin to fall apart within the organization.
Remember the point about Business First? That needs to become the central belief of the enterprise architect and the entire company’s leadership team. A strong enterprise architect can separate strategy-related business tasks from IT operational ones. At the enterprise level, leaders facilitate a balance between short-term tasks and long-term goals with a clear approach for managing each. Effective enterprise architects endeavor to make the technical complexities simple through the use of lean processes, ownership mindset, and effective communication tools. Able to separate architecture tasks from fire-fighting tasks, they develop an approach for leading the IT team to support and advance the business needs.
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, architecture artifacts facilitate communication between business and development teams. They encourage making informed decisions 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. Included in the benefits reaped by use of 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, and the benefits match the costs or 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 allowing unauthorized access to personal data in your application to protecting your customers from privacy issues, security measures must be taken to protect the data. Differing interfaces for external and internal users will have security needs based on roles that must be understood and documented. Having an enterprise architectural plan provides the overview needed to see potential vulnerabilities.
Quality. An informed and intentional system with forethought and planning improves the overall system quality enhancing performance, security, reliability, and interoperability of applications. Each decision 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 are focused and success driven.
Performance. You want the application to run quickly and easily. After all, users are notoriously impatient. In order to ensure a short response time and a high throughput both now and in the future, you need strong enterprise architecture standards especially in the data design of your applications. A streamlined application allowing each process to move from 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. 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 architecture document, teams rely on a variety of ways to get started with making updates of 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, etc. 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 foundation 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 architects can be both challenging and expensive.
Finding a leader who is equally fluent in business and technology 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 team members for you.
If you are somewhere in between, a good custom software partner will work with you to provide the resources you need ebbing and flowing 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 architectural services, contact us with any questions. We can help you seize digital business opportunities and succeed in your implementation.
