Buy versus Build

Buy versus Build - always the first question to ask in the planning stage of a project, the answer to which dictates all the activities that follow as well as the nature of the resulting product. There is no cut-and-dried answer, since every situation is different. Buy may intuitively seem to be the most efficient, quickest and cost effective solution, but a good case can be made for Build which also offers efficiency, time and cost benefits.

Some questions to consider when deciding which way to proceed:

1. can the required functionality be found in purchased software or is a custom solution necessary
2. how long will it take to find and procure a known product, versus building a new one from scratch
3. what is the total cost of ownership entailed in building a custom solution
4. what are the options for Build, in-house or outsource
   

How much Software Planning is necessary?

How much planning should be done in software development? That depends on many factors - criticality, complexity, cost and time.

Upfront planning performed before construction begins will always produce a better end result. But how much is essential and how much is too much? If we understand software planning (strategy, architecture and design) to mean creating the roadmap and blueprint of the system, then we can conclude that planning entails high level decision making affecting future activities in the process of construction. Decisions made at any stage in a project that affect prior work (i.e. upstream activities) such as design decisions made during contruction will often have adverse affects overall since they may be made out-of-context, with limited knowledge of the overall system, or for reasons of expediency.

Systems with high criticality (e.g. process control, medical) necessitate sound decisions and detailed plans to produce high quality, mission critical, error-free systems. Complex systems require comprehensive architectures to lay out the big picture and structure the component parts. Low-end web sites under tight cost constraints likely operate under less rigorous and disciplined designs, suitable to Agile methodologies under the guidance of informal strategic planning.

What is Software Planning?

Planning is the activity of "devising a method for achieving an end". With respect to software - it encompasses the strategies, architecture and design of the system to be built.

Our Philosophy of Software Development

Many organizations responsible for software projects fail to appreciate the importance of architecture and design, similar to a failure to appreciate the importance of process and management. Best practices in any human endeavor dictate that planning take place before doing.

The essence of our philosophy for business software development is the principle of planning - identify objectives and consider different strategies. Next devise the appropriate architecture and design patterns. Then build the system.

In the development of business systems, "documenting" architecture and design can be a sticking point in the way that documenting requirements can be a challenge for business groups. Documenting architecture at a high level first using pictorial artifacts, and later drilling down to more detailed technical designs, allows the technical planning to be done up front and in an Agile-like context. Issues can be resolved upstream in the SDLC with fewer errors, lower cost and in less time.

The trick is to encourage the different streams of work and people so that they are mutually supportive and feed into each other, with each workflow contributing to the overall success of the project.

About this Blog

This Blog maintains that the right philosophy is the key to good software development, just like the right philosophy is the key to a good life. More to come ...