This is a rehash of a topic I posted about back in 2008 but it is just as relevant today.
When you work towards a release or some other looming milestone. There’s that urge to leave stuff behind, cut some corners – you know, just a wee bit, no harm done – so we can ship the damn thing already. Mostly you’d fight that urge. But sometimes you’d want to make a conscious choice to make a shortcut because, well, sometime delivery is more important
A little drop in quality in a single piece of code will not do much harm…for a while. There are, however, two problems with going this approach. One is that it is a slippery slope, i.e. it is probably not just one piece of code that gets this treatment in your code base. The second problem is … Read More »
The last activity of SAF is deployment of the architecture. This step can make the difference between an ivory-tower architect and one whose designs are actually used in real software projects.
Deployment of the architecture actually means two things
Verification and feedback loop. – making sure the architecture is actually the right one.
Governance – making sure that the architecture is followed by the designers and developers
Verification and Feedback loop
It is common practice to think of software development as an iterative process. Knowing that Software architecture is early and that it encompass the important decision which are hard to change, it is probably wise to think of the first few iterations as architectural ones. You would try to work with the team and form the major abstractions, hopefully come up with a blueprint for processes etc. However, the fact that you’ve decided only the … Read More »
Onthe previous post on architecture evaluation I talked about evaluating a candidate architecture in code. This post is dedicated to evaluation on paper.
I remember one system I was working on, I was keen on making the architecture asynchronous and message oriented (it was all circa 2001 by the way) However, I was new on the team and my role (as the project’s architect) wasn’t well defined so I had to do many compromises and get wide acceptance in order to get anything going forward. We set a team to try to come up with a suitable architecture, since each of the team members had his/her own experience we came out of these meeting with more than 20 (!) different candidate architectures (actually there were fewer architecture variations but they were multiplied by the possible technology mappings). Trying to decide which was … Read More »
In SAF – Architecture Evaluation (Introduction) I said there are two approaches to evaluating a software architecture. This post talks about the first approach – evaluating an architecture in code.
The first evaluation-by-code tool is the Proof of Concept (POC for short). Building a POC is about building a minimal amount of code implementing a focused area of the architecture or the architecture’s technology mapping. The aim of the POC is to help weight alternatives (when you are contemplating which way to go), lower technical risks or lower stakeholders’ anxiety over an architectural choice.
POCs map quite well into XPs spikes
Lets look at a few POC examples (examples from my past projects)
Example 1: Validate the feasibility of an architectural direction
On one project we inherited this ugly application incorporating its own proprietary cgi web-server, the architectural decision was to keep this as a black-box and develop the project using … Read More »
I said in “what’s Software architecture” – architecture is both an early artifact and it also represents the significant decisions about the system – or to sum it up “Architecture is the decisions that you wish you could get right early in a project.” (Ralph Johnston*). That is exactly why I made evaluation one of the key steps in SAF. We want to raise the level of certainty that the direction(s) we are taking are indeed the right ones and we will not hit a wall later on. Especially considering most projects these days are iterative, which makes this even more challenging.
But, how do you evaluate an architecture? (on a give set of quality attributes) How can you tell if utilizing, say, SOA, will yield better results than distributed objects ? Is using fault-tolerant hardware better than using a database (on performance vs. robustness trade-off)? and … Read More »
The next step in SAF after Modeling is technology Mapping. While mapping is not a part of the architecture per se, it is, in my opinion, an important and sometime crucial step.
Before I rumble on explaining why I think this is an important step, let me try to define what exactly do I mean by “technology mapping”
Architecture in essence is technology neutral – it describes the major components (read objects/services/components etc.) and their interactions – but it doesn’t specify what technologies and what technologies, products or existing assets will be used to implement it – that’s where Technology Mapping steps in.
For example, in a previous post (Architectural Modeling – First Step ) I presented the following block diagram as a possible view for an architecture (Layer diagram):
One possible technology mapping for this (view of an) architecture is depicted in the following diagram:
Before I continue … Read More »
Ok, so we’ve identifies stakeholders, set principles and guidelines, found out what are our architectural requirements and we want to start modeling already – especially considering architectural modeling is great fun (for techno-geeks like myself anyway). However, before we just start to create an endless flurry of blocks, boxes, arrows and whatnot, it is probably worthwhile to take a few minutes to think which Models we want to create and what views do we want to use to communicate them otherwise we may end up doing a very good job thinking about and describing something that doesn’t interest anyone and gives no real value.
IEEE 1471 defines (an architectural) view as a representation of a whole system from the perspective of a set of concerns (where concerns are the key interests of the different stakeholders)
A view is comprised … Read More »
The next step in SAF (after “quality Attributes”) is Modeling. Webster’s dictionary defines “Model” as (among other things) : “3 : structural design; 7 : Archetype ; 10b : a type or design of product (as a car);11 : a description or analogy used to help visualize something (as an atom) that cannot be directly observed” – as I mentioned in my what’s software architecture post there’s no single structure that IS the architecture – this means that we’ll have to look at the architecture from different angles (viewpoints) – for example a block diagram such as the diagram below (accompanied with some documentation that explains it) may tell us something about the layers that will be used to solve a problem it tells us nothing about the business that we are trying to solve.
We need to augment with more views on the system (such as the next diagram) so that we can … Read More »
In previous posts (here and here) it seems I downplayed the importance of functional requirements (vs. quality attributes) on the architecture. Nevertheless the functional requirements do have few important roles in shaping/looking at the architecture. One aspect of the functional requirements role was demonstrated in the scenarios that describe the instantiation of quality attributes within the system. Lets look at a couple of other aspects.
As I mentioned in a previous post no single structure is the architecture – this means that in order to present an architecture it is needed to describe it from several different angles or viewpoints (I’ll spend some time taking about these in the next few posts on SAF). One of these has to do with the domain architecture for the solution. This can include identifying business areas trying to identify services (in an SOA), identifying major components for … Read More »
In the previous post about SAF I introduced the concept of quality attributes. I wrote that using a “utility tree” approach is a very good way to identify, document and prioritize quality attributes. The purpose of this post is to expand on this issue
As I mentioned before, MSF 4 for CMMI improvement make use of LAAAM (developed by Microsoft’s Jeromy Carriere )
) for assessing the architecture (it is used there for assessing the architecture, which is also a good place to use it – but I’ll talk about that when I get to E(valuation) of SAF.). LAAAM also builds on a “utility tree, below are the sub-activities mentioned in the MSF beta bits:
Examine quality of service requirements and product requirements to determine the key drivers of quality and function in the application.
Construct a utility tree that represents the overall quality of the … Read More »