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.

Pages: First |1 | 2 | 3 | ... | Next → | Last