Typically, there are two approaches toward Systems Architecture or Enterprise Architecture.  One of skepticism the other of religion.  In the first position are those who think that Architecture is simply the art of looking “smart” or “savvy” before the audience and that working, discussing and designing Arquitecture really carries no tangible or concrete benefits (even no results).

On the other side are those who think that defining Arquitecture makes it all, being the rest only implementation “details”.

As expected, the truth stands somewhere in between: Archicture is requested to establish a roadmap to follow through in order to attain the desired business objectives normally agility, cost reduction, and making room for new business processes.

But additionally, Arquitecture carries a benefit not always evident that has nothing to do with technology itself.  
Just to lay a common ground, let’s define it briefly: Architecture is a high level vision of the components required to achieve business objectives in the most effective and efficient possible way; also, to establish relationship among these components.  Normally, it will take the shape of one or more diagrams, presentations, some documents and, if required, some reference or pilot implementations.

Seen like this, the additional benefit of investing time and resources in Architecture is a good way to let the rest of the organization —or customers or business partners— know that we really know what we are doing.  On the contrary, if we are not capable to show an Architecture, we are leaving the impression that we are just building along the way as we advance, which for any level C Manager sounds as (and I cross myself while I write) RISK.
If we apply this vision to Architecture we are forced to deduce that Architecture must not be a collection of acronyms, initials or technicalities but both a graphical and in English depiction of what we are looking for, of our strategy to support the business.

Even being hard to believe by some professionals, if adequate words are used, anyone can understand an Enterprise Architecture, taking into account that we are talking about Architecture, not about calculation book (making an analogy with Civil Engineering). The calculation book stays with us, as we are paid to make that “dirty work” to make it all happen while the owner doesn’t want nor need to know about it.

So let’s get down to it.  Let’s prepare the Architecture document with this focus in mind. Taking technicisms' boredom off, our job becomes fun, heartwarming and easily understable by all.