A final product in the hand of the user is a cross domain team work your have the product design team the UI team the Device Driver Team the Application software team the Hardware team the firmware team and the board design team. Each of these teams will have its own architect who will more or less deal with his own area of specialization. For e.g. the hardware architect will be defining the hardware aspect of the system and the software architect will be defining the software aspect of the system. It then falls on the system architect to define the complete system and ensure that the software is capable of running on the hardware and ensuring that both of these are capable of interacting with the external world as required.

Previously in more simpler times we had a single architect who would define all the components of the system be it hardware or software Now these roles are distributed over

Hardware Architect normally interfaces with the system architect and in his absence directly with the end customer and the software architect. His role typically encompass

1. Generating the hardware requirement list based on users needs and budget.
2. Ensuring the correctness and completeness of this list.
3. Defining the reuse strategy to take maximum advantage of existing (commercial or in house) off the shelf components.
4. Partitioning the design into sub modules distributed over different functional domains involving minimum handshake.
5. Fine tuning the partitions till it can be broken in manageable chunks.
6. Ensuring robustness of the final design.
7. Defining acceptance tests for each level of the design
8. Defining models to check the correctness of the final implementation

System architectures can be either organic or explicit.

An organic architecture does not begin with a grand road map to address all the current and future product needs. Indeed in the technological domain it is difficult to predict the needs 1 year down the line. I an organic architecture the initial architecture is designed to address the known set of problems or requirements. No plans for version 2 are drawn-up. As version 1 is marketed and deployed based on user feedback and new product requirements the original architecture is improved and version 2 is released. The product roadmap evolves over time through such continual sets of improvements made to address newer and newer sets of application/problem domains

An Explicit architecture starts with defining the roadmap for a series of products to be released over time. This roadmap will contain details of what features are to be implemented in which product. As it is difficult to forsee the unexpected future problems and requirements such an architecture definition becomes an major R & D effort. Typically the investment in a decent architecture will be twice the costs of an implementation. So the first product in your roadmap endsup costing three times as much with an explicit architecture compared to the first product with an organic architecture.

It is interesting to note that some of the major architectures in the computing domain have failed to recover the investment for the investors. One reasoning for this is that since a properly defined architecture is a major R & D Work which has to happen independent of the production schedules. This activity can be taken up only by a hugely successful company. This huge success in its domain quickly converts into a monopoly in the market bringing on anti-trust investigations resulting in break-up of the company and release of its architecture and related patents in the public domain. e.g.

1. While Xerox-PARC was developing its office of the future it was under investigation by the justice department and had to give up some if its key patents which ended up in helping its rivals like Cannon, Sharp etc.
2. We have a Similar Story with IBM and its 360 architecture
3. Microsoft's longhorn plan coincided with its anti-trust investigations.

The examples above are not meant to indicate that any major explicit architecture plan is jinxed and will result in dooming the company. What it indicates is that a company can afford to have a long term strategy and spend resources in a major architecture definition only after it has tasted resounding success.

If that is the case then one is forced to ask the question that if a company has achieved resounding success through organic development of its architecture then why does it feel the need to change it strategy and go for an explicit architecture?

Normally during the infancy of the organisation when it is trying to carve a niche for itselves it has to move quickly to gain the first movers advantage. This business need results in a product which may be a patch work of incompatible systems put together using glued logic. When the first revision tastes success this fuels a further growth of variants of this products based on customer requirements. Due to time to market constraints each such variant will have some other logic glued on top of it. Normally after a few such iterations the design would either start evolving into a better architecture or degrade into an unmaintainable chunk of logic. Also after having a few products under his belt the team knows the market better and acquires the ability to predict its future directions. Such a team can now reevaluate their original design constraints and design a better system more attuned to the market requirements.

Most often the switch to a new architecture is not initiated by the origin design team. As time progresses the original team moves on to new roles and responsibilities either within or outside the organization and new people are brought in the maintain the product. Each such team of desiginers tend to leave their footprints over teh code base either in terms of their coding styles or implementation methodologies. Over time it becomes common for a logic block to have different coding styles and redundant logic because the desiginer was not confident about re-purposing the existing logic to handle additional functionality. Over time a need is felt to redesign the system to have a cleaner coding style and simpler interfaces. While the intention here is honorable one risk in this effort is that what might look like redundant logic or an odd coding style may indeed be a specific fix to a corner case bug. In his effort to do a clean design from the spec the designer may end up in throwing out all such fixes which were never documented.

One way of mitigating this risk is to avoid a clean slate design. Instead what one should plan for is a series of refactoring efforts which will rewrite the code to use a consistent coding style and carefully remove the glue logic and incompatible interfaces and rewrite them to achive the required results.