Guiding Software Principles

The practice of developing software has changed dramatically over the last 20 years. Many of the more traditional management techniques have been updated to reflect recent experience. The driving forces behind this shift have been the ability to develop more features over less time, and as a result, the increased complexity of current software products. Competitive pressures, growing customer influence, constant increases in technology company stock values, and constantly evolving technology have all combined to force organizations to streamline their development process. But above all, the driving factor behind the streamlining of the development process is that too many projects have failed. The motivating goal of today's software developers is to successfully build better software with less money. The new mantra is "Ship the right product at the right time."

For this section, we have compiled a list of software management principles on which to base the development of enterprise application architectures. The principles are not listed in any particular order, because they are all important to a successful application development process. These are the keys to shipping the right product at the right time.

Alignment with Business Goals

Every project must justify its capital resource requirements. The organization's business goals form the basis of this justification. Thus, the vision for each development project is driven by the business needs of the project's stakeholders.

A project's return on investment is not always measured in strict financial terms; the project may provide strategic value to the organization that is difficult to quantify monetarily. However, the business values the project addresses must align with the stated business goals of the entire organization. As the organization's goals change, the project team must reassess the underlying business goals to confirm that the project is still in alignment with the organization's goals. At the very least, the project must not conflict with any new goals.

Because business goals are critical to the project's success, it's not enough for the project team to be technically competent only in the ways of software development. Many a great product has been shelved because it did not meet the customer's business goals, even though it was well-written and technically sound. To prevent this kind of disconnection between product and goals, the project team needs a clear understanding of the business problem it is trying to solve.

Product Mindset

The product mindset is not about shipping commercial software products as Microsoft does, or about developing applications for internal customers. It's about treating the results of labor as a product. Having a product mindset means focusing more on execution and what is being delivered at the end of the project and less on the process of getting there. The application development process is not unimportant, but it should be used to accomplish the end goal and not just for the sake of using a process. Adopting a product mindset means that everyone on a project team feels responsible for the delivery of the product. Everyone's primary job is to ship the product; all other responsibilities are secondary.


In Software Project Management, Walker Royce states that "architecture-first" is the single most important principle of modern software management. Using an architecture-first approach achieves a demonstrable balance between the business requirements, the architecturally significant design decisions, the customer's expected ship dates, and the product's life cycle plans, before resources are committed for full-scale development. Prototypes and proof-of-concept systems can be used to help determine the appropriate design decisions. The project team must make the appropriate trade-off decisions between resources, ship dates, and features, as well as create a product vision that is shared by all project stakeholders.

Design Within Context

Today's complex applications don't exist in a closed environment. Applications interact with business needs, other applications, network and system infrastructure, and data systems. Just as applications involve other systems, current and future systems interact with applications. So applications must be designed to integrate into the entire enterprise environment. Project teams must be sure they understand the product's inherent interaction with and reaction to the environments in which it will run.

Different Languages for Different Project Phases

Using specialized languages for the different phases of development is a well-recognized best practice in the software industry today. For example, various print and electronic forms can be used to communicate business requirements; UML provides notations for stating requirements and excellent design-modeling capabilities; and modern programming languages, such as Visual Basic, C++, and Java, provide robust application development platforms.

Project Success Factors

Each application project has different priorities and must work with different constraints. Just as each project is different, the specific goals that measure each project's success are different. Success cannot be defined for a particular project without first determining the expectations of the project's stakeholders.

Team Approach

Today's enterprise applications are too complex for any one person to grasp completely. Ensuring that all the critical success factors are addressed requires a team approach that assigns critical success factors to different team roles. Assigning ownership of key success factors also significantly improves project success rates.

Individual Commitment to Project Goal

The success of a project team resides in the commitment of the team members to the project's goals. Everyone must agree on these goals and accept success as an all-or-nothing proposition: "We will get it done, period." In addition, team members and the customer must commit to a common project vision—that is, to a clear understanding about the goals for the project. Team members and the customer bring with them assumptions and hidden agendas concerning the project and what the product should do for the organization. To mitigate these risks, the team must commit to the common goal. Ultimately, all members of the team must be working to ship the right product at the right time.

Early Product Demonstrations

The project team must understand the interests of the customer and help the customer identify and prioritize the features of the product, determining which features must appear first and which can wait for a later release.

During the initial project phases, prototypes can be used to give the customer, the users, and the team a better understanding of what the product will do. These prototypes can consist of user screens that demonstrate product concepts and system progression. Without fail, the customer and users will change their priorities or identify new needs after seeing the prototypes. These changes are not motivated by greed, but result simply from a better understanding of what can realistically be accomplished.

During the middle phases of a project, architects and developers can use proof-of-concept systems to test critical designs before large code segments that rely on unproven designs or technology are written.

Finally, during the early stages of the development process, alpha and beta product releases can be used to solicit additional input from the stakeholder community. More importantly, beta product releases address system-integration and deployment issues before the development is completed.

Risk Management

Risk is the possibility of suffering loss. For any given project, the loss can be in the form of diminished quality, increased cost, missed deadlines, or complete failure to achieve the goal of the project. These risks must be addressed, either proactively or reactively. Good project management proactively identifies and manages project risks throughout the entire project life cycle. Managing risks as a formalized process raises awareness of the risks and provides a common tool set that all project participants can use and review.

A solid risk management process:

  • Identifies the risk.
  • Determines its potential impact on the project.
  • Determines the probability of occurrence.
  • Determines the risk exposure to the project.
  • Proactively mitigates the risk.
  • Designates a contingency plan to be followed if the risk materializes.

If effective risk management is practiced from the beginning of a project, the probability that risks will materialize during the late stages of a project is significantly reduced.

Component-Based Development

Mary Kirtland's book Designing Component-Based Applications (Microsoft Press, 1998) summarizes the component-based approach. Traditionally, an application's services have been exposed through application programming interfaces (APIs). The learning curve for a development team to make effective use of APIs is significant.

Object-oriented frameworks are another popular way to expose services, but they also have a significant learning curve. Additionally, object-oriented frameworks are usually specific to one programming language.

Components provide a standard model for packaging services and exposing the services to other applications. These components act as "black boxes," hiding all their data and implementation details. Component services are exposed via public interfaces and a common programming model. As an additional advantage, component models provide facilities to enable communication with components regardless of their development language or deployment location.

Change Management

Each project needs a change control process and system, and committing to the change control process is everyone's responsibility. Developers have used source-code control systems for years, but these systems are typically only revision control systems for project artifacts, such as documents, agendas, functional specifications, source code, compiled code, and so on. Revision control is only part of change management. A change control system incorporates additional steps, such as how changes affect other components, who implements a change and how, the impact on project constraints, and the creation of a new product baseline that includes the change. Following a change control process decreases the entropy of a project.

Product Versions Based on Customer Priorities and Expectations

No matter how fast the project team advances, the market, the technology, the competition, or the customer's business advances faster. Releasing versioned product updates enables the project team to respond to continuous changes in scope, schedule, and project risk. Frequently updating the product allows the team to communicate with the customer as well as collect suggestions for future product releases directly from the customer's use of the product.

The team should deliver a core set of features in the first release and add features incrementally in later releases, until the full vision for the product is achieved. As later product versions are delivered, the product vision can be validated and updated to reflect any changes to business requirements.

After the development team establishes a pattern of making good project trade-off decisions and shipping products, it's important to cycle through versioned releases as rapidly as possible.

Flexible, Scalable Framework

No one process works for all application development projects. A practical process must provide a flexible framework to address the needs of different projects. This process framework should be scalable to large and small projects.

As projects are completed using the framework, a collection of proven best practices can be compiled. These best-practice experiences can improve the development process and increase the likelihood that the right product will be delivered at the right time; in other words, that projects will be successful.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: