You may have read about the guy who after spending 2 years on a Ruby on Rails project switched back to PHP. Without getting into the debate of whether Ruby on Rails is better than PHP or wether Ruby is overhyped (probably - but that doesn't mean it isn't any good either.By the way  it is the same with SOA, but I digress)

Reading his post I saw a few quotes that raised a red flag for me such as:

"But at every step, it seemed our needs clashed with Rails’ preferences. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.)"

and

#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change..

and

Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me.

What these quotes say really is that this guy doesn't know about "Technology Mapping 101". Here is what I wrote about  technology mapping*  about 2 years ago (incidentally that's about the same time this guy started his Ruby adventure :) )

"Technology mapping can have a significant impact on the ability to actually implement the architecture. The wrong mapping can make adhering the architectural guidelines very cumbersome and sometimes nearly impossible."

Every technology or framework has its own architecture. This architecture poses constrains and makes certain things easy (like using the ActiveRecord pattern in Rails) and certain things harder (like not using O/R Mapping ) so, for instance, on the case mentioned above a better technology mapping might have been RBatis (iBatis for Ruby/Rails) which lets you map SQL statements to objects. It is important to note (in Rails case) that one of the core tenets for Rails is preferring convention of configuration when you don't do that you have to work hard(er) - as you are working against the framework

Another problem with the technology mapping here was his point #2. It is a pity he only saw it in after the fact. It can be justifiable to switch everything but you've got to allow this change to occur iteratively. While I generally dislike the software architecture = building architecture metaphor, using it here does make sense: building software for an existing business (vs. greenfield development) is like building a new intersection. You have got to think about building all the detours that would allow the traffic (business) to continue to operate, sure it might run slower in the intermediate phase but it can't stop altogether.

So again, Once you have an architecture that fits your business, take a look at the technology options you have. try to choose the best fit. Whatever you choose - take a look at the implications of that technology and think about the tradeoffs you may find that you either have to adjust your architecture or change the technology altogether - if you don't you might find you waited 2 years of development effort or even more..

---

* Technology Mapping is one of the steps of a set of activities I identified as needed to make sure your have a solid architecture. The activities goes by the acronym SPAMMED and you can read about them more in this article and/or this presentation

 

I won't say anything about my presentations (that's for others to say :) ). The point of this post is just to let you download them. So here they are:

• SOA Patterns (2.14mb) - Takes a look at different strategies (patterns) to solve common SOA pitfalls
  
• Getting SPAMMED for architecture (4.56mb) - Takes a look at the activities architects can/should do when they think about software architectures. The presentation also covers architecture in agile projects.
  

 

I've posted a new paper on the site. Designing a good architecture is not enough. The paper explains how to make sure the architecture is both relevant ands followed throughout the project. You can download the paper directly from here.

 

I've added a new section on the site www.rgoarchitects.com/Papers to allow easy access to all the papers, presentations and articles I published (and will be publishing e.g. I'll add a paper on architect soft skills in a month or so etc.)

 

 

The October issue of Dr. Dobb's Journal is available and with it my article on the SPAMMED Architecture Framework .

 

 

[Edited version of post in DDJ]

Since I have been blogging for about a year now on this blog and now also on the DDJ blog. I think  it is time to try making something with more two-way communications.

Consequently, I am going to run a little experiment for a few weeks and see how it goes.

The idea is as follows: If you have an interesting architectural or design dilemma, drop me an email at ask@rgoarchitects.com I'll pick one issue per week and post (on the DDJ blog) the dilemma (anonymously) plus voice my opinion (and/or suggested solution)--and then everyone else can chime in with their comments and insight which hopefully will shed some light on the subject.

I'd be interested to hear both your opinions on this initiative and, of course, interesting dilemmas you are facing. Again, send your dilemmas to ask@rgoarchitects.com)

 

For those of you who are following my writing on SAF (or the Milestone 1 post for more details) - here is an introductory presentation to SAF (1.2 Mb). I delivered a slightly modified version of this 2 days ago and someone commented he would like to see more information on strategies to deal with quality attributes. I'd be happy to hear any other comments you may have

 

It took awhile but I finally managed to complete describing all the activities of SAF at least at some level of detail.

What is SAF?

There is very little guidance on how one can go about designing/developing an architecture for a software project. The SPAMMED architecture framework (SAF) aims  to help fill this gap. 

 

SAF  is a set of activities that an architect can follow when she sets out to design an architecture. These activities helps the architect to keep abreast of the project's needs and the drivers that affect the architecture.

 

Overview posts:

Getting SPAMMED for architecture

SPAMMED State chart

 

 

SAF Activities

The Activities of SAF include

• Stakeholders -identify the stakeholders   - Anyone with vested interest in the project (end users, clients, project manager, developers etc.) These are the people you will have to explain you architecture to. These are the people that have concerns that the architecture will have to satisfy (or most likely balance). Thus, the fist step is to identify and rank them.

• Stakeholders Everywhere
• Stakeholder Template

 

• Principles – list Principles, Goals and Constrains. These are the properties you wish your architecture to have (or lack) based on your previous experience. Constrains can also come from your stakeholders (e.g. management decided that all project should be .NET, a deadline etc.)

• P is for Principles (and Guidelines and Constraints...) - Iteration I
• P is for Principles (and Guidelines and Constraints...) - Iteration II
• Principles Template
• Constraints Template

 

• Attributes –  discover quality attributes, the non-functional reqeirements, that (once prioritized) serve as the guide for the overall goodness of the system (Performace, Availability, scalability etc.)

• Quality Attributes - Introduction
• Utility Trees - Hatching quality attributes
• Architecture & Functional Requirements

 

 

• Model – model (and document if needed)  the architecture as seen from different viewpoints (list of viewpoints is stakeholder driven). Example for viewpoints include package diagrams, deployment diagrams, DB Schema etc. etc.

• Architectural Modeling - First Step
• Architectural Modeling - Choosing your Viewpoints
• Modeling - Architectural Styles
• Software Architecture Document Template

 

• Map – Technology mapping, buy vs. make decisions etc.

• SAF - Mapping -Don't forget the Technology

 

• Evaluate – Since architecture is the set of decision that are hardest to change it is worthwhile to spend some time trying to evaluate if they are indeed correct before commencing on

• SAF - Architecture Evaluation (Introduction)
• SAF - Architecture Evaluation - Evaluation in Code
• SAF - Evaluation part II - the "Formal Methods"

 

• Deploy – Software architectures are not a fire and forget thing. As an architect you still have to make sure that the guidelines set are indeed followed and even more importantly that the architecture chosen indeed match the project’s needs and doesn’t have to be reworked.

• SAF - Deployment - What to do when the architecture seems stable?

 

Feedback & Future

I would be very interested to hear any feedback on SAF - you can send  feedback to saf@rgoarchitects.com or just leave a comment

 

On the next SAF posts I am going to talk about SAF alignment with development methodologies (RUP, MSF 4, SCRUM etc.) as well as strategies for following or acting upon the activities.

 

 

 

 

 

 

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

1. Verification and feedback loop. - making sure the architecture is actually the right one.
2. 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 (let say) first two iterations are architectural ones, doesn't mean that new non-functional requirements won't emerge during later iterations. Since practice shows us it is (almost always) futile to try to analyze "all" the requirements before we do any design - this is almost bound to happen.

Be ready to monitor the project's progress after the "architectural iterations" to see and deal with any emergent requirements. As the stakeholders (e.g. product owner, project manager and the architect) try to prioritize tasks/requirements from iteration to iteration, hopefully most of the architectural issues would both surface and be taken care of the first few iterations (remember - architectural decisions are the ones that are hard to change…) - but unfortunately this isn't always so. I recently audited the architecture of a project (which has been running for more than a year) where they identifies the need for transactions, but following some stupid 80/20 rule decided that most of the system does not need that (deadly sin #1) and that they'd be able to easily patch it in later down the road (deadly sin #2) - so not enough just to identify a need, you also need to deal with it early.

The first few iterations also serve as a feedback loop on the suitability of the architecture, sure you've tried to evaluate  the architecture both in code  and on paper , but once it is deployed, or used for real - that is its real test. You will probably want to allocate some time to sit with developers and designers and actually see how the architecture is used and the implications of your decisions.

Governance

It isn't enough to design a software architecture, show it off at some architecture review and maybe at product demonstrations. Designers and developers are more than likely to bend your architecture to their convenience - this can happen for a multitude of reasons - for example:

• They flipped the bozo on you  - they think they know better
• They don't see the big picture and they try to optimize locally
• They don't know any better, they just do what they always did
• They believe they are following your design but they didn't really understand what you've meant (or alternatively - you didn't explain yourself very well)
• They cut corners e.g. to meet dead-lines (just to appease the project manager breathing over their shoulder)
• Etc.

When the architecture is compromised, it can definitely  have severe  effects on later iterations and the overall stability/usability of the system. It is important to note that  it may even result in harsh implications for the organization - imagine someone circumvents some auditing mechanisms you've put in place to comply with SOX or Basel II.

What this means for the architect is that she cannot disengage from the project completely even once the architecture is stabilized (i.e. after the first few iterations). Architect involvement is needed for design reviews, maybe key code reviews , on mile stones  etc.

I think it is one of  the architect rolls to act as a "comptroller" and oversee that the project stays on track as far as the architecture goes. Unfortunately there aren't too many automated tools to help with that. DSLs is one direction that may help (look for example at the Guidance and Automation Toolkit here  and here  ). I've also recently saw an application that claims it can enforce and monitor SOA policies on e.g. on contacts (for both Java and .NET). I hope we'll see more of these tools in the future - meanwhile it is up to us, architects, to do that as part of our overall responsibility.

 

 

On the 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 the best option to follow we trying to conduct some sort of a QFD process where several members where in charge of the weights and the rest where in charge of evaluating and scoring the different categories (per option). Like most "design by committee" efforts this also proved a doomed from the start - and the option everybody disliked got the highest score. If you are wondering what happened - we scraped this effort and started from scratch in a more sensible way (which included a detailed prototype) - what's important for the purpose of this post is that it got me thinking that there must  be a better way to do evaluate architectures. Well, a lot of research and several projects later I think that there are few techniques that give much better results.

 

The first methodology I stumbled upon was ATAM (short for Architecture Tradeoffs Analysis Method), developed by SEI.

ATAM is a rather lengthy and formal method to evaluate architectures it requires a lot of preparation and commitment from the different stakeholders. You can get an overview of the process from the following (~130K) ATAM presentation  I prepared few years ago (While this is probably not  the best presentation in terms of presenting it to a crowd (I know better now :) )  it does provide a good overview of the 9 ATAM steps).

 

ATAM is explained in more details in "Evaluating Software Architectures", the book also details two more evaluation methods SAAM (which I'll let you read in the book) and ARID (Active Reviews for Intermediate Designs).

ARID, like ATAM, is a scenario based technique, meaning that as part of the evaluation process you need to identify scenarios where the system's quality attributes (see Quality attributes - Introduction ) occur or manifest themselves. The main idea in ARID is that for each (prioritized) scenario the participants try to draft code that solves that scenario utilizing/following the  design  under test. The results of the effort are then evaluated for ease of use, correctness etc.

There's a good introductory whitepaper on ARID in SEIs web site.

 

Note that ARID is more suited to agile/iterative development (compared with ATAM) since (as its name implies) it doesn't require the architecture to be completed and finalized up front.

 

While I was working for Microsoft, I stumbled upon another evaluation method called LAAAM (which is now a part of MSF 4.0 for CMMI Improvement). LAAAM which stands for Lightweight Architecture Alternative Analysis Method  is also scenario based and like ARID is more agile alternative to ATAM.

 

In LAAAM you create a matrix which has scenarios on one dimension and architectural approach, decision or strategy on the other dimension. Each cell is evaluated on three criteria:

• Fit - how viable is the approach to solve the scenario (including risk, alignment to the organization's standards, etc.)
• Development Cost
• Operations Cost

 

LAAAM was developed by Jeromy Carriere while he was working for Microsoft (he is now working for Fidelity Investments in Boston).

 

SAF works well with all of these techniques, as one of the basic steps is to identify the quality attributes and write down scenarios where these attributes manifest themselves in the system (see Utility Trees - Hatching quality attributes  )

 

To sum things up -

There are several ways to evaluate software architectures on paper - ATAM, ARID, LAAAM and few others (I didn't discuss here)

Scenarios based evaluations help verify quality attributes are being taken care of by the suggested architecture

Paper based evaluations can help reduce the number of options to few (hopefully one or two) leading solutions which can then be evaluated in code (as the previous post on this subject suggested)

 

 

Reading the November issue of Crosstalk I came across an interesting article on managing Architectural dependencies using a Dependency Structure Matrix (DSM) - rather than dependency graphs induced by UML. The article is called "Dependency Models to Manage Software Architecture" by Neeraj Sangal and Frank Waldman"

The article talks about the value of using DSM technique for managing architecture evolution as requirements change (analyzing ANT as an example) - Apropos "Architecture Evaluation",  I think the DSM technique can also be useful in early stages of the architectural design as a way to infer dependencies and to help promote loose coupling

 

 

 

In the introduction to architecture evaluation I said there are two approaches to evaluating a software architecture. This post talks about the first approach - evaluating an architecture in code.

 

POCs

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 a better more scalable architecture (though we still needed to utilize functionality form the C++ server now and then). The challenge to make this happen was to be able to maintain and  pass the session from the rest of the application (JSP, Servlets and J2EE) onto the C++. A (successful) POC that tackled this issue allowed us to advance in the chosen architectural direction, reducing the risk significantly.

 

Example 2: Validate a technology mapping

On another project I worked for (when I was with Microsoft) we analyzed the project quality attributes and found that there's a need for near-fault tolerance (fail-over in 5 seconds or less). The architectural solution that we decided on was to use an active server and a semi-active one (on-line, ready to take over server that constantly applies state from the active server)* - for technology mapping we considered several options (e.g. fault-tolerant hardware ). One of the option considered was using SQL Server 2005 Database mirroring to keep the two servers synchronized (DB mirroring gives you a failover of the DB in about 5 seconds or less). In order to verify this direction I set up a small Proof of concept to verify that this direction is viable. I was told that after I left Microsoft, further investigation of the issues found led to Microsoft's decision to postponed Mirroring for now. 

 

Example 3: comparing alternatives

We wanted to compare MSMQ vs. using an existing distributed object middleware both in terms of performance and usability (is it developer-friendly). We crafted 2 POCs one for each technology which enabled us to compare the two approaches head-to-head.

 

POCs help evaluate alternatives and  lower risk in specific areas of the architecture (and design for that matter). However, POCs will not give you a feel on how the overall architecture  will play together - enter prototypes

 

Prototypes

A prototype is basically a working simplified model of the system. There are many characteristics to distinguish between different types of prototypes (hi-fidelity/low-fidelity, global/local etc.) - let focus on two:

• Horizontal prototype - which models wide aspects of a single layer, i.e. many features with little details. The most common example for Horizontal prototype is a  user interface prototype which is used to test the overall interaction with the system.
• Vertical prototype -Implementing some sub-system or a limited set of features across all layers /modules.

 

The Vertical prototype is useful way evaluating, getting a feel and understanding of how the different components, that makes  the architecture, work in unison without getting bogged down in all the fine details of the system's functional requirements.

 

Example: Using a prototype to evaluate an architecture alternative.

We were getting ready to embark on a rather large project (we did the prototype around the release of .Net 1.0 and the project is still going on…). We wanted to understand the capabilities  and limitations of .NET. We chose a limited aspect of the system (which we considered the most risky), chose some of the designated team-leaders and took an architect from Microsoft Consulting Services to help us build the "by the book" architecture.

We did a very extensive prototype, total effort of 3-4 man-years including all the preliminary work and the post-mortem analysis. We gained a lot of insights on what .NET can and cannot give us out of the box, we understood the limitations of the components we integrated (e.g. ESRI's limitations in displaying near-realtime moving objects) and we  also used the preliminary prototype (which was a performance hog) as a platform for running POCs for other architectural and technological directions. Additionally, once we solved the performance problems, we also used it as a demo for the client.

By the way, this experience also had some additional positive residual effects like, getting the team leaders up-to-speed on the (then) new technology, jelling the core team  etc.

Taking all the information gathered during the prototype we were able to design a better, more robust architecture for the project itself (which the architect, that came after I left the project, managed to mangle - However that's another story altogether :) )

 

I've found that in most cases exploratory prototypes, or "Throwaway prototypes" are more useful as they really let you get to the crux of the matter quickly, i.e. getting all the components connected the way the architecture dictates to test their interactions and usage. Again, the idea here is to focus on evaluating the architecture, not on the implementation details of the overall solution. Nevertheless, once the architecture is more mature you may choose one of the prototypes and evolve it into the actual system (sort of turning it into an architectural skeleton).

 

Architectural Skeletons

Once you've decided on a candidate architecture (i.e. the architecture you want to use for the project) your first iteration or two (This might not be the first iteration as  you may already done a couple or so prototype iterations) should be focused on creating the architecture skeleton.

Architecture skeleton is about implementing the minimal set (bare bones, so to speak) of the project's functionality that is needed to connect all the pieces in a meaningful, integrated way (for example it can includes an implementation of a single thread in a use case or a important story). It is somewhat similar to a prototype, with 2 differences :

• It has to  implement real functionality of the system (though the functionality is, usually, very thin)
• You don't throw it away (hopefully anyway)

 

Most current methodologies (RUP, MSF for CMMI Improvement, XP etc.) support the notion of architectural skeleton (though not using this name). In RUP, for example, you would have the architectural skeleton up and running at the end of the elaboration phase - a running architecture which you can expand and functionality to in the construction phase.

 

It is important to implement a skeleton (vs. starting to implement the different components and try to integrate them later) as it gives you a relatively early opportunity to actually test if your architecture holds, and it is much better to find errors, especially architectural ones, as early as possible.

 

Summary

I demonstrated  3 "tools" to enable evaluation of architectural decisions in general and the overall architecture in particular:

• POC - focused on a specific area
• Prototype - overall architecture with "simulated" behavior
• Skeleton - "barely running" implementation of the chosen architecture.

 

The problem with these approaches, especially prototype and skeletons is that they require a relatively long time as well as resources to implement. We need some additional tools in our evaluation toolset to allow us to focus on architecture alternatives that are most likely to match our needs.

I think that there are such tools, and on the next post on architecture evaluation I will try give my view on what they are and how to use them.

 

---

* other options are active-active and active-passive (e.g. Windows clustering)

 

 

I've been a little busy in the last couple of weeks and unfortunately, didn't have time to blog - to get my self started again - here is a short introductory post on the subject of Architecture evaluation:

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 so on and so forth.  Even if we say that flexibility and the ability to cope and embrace change is the most important trait (read quality attribute)for our architecture   we still need a way to evaluate which approach will give us the most flexibility

The way I see it there are basically two approaches for evaluating software architecture

• In code - as in proof of concepts, architectural prototypes and architectural skeletons
• On paper/discussion based -so called  "formal" methods: ATAM, ARID, LAAAM to name a few

 

I will try to use the next few posts on SAF to elaborate on these issues - where, the next post on SAF - Evaluation will explain and demonstrate the "in code" methods. The post following that, will talk about the paper based methods, and the third post on the subject, will try to contrast the two approaches and  talk about their respective pros and cons

 

---

*As quoted by Martin fowler in "Who needs an Architect"  - which, by the way, provides for a very interesting reading on architecture and the architect's role.

 

I've posted in the past about the importance of stakeholders for the architecture design process (in  "Stakeholders everywhere"). I recently stumbled upon an interesting article called "Understanding Organizational Stakeholders for Design Success" by Jonathan Boutelle that goes into depth discussing both the importance of stakeholders and the process of mapping thier interests and influence (which I also mentioned in my post)

 

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 - a 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 any further, I should probably say that I think that technology mapping is basically  a design activity and not an architectural one. But wait, if that is true, why am I mentioning this as a step in a framework for building architectures (SAF ..) ?

 

Well, besides the obvious answer, that it helped me create a nice acronym for the process - being the second M in SAPMMED,  Technology mapping can have a significant impact on the ability to actually implement the architecture. The wrong mapping can make adhering the architectural guidelines very cumbersome and sometimes nearly impossible.

 

For example, in one of the projects I am currently working on we made the decision to create an SOA (surprise, surprise*). We decided that the various services shall communicate using a service-bus and our intention was to map that to a messaging product (such as Microsoft's MSMQ  or Tibco's Rendezvous ). As it happens, the powers that be (i.e. upper management) decided that there is no room for investing in a new inter-process communication solution and that the project will be forced to reuse the existing solution. The existing solution, in this case, is a proprietary distributed objects solution developed in house. While our intention was to promote message-oriented development and contracts. The existing middleware, being a distributed object framework induce chatty RPC-like contracts (you can read more on RPC vs. message-orientation in "Mort gets the message" and few of the other posts on John Cavnar-Johnson's blog ). The implications of this technology decision is that the architecture team has to closely pay attention** (on daily level for the initial iterations) to what the designers and developers do so as to ensure that the architectural decisions are kept. 

 

On another project I worked for in the past we designed the solution to use an application server (multi-tiered hardware architecture) however the solution also had to incorporate ESRI's ArcGIS which (at the time) only worked in a "two-tier" client/server manner with its underlying data. In order to support the implementation of an application server (which we felt was really needed) we had to (decide and) develop an independent "entity layer" on top of ArcGIS. Failure to notice that the technology mapping implications  would have resulted in the architecture not being implemented (and serious scalability issues for that particular project).

 

The second reason for including Technology mapping in the architectural process is to help promote reuse in projects by making this as an activity at the architectural level (i.e. both early in the process, and making the decision to  reuse a component  a global decision governing the solution).

Making reuse a first-class citizen in the architectural effort can greatly help promoting product-line approach (examples for additional factors that can help promote product-lines include domain-driven design or concepts like software factories)

 

To recap:

• Technology mapping is about deciding which products, technologies and existing assets are going to be utilized for implementing the architecture.
• Technology mapping can have a significant impact on the ability to adhere to the architecture to the point where under certain mapping constraints you may need to reevaluate the architecture (i.e. is it worth-while to go "against the stream" and implement the architecture using a technology/components whose architecture.
• Deciding which existing assets can be reused at the architectural phase helps to create systematic reuse (vs.  opportunistic reuse) which improves time-to-market and solution quality (assuming you carefully choose assets for reuse )

 

I recommend either making technology mapping a required step in the architectural process or alternatively revisiting the architecture once this step occur as part of the design.

 

---

*when you get over the incredible amount of hype around it (I believe) SOA does have several distinct business and technological advantages - I'll try to elaborate more on this in one of the next posts

 

**I'll talk more on what happens once the architecture is "released" for public consumption when I'll coved D- Deployment phase of SAF

 

I claimed in the past (on my "what's software architecture" post) that Architecture is a type of design - if that is true, an interesting question is do we also have architectural patterns ?

 

I think the answer is yes - there are architectural patterns they are also called architectural styles - I actually like this term better as it is helps differentiate them from design patterns; for example I agree with  Harry Pierson's observation  that many of the patterns in Martin Fowler's PoEAA are indeed technical patterns at an engineering or design level and not architectural patterns.

 

The difference between architecture styles and design patterns is similar to  the distinction between architecture and design - architectural styles effect the solution globally or at least it affects major parts of the solution and not solve local issues. Although it is interesting to note that some architecture styles have been well known well before the notion of design patterns for software was introduced.

 

SEI's architecture glossary defines Architecture Style as

"A specialization of element and relation types, together with a set of constraints on how they can be used."

That's a good start but it might be a little hard to understand we can basically say that an architectural style  defines a family of solutions in terms of a pattern of structural organization using a vocabulary of  components and connector types (plus constraints on their use). It is also worth mentioning that different styles can be combined to create compound or derived styles.

I'll try to illustrate what a style is using an example:

 

One of the basic architecture styles is "Layered architecture":

 

The layered style is composed of layers (the components) which provides facilities and has a specific roles. The layers have communication paths / dependencies (the connectors).

In a layered style a layer has some limitations on how it can communicate with other layers (the constraints). Typically a layered is allowed to call only the layer below it and be called only by the layer above it (but there are variants e.g.  a layer can call to any layer below it; vertical layers that can call multiple layers; etc. - as long as the layers communication paths are limited by some rules)

 

You can see the application of layered style all over the place for example: logical software layers (e.g. presentation component, UI Controllers, business processes, business components, data entities, data access layer) , SOA layers (fundamental , Intermediate, Process), physical tiers (e.g. database server, application server, web server and clients)  etc.

 

There are many other architecture styles including for example pipe and filter, push based, peer-to-peer, blackboard, MVC, PAC, or the more recent Adaptive Object Models, REST and SOA (some will probably disagree that SOA is a style - but I'll try to explain why I think it is on another opportunity). I'll try to talk a little about some of them in the next posts.

 

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 of parts of one or more models to demonstrate the how the concerns are covered

A view is (sort of) an instantiation of the pattern defined in a viewpoint (see more below)

 

So for an example if our concerns are concurrency and timing issues looking from this viewpoint can  be looking at the threads and process model of the solution and we can use views like process diagrams and timing diagrams to visualize it.

 

One thing we can do (over time) is to create a viewpoint repository and then when faced with a set of concerns  we can easily choose which views to create.

Rich Hilliard suggests that a viewpoint would hold the following information:

• Viewpoint name
• The stakeholders addressed by the viewpoint
• The stakeholder concerns to be addressed by the viewpoint
• The viewpoint language, modeling techniques, or analytical methods used
• The source, if any, of the viewpoint (e.g., author, literature citation)

  A viewpoint may also include:

•  Any consistency or completeness checks associated with the underlying method to be applied to models within the view
• Any evaluation or analysis techniques to be applied to models within the view
• Any heuristics, patterns, or other guidelines which aid in the synthesis of an associated view or its models

 

If you are just starting out you can turn to various frameworks to see which views they have and use that as the basis of your repository for example:

RUP suggest a 4+1 set of viewpoints:

 

Microsoft is currently moving from the MSF 3.0 model (4 spheres - contextual, conceptual, logical, physical crossed with 4 "views" -business view, applications view information view and technology view totaling in  16 viewpoints) to the following set of viewpoints:

 

Other examples are DODAF (3 main viewpoints with 26 sub-viewpoints), RM-ODP (5 viewpoints)  and Zachman Framework (with 36 viewpoints)

          

         Lastly the software architecture document  template  I've posted also contains a list of possible views

 

 

What about a minimal set of viewpoints? Well, I don't know about a minimal set - there are however few viewpoints that  usually get used:

Some sort layer view (usually block diagram)

A logical view (main classes/packages)

A deployment diagram (tiers, zones etc.)

A view to show concurrency and timing issues.

On SOAs there's also a service view (services, policies)

 

To wrap-up -

• Choosing which views to create (viewpoints) is an important step before embarking on modeling.
• Viewpoints are chosen according to the stakeholder's concerns (to help make sure the concerns are addressed and to communicate the architecture better).
• Growing a viewpoint repository is a way to reuse your knowledge of concerns to views mapping.

 

 

I've added a sample skeletal  template for a Software Architecture Document  on the SAF page.

 

Few notes on the template:

• It is based on formality level required for large safety critical projects - most projects do not need this level of formality and can (and should) do with fewer views
• When there isn't a specific requirement by the customer to create an "official" architecture document - you probably want to have it just barely good enough
• The view list in this template is not an exhaustive list - these just the views I've used most often. (more on views on the next post :) )

 

 

Any feedback (either as a comment or to my email) is more than welcome

 

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