IT architecture activities typically involve a small team working with a variety of business domain and business process experts that understand the "system" (i.e. the enterprise or a portion thereof) in question. Like software development this it's not an engineering discipline from the standpoint of well-defined principles and methods based on hard facts and centuries of application. It still is therefore a "craft" requiring years of study and practice before one gets good at it. The principles and practices defined here are an attempt to shorten this learning curve by describing the keys to success.  UAM has also define an approach that tries to make IT architecture more of an engineering discipline, however it is just a start in hopefully the right direction. 

With the advent of corporate computer networks, and the explosive growth and use of the Internet, enterprises and the many computer systems and their contained applications are no longer stand-alone contained black boxes. Everything, yes absolutely everything, is connected to everything else these days. This has enabled more dynamic and agile enterprises, but has resulted in the need for and greatly complicated the job of the enterprise or domain architect. No longer can projects go off and do their own thing, they have to be architected and designed to fit into the larger enterprise (or even Internet) context. This also means that the enterprise needs to have an IT blueprint—integrated IT architectures.  

Today, Information Technology (IT) is more and more a key business enabler—so our approach to IT must be more and more business-oriented and business-driven. The following principles articulate best practices for this broad enterprise (and Internet) context and highly integrated and evolving business-driven IT. They are:

Each of these pages presents one of the above principles, emphasizing: