The most straightforward way to convey the difference between technical architecture and enterprise architecture (EA) is by looking at the scope and focus of each.
As the name suggests, technical architects are more concerned with the technicalities and the specifics of a particular technology than with technology’s place in the enterprise.
That’s not to say that they operate without the enterprise’s overall strategy in mind. They do – or should – but the direction for said strategy typically comes from elsewhere. Most significantly – from an enterprise architect.
In this post:
- What Is a Technical Architect?
- The Difference Between Technical Architecture and Enterprise Architecture
- Technical Architecture vs. Enterprise Architecture – Which One Do I Need?
What Is a Technical Architect?
A technical architect works closely with development teams in a supervisory capacity – providing leadership and guidance during the project lifecycle.
They often work under more specific titles, reflecting the technology they specialize in – e.g., “Java architect” or “Python architect.”
Typically, their operations revolve around technical services and in the context of the project lifecycle – enabling technology.
It’s a role that requires good communication and relationship management skills, as well as the ability to anticipate problems, manage their time, and operate under pressure.
The Difference Between Technical Architecture and Enterprise Architecture
We previously have discussed the difference between data architecture and EA plus the difference between solutions architecture and EA.
In the latter, we described enterprise architects as having a “holistic view” of the organization, mostly focusing on things from a high-level, strategic point of view.
Although technology is something that enterprise architects are concerned with, they aren’t expected to have a deep, ground-level understanding of the tech itself.
Their broad scope and holistic view of the enterprise does not allow for this.
Technical architecture can be seen as the antithesis to this. Instead of seeing the organization from a high-level, strategic point of view, technical architects operate amongst the weeds.
They have a high focus on technology, and a low focus on how that technology fits in with the enterprise’s overall strategy.
Using an orchestra as an analogy, enterprise architects would assume the role of a conductor who is less concerned with how any individual instrument operates but requires they work together cohesively to complete the performance.
While enterprise architects have a high strategy focus, they are less detail orientated., Technical architects operate in the reverse, with solution architects somewhere in the middle.
Enterprise Architecture vs. Technical Architecture – Which One Do I Need?
Well? … Both.
It’s a straightforward and somewhat vague answer. But it’s one that needs to be given, because we’re asking the wrong question.
In a world where organizations are increasingly data-driven, any ambition to scale will inevitably scale with the complexities of the systems involved too.
With this considered, we should abandon the binary question, in favor of asking “when” instead of “which.”
When do I need enterprise architecture? When do I need technical architecture?
The answer to both is “sooner, rather than later.”
With regard to enterprise architecture, many organizations already are doing enterprise architecture before they have a formally recognized enterprise architecture initiative or enterprise architecture tool.
We consider these efforts “low-maturity” enterprise architecture.
But doing enterprise architecture this way can cause bottlenecks as an organization’s enterprise architecture scales. Additionally, this sort of enterprise architecture is vulnerable in its dependency on individuals.
Without a formalized approach to enterprise architecture, the whole enterprise architecture could collapse if the person in charge of the EA were to leave without contingency plans in place.
You may already be at and the point of experiencing bottlenecks. If so, you should consider formalizing your enterprise architecture approach and investing in an enterprise architecture management suite (EAMS) now.
This 2020 Forrester Report on EAMS is a great place to start your research.
The need for technical architecture implies an organization already has a complex enterprise architecture and some degree of formalization for managing it.
This, in turn, implies an organization is large and therefore has more complicated product lifecycles and higher stakes implementation procedures for new tech.
In either case, managing an organization’s enterprise architecture through manual processes and repurposed systems – some organizations attempt to make do with managing their EA via PowerPoint slides and sticky notes – is not the recommended approach.
For a scalable, manageable and efficient approach to enterprise architecture, organizations should adopt a dedicated enterprise architecture tool.
erwin Evolve is one such tool that also supports business process modeling use cases.
erwin Evolve has collaborative features at its core, meaning organizational silos that had once kept EA in an ivory tower are broken down, and the holistic view of enterprise architects is enhanced.
With erwin Evolve, users enjoy the following benefits:
- Creation and visualization of complex models
- Powerful analytic tools to better understand an organization’s architecture – such as impact analysis
- Documentation and knowledge retention for better business continuity
- Democratization of the decision-making process
- Greater agility and efficiency in implementations and dealing with disruption
- Lower risks and costs driven by an enhanced ability to identify redundant systems and processes
Organizations can try erwin Evolve for free and keep any content you produce should you decide to buy.
For more information on enterprise architecture, click here to get the erwin experts’ definitive guide to enterprise architecture – 100% free of charge.
