By Stephen Dougall
For professionals engaged in business or IT architecture, managing a portfolio of applications presents a formidable challenge. The task involves architecting these applications in a manner that optimizes their development and maintenance. Often, these applications fall under the mandate of different teams and architects, leading to a situation where applications within the same portfolio are constructed as isolated silos, each employing diverse and varying architectures. This diversity can significantly escalate the costs associated with development and maintenance, as each solution architecture demands a unique approach. Furthermore, teams are required to master a multitude of technologies and architectures, which requires a huge amount of effort.
Architecting Application Portfolios
Architects dealing with extensive application portfolios face the additional challenge of defining and communicating their strategic vision, guiding principles, and business requirements. It is common that the same set of business and architecture requirements applies to multiple applications.
In many instances, these requirements are derived from laws or regulatory standards, often written in a manner open to interpretation. Compliance with these requirements is of paramount importance, as non-compliance can lead to severe penalties or even halt business operations. Industries with a strong focus on safety and liability, such as pharmaceuticals, aerospace, nuclear, and medical, grapple with these challenges. For example, pharmaceutical production systems must adhere to traceability requirements set by organizations like the FDA (Federal Drug Administration) to track products from production to distribution.
Even when businesses aren’t bound by strict regulatory standards, they often face common requirements across their portfolio. These may include considerations like platforms, technologies, usability, security, maintainability, and testability.
Business Requirements
Business requirements describe what the business needs in order to function effectively. The challenge arises when the same set of requirements is applied to various application development projects, resulting in distinct designs for each project that essentially fulfill the same requirements.
This lack of efficiency over time makes governing and maintaining application portfolios increasingly difficult, as divergent designs emerge. Changes to common business requirements ripple through to all applications related to that requirement, which can become a daunting task to manage when applications have adopted different architectures and designs.
To streamline the management of application portfolios, a common architecture and design that outlines how requirements are fulfilled across different solutions may be required. This can be accomplished through the adoption of a reference architecture.
Reference Architectures for Solutions
Reference architectures come in various forms, often characterized as templates, sets of practices and principles, building blocks, or generalizations. In essence, it serves as the foundation for one or more solution architectures, providing guidance and regulation for constructing them. The reference architecture offers design guidance to facilitate decision-making while also imposing specific designs that must be adhered to.
By considering the common business requirements across a portfolio of applications, a common architecture can be created as the foundation for all applications within that portfolio. Some of the benefits of employing a reference architecture:
- Best Practices – Provides guidance and establishes a common language for solution architects.
- Consistency – Facilitates uniform designs, making applications easier to maintain.
- Governance – Provides a basis for governance, ensuring compliance with critical regulatory requirements.
- Training – Simplifies learning multiple applications from both architectural and development perspectives.
- Documentation – Reduces documentation overhead by describing common designs in the reference architecture.
- Agility – Strikes a balance between standardization and flexibility.
- Quality Assurance – Allows for the reuse of design validation and verification across applications.
Principals for Reference Architectures
When developing a reference architecture, it’s essential to strike a balance between generic designs and those specific to solutions. The goal is to facilitate architects rather than hinder them. The following are some principles that can guide reference architecture development:
- Generic Design: Ensure that designs in the reference architecture are genuinely generic across the application portfolio, avoiding application-specific details.
- Tangible Designs: Maintain a level of abstraction in the reference architecture that makes the design tangible, avoiding overly abstract designs that can be interpreted in multiple ways.
- Evolutionary: Recognize that the reference architecture should evolve with the business and applications, adapting to emerging design patterns and business requirements.
- Significant Design: Include only truly significant designs in the reference architecture to prevent excessive changes that could impact all applications in the portfolio.
Summary
In summary, for professionals in business or IT architecture, a reference architecture provides a fundamental design to address the challenges of managing application portfolios effectively, ensuring consistency, compliance, and efficiency in architecture and development.