Hey everyone! Yes yes, I do realize it's been forever since I've posted, but hopefully you haven't forgotten about this humble little blog-the thing about the ADM role is, it's never a guarantee when things are gonna start popping up like tulips in spring for you to do :D. But I've got a bit more free time on my hands now, so I thought it would be a good time as ever to jump back into this. Let's start discussing the next phase of ALM, which is architecture.
So let's review what should have been done by now: The list, fortunatetly, isn't very long:
I've mentioned before how I like David Chappell's definition of ALM, as it's broken up into different stages; we're still in the stage of ALM known as Governance, where we're making decisions about the application-even if we're not coding yet. So now that we understand what we're supposed to do in our application, it's time to start deciding how we're going to do it.The start of that process is in architecture-
But how does it work? What do you think about when considering architecture?
You may be accustomed to having programs that are just a few files big and their complexity not too difficult-but in the real world that's not always the case. To help you understand, think of an application like a human body-
Maybe not this body...
In your body, you have different parts and organs, and each one has a purpose- lungs help you breathe, the stomach digests your food, the eyes help you see, and the brain does the thinking for you. The different organs interact with each other to get the vital nutrients, oxygen, or data from their surroundings they need to keep you breathing, able to read this blog, and wondering what on earth I'm getting at here.
The point is, software architecture is no different-there are different parts to an application, and each serve a purpose to keep the application functioning-Software Architecture is all about figuring out what those parts are, and how they'll interact.
An example of some layers of an application are as follows:
UI: This would be the front end of the application, the buttons and windows and textboxes you see when you work on the application. This could be in a language like XAML, HMTL, or a Windows Form
Middle-tier: this layer handles interaction between the UI and other parts of the application, to get the user interface what it needs to display, or react to things the user does with the interface.
Data: If the application does something like pull up information about people or save settings, there's usually some data involved-either in a database or in memory, or in an XML file. Either way, it's there, waiting to be dealt with. Some people like to call this the "back end"
While the way an architecture diagram looks varies from place to place, they can essentially look something like this:
As I mentioned, you can see the different layers, each closed off by a box. At the top we have the UI portions (client), then we go into the middle-tier which does the ineraction (Business), and finally, we have the back end, which handles the data (Resource Access Layer). The placement of each box in the diagram, along with arrows or lines indicating how data flows from one layer to the other, represents where in the grand scheme of things, each layer is meant to go-the resource layer in this case is the foundation, and each layer builds on it. You'll often see boxes on the side like this one has, and they typically represent layers or processes that occur simultaneously with the flow of the architecture, but aren't directly involved unless necessary.
I mentioned this before and I'll mention it again-not all diagrams look like this. Some diagrams can show flow from left to right, and others can be web-like with many branches
However, there's more to architecture than just slapping boxes on a diagram-in fact, accompanying most architecture diagrams is a deep detailed description of how each layer of the application works, known as the architecture decisions. This is to assist in further explaining the reasoning behind each decision for the architecture plan laid out, and often times justification for one technology or system design over another. Often times, there are also data migration maps and plans which describe the metadata required by the system and how it travels from one end of the application/system to the other. Depending on which architecture framework you decide to use (TOGAF, MS, and DoDAF to name a few- you can learn about more of them here ), your final design and the accompanying documentation and reasonings you may have for each decision may vary.
Whether or not you're doing software architecture for the first time, here are two tips to help you make sure you're on the right track:
Think about your requirements-Based on your first phase, you've already got an idea of what it is that the applicaiton needs to do-as your make your technology decisions, make sure you're keeping the decision focused on meeting your needs. It may be nice to have this technolgy or that piece of hardware, but make sure that you're not making a decision based on nice bells and whistles, or you may wind up using up too much of your budget too soon. I'm not saying you need to be a penny pincher or cut corners, but just make sure you have a true understanding of why your decisions will prepare your application for what it needs to handle now and in the future.