Architecture description can affect the "life and death" of the software system that it describes.
I was hired many years ago as a corporate level principal architect. The first assignment I got was to describe the architecture of an existing software system product inherited from a company acquisition. The original people who created the system had left the company. There were no architecture or design documents; no one had insight about it to be able to describe what it really was. The marketing folks didn’t know how to market it, so the product faced the “death penalty”. To the engineering teams, the product was current, state-of-the-art, and very competitive with lots of great ideas built-in. By collecting information from multiple channels, I provided architecture description for this system, and did it justice. Also, I provided architecture for its future evolution. Both marketing folks and engineering teams were happy with the results.
From this experience, we can see what’s involved with architecture description, and how we can perform our roles effectively. In the context of overall architecture design, architecture description is to transform the collected and organized architectural information and intents into viable models. The creation and adoption of effective architecture approaches, methodologies, patterns, reference models, etc., can certainly benefit architecture description. The architecture description is the end product in the architecture development process; and it is the ultimately visible representation of architecture.
More details can be found at: http://msdn.microsoft.com/en-us/library/bb421528.aspx
The Enterprise Architecture concept exists for more than 20 years, but its need become urgent until recent years due to the rapid change and increasing complexity in IT, as well as the demands for business agility in Internet era. The SOA, as an architectural style, is becoming popular in architectural practice. It is moving business and IT to an integrated new paradigm. It brings new agility to EA practice, helps EA realize broader acceptance, and makes EA more usable to end-to-end enterprise solutions. Conversely, EA provides SOA practice with enterprise views as a foundation. The combination of the two benefits both business and IT for an enterprise.
It should be noticed that SOA is in a sub-domain of EA. We adopt SOA in where it applies, not practice SOA for its own sake. It's one approach after all, and many other complimentary approaches can be applied simultaneously.
The Service Oriented Infrastructure is to apply SOA to IT Infrastructure. With the changing role of IT, IT infrastructure is not only associated with hardware, software, and network components, it is becoming more integrated with business operation strategies, and being operated as a business service as well. In US Federal Enterprise Architecture program, a segmentation approach is adopted that divides the complete Enterprise Architecture domain into segments based on the identified Lines of Business (LoB), where IT Infrastructure is one of the identified LoB. The current Cloud Computing evolution is one step further, which enables a practical implementation.
