Analysis

Software is a set of solutions for a bunch of related problems. 

The first step in building software is always to perform an ‘analysis’ of the problems. If you don’t know what the problem is, you certainly can’t build something to solve it.

The point of any analysis is to shed light on all parts of the ‘domain’ (business, industry, field, knowledge base, etc.) that one needs to understand in order to design a workable solution.

For software, any solutions exist purely in the digital realm but usually have various touchpoints back to the physical world. What this implies is that someone needs to look carefully at the physical world, in particular the parts of it that intersect with the domain, to find ways to encapsulate this digitally.

So, if the solution is to automate a specific process that is happening in a company, then ‘all’ aspects of that process need some form of digital equivalence. That equates to finding all of the terminology that intersects the process, essentially all of the verbs and nouns, and carefully defining them. 

The definition of the nouns is effectively a data model. The definition of the verbs is most often the workflows. These two concepts form the foundation of any analysis. 

If you were interested, for example, in keeping track of what bonds where being bought and sold by a brokerage company, then the obvious nouns, or ‘entities’, involved in this would be the ‘clients’, the subset of ‘financial instruments’ (bonds, money-market, etc.) the ‘traders’, ‘salespeople’, etc. As well, since this commerce doesn’t take place in an institution like a stock market, but rather is ‘over-the-counter’ there are various notions of the established norms and practices in the industry that are necessary too. Fundamentally, that all falls back down onto the way the traders ‘talk’ with the clients, the questions asked and the answers given, and the way that the transaction is ultimately processed. 

Oddly, although all of this might seem simple, an industry like bonds, also known as ‘fixed income’, is really old and very nuanced. It’s been ongoing for at least 250 years, so over that time a lot of reasonable and some irrational things have built up. That is pretty much true for all of the domains in our modern society. As an outsider, they might not seem complicated, but internally the complexities have build up over time and aspects of them are often ‘counter-intuitive’. You can’t build a viable solution in one of these domains without a full and complete understanding of the domain; avoiding this will result in a rather useless over-simplified partial solution that will inevitably just makes the problems worse.

And it’s exactly this intrinsic built-up complexity that needs to be captured, fully and correctly, in an analysis. If it was simple and obvious, then it would be easy to whip together a good solution, which oddly given the age of the computer industry means that it would have already been built decades ago. That is, if it were easy, it would be done already.

It’s obviously a lot of work than to take a real problem, iterate out all the complexities, and then use that to design effective solutions. For an organization that has been in the same business for decades, although the technology has been changing fairly often, the core underlying parts of their domain have probably not seen too many shifts. A complex domain also has lots of different specializations, all of which need different solutions, so there tends to be a lot of different, but related ‘systems’ built. 

Given that this has been a huge, ongoing effort for a long time now, it makes the most sense for organizations to find ways of reducing this effort. It is quite costly. From this, it is pretty obvious that if someone did a good, strong analysis, a decade ago, that while parts of it may need updating, going right back to the ‘drawing board’ would be an epic waste of time. This underpins the importance of making sure that any analysis is reusable. That it is in some format that is independent of the system, popular tech stacks, or tools. That it is assembled together so it isn’t forgotten. That is referenceable so the core parts don’t have to be picked out of the long rambling text.

That is, the main and most important deliverable of any analysis is to build up and contribute to a library that contains a full accounting of the real-world models and workflows that evolve slowly for the domain. If that resource exists, the later analyses can leverage the work done initially. It would still need to be checked and updated, but that is far less intensive than finding it all from scratch, for each new system. 

So, it’s pretty clear that the deliverable for any analysis is something that has a life of its own. It’s not just a shallow document that looks at a few details in the domain, but rather it is that set of knowledge that is foundational to the next stage, which is design. When you know enough about a problem, the solutions you create will work better, be faster to build, and will stay relevant for a lot longer.