TL;DR
Technology Architecture is not just a response to data and application requirements. It also identifies technology-driven opportunities for business change, while managing the risk of introducing new technologies too quickly or inconsistently.
Approach at a glance
The visual below summarizes the two sides of Phase D: responding to architecture needs and using technology as a driver for business change.
More than a fulfillment layer
Technology Architecture supports the Data and Application Architectures, which support the Business Architecture.
That does not mean technology is only a delivery tool.
Emerging technologies can create new ways of operating and improving the business. Phase D should therefore look for transformation opportunities made possible by technology, not just translate information systems requirements into infrastructure.
Practical stance
The Technology Architecture approach should:
- support the target Business, Data, and Application Architectures
- anticipate technology-driven change
- look for new ways to improve business operation
- capture transformation opportunities from new technology
- treat technology change as a strategic resource
- assess enterprise impact before adopting new technology
The ADM allows technology change to become a driver of change, not only a recipient of change requests.
Balance opportunity and impact
Technology Architecture may both:
- drive new business capabilities
- respond to information systems requirements
Both are valid.
The risk is uncontrolled technology adoption. Rapid adoption of changing technologies can create discontinuities across the enterprise.
Before introducing new technology, assess:
- impact on existing architectures
- integration with current applications and data
- operational readiness
- security and compliance implications
- support and skills requirements
- lifecycle and standards fit
- cost and migration effort
Reuse existing architecture assets
As with other ADM phases, start from the Architecture Repository.
Useful resources may include:
- documented IT services
- IT service catalogs
- existing technology standards
- existing infrastructure platform descriptions
- reusable building blocks
- generic technology models relevant to the organization’s industry
Reuse saves time and keeps the Technology Architecture aligned with the rest of the enterprise.
Reference models
TOGAF points to reusable reference models that may help Phase D.
| Reference model | What it helps with |
|---|---|
| TRM: Technical Reference Model | A generic model for technology services and platform services |
| III-RM: Integrated Information Infrastructure Reference Model | A reference model for application-level components and services needed for integrated information infrastructure |
The Phase C Approach note also mentions III-RM because it is relevant to integrated information infrastructure and application-level services.
Exam note
- Technology Architecture supports Business, Data, and Application Architectures.
- It can also drive business change through emerging technologies.
- New technology can create enterprise discontinuities, so impacts must be assessed.
- Reuse Architecture Repository assets when developing Technology Architecture.
- TRM means Technical Reference Model.
- III-RM means Integrated Information Infrastructure Reference Model.