I kick this newsletter off with a little exploration of the word “strategy”, in particular in the context of software development. It is such a generic word that I think it would be useful to specify what I mean by it. An understanding of something broad and generic is likely to change over time so this is my first attempt but I may come back and refine what I said.
Let me start with what is NOT a strategy:
- Random actions are not a strategy
- A plan that is not expressed or formulated in any way is not a strategy.
- A strategy where it’s key components are not somehow measurable or teachable to others is not a strategy
- A strategy that can not explain why it leads to certain actions (and not others) is not a strategy
- A strategy that changes and can’t explain why it does is not a strategy
- A strategy that allows actions that go against it is not a strategy
So then what is it?
Wikipedia:
Strategy is a high level plan to achieve one or more goals under conditions of uncertainty. 1
Let’s analyze this definition in the context of software architecture by starting at the end and going backwards.
What are the uncertainties of software?
The most common source of uncertainty stems from entropy. It still amazes me every day how quickly something simingly simple becomes all of a sudden complex and difficult to understand.
Computer professionals answer the challenge of entropy with creating a lot of frameworks, programming languages, design patterns etc. Going one step further, the uncertrainty of software development comes from making the right (technological, design) choice (if there was, for example, only one programming language available (“FORTRAN”), then there would be no uncertrainty in choosing it).
What are goals?
The goal of software can vary a lot depending on the context where it is used (e.g. open-source versus comercial software). In this newsletter, I solely focus on developing comercial software. That means, the primary goal is to meet business goals. Without a functioning business, there is no software. Does the design and architecture of our software ensure that it delivers everything necessary to succeed as a business?
Out of the business goals we can derive functional and non-functional requirements. Being an architect, I write mostly about non-functional requirements or goals
What is a high-level plan?
Now the final missing piece of the definition: what do we mean with a “high-level plan” in terms of software architecture?
“Having a plan” is what most people would think of what makes a strategy.
In software development, a plan consists of three ingredients:
- Specification of requirements
- Research of options and choosing among the options
- Proposing actions that meet requirements and are based on the choices made in step 2)
Requirements can be functional and non-functional, options are technological and architectural design choices and actions are concrete steps to implement software the meets the requirements.
Software Strategy
Depicted what was said we get following diagram:
Business goals define requirements. Entropy and uncertainties motivate creation of options (technological, design, execution) and choosing from those options lead to actions. Strategic planning (requirements + options + actions) helps to meet business goals.
Summary
Taking everything together, I use the word strategy in the context of software development as follows: a strategy consist of strategic planning which is a three step process of requirements gathering, evaluation of options and specification of actions in order to meet business goals in an environment of increasing entropy.