Ok, so you've designed this grand glimmering SOA, and you have a few dozens services each assigned to a development team.

As the iterations spans the contracts have to be amended (be that WSDLs, plain old messages, object APIs or whatever) - do not leave the task of changing, aging or maturing to your developers, team leads or anyone else - I strongly believe that the architect, having defined the boundaries between the major components (services in this case) is the one also responsible for the space between the services. Anything that travels this space is in the realm of the architect*

In my opinion, failure to be in charge of the contracts can result in major breakage of the architecture (chatty interfaces, security problems, services dependency to name a few of the possible and likely problems)

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)

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 recently read Weblog Usability: The Top Ten Design Mistakes by Jacob Nielsen  [found via Jeff Tash's IT Scout blog]

The first 2 mistakes Jacob discusses are  missing author photo and bio - since these are relatively easy to fix, I went on and mended the situation. I've added a photo  on the sidebar and I've posted a short bio in a new "about me" section.

Avoiding the other 8 mistakes require more effort - but I think (read: hope) I have most of them covered.

I'll take this opportunity to make a quick note on the architecture posts. I see that there's a lot to say about architecture modeling (oh my, what a surprise). I want to cover SAF at a certain level before I get lost in the details - so if you found SAF interesting thus far, watch out for posts on Mapping, Evaluation and Deployment soon :)