I am working on moving my blog to wordpress and as part of the effort I am cleaning up and rearranging some of my older posts. Since my readership has increased substantially compared with the time I started blogging I think some of them are worth republishing. I think that the series on SPAMMED, my software architecture meta-framework falls under the category.

Overview
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. 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.
• Principles – list Principles, Goals and Constrains. These are the properties you wishyour 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.)
• 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.)
• 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.
• Map – Technology mapping, buy vs. make decisions etc.
• 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
• 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.

Download the SAF introduction presentation (pdf) or watch it on slideshare You can also  read the DDJ article and read all the posts I made on the subject here :

• Getting SPAMMED for architecture
• SPAMMED State chart
• Stakeholders Everywhere
• P is for Principles (and Guidelines and Constraints...) - Iteration I
• P is for Principles (and Guidelines and Constraints...) - Iteration II
• Quality Attributes - Introduction
• Utility Trees - Hatching quality attributes
• Architecture & Functional Requirements
• Architectural Modeling - First Step
• Architectural Modeling - Choosing your Viewpoints
• Modeling - Architectural Styles
• SAF - Mapping -Don't forget the Technology
• SAF - Architecture Evaluation (Introduction)
• SAF - Architecture Evaluation - Evaluation in Code
• SAF - Evaluation part II - the "Formal Methods"
• SAF - Deployment - What to do when the architecture seems stable?

 

A few days ago I was contacted by Lianping Chen a doctoral researcher from the Irish Software Engineering Research Centre. Lianping is doing research on “how to elicit architectural significant requirements” and he asked me a few questions, which I though, might be interesting to a wider audience.

1. Do you agree that architecture design and requirements elicitation are usually in parallel or have a big time overlap? In other words, Architectural design usually starts before requirements elicitation ends, and usually a big time overlap exists between these two activities.

While it seems to me Lianping is thinking mostly about large waterfall (or waterfall-ish) projects. I’d say this is true for all kinds of projects (agile, lean, iterative and waterfall). The tradeoff usually is waiting for some unknown point in time where the requirements will be set, known, approved and whatnot and starting to move forward. Architecture usually needs to start rolling when the data (in the sense of what exactly the architectural requirements are) is incomplete. This is exactly why I think Architecture should evolve over time (see the previous two posts on “Evolving Architectures” – part I, part II).

In my experience, in large projects, it is beneficial for the architects to be part of the requirements elicitation team. It is true some architectural requirements can be derived from “pure” functional requirements. However most of the architectural requirement can (and in my opinion, should) be formed  by a deliberate effort. I personally, like the scenario based approach of  creating a utility tree. Note that this does not contradict the point above, which says that some of these requirements will probably be off of the real requirements which will surface during the project.

2. Do you agree that when perform architecture design, making some decisions depends on the outcome of some other decisions? I other words, a sequence/order exists for the set of architectural decisions need to be made.

Yes some architectural decisions depends on others. For example, technological choices can change other architectural decisions – after all technologies usually come with their own set of architectural decisions made by the people that created them. On the other hand, it is important to understand that some decisions can progress or be made  in parallel as well. For example, UI architecture design can progress and form while the distribution architecture is still being debated.

3. Do you agree that, in most cases, for a particular architectural decision, only a mall portion of the whole requirements actually influences the decision making? In other words, there is mapping exist from the architectural decisions you need to make and the requirements required when you make those decisions.

Right, most of the functional requirements drive design and the implementations. Only a relatively small part of the requirements drive the architecture.

4. Do you agree that requirements engineers usually do not know clearly what items/aspects of requirements are architectural significant (i.e., it is not easy to distinguish architectural significant requirements from normal non architectural significant requirements)? Thus, they may ignore/miss some items of requirements (some of them may just look like trivial details) that are actually architectural significant during their requirements elicitation.

Yes, this is natural. “Requirement engineers” (or product owners in agile projects) are mostly concerned with the business aspects of the system  - and rightfully so. It is important to have architects involved in analyzing requirements. Also, as I mentioned in a previous answer, it is even more important to have architects work with the different stakeholders (req engineers included) to specifically elicit architectural requirements. Sessions dedicated to quality attributes and forming them as scenarios in the system can help bridge this gap (the scenarios provide the connection to the functional reqs, and architectures are build around quality attributes)

5. Do you agree that requirements engineers usually are not aware of which items/aspects of requirements are required urgently by architects and which items/aspects of requirements can be scheduled a bit later to elicit? Thus, they may first elicit the requirements required for making the decisions in the tail of the decision making sequence, and schedule the elicitation of requirements required for the architectural decisions in the front of the decision sequence to the end of the requirement elicitation phase.

I am not even sure architects are fully aware which items and requirements are important :)  . In any event, as mentioned above,there are basically two types of architectural requirements. The first kind is requirements that can be elicited by direct, intentional analysis of the system from quality attributes perspective (thinking about scenarios where security, availability, scalability etc. come into play). For example in my current system (xsights) one requirement under extensibility – effort to change (data) we have the  scenario “Under normal conditions, refreshing the system’s data (links, interactions etc.) shall not require a system restart.”

The other type of architectural requirements  are derived from functional requirements i.e.  specific functional requirements whose implementation can have significant implications on the system. For example in a previous version of our system we had the requirement to handle 3G video call. Components that participate in this need to be stateful (as there is constant streaming of video in and out)

The conclusions are that, again, architects needs to be involved in the requirement gathering effort; architects need to lead specific session(s) that involve eliciting requirements based on quality attributes analysis. Architectures need to evolve over time as requirements significant to the architecture may (and a lot of times do) pop up during the development effort

6. Do you agree the following statement: If the requirements engineers are informed of what items/aspects of requirements are required and when they are required by the architects for making architectural decisions, the requirements engineers will be able to properly schedule their requirements elicitation activities and elicit the required requirements in enough detail and precision. So they will have higher chance to provide the required requirements to the architects before the architects make those architectural decisions.

Yes to some extent, but architects involvement as mentioned above, would probably yield better results (in my opinion of course)

7. What are the main issues in eliciting architectural significant requirements? What researchers can do to solve these issues

I think I already answered that – but if not feel free to ask for clarifications

 

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 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 better visualize and convey the architecture of the system.

 

 

 

IEEE 1471-2000  "Recommended Practice for Architectural Description of Software Intensive Systems"  defines the relationship between the Stakeholders, their concerns, viewpoints, views and models:

(IEEE 1471 model adapted from a presentation by Rich Hilliard )

 

By the way, the fact that we need to look at the architecture from different viewpoints doesn't  necessarily  mean that the documentation isn't just POW("plain old whiteboard") - The formality of the documentation is driven by the project style (agile/formal) and other stakeholder constraints (company standards, customer requirements  etc.)

 

Since models participate in views (which in turn conforms to viewpoints -  which address the stakeholder's need/interested in) I consider choosing the views a prerequisite for modeling. Thus, on the next post on modeling I am going to talk a little about choosing views (suggested minimal set,  viewpoint library etc.). Once I'll get that off the table I'll try to talk a little on architectural styles and patterns and follow that with some strategies for dealing with quality attributes before moving to the next SAF phase (Mapping).

 

 

 

 

Rich Turner writes about architecture & change. I agree with a lot of what he says.

I often find myself explaining to stakeholder (PMs, developers, etc.) that the only constant thing in the project is that it is that it is changing :)

 

 

One project I am currently working on,  exhibits this inherent change - For one the  customers don't really know yet what - they want (think) that they would be able to use the exact same solution for a  several very different configurations (ranging from standalone computer to a server farm with dozens of clients) etc. 

What do we, as architects, can do to handle these situations? Well, what I usually do is add a lot of modifiability related quality attributes (see utility trees) these can include requirements for interoperability, adaptability, changeability etc. etc. (An example scenario may be: provided with a verified algorithm,  replacing an existing navigation  algorithm shall take less than 3 man-weeks).

 

While I will (probably) talk a lot more on strategies for handling quality attributes in posts regarding modeling (as part of my SAF posts), SOA (sans hype…) is a good strategy to cope with flexibility (i.e. changing requirements). The explicit boundaries and contract first approach help localize changes  also the resulted loose coupling help to replace, add and remove services easier, Lastly the basing communication on policy helps postponing issues that has to do with the network (QOS, security etc.)

 

 

A completely different angle on the issue of changes -  is that sometimes it can be problematic to allow it, even at the expense of missing some of the customer's changing requirements. An example (maybe the only one) is for critical systems, where a defect can result in loss of lives  (two polar examples are medical systems on the one hand and weapon systems on the other). In order to be able to ensure software safety (Identifying hazards, proper fault tree analysis etc.) there's a need to affix the requirements for longer periods compared with other types of projects.

 

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 a component based architecture, or even identifying major use cases in a "use case view" (as part of a Unified Process 4+1 approach )

 

Listening to "Almost Cut My Hair" by Crosby, Stills & Nash, in the background kinds of brings me to the 3rd area where  I see functional requirements meets architectural decisions. When there are extreme/hard/important requirements there are many times where you have to decide whether to cut your hair and  bend the entire design to answer that requirement (i.e. make that a global decision - hence an architectural one) or satisfy it by a specialized local solution (i.e.  Postpone it to the design phase). For example, I once worked on a system where we identified one area of the solution that needs a (relatively) high update rate (low latency, high throughput for updates coming from an external system, processing it within the system and  all the way to the user's workstation window). While this was both predicted to be frequently used and an essential requirement for the success of the system the majority of the system's functionality did not have these characteristics. The decision I've made was to treat it as a local issue (to be given a specific solution @ design time). (Unfortunately ?) I moved to another company before the project ended, and the architect the followed me took the decision the opposite decision (i.e. to make the solution for that problem an architectural solution for all the system's "entities") - which resulted in making all the interactions within the system (even the simplest ones) asynchronous. I recently  had a chance to see the effects of this decision on the system's schedule, robustness and complexity, well let me just say that the lesson here is that while cutting your hair (making an architectural decision) is not an irreversible decision, you cannot just undo it instantly and it can take quite a long time (=money) to correct things.

 

To sum things up

• Functional requirements manifest themselves as part of the utility tree (as the scenarios),
• It can also be important to view the architecture from the functional perspective
• Significant/important functional requirement should be weighted for their influence on the system's architecture (should they get a local treatment (as part of the design) or affect the system globally)

 

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 application. The root node in the tree is labeled Utility.
• Subsequent nodes are typically labeled in standard quality terms such as modifiability, availability, security. The tree should represent the hierarchical nature of the qualities and provide a basis for prioritization.
• Each level in the tree is further refinement of the qualities. Ultimately the leaves of the tree become scenarios.
• For each leaf in the utility tree, write a scenario. The scenario is in the form of context, stimulus, and response. For example, "Under normal operation, perform a database transaction in fewer than 100 milliseconds."
• Open the assessment matrix template. Enter each scenario as a row in the assessment matrix.

 

ATAM (by SEI) - (another architecture evaluation methodology) talks about a similar process with the addition of prioritization:

 

• Select the general, important quality attributes to be the high-level node
  • E.g. performance, modifiability, security and availability.
• Refine them to more specific categories
  • All leaves of the utility tree are “scenarios”.
• Prioritize scenarios
• Present the quality attribute goals in detail

 

This post is going to cover writing the scenarios, their prioritization and what's missing from both these methods (since they are evaluation methods) - ways to help us identify which quality attributes to use in the first place.

 

First, before we delve too much into details, here is an example for what the end result might look like (taken from http://www.akqit.ch/w3/pdf/bosch_atam.pdf - I am trying to see what I can publicize from project's I've been involved with - but I guess this will have to be later, i.e.  in a separate post)

 

It is hard to explain exactly how you would go about eliciting the quality attributes and their refinements (I think that the best way to do that would be through a workshop - but it's hard to do that over a blog :) - it does, however, include the same techniques you would use to elevate any other requirement -either by building on your past experience from similar systems but  mostly by working closely with your stakeholders:

• Interviews - meeting with individuals stakeholders to discuss their view of the system
• Brainstorming - meetings with multiple stakeholders trying to come with attributes and scenarios
• Reading written requirements (if available) - e.g. RFPs, use cases , project risks document etc.

 

To help with the elicitation, I'll try to give you some list for the first two levels (Attributes and refinements) that can serve as a repository or checklist when you are working with the stakeholders.

 

I already provided  a relatively long list of quality attributes to draw from to create level 1 of the tree (though the list is not an exhaustive one) in the previous post .

 

For the next level 2 of the tree (refinement) consider the following lists for the common quality attributes (most from A Method?< Analysis Tradeoff Architecture the to Scenarios General of Applicability)

 

• Performance
  • latency
  • deadline
  • throughput
  • jitter
  • miss rate
  • data loss
• Availability -
  • time period when the system must be available
  • availability time
  • time period in which the system can be in degraded mode
  • repair time
  • boot time
• Modifiability / Replacability / Adaptability /Interoperability
  • difficulty in terms of time
  • cost/effort in terms of number of components affected
  • effort
  • money
•  Efficiency
  • Resource X (CPU/Memory/…) usage on average per unit of time
  • Max usage of Resource
  • Availability of resource over time
• Usability / Learnability  / Understandability / Operability
  • task time
  • number of errors
  • number of problems solved
  • user satisfaction
  • gain of user knowledge
  • ratio of successful support requests to total requests
  • amount of time/data lost

 

The scenarios are the most important part of the utility tree, the main reason is that the scenarios help us understand the quality attributes needed, and more importantly, by tying the attributes to real instances in the system the scenarios help make these goals both concrete and measurable.

 

A couple of things that are important to note about scenarios

• First and foremost - Scenarios should be as specific as possible.
• Scenarios should cover a range of
  • Anticipated uses of the system (“use case” scenarios) - what happens under normal use
  • Anticipated changes to (growth scenarios) - where you expect the system to go and develop
  • Unanticipated stresses to the system ("Soap opera scenarios" or exploratory scenarios , pushing the envelop etc.) 

 

 

Scenarios are basically statements that have a context a stimulus and a response and describe a situation in the systems where the quality attribute manifests itself.

Context - under what circumstances

Stimulus - trigger in Use case lingo

Response - what the system does.

 

 let's look at few examples to try to clarify this:

 

• Under normal operation, perform a database transaction in under 100 milliseconds (Use case)
• Remote user requests a database report via the Web during peak period and receives it within 5 seconds (Use case).
• Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week. (Growth)
• An intrusion is detected, and the system cannot lock the doors. The system activates the electromagnetic fence so that the intruder cannot escape (Use Case)
• For a new release, integrate a new component implementation in three weeks. (Growth)
• Half of the servers go down during normal operation without affecting overall system availability (Soap opera)
• Under normal operations, queuing orders to a site which is down, system suspends within 10 minutes of first failed request and all resources are available while requests are suspended. Distribution to others is not impacted. (Use case)
• By adding hardware alone, increase the number of orders processed hourly by a factor of ten while keeping the worst-case response time below 2 seconds (Soap opera)

 

If we take one of these (e.g. "An intrusion is detected, and the system cannot lock the doors. The system activates the electromagnetic fence so that the intruder cannot escape ")

The stimulus - An intrusion is detected

Context - the system cannot lock the doors.

Response - the system activates…

Or another one (Half of the servers go down during normal operation without affecting overall system availability)

Stimulus - Half the servers go down

Context during normal operation

Response - without affecting overall ...

 

 

The last step is prioritizing the scenarios, it is common to use 2 criteria  (though you can use more)

• Importance  to system success
  •  High, Medium, Low
• Risk/difficulty in achieving
  • High, Medium, Low

 

The interesting scenarios (where you would focus) are the ones with high priority (H,H);(H,M) and (M,H) - these will be used as input for the modeling step of SAF

 

I'll try to provide  samples based on my experience in one of the future posts.

 

 

I just found this on the new CodeGallery on GotDotNet (via Brad Wilson's blog). The paper provides for an interesting reading and discusses some of the issues I was going to cover regarding Architecture Evaluation (I will probably blog about them anyway, but that's just because I like to write :) ).

Also note that the document is labeled "Microsoft Confidential." on the first page - I am guessing that the document status changed and they forgot to remove this notice - but it might also mean the document will not be there for long...

 

I read today a post by  David Ing called "An Overly Long Guide to Being a Software Architect" . David talks about different aspects of a software architect - among those things he mention two important soft skills for architects namely Organizational Politics and communications. Two additional soft skills (or competencies) that an architect needs are  strategic thinking and Leadership (There may be some others but I think these 4 are the main ones).

Dana Bredemeyer measures competencies from 3 viewpoints - what you know, what you do and what you are.
For example looking at Organizational Politics

• What you know - Who the key stakeholders are, what they want from the business and personal perspectives
• What you do - Communicate, network, build relations, sell the vision/architecture
• What you are - comfortable with compromise and conflict, able to look at situations from several viewpoints, articulate, patient, resilient, sensitive to power flow within the organization.

Or if we look at leadership

• What you know - yourself
• What you do - mentor others, motivate others, build teams and set their vision, influence decision makers
• What you are - committed, passionate, credible.

Brdemeyer also supplies competency elaborations (levels for each competency and and guidelines on how to advance yourself between the levels) for Strategic alignment, Organizational Politics  and Leadership .

Another interesting source on architecture competencies is a book called "Software Architecture - Organizational Principles and Patterns"   by David M. Dikel, David Kane and James R. Wilson.
The authors detail a reference model of the organizational aspects of the software architecture process (vs. for example the SPAMMED Architecture Framework (SAF) which details the more technical aspects of the process).
The model takes about 5 principles :

• Vision - Deals with the mapping of future value to the constraints on the architecture and how well understood, flexible etc. are the architecture's structure goals
• Rhythm - the predictability and recurrence in the exchange of deliverables between the architecture group and the architecture consumers.
• Anticipation - The extent to which the architects predict, validate and adapt the architecture to changing requirements (as well as technologies, competition etc.)
• Partnering - the extent to which the architects interact with the architecture stakeholders to allow maximizing the value delivers or received by the different parties
• Simplification - achieving the "zen" (clarification and minimization) so to speak of both the architecture and the organizational environment where it lives.

An example for the patterns and antipatterns that relates to Stakeholders (first step of SAF)

• Criterion : The architect continually seeks to understand who the most critical stakeholders are, how they contribute value and what they want.
• AntiPattern - Phone Doesn't Ring
• Pattern - Know Thy Stakeholders
  
• Criterion: Clear compelling agreements exist between stakeholders
• AntiPattern: Lip-Synching
• Pattern: Reciprocity
  

The book naturally continues to describe what these patterns are :).

The important takeaway from this is that while knowing every nook and cranny of "the framework formerly known as Indigo" (WCF) will probably won't harm you -  technical competency alone will only take you so far as an Architect and  you can not afford to neglect growing and working on the aforementioned soft skills .

 

 

 

This is part II of P is for Principles (and Guidelines and Constraints...) - Iteration I

In the previous entry I've said that it is helpful to provide a list of constraints and principles as it helps in limiting the scope of the solution and directing it toward good (and/or required) practices (Architectural, technological or business aligned). However, I also claimed that a simplistic list is problematic - I'll try to demonstrate this through a couple of real-world examples:

 I recently reviewed the software architecture document (SAD) of a rather large software project, I saw that they it is mentioned that the project uses "service oriented architecture" - reading on, I saw the architecture builds on a distributed "shared memory" where every client and server has a full image of all the data entities, further more data entities are intertwined without any boundaries whatsoever. when I asked what's service oriented in that, I was told that the underlying distributed "shared memory" engine provides several services like dissemination, scheduling etc. The point here is that a catchy name can mean different things to different people.

On another project some of the stakeholders mentioned it is important that the solution would have an "Open Architecture" - sound good to me, but what the hell does that mean? based on open standards? promote extensibility (easy to add features)? promote replacability (easy to replace components)? all of the above? something else?

Furthermore if you don't understand the implications behind each of the principles you name -  it gets very tempting to create a "Buzzword Oriented Architecture"- we want SOA, AOP, Software Factories, Smart clients, GRID, fault tolerance and whatnot... (Note - It is recommended to proceed with caution if you see too many buzzwords in your guidelines/goals. You might be trying to accomplish too much and/or you have too much marketing influence).

So what makes a good (or at least better) description for a principle?I currently use the following template:

Name - something easy to remember (e.g. SOA, Layered Architecture etc.)
Description - What does it mean
Rationale / Benefits -  Why do we want to apply this principle
Implications - What does it mean to use it 
Alternatives - What else - What are the other options we considered and why we didn't use them.
Scope/Exceptions - when and where does it apply

Note: I used to use a simpler template (whiteout Implications and Scope) the current version is based on a template by Ilia Fortunov from Microsoft UK. I can explain that further but it will probably be easier to understand through examples - so here are a couple from projects I worked on:

Principle Name: Code Generation
Description:Generate specific implementations and allow users to configure generated code via designers.
Rationale/Benefits: Increase longevity of the domain model (help separate from technical implementation). Reduce bugs via use of design tools.
Implications: Need to "templatize" solutions and develop code generators (need to check commercial solutions)
Alternatives: 100% object orientation and generic implementations. rejected due to tight coupling to technology, performance implications and impact on code readability.
Scope/Exception: Domain entities and any "aspect" related implementation (logging, security etc.)

Note: this is for a solution that has to use .NET 1.1 - had it been for a solution that relies on .Net 2.0 Another option - using Generics  might have been a viable solution

Another example:

Principle Name: Distributed Database
Description: Each site shall have a separate independent copy of the DB and will have to synchronize its data with connecting sites (Note that I use the term synchronize and not replicate - as replication is a specific technical solution)
Rationale/Benefits: The inter-site communication medium is unreliable plus sites has to maintain autonomy.
Implications: The system has to cope with partial data. There's a need for conflict resolution policy. We need to consider idempotent messages for inter-site communications. Need a distributed primary keys management scheme.
Alternatives: Federated database - problematic since (some of the) data will not be available when sites are disconnected. Another solution weighted is a combination of centralized server and "off-line" capabilities upon disconnection - rejected as it would be more complicated (based on past experience) and have high-dependency on bandwidth (for on-line work)
Scope/Exceptions - Database layer and inter-site communication.

The next thing we have to deal with are constraints.As I've said in the previous post constrains originate from the different stakeholders and limit the scope of the solution. To document the constraints in a meaningful way I use the following template:

Name: something easy to remember
Definition: What does it mean
Implications: What does it mean for the architecture? what are the limitations it places.
Scope: where will we feel the impact
Origin: who placed this constraint and why

Again, lets look at a couple of examples:

Name: Use .NET 1.1
Definition (pretty obvious...)
Implications: use tools/products compatible with .NET 1.1; don't relay on .NET 2.0 capabilities (important for the mapping stage of the SAF)
Scope: All the system
Origin: using .NET is a company policy; we need .NET 1.1 since all the existing tools (e.g. ClearCase, XDE) only support 1.1

And another example:

Name: Deadline
Definition: We must have a working deliverable in 5 months.
Implications: Strive to reuse existing assets; try to migrate code from legacy version; try to model (an extensible) simple architecture (don't try to solve everything now - but try to leave flexibility for future growth)
Scope: Mapping stage; Architecture documentation; quality attributes of the solution
Origin: Customer  (time-to-market)

One thing important to remember is that we are not interested in all the project's constraints (we are- only not in this context). The meaningful constraints are those that have implications on the architecture.

To summarize. Principles and Constraints help you limit the scope of the intended solution architecture. Principles are based (mostly) on past experience, constraints must be followed (and are originated from the different stakeholders). Using only a catchy phrase to describe either of these (Principle or Constraint) can prove to be problematic (creates confusion, doesn't really add anything etc.) and it is better to think about the implications of applying the principles and constraints. Lastly, principles (at the first stage) should be taken with a grain of salt - as they may not be suitable for the current requirements - you should be ready to reiterate and update them once you know more about the requirements (The end result would be to have a list of guidelines which are actually used for the solution's architecture).

Both templates (principles and constraints) are available for download on the template section of the SAF page.

 

Whenever you start a new project, even if you think you start for scratch - you don't really start from scratch. You always bring your past experience into the fray. Developing an architecture for a project is not different. the "Principles"  stage of the SPAMMED Architecture Framework (SAF) is about bringing in your "lessons learned" and "best practices" as  baseline rules or starting point for the architecture you are trying to build. laying down a good set of principles will help you limit the scope of the solution and focus on proven tactics.

It is important to note that principles you set should be treated as recommendations - the main reason for that is that they are based on past requirements and experience and not on current requirements.

An example for a principle may be "use layered architecture"  Layered architecture is the practice where you define several level/areas of processing and limit the communication paths between them (common patterns are: layer can talk to the layer just below; layer talks to any layer below it etc. - the important characteristic is that communication is restricted). Layered Architecture brings a lot of benefits especially in promoting flexibility in deployment, modifying implementation etc. some of you reading this may think this is a trivial principle - however, sometimes it is good to put even trivial assumptions on the table, furthermore not everybody agrees that it is always needed see this  for example. Lastly using a layered architecture has its risks for example the different layers can't scale to the same extent you may find yourself with scalability issues down the road. (I'll give more detailed examples for principles in the next post on this subject)

A similar notion to principles, in the sense of limiting the solution scope is constraints. However, unlike principles, these are not recommendations but rather these are limitations you have to follow. Constraints are set by stakeholders (their origin may be company standards, customer standards).There are several types of constraints:

• Technical - limit platform, reuse existing system/solution/component, follow a particular standard  e.g. use Windows, .Net (alternatively use Linux, Java), use Web-services
• Organizational - follow a particular process, availability of the customer e.g. use RUP , MSF, company standard # 15 ..
• Business - time/money (deadline, budget). Another interesting example for this is "application freeze" - when an organization forbids change for a period - something some organizations did just before Y2K. [thanks to Andrew Johnston from www.agilearchitect.org for this one]

So how does it works - well, you bring in your architecture team along with some of the technical stakeholders - go through one of those "brainstorming" meetings and come up with a list - e.g.:

• Build on Open standards
• Reuse
• SOA
• Layered Architecture
• support scale-out
• .
• .
• .

Wait, what's wrong with this picture - well, for one it is too simplistic view (it doesn't say much) and even more importantly it not accurate (i.e. it can mean different things to different people) - on the next post on this subject I will show a better way to document and understand principles along with a few examples from real projects.

 

 

It is not a secret that user involvement increase the success rates of software projects. We can basically look at the architecture as a mini-project inside a project. The users in that case (as my entry on Stakeholders shows (or tries to)) are the stakeholder.

Richard Demers talks about Architecture Control Board (on his smalltalk blog - oh my :) ) as a way to increase the involvement and of stakeholders for large software projects. The idea is to engage as many stakeholders groups as possible on a periodical basis and to set up a review and change board that approves changes in requirement and also review and approve  the architecture (I'll talk more about something similar when I'll get to E - Evaluation in SPAMMED).

Richard lists 13 points in regard to the Architecture Control Board - the most important ones (in my opinion) are

• the ACB set the requirements scope for the architecture (what requirement/quality attributes should be accounted for)
• the ACB  review and criticize the architecture - they don't, however, design it or vote for its correctness.
• the architecture team has final say on architectural decisions (though an escalation path to upper management should exist)
• the documentation approved by the ACB is the ultimate deliverable of the architecture team (i.e. the "Software Architecture Document")
• go read the rest :)

While establishing a "formal" ACB in smaller-scale projects is probably an overkill you may still want to follow some of these tactics on a less formal basis to increase your stakeholders involvement and more importantly cooperation.

 

 

 

It should come as no surprise that the first pillar of the SPAMMED Architecture Framework (SAF) are the stakeholders - after all at least some of these are the people/organizations that are the cornerstone of the software project itself.

What exactly is a stakeholder - EIA 632 , a standard for System Engineering, defines a stakeholder as "An enterprise, organization, or individual having an interest or a stake in the outcome of the engineering of a system".

Sounds good enough to me :) - but before we delve into more details on how to identify these stakeholder, what do we do with that information, we first have to understand why it is important to us as architects. The short answer was already mentioned stakeholders (most obvious examples are Customer, Project Manager) are what makes the project tick. That, however is just the beginning of it. One of the primary responsibilities of the software architect (much like the project manager by the way) is to balance the stakeholders interest to ensure the success of the project. In the SAF sense the stakeholder are important for several reasons:

•  The solution is developed to serve their needs or goals (at least some of them i.e. customer, end users, management)
•  They serve as the source  for constraints (and sometime principles)
•  Their concerns can help elevate needed quality attributes
•  Stakeholders can (and should) help evaluate the architecture
•  The documentation of the software architecture is targets at stakeholders

Several stakeholders are pretty common to any project . The following list shows them along with samples for some of the concerns (or vested interest) they have regarding the project:

• Customer - Functionality, price 
• End-User - Ease of use, performance
• Project Manager - On time delivery, development costs
• Management - Price, reuse
• Developers - structure and dependency between components, interesting technology
• Maintainers - ease of debugging, modifiability
• Testers - Testability, Traceability
• Security Analysts - security
• Project New comers - structure and dependency between components, traceability
• Customer’s IT group - ease of installation, stability

This list is a nice starting point but it is just that - a starting point. There are still a few things we may want to do

• Identify additional stakeholder - sometimes there are less common or obvious stakeholders (e.g. System engineers, shareholders, safety analysts, the general public etc.)
• Map stakeholders relevance - Jaap Schekkerman from  suggest prioritizing stakeholders by power vs. interest. I believe the privatization should also include the (stakeholders) concern importance:
  

• Lastly you may want to document your stakeholders so as not to forget what they are interested in. This documentation can include the constraints they place their concerns (translated into quality attributes) and a list of viewpoint that are needed to satisfy them (i.e. explain the architecture to them). A template for documenting stakeholders is available from the SAF page.
  

 

I've added a new area on the site for the SPAMMED Architecture Framework (SAF)

www.rgoarchitects.com/saf

There's nothing much there (yet...) except links to the blog entries on the SPAMMED process, however, I am going to add there presentations, whitepapers, a workshop etc. in the future (some of these are already under development)

 

Everybody talks about "Software architecture" these days (your humble servant included...) - but what the hell is it?
I mentioned in my first  SPAMMED Architecture Framework post. that Software Architecture "deals with the major components or structures, their relationships and interactions. It encompasses the major (read hard to change) decisions and their rationale and every system has an architecture (even if it is a default one)" - OK sounds nice, but is it enough?

Probably not (If I thought it was enough - I wouldn't have wrote this post...). There are literally dozens! of definitions for what (solutions) Software architecture is ( you can see many of them here). I am not going to quote all of them, instead, Lets spend some time looking at some of the more prevalent characteristics found in most definitions

• Architecture is Early - It represents (well at least, should represent) the set of earliest  design decisions which are both hardest to change and most critical to get right.
• Every system has an architecture - even if it is just a default one (i.e. it can be described using reverse engineering) it still there.
• Architecture is about breaking a system into components and setting boundaries. It doesn't describe all the components - it usually deals with the major components of the solution. Also it doesn't describe the complete characteristics of components - it mainly deals with their interfaces or other aspects that has to do with their interactions.

which brings us to the next point:

• Architecture is about the relationships and interactions of components. Again we are interested in the  behaviors of the components as it can be discerned from other components interacting with it.
• Architecture explains the rationale behind the choices (vs. the choices not made). It is important to understand the reasoning as well as the implications of the decisions made in the architecture since their impact on the project is large. Also it can be beneficial to understand what alternatives where weighted and abandoned (for future reference, when/if things needs to be reconsidered, and for anyone new to the project that needs to understand the situation).
• There isn't a single structure that is the architecture - there's a need to look at the architecture from different directions or viewpoints to fully understand it.

There's a very interesting standard called IEEE 1471-2000  "Recommended Practice for Architectural Description of Software Intensive Systems"  which defines the relations between the system stakeholders and the different viewpoints of the architecture. It serves as a good reference for understanding how to document an architecture - it also means that identifying the needs of the different stakeholders will tell us a lot what views (details of the architecture from a specific viewpoint) we need to have.

• Architecture is the first design artifact where a system’s quality attributes are addressed

Stakeholders are also the main source for these "quality" requirements and It is the architect's responsibility to balance the quality attributes of the system. This and the previous point are the main reason that the SPAMMED process first step has to do with identifying stakeholders  (And I'll elaborate more on this on the next SPAMMED related post - "Stakeholders Everywhere")

Apart for the quality attributes side of the last point - it also basically state that:

• Architecture is design (but not all design is architecture) 

Which raises another interesting question - what's the difference between architecture and design. But this will have to wait for another post as well

 

The architect doesn't talk, he acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!" (17) (The Tao of software architect - Philippe Kruchten)

On the surface - When it comes to agile development the role of the software architect is a little more blurred.

The most obvious aspect where architects is for the technical architecture. An experienced technical architect, can greatly enhance any project by steering the designs into the "best" directions (under the chosen platform constraints). The technical architect can also promote reuse etc.

Additionally while the requirements change a lot and not fully defined, the quality attributes of a system are more stable - if you need performance, then you need performance!. More so,  there are some qualities that are inherent to agile process - for example you want to put an emphasis on flexibility and maintainability - if your developed solution does not have these it is going to do refactorings. Thus, depending on the size of the project you may want to use an architect to help set the ground rules in the first couple of iterations.

Another area where architect involvement can be very beneficial is when you try to scale an agile project a good choice is to try to break the project to smaller loosely coupled projects (see this paper  for example)  - well, this is just  what we (architects) live for...

By the way, few agile processes, define the architect role up-front, one such process is MSF 4 Agile. Note that MSF (Microsoft Solutions Framework) version 4 comes in two "flavors" one that is aligned with CMMI  and the other a (much) more light version, the afford mentioned MSF 4.

 

How does the SPAMMED process fare with an Agile project - (surprisingly enough) I would say pretty well

First of the architect should be hands-on i.e.  part of the development team (most likely the technical lead)

• Stakeholders, you would probably want stakeholders on-site for any architecture related  meeting (just as much as you would want the customer on site for other activities)
• Principles would include things like TDD, Simple Implementations, Refactoring
• Quality attributes would hold Flexibility and maintainability and a couple or so of the important project qualities (performance, availability..)
• For the modeling you would chose very few views and would try to focus on ones that have manifestation in deliverables
  A good example for this is the Application designer  in Whidbey (see screen shot below) - the result of which is the projects structure for the solution

• Mapping doesn't really change
• Evaluation would be focused on proof of concepts and/or skeletal architecture.
• Deployment - well,  being part of the team... you would notice if your decisions were wrong or circumvented

To sum up - yes Agile projects can and many times should use an architect to help it stay on track - hey, even XP has an architectural spike...

 

 

The previous post on SPAMMED introduced the different pillars of the process. This one focuses on their interactions

The state chart below (modeled using Sparx System's excellent Enterprise Architect) shows the possible transitions between the different process steps

Eliciting stakeholders is usually the first step to take - the reason is that stakeholders serve as the base for several of the following steps for example stakeholders concerns serve as a guideline for deciding which views to document during the modeling step.

The next step is documenting principles and goals - which are based on past experience. The real reason however that this step follows the Stakeholders elicitation is that the step also includes documenting constrains, and most of these are set by the different stakeholders (e.g. use .NET/Java because it is a company standard).

Quality Attributes builds on the former two steps, deciding which quality attributes are important and balancing them is based again on the stakeholders concerns and the principles you've set.

You would then follow this with some modeling and then technology mapping.

Up to this point the process has been pretty much "waterfall-like", however after you evaluate your former steps, you may find that you need to revise any of the preceding steps. This is why you want to get here as soon as possible. do not try to complete and "finalize" the architecture and only then perform the evaluation. Developing the architecture, is very much like the other parts of the development life-cycle, and can benefit greatly from a short feedback loop. Evaluating early helps prevent the architecture from being a bottleneck holding all the development process and even more importantly, building too much structure based on false assumptions/decisions.

Deploying the architecture, i.e. releasing it to the designers and developers is the next step (assuming the evaluation was OK). Once the architecture is "out-there", the realities of the chosen technology/product, changing requirements, budget/talent/ time constrains and most likely the mere iterative nature of modern software development will probably still make you evaluate and retrace some of your steps as a result. I believe this refactoring is a healthy procedure -  in the first few iterations (the actual number depends on methodology used, iterations length as well as project size) of your project. Nevertheless if the number of times the architecture has to be reevaluated and changed or alternatively the number of changes is large - it is probably a sign that your architecture is in need of a serious overhaul.

 

General overview of the SPAMMED process for developing software architectures