{"id":82047,"date":"2009-04-12T21:30:12","date_gmt":"2009-04-12T21:30:12","guid":{"rendered":"https:\/\/www.webstaging.red-gate.com\/simple-talk\/?p=73231"},"modified":"2018-12-12T13:32:00","modified_gmt":"2018-12-12T13:32:00","slug":"requirements-vs-architecture","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/requirements-vs-architecture\/","title":{"rendered":"Requirements vs Architecture"},"content":{"rendered":"<p>Okay, so on the first look this sounds like the most boring Japanese action movie ever. Requirements is tearing through the village, and Architecture is in the city.&#160; Developers by the horde are trying to code both of these into oblivion\u2026Maybe not.&#160; Clearly I am talking about something a little more exciting\u2026the battle between the forces of business and computing, or more precisely, the forces trying to keep them apart. Back in 2000, C J Date produced a book (which I clearly haven\u2019t read) called \u201cWhat, Not How\u201d.&#160; I haven\u2019t read it because as a person who does implementation, my primary care is about the opposite. \u201cHow, Not What\u201d&#160; I would like to think that if the \u201cwhat\u201d was perfectly defined, all we as implementers would have to do would be to translate from business language to machine language, but all to often I find myself involved in the business analysis, either because it is thought that I would be, or because the requirements come to me in terms of how the software will be created (which isn\u2019t usually the way I want it done, which usually does matter, since it is my responsibility to actually design and often do the implementation.)<\/p>\n<p>The thing I tend to find is that one of the most difficult parts of the software implementation process is getting people in the proper roles. As an architect, I find that a lot of times it is expected that I know a lot about the subject matter of the system I have created.&#160; Even worse, when it comes to the creating a new system, it is supposed that I would be able to pick a lot about the system that is being designed (often without it being formally communicated.) There is some truth there, but let\u2019s be honest.&#160; I got a degree in Computer Science, not chemical processes, accounting, or food service\/logistics. Every new system that I might work on is a crash course in learning a new industry.&#160; And to be honest, not always one that I really want to fill my brain with permanently.<\/p>\n<p>However, the person whose role is entitled Business Analyst does in fact have that role to learn enough about a problem in an industry and turn it into a specification. This document is what will be used to create a future piece of software and\/or manual processes (that is for us to decide once the scope of the system has been decided upon.&#160; Their job is to, well, this might sound silly if you think about it, but to analyze the business and \u201cfigure it out\u201d.&#160; This role is one that I feel is essential to the health of a project because they are cleanly divorced from the implementation whereas I as an architect are not.<\/p>\n<p>Put it this way, consider the role of the architect for a building.&#160; Does the architect determine what the house is for? No, for if they did every house would be 100 stories with artsy windows in every room.&#160; I saw a good example of this on the TV Show \u201cHow I Met Your Mother\u201d the other night. Ted (the architect) was told to design a bleak room for the clients new \u201cfiring room\u201d (this was to be a copy of the existing one, just on a different floor of the building).&#160; He wanted a horrible place to can people because he was completely sadistic.&#160; Ted wanted to put his touch, and designed a whole system for nicely letting someone go, including a sympathy room with councilors, and such.&#160; Needless to say he was fired from his job.<\/p>\n<p>As an architect, it is my role to take the business requirements and negotiate a solution that closely resembles what is desired, bending mostly for cases where the desired system, if built in the exact manner of the requirements, would extinguish life on Earth or cost too much (sometimes just the latter.)&#160; Keeping out the influence of implementation during the requirements gathering phase of a project eliminates the \u201cthis is how you do it in this technology\u201d creep. I am a relational designer, and as such I feel I can do anything in SQL (I want someday implement a compiler, much like I used VB to implement one in a college class once. Not my best grade, but it did work.)&#160; I constantly find myself steering requirements toward what <strong>*I* <\/strong>know how to do, and as such find that I tend to miss a few points because I have started designing\/coding mentally even before all of the requirements have been gathered. Of course, in the implementation it is okay to steer towards what you know, as this is how things get done.&#160; Having multiple strong minded people on a team, however, is how great things get done.<\/p>\n<p>A classic example of this for me was when I was architecting the db for a chemical plant product testing system. Materials had to be within a given range or they were considered not shippable. Cool, makes sense, keep getting requirements\u2026must\u2026get\u2026coding. Well, a person who had really thought about their business would have probably realized that \u201cnot shippable\u201d might not always mean \u201cnot shippable\u201d when you are talking about materials that are not medical nor edible. So in the first week of production they go, \u201cokay, so how do I override these requirements to ship this lot of product to client X?\u201d Oops. Maybe if I had spent more time considering the entire process rather than trying to finish up my diagram to generate code\u2026<\/p>\n<p>What do you think?&#160; Can you turn off the \u201cGet \u2018er done\u201d part of your mind when you are doing requirements, or do you find that you really really want to start building software well before you really understand the entire problem?<\/p>\n<p>&#160;<\/p>\n<p><em>Now, before you get all \u201cbut in Agile we don\u2019t gather ALL requirements\u2026\u201d understand that I don\u2019t mean ALL requirement for an entire project.&#160; What I <strong>do <\/strong>mean is as many requirements as possible about the area you plan to implement, and I still mean that if you are the coder that steering requirements toward your expertise is not a great service to anyone but you\u2026well, unless you are really good, then maybe it is okay.&#160; In my example, if we had said \u201cWe aren\u2019t going to implement overriding in this sprint,\u201d the system would have still been unusable.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Okay, so on the first look this sounds like the most boring Japanese action movie ever. Requirements is tearing through the village, and Architecture is in the city.&#160; Developers by the horde are trying to code both of these into oblivion\u2026Maybe not.&#160; Clearly I am talking about something a little more exciting\u2026the battle between the&#8230;&hellip;<\/p>\n","protected":false},"author":56085,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"coauthors":[19684],"class_list":["post-82047","post","type-post","status-publish","format-standard","hentry","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/82047","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/56085"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=82047"}],"version-history":[{"count":1,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/82047\/revisions"}],"predecessor-version":[{"id":82353,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/82047\/revisions\/82353"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=82047"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=82047"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=82047"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=82047"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}