1. Enhance Your Application Architecture
Architect your applications with a foundation of well-defined stakeholder needs and quality attributes.

2. ANALYST PERSPECTIVE
Application architecture is a critical foundation for supporting the growth and evolution of application systems. However, the business is willing to exchange the extension of the architecture’s life with quality best practices for the quick delivery of new or enhanced application functionalities. This trade-off may generate immediate benefits to stakeholders but it will come with high maintenance and upgrade costs in the future, rendering your system legacy early.
Technical teams know the importance of implementing quality attributes into architecture but are unable to gain approval for the investments. Overcoming this challenge requires a focus of architectural enhancements on specific problem areas with significant business visibility. Then, demonstrate how quality solutions are vital enablers for supporting valuable application functionalities by tracing these solutions to stakeholder objectives and conducting business and technical risk and impact assessments through multiple business and technical perspectives.
Andrew Kum-Seun,
Research Manager, Applications Info-Tech Research Group

3. Our understanding of the problem
Application Architects
Obtain a clear understanding of your stakeholder objectives and quality attributes defining your application architecture.
Evaluate your current state application architecture from multiple perspectives.
Communicate and justify architecture designs to stakeholders and development teams.
Define a repeatable application architecture design process.
CIOs/CTOs
Enterprise Architects
Solution and Domain Architects
Development Teams
Make the right architectural decisions based on the information provided by the application architecture.
Become aware of the architectural constraints and available components that will dictate development, testing, and deployment.
Identify application architecture dependencies and conflicts with other aspects of enterprise architecture.

4. Executive summary
Most organizations have some form of application architecture; however, it may not accurately and sufficiently support the current and rapidly changing business and technical environments.
In an attempt to enable quick delivery, applications are built and integrated haphazardly, typically omitting architecture quality practices.
Well-received applications can have poor architectural qualities. Functional needs often take precedence over quality architecture. Quality must be baked into design, execution, and decision-making practices to ensure the right tradeoffs are made.
Systems are designed in isolation. Cross-functional collaboration throughout design is critical to ensure all types of issues are revealed early. Otherwise, crucial tests are omitted, deployments fail, and end users are dissatisfied.
Failing to involve development and stakeholder perspectives in design can lead to short-lived architecture and critical development, testing, and deployment constraints and risks being omitted.
Architects are experiencing little traction implementing solutions to improve architecture quality due to the challenge of tracing these solutions back to the right stakeholder objectives.
Translate stakeholder objectives into architecture requirements, solutions, and changes. Incorporate application architecture quality attributes in decisions to increase your architecture’s life.
Evaluate your application architecture from multiple views (i.e. use case, process, component, data, deployment, and system) to obtain a holistic perspective of the range of issues, risks, and opportunities to address.
Adopt the right architecture patterns and styles to help solve key design challenges. Create a reusable reference architecture that technical teams can use to discuss and implement architecture solutions and changes.
Regularly review and recalibrate your application architecture so that it accurately reflects and supports current stakeholder needs and technical environments. Actively involve and consult stakeholders and technical teams throughout the architecture design process.

5. Needs Can Come From a Variety of Sources
Application architecture must change to support the constantly evolving needs of the business
Modifications to application architecture are typically triggered by needs for better application functionalities and technical support in order to improve alignment with business needs.
Needs Can Come From a Variety of Sources
Realignment of capabilities and objectives from an enterprise architecture review.
Improving the health of the application portfolio driven by insights from rationalization and roadmap activities.
Enhancing the effectiveness and efficiencies of application development, testing, deployment, and maintenance practices.
Requests for new or amended functionalities to support evolving business needs.
Understand the rationale behind application change requests to ensure your application architecture design has sufficient buy-in.

6. Demand for quick delivery causes teams to omit architectural best practices, leading to downstream challenges
The business often doesn’t see the value in making sure architecture is maintainable, reusable, and scalable; they just want to get updates out the door quickly. This demand leads to an organizational desire for development practices and procurement of vendors that favor time-to-market over long-term maintainability. Unfortunately, technical teams are pushed to omit design quality and validation best practices. The common cause is that most business stakeholders do not have full view of the business impacts of their architectural decisions.
What are the business impacts of omitting architecture design practices?
Poor quality application architecture impedes business growth opportunities, exposes enterprise systems to risks, and consumes precious IT budgets in maintenance that could otherwise be used for innovation and new projects.
Previous estimations indicate that roughly 50% of security problems are the result of software design .... Flaws in the architecture of a software system can have a greater impact on various security concerns in the system and, as a result, giving more space and flexibility for malicious users.
Source: Mirakhorli
Errors in software requirements and software design documents are more frequent than errors in the source code itself, according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also are more severe and more difficult to remove.
Source: Soni

7. Technical teams have difficulty obtaining buy-in to enhance architecture quality
The business often cares about application functionality significantly more than the quality of the technical components supporting their applications. Technical teams then struggle to convince stakeholders of the value of investing in architecture quality improvements, which can lead to risky tradeoffs that shortens the life of the architecture or complicate maintenance activities.
Common Technical Risks with Poor Quality Application Architecture 1
Poor Adherence to Security Standards: Security practices and protocols are implemented inconsistently across enterprise systems and are not enforced in each stage of development and release. 2
Overly Centralized: Having too much data and processing in a single module causes bottlenecks and latency issues. In some cases, this module is the single point of failure and can render the system inoperable given the lack of redundancies. 3
Complicated Maintenance Tasks: Logic components are tightly integrated and overly distributed. Fixing existing features requires significant time reviewing all dependencies and validating regressions are not introduced. 4
Lack of Reuse and Knowledge: Teams are not aware of the services and entities that are available to them or the constraints and standards they must abide by. Logic is newly built rather than using components that already exist.
The bottom line: The business’ ability to efficiently operate in the long term is influenced by the technical team’s ability to manage and support the architecture. If it has low quality, then the applications supporting the business will perform and be maintained poorly. Quality best practices should be mandatory in the design and any quality enhancements should be built into the project’s proposal as necessary tasks.

8. Good architecture design practices can give you a number of benefits:
Design an application architecture to define the path to success within the constraints and complexities set before you
Good architecture design practices can give you a number of benefits:
APPLICATION ARCHITECTURE…
Lowers maintenance costs by revealing key issues and risks early. The Systems Sciences Institute at IBM has reported that “the cost to fix an error found after product release was 4 to 5 times as much as one uncovered during design” (Soni).
Drives consensus between various stakeholders since it provides a vehicle for enabling debate about the system solution.*
Supports the design and implementation activities by providing key insights for project scheduling, work allocation, cost analysis, risk management, and skills development.*
Eliminate unnecessary creativity and activities on the part of designers and implementers, which is achieved by imposing the necessary constraints on what they can do and making it clear that deviation from constraints can break the architecture.*
… describes the dependencies, structures, constraints, standards, and development guidelines to successfully deliver functional and long-living applications. This artifact lays the foundations to discuss the enhancement of the use and operations of your systems considering existing complexities.
*Source: Eeles

9. Use Info-Tech’s approach to design a valuable application architecture
The success of application architecture is ultimately dependent on the selection of the right problem space and choosing the appropriate solutions to drive value. This blueprint will walk you through the steps needed to design an application architecture aligned to stakeholder needs, existing constraints, and quality attributes.
First, define the business and IT stakeholder objectives and quality attributes that will drive your application architecture. This ALIGNment will ensure that architectural changes are satisfying the right stakeholder priorities.
The second step is to ASSESS the current application architecture to reveal current issues, opportunities, and constraints that are positively or negatively impacting the support of business capabilities and development.
Next, DESIGN application architecture options to enhance the value of your supporting application, considering the business and technical complexities revealed in your assessment. Analyze the benefits, costs, and risks of each option to make recommendations.
The final step in the process is to FOLLOW a repeatable process to ensure your application architecture design involves the right roles and perspectives and is continuously aligned with current stakeholder priorities and needs.
Align
Assess
Design
Follow

10. Broaden your architecture assessment and minimize system-wide degradation with cross-functional collaboration
As you begin to investigate initiatives to optimize your application architecture, consult the various roles that use, manage, and deliver application system changes to ensure you are not introducing new bottlenecks and inefficiencies.
For example, if architects decide to implement cloud solutions without consulting development and operations, they may encounter the following consequences:
Existing data will need to be restructured because of its incompatibility with the cloud.
Enterprise integration strategies and practices will need to be reviewed and modified to reflect the cloud vendor’s standards.
Significant effort will be required to modernize the existing codebase and application interfaces.
Discuss Tradeoffs With Both Business and Technical Roles
Traditionally, application architecture is designed in insolation. In some cases, key architectural decisions and solutions have negative effects on downstream teams who rely on the architecture, causing issues during development, deployment, and maintenance.
Holistic, cross-functional thinking will reveal all dependency, structural, and operational impediments within the entire enterprise system that may restrict you from delivering and supporting architecture changes in a timely manner. This level of thinking focuses on ensuring changes are sufficiently assessed from multiple perspectives, considering all complexities and constraints.
Application architecture builds on and improves best practices successfully employed by your technical teams. The goal is to involve and consult the various roles who are using, managing, and delivering your application system changes with the aim of revealing the scope of existing issues, risks, and opportunities to define the best solutions and practices.

11. Build the case for architecture enhancements by aligning your solutions to stakeholder objectives to justify value
Everything architects do to optimize application architecture must be directly or indirectly contributing to value delivery improvement or stakeholder buy-in would be difficult to obtain. Therefore, any improvement initiatives you decide to undertake must be aligned with high-priority objectives in order to assure the most important value is delivered to stakeholders.
Business Value
Example:
Ensure Delivery of
Value: Quick Response to Market Changes
Stakeholder Objectives
(Stakeholder requirements, capabilities, and objectives placed on applications and architecture)
Enable the Delivery of
Strategic Objective: Enable Business Agility
Operational Objective: Increase Sales Productivity
Aligned with
Application Portfolio
(Enterprise applications supporting business operations and capabilities )
Will Increase Its Alignment to
Portfolio: Sales Application Portfolio
Define a Valuable
Application Architecture Requirements
(Functional and quality attributes of the application architecture)
Will Increase the Value of
Functionality: Process Sales Cases
Quality Attributes: Availability and Scalability
Used by Team to Satisfy
Supporting People, Processes, and Technologies
(Mechanisms, structures, and tools needed for teams to design, implement, and support the architecture)
Will Satisfy
Architecture Enhancements: Migrate Infrastructure to the Cloud (Infrastructure-as-a-Service) and Standardize on REST APIs

12. Enterprise Architecture
Application architecture is not a standalone concept; it fits into the greater and holistic design of enterprise architecture
Application Architecture in Alignment
Application architecture cannot be designed to simply address the focus of application architects or even the IT department.
It must act as a key component in the all- encompassing enterprise architecture and reflect the strategy and design of the entire business.
Application architecture collaborates with data architecture in the delivery of effective information systems, and informs infrastructure and security architectures on applications-related infrastructure considerations.
Please refer to the following to see the full picture of enterprise architecture in Info-Tech’s taxonomy:
Enterprise Architecture
Business Architecture
Data Architecture
Application Architecture
Infrastructure Architecture
Security Architecture
Adapted from TOGAF
Refer to Phase C of TOGAF and Bizbok for references to the components of business architecture that are used in data architecture.
Architecture Domains
Strategy & Operating Model

13. A financial company aligned architecture decisions to business needs
CASE STUDY
Industry
Source
Financial Services
Anonymous Interview Candidate
Company Profile
An individual life insurance provider and financial services company is looking to improve the value of its applications and ensure its decisions are architecturally sound. This company has cemented itself in the industry, offering insurance products to North Americans for over 80 years.
Situation
In 2007, this company had a business-driven need for a secure platform to share documents across teams. In lieu of an easy- to-use internal solution, employees had been sharing confidential files using Dropbox, noting its simplicity as a collaborative tool. In response, the Chief Enterprise Architect (CEA) decided to implement SharePoint with the following approach:
Align: The CEA recognized the needs of the business and end users: the business wanted to improve collaboration across departments and end users wanted simpler application functionalities and greater accessibility to corporate services.
Assess: The application architecture was reviewed and system complexities and constraints were identified.
Design: Realizing the risks, a simple, small-scale architecture was designed to pilot the new application. The goal was to validate performance and stability of the application before it was rolled out to other areas of the company.
Follow: Lessons learned from this project were integrated into their design process for use in other projects.
Results
The team was extremely satisfied with how SharePoint enabled collaboration and championed the technology with others in the organization, making project buy-in easy to obtain. A team of architects and developers was assembled to scale the technology organization-wide. On completion, collaboration was enhanced company-wide while meeting the business need for secure document sharing.

14. INFO-TECH DELIVERABLE
Use Info-Tech’s Application Architecture Design Template to document and communicate your application architecture
INFO-TECH DELIVERABLE
Leverage Info-Tech’s Application Architecture Design Template to ensure all stakeholders and teams understand the business and technical objectives, benefits, costs, risks, and tasks to successfully enhance your application architecture and improve the value and support of your applications.
Goals:
Ensure stakeholders understand the strategic and operational priorities and quality attributes pushing the organization to enhance the application architecture.
Reveal the architectural opportunities, constraints, and existing issues of the application system.
Discuss the benefits, costs, and risks of architecture solutions and changes.

15. Use these icons to help direct you as you navigate this research
Use these icons to help guide you through each step of the blueprint and direct you to content related to the recommended activities.
This icon denotes a slide where a supporting Info-Tech tool or template will help you perform the activity or step associated with the slide. Refer to the supporting tool or template to get the best results and proceed to the next step of the project.
This icon denotes a slide with an associated activity. The activity can be performed either as part of your project or with the support of Info-Tech team members, who will come onsite to facilitate a workshop for your organization.

16. Info-Tech offers various levels of support to best suit your needs
Guided Implementation
“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”
DIY Toolkit
“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”
Workshop
“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”
Consulting
“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”
Diagnostics and consistent frameworks used throughout all four options

17. Enhance Your Application Architecture – project overview
1. Define Stakeholder Objectives
2. Assess Current Application Architecture
3. Design Target Architecture and Define Design Process
Best-Practice Toolkit
1.1 Understand Stakeholder Objectives
1.2 Clarify Application Functionalities
1.3 Define Quality Attributes
2.1 Document Your Current State Architecture
2.2 Review Architectural Issues, Risks, and Opportunities
3.1 Design Your Target State Application Architecture Options
3.2 Justify Your Architecture Decisions
3.3 Define Your Application Architecture Process
Guided Implementations
Review your understanding of stakeholder needs and scope of your application architecture optimization.
Discuss your interpretation of architecture quality attributes.
Review the current state of your application architecture from multiple perspectives and drive out key areas of constraints and issues.
Discuss the findings of your current state assessment and the impacts they have on architecture quality and value delivery.
Review your target state and the tactical plan and roadmap to achieve this state.
Discuss your justification behind proposed architecture changes from a business rationale, risk, and cost- benefit perspective.
Review your architecture design process.
Onsite Workshop
Module 1:
Define Your Stakeholder Objectives
Module 2:
Document Your Current Application Architecture
Module 3:
Design Your Target Architecture and Define Your Design Process
Phase 1 Outcome:
Current understanding of your stakeholders and their objectives
Defined quality attributes
Phase 2 Outcome:
Current state architecture
Root cause issues driving down value and architecture quality
Phase 3 Outcome:
Target state architecture
Implementation roadmap
Architecture design process

18. Enhance Your Application Architecture – workshop overview
Contact your account representative or for more information.
Workshop Day 1
Workshop Day 2
Workshop Day 3
Workshop Day 4
Workshop Day 5
Activities
Understand Stakeholder Objectives and Define Quality Attributes
Define a set of stakeholder objectives accommodating business and IT needs
Identify objectives dictating the satisfaction of business capabilities to apps
Discuss your interpretation of quality attributes
Document Your Current State Architecture
Understand current development and design standards
Obtain a clear picture of the current application architecture through multiple views
Review Architectural Issues, Risks, and Opportunities
Review of user scenarios and current state architecture views to identify issues, risks, and opportunities
Review current performance of metrics
Conduct root cause analysis
Design Your Target State Application Architecture Options
Develop your reference architecture
Brainstorm solutions to alleviate issues and accommodate new functionalities and opportunities
Design target state architecture options
Discuss changes to development practices
Justify Architecture Decisions and Design Architecture Process
Rationalize changes to application architecture
Conduct cost-benefit and risk analysis of architecture options
Make a recommendation
Create implementation roadmap
Define design process
Deliverables
List of stakeholder objectives
Scope of application architecture
Quality attributes in your context
Current development and design standards
Current state application architecture diagrams
Current performance of metrics
List of root causes behind realized issues, risks and opportunities
Reference architecture in your context
Target application architecture options
Changes to development practices to support target application architecture
Justification of application architecture options from a stakeholder, cost- benefit, and risk perspectives
Implementation roadmap
Architecture design process