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 sometimes crucial step.
Before I explain why I think this is an important step, let me define what exactly 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, 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 technology mapping is a design activity, 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 ..)?
Besides the obvious answer, it helped me create a nice acronym for the process – being the second M in SPAMMED, Technology mapping can significantly impact the ability to implement the architecture. The wrong mapping can make adhering to architectural guidelines cumbersome and sometimes nearly impossible.
For example, in one of the projects I am currently working on, we decided to create an SOA (surprise, surprise*). We agreed that the various services should communicate using a service bus, and we intended to map that to a messaging product (such as Microsoft’s MSMQ or Tibco’s Rendezvous ). As it happens, the powers (i.e., upper management) decide 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. In this case, the existing solution is a proprietary distributed objects solution developed in-house. We intended to promote message-oriented development and contracts. As a distributed object framework, the existing middleware induces chatty RPC-like contracts (you can read more on RPC vs. message orientation in “Mort gets the message” and a few of the other posts on John Cavnar-Johnson’s blog ). This technology decision implies that the architecture team has to pay close attention** (on a daily level for the initial iterations) to what the designers and developers do 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. To support the implementation of an application server (which we felt was needed), we had to (decide and) develop an independent “entity layer” on top of ArcGIS. Failure to notice 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 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 significantly help promote the product-line approach (examples of additional factors that can help encourage product-lines include domain-driven design or concepts like software factories)
To recap:
- Technology mapping is deciding which products, technologies, and existing assets will be utilized to implement the architecture.
- Technology mapping can significantly impact 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 worthwhile 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 investments for reuse )
I recommend making technology mapping a required step in the architectural process or revisiting the architecture once this step occurs 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 following posts
**I’ll talk more about what happens once the architecture is “released” for public consumption when I’ll coved D- Deployment phase of SAF
