Skip to main content

Architectural documentation: Views makes things clear

When Architects are involved in the definition of architecture, it is also their responsibility to represent it in such a way that all the audience understands it very well. This is more important when architects are involved in selling the proposed architecture of a solution as part of pre-sales process. They have to present concrete justification points to the potential customers to make them understand why their proposed solution architecture is best. When the solution presentation happens, it may involve various high level stakeholders from business, IT, technology etc. Same is the case when IT of an enterprise is pitching for an imitative or a new project; unless business is convinced, IT will not get a “go” signal and budget allocation.

The target audience of architecture can be categorized into two:

1. High level stakeholders like CIO, CEO, CFO, EA etc from business & IT who influence decisions significantly
2. Medium / Low level stakeholders like Tech. leads, developers who will actually help in realization of the architecture. It may also include other fellow architects from various technology domains like security, performance.

Unless the Architect who is responsible for an application’s architecture is able to document the architecture in such a way that it is clear for the above categorized audience, it will not move anywhere. Depending upon the target audience, architecture needs to be documented either only with the high level details or accurately in a very detailed manner. High level stakeholders (as classified above) many not be interested in the details of the architecture related to its implementation whereas developers & tech. leads will be very much interested in it. So, based on the target audience, it is the duty of the architect to use appropriate views & models.

There are various models & views used by the industry to help the architects in effectively documenting the architecture. Generally adopted views / viewpoints are Conceptual view, logical view, technical view & physical view. There are no industry wide naming standards or taxonomy related to documenting architecture. Some enterprises use the names like logical architecture, deployment architecture, conceptual architecture, etc to document architecture. Some even use business architecture, functional architecture (!) without knowing what content to put under such headings. Point here is that irrespective of views / naming standards that is used, architect should be aware the target audience & their expectations before planning for architectural documentation. Unless an architecture is flavor with various appropriate views / viewpoints in its documentation, it will not be clearly understandable by its audience. It’s like some blind men touching a hug banyan tree and making their own impressions about it.

In addition to 4 + 1 view as recommended by rational (which is in general followed by practicing architects), architects should use additional views / viewpoints based on the target audience. For example, it an architect is defining architecture for a complex system where security is considered as highly important quality, than that project may have a dedicated security architect. May be even in that case, there could be a demand from business & IT to get the architecture evaluated by security domain experts. In that case, architect should use Security view, in addition to other standard views.
Point here is that architect of architecture should use appropriate views / viewpoints / models for documenting architecture so that the target audience gets more clear understanding of the architecture from their domain perspective. If not, it will lead to more ambiguity & mis-interpretation and more room for conflicts.


DTG said…
hi there. technology is just a tool to enable/solve business problems. Rather than address architecture presentations to the audience, problems at the diff levels are what should be attacked e.g. if a COO says time to market for new products is a major issue for him in his rapid market, the ppt should say how the proposed architecture resolves that. A subtle but critical difference

Popular posts from this blog

Lambda Architecture on Microsoft Azure

Gone are those days when Enterprises will wait for hours and days to look at the dashboards based on the old, stale data. In this fast world of BYOD, fitness gears and flooding of other devices, it is becoming super important  to derive out “actionable” information from huge volume of data / noise that is generated from these devices or any other data sources and act proactively on them  in real-time, to stay competitive.

At the same time, the need for having dashboards and other analytical capabilities based on the quality, cleansed, processed data still very much exists.

With the emergence of more data types and need to handle huge volume, shift is happening from the conventional data warehouse practice to cloud based data processing & management capabilities where high volume batch processing is possible at the optimized cost. Business scenarios demanding the need to process the data in real-time   More

SharePoint 2013 Architectural Trade-Offs

When planning for deploying SharePoint 2013 based Enterprise workloads, it should be done with the consideration / awareness of impact of various architectural decisions what we make. As SharePoint 2013 is a flexible platform providing lots of options in terms of configuration of the existing OOB features and development of custom development solutions to address specific business functional needs, care should be taken when making a particular decision and its impact on overall solution. Even though SharePoint is a matured product, the effectiveness of various business capabilities such as Enterprise Social, Enterprise Search, BI, Document Management, Web Content Management, and Enterprise Content Management that will be delivered based on it, in terms of addressing the business requirements depends on architecture planning. Effectiveness here means performance, security, up-time and other architectural qualities like Scalability, Reliability etc. more ...

Flexibility through product customization - How Secured it is ?

When providing solutions based on the multiple products, the success of the solution depends on what level of OOB features of those products helps in addressing the business / functional needs and what level of flexibility those products offers in terms of customization.

Also, how those products help in addressing business needs is very important in terms of time-to-market through:
Capabilities for seamless integration with federated business partners through adapters (like what Microsoft BizTalk, & StreamInsighthave rich set of adapters minimizing the development time), Partner ecosystem with solutions(like what partners have solutions basedon SharePoint in addressing various business requirements such as document storage, DRM / IRM, BI etc)
In addition to above mentioned factors, success depends on how the products allow developer community in extending its capabilities to address complex techno-business requirements.
While allowing the developer community for customization, it is a…