Enterprise, Systems and Application Architecture (Best Practise?)

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.

Any guidance, comments and/or suggestions would be much appreciated.

Gineer

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

You seem to have a really good grasp of the situation and the understanding of the realm of artchitecture.

"Systems" Architecure is little harder to define - may be look for "solution" or "IT", but it sounds like your looking for how your software architecture relates to the physical server world, with a bit of networking thrown in

"We have a lot of smart people doing the right things, but just not consistently and repeatably."

Then, being TOGAF 8 certifed myself, - I would say that TOGAF brings a sense of "methodology" to different aspects of defining architecture and a way to bring a variours specialist technical groups together and pinning that firmly to the business objectives. TOGAF also helps understand the need for Architecture governance and firmly brings the idea of change (from all parts technical, data, systems, software and business) into the process.

The

1. Architecture Development Method
2. Technical Reference Model
3. Standards Information Base
4. Enterprise Continuum

All help gather information about the Archtecture effort and provide a consistant approach to developing and EA.

It also helps customers understand what you are doing and how you can present TOAGF as the method of showing how it fits together.

PS - I only state TOGAF as being useful do the quote that i have pulled out as TOAGF would address this for you.

There are other architect framworks out there.

Answer 2

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.

Answer 3

I have no hands-on experience on EA, but I'm actually on board with it. Among the top 4 EA methodologies, I have encountered the first three. I just don't know the Gartner one, maybe because of the unavailability of its documents. IMHO, when we are talking about EA, we are actually talking about aligning business with technology. So all of EA methodologies must be business oriented. If not, it's not EA at all.

I think TOGAF is quite useful and understandable. Yes, it is a process which evolve current baseline architecture into target architecture. Architecture principles act as the high level guidance of EA development. The core components of TOGAF are business architecture, information architecture, and technology architecture. And each of them can have its own architecture patterns. NIH has implemented an EA with FEAF. It is a good example for implementing EA. I think it is quite similar to TOGAF approach, at least from point of view of the deliverables.