CERTIFIED: ISO 9001 | ISO 13485 | ISO 27001
CERTIFIED: ISO 9001 | ISO 13485 | ISO 27001

Skip the Software Architecture & Design Step at Your Own Risk!

Skip the Software Architecture & Design Step at Your Own Risk!

You are tasked to build the next-generation software platform for your company’s aging flagship medical instrument, or perhaps you are building a new product from the ground up. Business goals are set, preliminary product level requirements are defined, and a proof of concept has been completed. While it’s tempting (and not uncommon) to jump right into software design, a systematic approach at this stage is critical to the overall execution of the project. Not doing so jeopardizes a solid software design, and can also threaten ship dates, market share capture, and overall profitability. Sadly, this critical step is often overlooked, or “glossed over”. This step is, of course, defining a Software Architecture.

All too often there is a significant knowledge gap between the business requirements and what must be done technically to create the optimal solution. To fill this gap there are important questions to answer in order to evaluate the technical trade-offs driven by overall business goals such as time-to-market on the sales side or ROI for the finance people. At Carnegie Mellon’s Software Engineering Institute (SEI), architecture development has been refined to a science. SEI has defined what are called “Quality Attributes” – significant characteristics of a given software architecture. They are considered to be “non-functional” attributes, such as performance, reliability, or modularity. These attributes emerge as developmental questions are raised, for example:

    • What are the driving Quality Attributes for the system?
    • What are the software design constraints?
    • Have you looked past the initial feature set to provide extensibility for future product features?
    • How should you optimally break your system down into software elements to meet requirements, manage complexity, and adapt to change over time?
    • How do you effectively document the architecture and communicate it to the business and technical stakeholders?
    • Where does the architecture stop, and the software design begin?
    • How big is the development effort, what resources do you need, and how will you organize your software team to get the job done?
    • How will architecture alternatives influence, or be influenced by, pure business factors such as market timing or development costs?

Asking these questions will serve to surface those attributes critical to the overall analysis and provide input into the architecture phase.

The Software Architect – a Critical Role

The software development team should have an individual whose job it is to bridge the gap between the business and technical needs. This is the role of a Software Architect.

The Software Architect is well versed in the relevant technologies as well as domain-specific business factors. In order to function as a Certified Software Architect, the Architect must have the ability to communicate clearly and mediate between different product stakeholders to define an optimal architectural solution. This architecture becomes the basis to organize and focus the software team as they design and build the product. The Architect works with the team as they iterate through development to ensure the overall integrity of the architecture is maintained, resolve fine details, and adapt to changing requirements.

Understanding Quality Attributes and System Constraints

Once established, Quality Attributes may include (in addition to those above) extensibility, scalability, security, modifiability, and others. Work on the architecture begins by analyzing these Quality Attributes with respect to the business requirements. While there are countless quality attributes, typically there is a small subset for any given product that are critical to the product stakeholders. This subset will drive the architecture. Frequently, meeting the needs of one quality attribute means accepting a trade-off for another attribute. For example, creating an extensive layering system for modularity can negatively impact performance, or selecting a relational database for performance may overload storage requirements. Determining the resolution of these trade-offs is non-trivial but can be done effectively if accomplished during the Architecture phase. The Architect considers the needs of the various stakeholders and actively optimizes the outcome.

Related to Quality Attributes are System Constraints. Does the product need to use specific hardware or software technology? Do we need to reuse legacy software? Do we need to comply with specific standards or regulations? Will standard hardware be available throughout the product life cycle? Each constraint imposes another decision point for the architecture who must balance stakeholder requirements in order to create the optimal solution.

Considering Current and Future Product Requirements

With the Quality Attributes and System Constraints in hand, the Architect must evaluate initial requirements and also gaze into the crystal ball and account for future features that will be demanded of the product over time. The architecture needs to consider these future features now in order to allow the product to adapt over time without the need to re-design the entire system.

Defining the Architecture

Armed with a clarified picture of the system, the Architect breaks the system down into its constituent elements and documents the relationships between them using various architectural views. These views form the blueprints for the architectural framework of the system using industry standard notations such as UML and techniques such as design patterns.

Typically, the architecture specifies down to the “public” software component interfaces before stopping to allow the detailed design to pick up at that point. The specifics of the individual components are then captured in lower-level software design documentation. Once the architecture is defined and approved by stakeholders, we now have the basis to make critical business decisions regarding the product such as effort estimates, staffing levels, and engineering resources.

The fact is, every software system has an architecture, whether evolved or planned. An evolved architecture determined by circumstance will not meet the full original product definition when complete (note the tire swing graphic above). Alternatively, a planned architecture maximizes the goals of the product, particularly when implemented by a Certified Software Architect.

Ensuring you have the best software architecture requires actively bridging the gap between business and technical needs. While it takes an investment to create an effective software architecture, the benefits far outweigh the initial upfront cost. When created properly, the right software architecture will ensure your product meets customer needs and can be built upon as a strong foundation throughout the life-cycle of the product.

Would you like to discuss Software Architecture? Contact us and a SEI Certified Architect will respond.