The use of system development life cycle (SDLC) models expanded in the 1980s, presenting a more structured and repeatable way to develop systems. The most popular SDLCs aligned the language of software development with that of building construction, paralleling much of the phase language: planning, specifications/requirements, design, and construction. In building construction, architects have overall design responsibility and interact with customers to help best deliver the customer’s dreams. As software development organizations integrated the newer SDLCs into their delivery practices, they defined software development-related architecture roles and staffed them with experienced resources.

How one architect role differs from another is usually defined at the organization level. Actual titles are not used consistently across the industry. There are technical architects, data architects, enterprise architects, operations architects, solution architects, interface architects, etc. Some companies now even have C-level architects (chief software architect). But which type of architect is most needed and valuable in the realm of software development and delivery? I say it’s the application architect in the world of system-related architect roles. “Application” as a modifier is ambiguous at best, so let’s pinpoint the definition.

As technology has evolved, technologists have sometimes focused on technical solutions that are not necessarily rooted in solving a business problem. Solutions cannot ignore standard technology concerns such as scalability, security, and performance. But every component should be designed to directly support a business need or goal, which is really the focus and purpose of application architecture. More succinctly, application architects ensure that software systems are designed to accurately and efficiently support desired business functionality.

Naming application architects into your organization is easy. At the risk of overusing the term, the best are grown organically, following a simple recipe:

• Identify smart and willing people
• Assign them test analyst roles
• Assign them an application area that supports a specific business domain
• Task them with analyzing and understanding the business scenarios they are testing
• Make them analyze defects they find
• Allow them to get accustomed to these steps for a few big releases

In many companies, defining and executing applications tests are left to less expensive, non-critical personnel. It’s true that repetitive test execution without detailed analysis, especially in light of advances in test automation, can and should be performed by cheaper resources. However, the reality is that the testing space is fertile ground for nurturing application architects.

Triaging test results against documented business requirements and desired scenario results ensures deep understanding of the business and technology needs. In this role, the future architect’s experience in testing provides core functional and application knowledge, leading to recognition as the true subject-matter expert. Think of the required skills as a major/minor degree pursuit in which the application architect majors in business functionality and minors in technology.

There should be roughly a 75/25 split between business and technology work. Understanding core business processes—and which application sets support those processes—should be an application architect’s main focus. The application architect must deeply understand technical details such as user interface, data loads, and the timing of batch jobs. The technical knowledge is always in direct support of the business, and the technology is understood to bolster the understanding of how applications fulfill business requirements and goals.

So how are application architects different from business analysts since they possess many of the same skills, particularly in their ability to interact with business owners in validating and documenting business processes? While BAs mainly focus on requirements gathering and translation, application architects contribute across all life cycle development phases regardless of methodology. Companies that embrace Agile methodologies may require the services of application architects more than traditional waterfall shops simply because of the iterative nature of the development. Architects are the experts in the business. They act as agents for the business in the technology organization, in addition to being the liaison to the core technology teams.

Application architects perform initial problem solving and estimating. They approve final designs, validating that the proposed design supports the business. They are key points of contact in building out options for resolving issues that arise during development and after system release. Like conventional architects, they are responsible for overall system functionality and customer satisfaction with
the results.

For most businesses, the technology organization exists to serve and support the core business functions. Technology organizations that embrace the application architect role and invest in building their necessary skills will see immediate benefits, not the least of which is an improved relationship with their business stakeholders.