Software Engineering Institute | Carnegie Mellon University

SEI Insights


SEI Architecture Technology User Network (SATURN) News and Updates

SATURN 2014 The Business of Software Architecture Session (notes)

Posted on by in

Notes by Ziyad Alsaeed, edited by Tamara Marshall-Keim Under N: Acceptance to Delivery in N Hours Umashankar Velusamy, Verizon Communications, Inc. Umashankar started the presentation with a simple question: Are all deliveries the same? Humans take about 9 months to “deliver” babies. Cats and dogs take about 2 months to do so. So not all deliveries are the same. In the software industry, the same thing applies—different deliveries take different amounts of time. However, we tend to apply a one-size-fits-all solution to everything. Umashankar asked another question: Does it make since to wait 2 weeks or even 2 months for something to deliver, when it takes only 12 hours to deliver? It’s definitely doesn’t make sense, Umashankar answers.

From the previous understanding, “Under-N” delivery comes into the picture. Under N is a method to deliver features in an under-N value of minutes or hours. Each person on the team should have clear responsibilities that will help him or her to perform tasks that fit the N boundary. Umashankar gave an example of an ER room. He asked why, in an ER room, nurses and physicians dealing with such critical cases as human lives are able to deliver or do their tasks in terms of minutes or even seconds, while in software, engineers don’t. In an ER room, people have defined processes that help them serve efficiently even though they don’t know what the inputs are exactly. Umashankar thinks that software organizations should develop a framework in which they define N-value templates and include all the changes that can be made within that time window. Then create a governance process to add a capability or task under the N value to insure integrity and quality. Then create a medium where the team can view, invoke, track, add, and manage capabilities. Finally, introduce a supporting structure to create the under-N template fabric (architects, developers, PMs, business partners, QA, and production support). Umashankar talked about some of the solutions to the challenges that a team could face while applying the under-N methodology:

  • The team mindset could be changed by showing them success faster through trying the methodology.
  • People claiming that they are already busy could be shown that by following the methodology they will actually have more time.
  • Flooding of work to the team as soon as the methodology is applied should not happen if the template is clearly defined.
Finally, Umashankar, argued that the methodology shouldn’t affect the quality of the delivered work as long as the template capabilities are well defined and governed. Presentation link: The Costing View of Architecture Eltjo Poort, CGI Architecture is usually a technical job, while costing is financial. The architect’s task is to come up with a wonderful design. The financial person’s task is to figure out how to cover the cost of the architectural design. Eltjo thinks that we can no longer afford to think that way. In a research study, Raymond Slot (PhD thesis, 2010) found that budget overrun is significantly reduced, time overrun is 6 times less, and customers are more satisfied when architecture practices are applied to software projects. So there is definitely a relationship between employing architecture practices and controlling cost. However, most of these practices are only for software and not applicable to the full software package (software, hardware, and service delivery). In terms of time, most architectural practices take from 3 weeks to 6 months to deliver documentation. Eltjo thinks that we should change the architectural deliverables. Instead of looking at architecture as delivering documents, he thinks that the architect’s task is to prioritize architectural design concerns in a backlog and deliver decisions for these items on a continuous basis (agile approach) based on the best-fitting solution. Eltjo then revisited the definitions of architecture from ISO/IEEE and Fowler. He thinks these are good definitions. However, neither considers the costing-avoidance aspect by applying architectural practices. After looking into different practices from different disciplines, CGI came up with the RCDA (Risk- and Cost-Driven Architecture) practices. The most important takeaway from the model is the solution-cost aspect. In the solution-cost aspect, the architect should look into the cost associated with the proposed solution. Eltjo introduced a traceability model from requirements to costing. Moreover, Eltjo showed a diagram that explained how staff (including the architect) should collaborate to come up with the best solution. For example, architects should evaluate their solutions against pricing models developed by business owners. Also, architects along with the project/delivery manager should look into the delivery strategy of the solution. Architects still need to deliver some documentation to the stakeholder, but Eltjo thinks that the usual architectural views are not usually relevant to stakeholders. Therefore, a costing view for delivery and operation is a proper view to develop and communicate with stakeholders. He introduced a template that should help architects reach this goal. Presentation link: How to Incorporate Software Architecture into Your Business Model Tim Kertis, Raytheon Tim’s goal for this presentation was to share his knowledge and experience of incorporating software architecture as a discipline within an organization. The primary job of a software architect, in Tim’s opinion, is to take into account the software project size and complexity. From previous projects (AMEGS Web), Tim showed how size and complexity in network configuration, user interface, computation platform, and data management were very high. He immediately realized that this task goes beyond a software engineer’s capabilities. A software architect’s involvement was necessary—in his case, a program to bring the software engineers to a software-architect level. To introduce such program, you have to make a business case justifying your request. You will have to present your idea to different levels of people (engineers, business developers, and executives). Also, you would have to show cost–benefit analysis to sell your proposal. Moreover, you would need to identify the elements of your software architecture program. When an organization is creating the project software architecture, Tim suggests that it should establish an architecture-review mechanism. Also, defining roles and responsibilities is highly recommended to achieve the best outcome. Tim proposed a software competency model that should improve the quality. Creating a certification program to certify the competence of the organization’s architects is also necessary. Tim suggests that you document all your architecture processes and define the entrance and exit criteria of your architecture procedures. Organize your key architectural decisions, in term of equipment, software technology, development tools, and reuse strategy. In summary, Tim explained that establishing an architecture program required energy and focus to overcome all the obstacles. You should establish a convincing and solid business case to persuade management and obtain the required funding. Also, provide incentives to attract software engineers into the architecture program. Finally, Tim suggested that you tailor his experiences and recommendation based on your organization’s needs. Presentation link:

About the Author

Bill Pollak

Contact Bill Pollak
Visit the SEI Digital Library for other publications by Bill
View other blog posts by Bill Pollak



We welcome comments with a wide range of opinions and views. To keep the conversation focused on topic, we reserve the right to moderate comments.

Add a Comment


Type the characters you see in the picture above.