The next step in SAF after Modeling is technology Mapping. While mapping is not a part of the architecture per se, it is, in my opinion, an important and sometime crucial step.
Before I rumble on explaining why I think this is an important step, let me try to define what exactly do I mean by “technology mapping”
Architecture in essence is technology neutral – it describes the major components (read objects/services/components etc.) and their interactions – but it doesn’t specify what technologies and what technologies, products or existing assets will be used to implement it – that’s where Technology Mapping steps in.
For example, in a previous post (Architectural Modeling - First Step ) I presented the following block diagram as a possible view for an architecture (Layer diagram):
One possible technology mapping for this (view of an) architecture is depicted in the following diagram:
Before I continue 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
