Tuesday, July 27, 2010

More thoughts on Solution Architecture

My attempt to define solution architecture steps may have confused the readers and I started to receive more queries and I thought I will explain those in much more detail with examples.

NOTE: I will update this with an example to give more clarification as soon as I get some enough free time from my paid job :)

1) At what point will you decide on architecture pattern(style) e.g., Layers, SOA, REST, MVC ?
As we discussed earlier. There are tiers and different layers in each tier.
For example: At conceptual level itself you should be able to define the different tiers. A two tier, three tier or n-tier application.
The layers are identified at the Logical architecture level. For example in a n-tier app at the business tier I can have multiple layers based on various considerations (design approach, nfr , complexity, reusability etc.) like service layer, component layer, data access layer etc based on the concepts of separation of concerns / class-responsibilty-collaboration etc
SOA is a pattern/paradigm not a layer or tier. REST is a protocol to choose at the technical architecture level.

2) Where exactly are NFRs realised (In Conceptual or Logical architecture).
I would say NFRs are considered at all stages in architecture but the amount of impact of NFR in architecture differ at differnt phases. For example a performance requirement can reduce the number of tiers OR layers chosen for a system at the coceptual and logical levels.
The same performance requirement can introduce a caching layer at the time of logical/technical architecture phase. It can impact the technologies chosen at the tarchitecute phase. Since technical architecture being the pillar of a solution architecture this is where you get most impact and where you get your hands dirty :) Again architectures goes through different iterations to achieve its perfection, so when you define an architecture document for a project, put all your deep thoughts into it but keep it as a living document. Atleast thats what I found in my experience.

3) How exactly do you differenciate between Conceptual and Logical architecture.
I hope I answered this as part of frst question. Still to elaborate, the difference lies in the level of details. You also need to consdier that there are different audience for your architectue. This involves stake holders, other customer officials, business managers, sales team, testers and (the most important audience) developers who need to execute this. So we should be defining architecture at different detail levels for easiness of grasping the architecture for all type of audience. Many of the business audience/sales may not be much intersted in knowing all the layers in detail but may be interested in the conceptual architecture. I am not sure whether this will confuse you more but I would suggest you to compare conceptual-to-logical as a journey from highlevel design to lowlevel design (just to compare design is not architecture always).

Monday, July 26, 2010

Defining Solution Architecture

There are different types of architectures and architects in todays industry spanning from enterprise/solutions/system/technical/application/platform/data architectures/architects. (Architecture is now a very generic term) So the analysis of requirements to architecture differ for each of these cases.

Still let me try to explain the architecture at a solution architecture level as I understand enterprise architecture is still far from my reach :)

By understanding the business requirements and grouping them into modules/sub-systems at a high level we achieve the conceptual architecture. In normal scenarios we will be able to identify the different tiers in the system at this time.

These high level modules/subsystems are further analysed in more detail to get to a logical architecture and at this point we should be focusing on defining the various layers in each tier. This is achieved by identifying the business services, the reusable components that make up these services etc.

Now this logical architecture needs a technology mapping. Which technologies you choose for the each of the subsystems/tiers/layers are identified at this stage and this phase should form the pillar of our architecture. This is where the architecture reflects how the business requirements are transformed to technology solutions. This is where an architects breadth in technology knowledge comes handy and these chosen technologies are where a hands-on architect will increase his depth of knowledge. We also need to consider the non-functional requirements while choosing technologies and platforms. But please also note that non-functional requirements should be heavily prioritized as many of them can be compromised over the duration of a project. I like to call this phase as technical architecture (tarchitecture).

Once you have mapped your business requirements to technology, you need to define a physical view of how these technologies will be laid out and hence we define a Deployment architecture. The non-functional requirements like scalability, availability etc play a significant role while defining this. Whether our components should be co-located or distributed we decide at this stage assuming our tarchitecture supported both :)

So in short defining conceptual,logical,technical and deployment architectures are what i followed from the requirements to solution to delivery. There are more variations and additions and exceptions to these in specific cases which i skipped here and we can write a book to explain all those as we adapt many of our approaches based on each project :)