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:

• Gathered requirements for the application

Told you.

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...

Source:http://www.reviewexplorer.com/news/8511_da-vinci-robot-cracks-wishbone-in-operation/

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:

Source: http://msdn.microsoft.com/en-us/library/bb190164.aspx

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

Source: http://www.objectivity.com/cloud-computing/link-analysis-in-the-cloud.asp

Source: http://www.eventhelix.com/ThoughtProjects/AutoDrive/architecture_design.htm

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.

•  End-User Quality- these checkmarks make sure that your deisgn will make the end users of your applicaiton satisfied- things like performance, reliability, security, usability, and globalization. Do help with this, ask yourself these questions about your design: Does the architecture allow for reasonable applicaiton speeds for yor user? How quickly are the technologies in your proposed design capable of recovering from some form of downtime?  How difficult is it for unauthorized users to get to valuable information? If the design is for a large project, can others in the same area or across the globe easily access and use the application/system?
• Development Quality- Odds are this first version of the application is not the last and ultimate version. You'll need to make sure that you're designing your system so that future developers are able to build upon it now and into the future, so here you'd aim for Maintailability/Extensibility, Flexibility/Modularity, and Testability. Ask yourself: Is this design going to be maintainable? How easily can developers add their own pieces to it, or have other technologies attached to it? Are the components of the design able to communicate in different configurations, and are they independent enough that they may be included in another application's design (this is to check for modularity, another term for this in the biz is that your components are 'loosely coupled'-they're pretty independent of each other and can be used elsewhere)?
• Operational Quality-It's nice when you make people's lives easier, especially those of IT Professionals, who will have to maintain your architecture, so it's good to check for scalability by knowing How many users, pieces of data, etc can this architecture scheme handle and if it could be modified to handle more. Supportability is also important, so try to understand much effort will it require to support and fix issues in an application or system built on your design. You should also check for Interopability, meaning of this design play nice with the other applications/systems in your business' environment now and later on as other applications or systems are added. Finally, check for portability if needed, meaning can the design be applied to other platforms or systems without too much hassle.