It is important to ensure that any system developed by a project team maintains the integrity of other architectures. Architecture domains can be found all around the project environment. The following are architectural domains that need to be reviewed.

Enterprise, Business and Domain Architectures

Enterprise Architecture is the architecture across the entire enterprise (including people and processes) and many organisations use the Zachman Framework as a model. How the enterprise architecture has been defined is relevant to understanding the way the enterprise works. The business architecture involves the top level strategic thinking down to its specific implementation across various domain architectures. Both the business and domain are relevant when developing applications requiring domain specific knowledge for an organisation.

Information Technology, Infrastructure, Platform and Security Architectures

Enterprises rely on their IT management to secure its data assets. This involves the infrastructure and access. Infrastructure and Platform Architectures involve hardware and software assets as well as the configuration and maintenance of bought and built technologies. Security Architecture involves the security model that defines policies down to the specialized knowledge of cryptography API’s and other security infrastructure. It is important to deliver within the constraints of the security policy and build on the appropriate platforms and technologies.

Systems, Technology, Integration and Application Architectures

These architecture domains are relevant because they define how applications are contained within the framework. Technology Architecture involves problems having to do with using a specific technology. Application Architecture involves development of non-domain specific utilities and generic application infrastructures. Enterprise Architecture for Integration involves cross-domain issues and standardization across platforms and products.

Data and Information Architectures

Data architecture involves the structure and organisation of persistent data usually in relational database management systems. Information architecture is relevant to knowledge management and extracting business value from data using analytical methods. Databases are usually secured and administered in a separate domain to development. It is important that data is not unnecessarily duplicated and that the integrity of existing data stores is maintained. An understanding of the data is associated with the business domain. This is often a key component of applications developed by the project team and the project should conform to the data and information architecture.

Knowledge, Repository and Portal Architectures

It is important for knowledge retention to store metadata about a system in a central Meta repository. As artifacts also change over the life of a project, it is best to make artifacts available on line through a knowledge portal. Automation of software engineering can also be achieved with metadata in a repository and reduce unnecessary coding and errors in code. Consistency in the naming of components and objects along with the correct spelling in authored programs can be achieved using lists derived from a central metadata repository.

Product and Project Architectures

Many solutions involve a mix of bought and built components. Software Development Projects are often undertaken for building solutions that enterprises prefer to build than buy. The relationship between product and project architectures needs to be considered. Projects should not delivery solutions that become unnecessary or unwanted by-products. Architects must define the way project architectures configure, conform to and change product architectures.

Services and Component Architectures

Finally, we come to the architecture we probably consider first. Don't commit too early to defining your internal component architecture without considering the externals, the interfaces and communication layers that interact with the architecture that exists around you. If you are working with multiple product teams in parallel, define explicitly the interfaces as contracts of agreement. The method calls, the input parameter structure and the returned structure. Well defined and documented XML schemas, metadata dictionaries, web services, stored procedures, APIs - these can be constituted as contracts of agreements between teams.

Avoid building layered components and black boxes without a set of clearly defined interfaces. It creates dependencies that force teams to work in sequence and in turn stretches project timelines out. The architecture suffers due to unneccessary layering and wrapping. Define your units of construction - what type of components you are building. Setup a Tiger Team to test build the integration components and to test any interops, then define the interfaces accordingly. A well defined project architecture will preserve the architectural integrity of its target environment.