Enterprise, Systems and Application Architecture (Best Practice?)

Question

I am currently tasked with creating a documented, consistent Architecture guide for software development. We have a lot of smart people doing the right things, but just not consistently and repeatably.

We are using Microsoft’s Application Architecture Guide 2.0 as a starting point. Hence coming up with an Application Architecture is fairly (I won't say easy) straight forward. Possibly because I have a couple of years experience as a developer so I have a pretty good understanding of this realm and there are also loads of examples and guidance.

Since our organisation has a couple of applications that form 1 or more systems which we then install "at" clients... we thought it would make sense to create a System Architecture and an Enterprise Architecture as well. And this is where the problems start.

There is no consistent guidance out there. If you search for "System Architecture Examples", the stuff that you get back is so different that I am wondering if there is a "Standard" way to do this.

From my (Limited - clearly) understanding of it all, the System Architecture is an abstraction of 1 or more application architectures depicting how they work together to form a system. Furthermore, an Enterprise Architecture is a further abstraction showing how your system(s) fit into a organisations Enterprise and how it interacts with the Business processes, IT Strategy and how it Integrats into other systems in the enterprise.

• Do I have it completely wrong?
• Are there any standards out there (and where can I find them)?
• Should there be standards, or would a "good" System Architecture simply be any document in any format which is clearly and easily understandable and useful to its readers?
• What would the seasoned Architects think of that approach though?

I don't want to simply list a set of SOA related patterns that may be useful... I'd like to make it a little more focused to what we do, which is the build financial solutions on a Service Orientated Architecture.

Update: What about TOGAF(9). Does anyone have experience with it at all and is it worth the effort of trying to understand it in detail.

Answer 1

I submitted the question a couple of days ago, but by continued research and after reading littlegeek's reponse, I think I have found an interesting white paper that I found very informative and interesting.

Read: A Comparison of the Top Four Enterprise-Architecture Methodologies By: Roger Sessions

a snippet...

-- - - - - - - - - - - 8< - - - - - - - - - - - -

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

• The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy
• The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process
• The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture
• The Gartner Methodology—Can be best described as an enterprise architectural practice

This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:

• IT systems that have become unmanageably complex and increasingly costly to maintain.
• IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.
• Mission-critical information that is consistently out-of-date and/or just plain wrong.
• A culture of distrust between the business and technology sides of the organization.

-- - - - - - - - - - - 8< - - - - - - - - - - - -

The White Paper helped me in several ways.

1. It gave me a good introduction and history of Architecture (Enterprise Architecture specifically)
2. It introduced me to what the author suggest is the 4 leading Enterprise Architectures available.
3. And then continues to compare them in a logical and simple manner with good examples that I could relate to.

I cannot say that all my questions have been answered and I am now ready to die :-), but much has become clearer and thus I thought that someone else out there may also find this useful.

I would still value any additional comments, suggestions and questions you may have on this subject.