I had an interesting e-mail thread with some folks here at Microsoft talking about delivering content for architects and thought I would share.
What was interesting about the conversation was that sometimes folks blur the perspectives of looking at a products architecture vs. looking at a solution architecture. All too often we combine the two as if they are the same. I think we need to separate out the two very important perspectives. I am referring to the notion of Product Architecture and Solution Architecture. While they are similar they are actually worlds apart.
Let’s take a look at each of them:
Product Architecture (PA) – Examines the detailed architecture of a specific vendor product such as SharePoint. This perspective is looking from the product outwards. Usually you will see this type of architecture perspective when evaluating a technology as a platform for multiple solutions, RFP like processes, etc.
Solution Architecture (SA) – Takes the business problem and derives to a technology solution that may encompass one or more products and services. Key concerns for this perspective are that the technologies align to the business problem, non-functional requirements are meet (quality attributes of an architecture such as reliability, security, etc.) and IT fit for that specific organization.
As you can see it’s all a matter of perspective and what viewpoint you are standing at. For most architects in enterprises they will start from the SA perspective first then once they know what technologies they want to employee then the take a deep dive into PA. Unless of course, that the product is mandated or already chosen for the architect, which is known to happen from time to time…
For software vendors such as Microsoft I think it is important to clearly understand the types of architects and subsequently their needs. One way is to build a set of scalable scenarios that architects commonly face. Somewhat like a cookbook that has 3000 different ways to cook a turkey. In this case maybe Microsoft SharePoint is that turkey and there are 3000 ways to build solutions (i.e., cook) with it.
An example of this would be to derive to specific recipes in that cookbook. You may want to start with a common theme that would then lead to a set of scenarios and in turn would have solutions or implementations associated.
Theme –> Scenarios –> Implementations
These scenarios would obviously not apply to every problem or subsequent solution, but if picked right, they can “scale” into other topic areas. This could be a great way to lead off into other aspects.
For the Enterprise Architects (EA) have much different perspective, while they ask the question of “why”, they also ask all the others as well. The difference here is scope and context. I talk about this a bit with customers and it resonates very well. This maybe a familiar graphic that shows this terms of breadth and depth:
It turns into a whole new set of questions at that level of abstraction. While the solution architect is worried about specifics around the solution itself, the EA’s are looking holistically in the enterprise. Questions like:
How well does this align with business imperatives?
Does this platform or solution fit into the technology roadmap of my organization?
How well does it align with what our engineers and architects know? Will we have to re-train, re-tool, etc.?
Can we reduce the number of similar systems that do the same thing?
While both of these perspectives are important and need to be understood, careful consideration needs to be placed in tailoring guidance to this audience. It’s not about giving them a set of raw building blocks but rather the context in which these building blocks apply. Architects of all flavors will not only need to know the detailed design of a solution but will need to understand how it impact the business, their IT fit and if it reduces complexity in their enterprise.
What are your thoughts?
Comments