Enterprise Services
Showing results for 
Search instead for 
Do you mean 

The Three Peaks of Solution Definition

‎06-24-2013 04:26 AM - edited ‎09-30-2015 06:57 AM

By:  James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company


Author’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.



The theme of the March/April, 2013 issue of IEEE Software was “Twin Peaks of Requirements and Architecture”, in which several articles discussed the iterative interaction and dependencies between requirements and design. The Twin Peaks model is presented as two triangles (‘mountains’) in which the level of detail increases over time. One triangle represents the requirements as they are exploded to lower levels of detail. The second triangle represents the architecture (solution design) which is progressively refined in parallel with the increasing level of detail in the requirements. A bi-directional interaction loop occurs between the two peaks. The Business Analysts (BAs) supply the Architects with the requirements specifications, and the Architects incorporate these requirements into the solution design and provide feedback on the requirements. The Architects may also prepare alternative candidate architectures for consideration.


In a previous blog article, I discussed Leveled Requirements Setswhich made the point that to avoid analysis paralysis and defective detail in requirements, BAs need to progressively refine requirements through scope statements, business requirements, and system requirements. This leveled approach for developing requirements supports the Twin Peaks model.


However, the Twin Peaks model needs a third peak. It is almost impossible to maintain balance on a two-legged ‘‘stool’ and it is difficult to get the four legs of a chair to be perfectly level, but a three-legged stool is very stable.  Well-run projects are like a three-legged stool and optimize three key dimensions: time, cost, and quality. Likewise, well-run projects need to have three peaks of integrated and progressively detailed requirements, designs, and plans. The missing third peak is Project Management.


Initially, the lead Business Analyst, lead Architect, and the Project Manger need to work together to define the project scope. BAs capture functional and non-functional (e.g., performance, data security, etc.) requirements for the users. These will be supplied at varying levels of detail.  For example, one user will say, “We need a new payroll system.” and another will say, “I need a column added to the x report.” The BAs need to abstract and structure these initial inputs into a set of high-level scope requirements for the project.


These scope requirements then guide the creation of the initial solution design. The architects will include components to meet the non-functional requirements (e.g., with sufficiently powerful servers). However, they can often also meet functional requirements with COTS components to replace a custom build of parts of the solution. The PM has to continually interact with the emerging scope requirements and design to ensure that delivery time, cost, and feasibility are being considered. The PM may determine that some of the requirements and designed components need to be excluded from scope or given a lower priority and moved to subsequent releases.


Once the scope is approved by the client (a user stakeholder, the PM can finalize the high-level plan for the project.  The BAs, Architects, and PM then work together on the next iteration, at more detailed level. The BAs produce the business requirements—fleshing out the in-scope requirements. These requirements can be used to drive COTS component assessments, refined solution designs, and group functionality into iterations and releases. The PM has to constantly ensure that the more detailed requirements are in scope and that the emerging solution design remains within budget. This is usually the point at which the PM must manage client expectations.


After the business requirements are approved, the final project plans can be prepared (with sub-plans for each release and component). For example, one sub-plan may be required to define the system requirements (e.g. use cases and user interface specifications) for part of the solution which will be custom built. Another sub-plan may cover the specification of the detailed requirements and development of scripts for configuring a COTS component. A third sub-plan may detail the build-out of the network and the test and production servers.


The Twin Peaks model for requirements and architecture is a good way to understand solution refinement. But it needs a third peak added—the project management peak—if a project is going to be a success.


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



Blogs in the Producing Quality Software series by Jim Hughes


Other blogs by Jim Hughes:


About the Author


Image for Blog.jpgJames (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP.  He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards.  Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall.  He currently lives in Toronto, Canada.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He lives in Toronto, Canada.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Aug 29 - Sep 1
Boston, MA
HPE Big Data Conference 2016
Attend HPE’s Big Data Conference to learn from peers in every industry and hear from Big Data experts and thought leaders in an exciting, energy fille...
Read more
Sep 13-16
National Harbor, MD
HPE Protect 2016
Protect 2016 is our annual conference and is the place to meet the world’s top information security talent, discuss new products and share information...
Read more
View all