Business Analysis - Solving App Development Problems like a Puzzle
The definition of Analysis is, "the process of breaking a complex topic or substance into smaller parts to gain a better understanding of it". I would like to submit a more specific definition as it relates to Software Development and Computer Business Analysis: The process of viewing a defined problem systematically in the hope of deriving an acceptable solution. Let's start with the phrase "a defined problem".
The word problem should not be loaded with any negative connotations. I mean it as a term in logic or mathematics. A problem is just a challenge to find a solution. I also use the word 'defined' in that many people still dream of computers or mobile applications making them more money with less work. The reality is that computers or mobile apps perform quick, successive, and perhaps complex logical or mathematical functions that sometimes lead to people making more money with less work. The computer or a mobile phone is a tool that enables a greater human effort and not a substitute for human effort. Analysis can only begin once the dreaming ends and a specific goal has been defined. The next part refers to using a systematic approach. I would like to spend the bulk of the article on this so let's come back to it. The phrase, "in the hopes of" implies that analysis does not guarantee a solution. The problem of teaching a computer or a mobile phone to read with comprehension is fun to analyze, but as of yet, no one has offered a practical solution. The last part is "acceptable". Given the constraints of time, money, and technology, many solutions are rejected. So the solution must be a good fit.
Now to the systematic part. The original definition defined analysis as break the big problem into smaller and smaller problems until understanding breaks forth. It still leaves a component of magic by assuming smaller problems are easier to solve. While this is true in many cases, the real question is why? What is it about smaller problems that make them easier to solve? In practice, I see two factors:
1) Smaller problems are easier to think about, and...
2) Smaller problems are easier to relate to. Bingo.
It is not about the size of the problem, it is how well you relate to the problem. Recursive analysis is about pattern matching. Think of a large jigsaw puzzle. To assemble the puzzle, all you need to do is find where each piece goes and you’re done. In my family, we hunt for the corners first. In analysis, this relates to the constraints. What are the bounds of an acceptable solution? Next, we look for pieces with a straight edge and connect the corners. Given the constraints of a problem, what are the objectives and how do they relate? I don't focus on what is practical, just what is possible. Once we have most of the straight pieces in place, we start matching. What piece has these colors? What piece has this shape? My wife might call out, "has anyone seen a piece that looks like Mickey Mouse"? What she is asking for is a shape that is roughly circular with two appendages on one side or the ears of Mickey Mouse. Given that she knows the shape of the 'problem', she is looking for a solution that matches that shape. There are specific methods and tools useful to aid in analysis, but the basics are: define the constraints, define the objectives and how they relate, then look for pattern to emerge.
Too abstract? Let me submit a real life example. I was called to speak with a web app development client about a data management system that featured an archival component and a search engine. This company often was involved in legal battles and wanted all emails, instant messages, and text messages preserved for seven years to prepare for litigation. Because the company was quite large, the database was enormous. My role was not to build this, but to address a single concern: "How do we know we have it all"? Because of my background in accounting, email, and low level programming, someone recommended the client speak with me.
Constraints
Must be external of the software used to store and search the data. Must be compatible with the OS and programming languages already in use. Must be completed by a given date (10 months from this meeting). Must not cost more than X dollars (where X was 10% of the cost of the system this subsystem was to monitor. May read the storage database but must not write it in any way. As much as possible, work in isolation from the other team so the solution would not be a result of collaboration.
Defining the corners
May I have a component in the stream that counts the messages? Yes. May I have the documentation as to how the other team plans to capture and record data? Yes. May I have all the record layouts of what they capture? Yes. May I run test data through a version of the system to see the cause and effect? Yes.
Connect the corners
I assume that for each input (by type) there is a predictable number of records written to the database. Is this true? Yes.
Matching the pattern
I know that an audit is three things: 1) Was the given procedure followed, 2) Was the expected result obtained, and 3) Is the evidence to support items 1 and 2? If the input is processed as described in the documentation, the input should yield as specific number of output records. Random samples pulled from the input should have corresponding output records.
Solution
I will write my own hooks to count the messages. I will use the other team’s documentation to calculate how many records they should have stored. I will read the number of record they did store. If they are within a given percentage and they percentage fluctuates above and below the expected number, then we can assume they are saving the right number of records. I will pull from the message stream a small number of messages, add a serialize number to the bottom of the text, and return those messages to the message stream. Then I will use their search engine to find the number I assigned. If there is any number I cannot find, they fail the audit. This process may be run on request or continuously. With a team of two web app developers, I will design and implement this system in six months.
Conclusion
They liked it. I won the contract. They asked me to start work right away. It turned out to be a little easier than I thought to read the database and predict the counts. They decided not to modify the message text. So they dropped the random audit. They did not hire the app developers and I did it myself in nine months. The solution was not really all that complex, but they interviewed about 20 people and only 10 proposed a solution. A few knew how to count messages in a stream. I was the only one the interviewed that matched the audit pattern to their problem.
Most people teach analysis by teaching commercial methods and tools. But perhaps it is more appropriate to teach common problems and common solutions. We should teach patterns and how in combination they yield solutions. It’s not just divide and hope for magic, it is looking for patterns from what we already know.
About the Author
Al Wilgus is a current software developer with more 30 year as a programmer, systems analyst, business analyst and currently works at iTexico as a Senior .Net developer / Team Lead. He holds a Masters in Business Administration and enjoys life in Guadalajara, Mexico. His other interests are electronics, robotics, music and theology.
Post Your Comment Here