The technology architecture domain describes the technology capabilities that the enterprise uses to support its functional architecture. The capabilities may be provided by physical machines and tools or software platforms and applications, and the description of these will conform to a technology strategy that incorporates standards and policies. Thus, the technology architecture comprises the following:
- Standards, principles, and definitions
- Application or solution architecture
- Technical capabilities across the various applications/solutions
- Data persistence (repositories)
- Integration (how the applications are used together to support enterprise functions)
- Metrics and measurement (the tools and frameworks used to measure operations and progress towards targets/goals)
It is common to describe this architecture in functional domains, as defined in the functional architecture. Taking the HR functional domain as an example, we may present the following technology architecture. In this exercise we will assume some standards and principles are observed by the enterprise and solution architects:
- Align with the technology architecture strategy
- Buy not build - the enterprise is not in the software business and so it would not make sense to build software in cases where it can be bought
- Optimise the number of technology suppliers - supplier management can be a considerable overhead when managing change (upgrades, etc.) across a variegated estate
- Share existing resources - all software solutions must be implemented on the common infrastructure architecture. This generally means that they must be able to function normally on the operating systems, database systems, and integration systems that are used by the enterprise. Proliferating types of these or requiring specialised infrastructure for a piece of software will reduce efficiencies and increase expenses, as well as create an unscalable, inflexible specialism within the enterprise for maintaining that software
- Reusable functions - use technology solutions that provide their various functions in on an open architecture. This means that the functions can be utilised separately to a useful degree, thus making optimal use of them throughout the other systems: they will then be able to use specific functions of a system in their own solutions. Vendors often collaborate in the marketplace to promote this type of interoperability where it benefits both parties. Often, for a particular solution (enterprise function) domain there will be an ‘ecosystem’ of vendors that cooperate in this manner
- Use the enterprise technology support model - this will include guidelines about where software should be installed and who should support it. There may be advantages to using a vendor’s own data centres and support teams, or the strategy may be to outsource technology operations and support to an outsource partner
- Contribute to efficiency targets - there may be targets to reduce the budget for maintaining and providing technology to the enterprise over the next 5 or 10 years. Replacing costly solutions with fewer less expensive ones, increasing efficiency, and reducing support and infrastructure requirements, and thus costs, should be differentiating factors when designing new software solutions
- ESG targets - contribute to the enterprise’s targets for reducing its carbon footprint and attaining carbon-neutral status. for example, a vendor that hosts a shared platform providing technology functions for all its customers may be much more carbon efficient than one that implements separate instances of their platform for each customer
The technical architecture itself will be arranged in a diagram showing placement of the applications and their data repositories within specified environments, delineated according to whether they are controlled and management directly or by a vendor or partner. It is important to note that this representation is at a summary level and that each entity on the diagram will have a detailed solution architecture document associated with it.
The aim of this summarised depiction is to facilitate understanding and discussion amongst stakeholders in the functional domain, without the need for technical expertise. The discussions themselves will be concerned with how well the technology architecture supports the current functional capabilities in the enterprise and to what extend it will need to change or be replaced to accommodate future goals and transformations.
In the model illustrated above, the enterprise has procured technology solutions from vendors that supply them ‘as a service’. This means that there is no need for the enterprise to build and manage a large data centre, upgrading and refreshing underlying infrastructure technology or to patch and upgrade the applications themselves - the vendor manages all this as part of their service. There are however some key technology architecture components that the enterprise manages itself, in our example, and these are concerned with secure access and identity management, legal and contracts, and analysing data for insights and reporting.
Most enterprises also utilise application portfolio management tools for managing the architectural collateral which comprises:
- Detailed solution architecture for each domain
- Vendor contracts and relationship management
- Costs and budgets that can be summarised at the subdomain, domain, and enterprise level
- Disaster recovery plans
- Dependency models (usually from the functional architecture supporting perspective)
- Upgrade and replacement schedules/time lines
However, these assets can be managed using a standard document repository and manual processes.