The term, level, type and form of IT Architectures in 6 min

What is architecture (I am referring to business and information technology related architecture), what are the different levels, types and forms of an architecture? I often see people struggling with these questions, so here a short summary:

1) Defining Architecture?

Architecture is not = technology; Architecture, in an IT context, is the “art” of managing complexity, reducing risk and cost. Architects are needed where existing complexity is impacting the decision-making process.?An Architect will have to understand the target solution – derived from the functional and the non-functional requirements, understand the current position as well as the constraints (commercial, security, compliance etc) to devise the best (value for money, time etc.) approach for understanding the route of achieving that target.

A key purpose of architecture is to address complexity. However, when looking at the different types it can be difficult to differentiate between the different types. Questions like "What is enterprise architecture in relation to solution, domain or project architecture?" can be cause confusion.?

2) Different Levels of Architecture?

Typically, an Enterprise Architecture considers everything – business and IT and covers the entire scope of the enterprise. A domain architecture also covers business and technology. However, it focuses typically on one main area of the enterprise – for example “payment” or “customer service”.

Project Architecture is typically related to the actual design and implementation of a solution like an “ordering application”, a “customer relationship management system”, etc.?

?3) The different types of Architecture

Next to the level of architecture there are different types of architecture like business, IT, solution, and governance architecture [1]. Each type of architecture will address different types of insights that may span Business, Information, Systems, etc.:

Enterprise Architecture details the structure and relationships of the Enterprise, its business models, the way an organisation will work and how and in what way information and IT will support the organisation’s business objectives and goals. Enterprise architecture provides an all-encompassing, holistic end-to-end view of the business in terms of people, process, governance, and technology within (and external to) the business to support those objectives and goals.

Enterprise Business Architecture (or Business Architecture) defines the integrated structure of the overall business itself (in terms of organisation, people, process, and resources). Business architecture supports business change with a more holistic perspective.?

Enterprise IT Architecture defines and describes the structure and relationships of IT systems at the enterprise level, in terms of the way that IT supports the organisation in achieving its business goals. This typically includes standards and guidelines that are applied within solution architectures.

Solution Architecture defines an architecture for a specific solution, whether this be business or IT. The solution architecture provides structure, standards, and guidance for the detailed design of a solution and is typically guided by the enterprise architecture. Note that “solution architecture” is often used as shorthand for “solution IT architecture” and is sometimes referred to as “project architecture” or” IT architecture”.

Information Architecture defines and describes the structure, standards, guidance and relationships of the information objects and their relationship with other objects within a specific solution or the enterprise. Note that standards and guidance in terms of model creation and amendment may already be in place. Note that “information architecture” is often used instead of “data architecture”

Infrastructure Architecture focuses mainly on the non-functional characteristics of a solution. It outlays all infrastructure related components needed to fulfil the non-functional requirements such as (but not restricted to) availability, stability, security, scalability, operability, and extensibility.

Governance Architecture defines not only the traditional IT Systems management capabilities, organisation, and systems, but also addresses business governance (how to manage the overall business processes, formal and informal) as well – critical in these days of increasing business regulation and compliance.

Security Architecture defines not only traditional (ie firewall, proxies, etc) IT security but also addresses business and information security, as well as the resulting organisational and business-related services to deliver the required security. Often linked to the governance aspects to cover what is termed security management.

This holistic view of architecture is directly reflected in our integrated architecture framework (IAF) by making use of specific “Aspect Areas” that focus on business, information, information systems, technology infrastructure, security, and governance. Typically, projects are concerned with the solution design during pre-sales engagements, project related solution design, build, implementation and the run of infrastructure related aspects and seldom with enterprise and/or application related aspects.

Another term that you might come across is agile architecture:

Agile Architecture is the art of designing and delivering the “right” solution - meeting the requirements, expectations and demands of the client - while being able to respond to change in any uncertain environment. Responding to change means that we no longer create a “Big Design Up Front” (BDUF). Instead, the architecture designed in an agile context. See here more detail.?

4) The different forms of Architecture??

Next to the different levels and the different types, architectures will have to be documented. Typically there are several different forms [2] that are being used.

Reference Architecture (RA) in the field of IT architecture provides a template solution for an architecture for a domain or project. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality. A reference architecture often consists of a list of functions and some indication of their interfaces (or APIs) and interactions with each other and with functions located outside of the scope of the reference architecture.

Target Architecture (TA) According to the Open Group a Target Architecture is the description of a future state of the architecture being developed for an organization. There may be several future states developed as a roadmap to show the evolution of the architecture to a target state. Target Architecture therefore has a timing element attached to it.

Project Start Architecture (PSA) ensures that new developments and changes are realized in a cohesive manner and in line with organization-wide management goals. The PSA translates the overall enterprise or domain architecture to the specific situation of the project. The PSA had two main purposes:

• It identifies those pieces of the reference architecture that are relevant to the project by the time it starts. This imposes an architectural framework to the project team.
• It captures the design decisions made by the project team within the limits of the PSA (~conform the enterprise architecture) if they are candidates for standardization. It also records agreed deviations from the framework imposed by the PSA.

High-Level Design (HLD) provides an overview of (part of) an solution, platform, system, product, infrastructure service or process at a logical level in such a manner that it can be used as a starting point for further detailed designs. The HLD states functional architectural components which provide the required functionality and the relations between these components. A HLD does not provide technical and/or product specifications or detailed interface descriptions. This detailing is typically part of the Detailed Design.

Architecture Decision Record (ADR) covers all decisions related to the architecture and is therefore an important tool in the architectural governance, even more in an agile context than in waterfall. The main reason is that some architecture decisions might be left to the teams, and therefore need to be documented by the teams. As already stated under Just Enough Documentation, the ADR needs to be versioned as well to ensure decisions can be traced back and changes in decisions are documented.

In the past we "used" to encode these in .doc or .docx. Today, documentation should be treated as code. This is not just for code documentation, but also for architecture related documentation.

Summary

Architecture is mainly about managing complexity to reduce cost and risk. Architecture typically works on an Enterprise, Domain or Project level and there are several different types of architecture covering business, IT, solution, and governance architecture, all documented using different forms.

Thanks for Reading! Gunnar

[1] Only the main types are being documented?

[2] This is only a selection of forms typically used