Tag: solutions architecture

Categories
Enterprise Architecture erwin Expert Blog

Enterprise Architecture vs. Technical Architecture

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:

Enterprise architecture review

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.

Categories
Enterprise Architecture erwin Expert Blog

The Difference Between Enterprise Architecture and Solutions Architecture

Despite the similarities in name, there are a number of key differences between enterprise architecture and solutions architecture.

Much like the differences between enterprise architecture (EA) and data architecture, EA’s holistic view of the enterprise will often see enterprise and solution architects collaborate.

And as with data architecture, a solution architect’s focus is narrower.

In this post:

What Is a Solutions Architect?

Solutions architecture is about solving problems. It describes the process of orchestrating software engineering to address an organization’s needs.

Typically, a solution architect’s responsibilities cover:

  • Assessing and understanding an organization’s technological assets
  • Finding a solution to address a problem
  • Defining and denoting the critical technologies for the organization’s operations
  • Understanding the impact of time on the current technologies in place, including establishing what can be scaled and what must be replaced/upgraded
  • Designing prototype solutions
  • Assessing and selecting new technologies

Their technical skills typically include software engineering and design, DevOps, business analysis and increasingly, cloud architecture.

What Is an Enterprise Architect?

Broadly speaking, enterprise architecture is a strategic planning initiative.

Enterprise architects are concerned with how they can reduce costs, eliminate redundancies in technology and processes, and prepare for, mitigate and manage the impact of change.

To operate effectively, enterprise architects must have a solid understanding of the organizations they work with/for.

Such an understanding has its advantages, but it also means that there isn’t the scope to be concerned with the more “technical” side of an organization’s architecture.

Typically, an enterprise architect’s responsibilities cover:

  • Understanding and developing the whole enterprise architecture
  • Evaluating risks and the impacts of change and creating a roadmap with such evaluations considered
  • Ensuring alignment between the business and IT through the organization’s enterprise architecture
  • Advising decision-makers and business leaders from an organization-wide, holistic perspective of the enterprise

From this perspective, solution architecture’s value to enterprise architecture becomes even more clear. Where an enterprise architect is concerned with the EA’s current state, and the strategy to reach the desired future-state, solutions architects act on that strategic direction.

Enterprise Architecture Tools

Enterprise Architects vs. Solutions Architects

Perhaps it’s misleading to use “versus” to describe the difference between enterprise architecture and solutions architecture. They are very much collaborators in the organization and should not be looked at as competitive in terms of which provides more value.

A better way of highlighting the difference between the two is through their focus on strategy vs. technology.

A focus on strategy implies a broad understanding of the mechanics of any given technology. This is because there is a lot more to strategy than just the technology needed to implement it. A skewed focus on technology would mean that the processes, people and other variables required to inform strategy are ignored.

Conversely, a focus on technology is necessary to ensure implementations and operations can run smoothly. By its nature, it is more “in the weeds” and so the necessary holistic perspective of the organization can be harder to understand and/or account for.

With their holistic view of the organization, enterprise architects take on the strategy. They then use their strategic planning perspective to inform and delegate to solutions architects.

In the same vain, a technical architect has a low strategic focus and a high technological focus.

Bottom line,  an enterprise architect’s strategic focus is high and their technology focus is low; technology architects operate in the reverse; and solution architects bridge the two.

The Imperative for Enterprise Architecture and Solutions Architecture

With the quickening pace of digital transformation and the increased acceleration owed to the Covid-19 crisis, enterprise architects and solution architects are becoming increasingly relevant.

“Enterprise architect” was named the top tech job in the UK for 2020 and as this article implies, solution architects should stand to benefit, as well.

However, simply hiring enterprise architects and solution architects isn’t enough. Enterprise architecture in particular has been blighted by its perception as a role operating in an ivory tower, disconnected from the wider business.

Considering IT and business alignment is a core tenant of an enterprise architect’s responsibilities, this is obviously counter-productive.

For many organizations, shaking this perception will require a change in how enterprise architecture is done. Organizations need a definable, measurable and collaborative approach to enterprise architecture to make the most out of its vast potential.

This means moving away from low maturity examples of enterprise architecture that are managed through a hodgepodge of repurposed tools, and decentralized notes.

erwin is helping organizations mature their EA with erwin Evolve. With Evolve, organizations can collaborate within a purpose-built enterprise architecture tool for both greater consistency and involvement from the wider business.

As part of the wider erwin Enterprise Data Governance Experience (EDGE), erwin Evolve lets organizations synergize their enterprise architecture with their data governance and management strategies.

This means that efforts to manage the enterprise architecture include a data inclusive perspective. And considering data’s value as an asset, this perspective is vital.

It means an organization can get a clear and full picture of the whole data lifecycle in relation to the systems and broader context it exists in, so that the intersections between data and the organization’s assets is clearer.

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.

Categories
erwin Expert Blog

Data Driven Enterprise Architecture for Delivering Better Business Outcomes

Data Driven Enterprise Architecture for Business Outcomes

Forget everything that you may have heard or read about enterprise architecture.

It does not have to take too long or cost too much. The problems are not with the concept of enterprise architecture, but with how it has been taught, applied and executed. All too often, enterprise architecture has been executed by IT groups for IT groups, and has involved the idea that everything in the current state has to be drawn and modeled before you can start to derive value. This approach has caused wasted effort, taken too long to show results, and provide insufficient added value to the organization.

In short, for many organizations, this has led to erosion in the perceived value of enterprise architecture. For others, it has led to the breakup of enterprise architecture groups, with separate management of the constituent parts– business architecture, information architecture, solutions architecture, technical architecture and in some cases, security architecture.

Data Driven Enterprise Architecture for Business Outcomes

This has led to fragmentation of architecture, duplication, and potential sub-optimization of processes, systems and information. Taking a business outcome driven approach has led to renewed interest in the value enterprise architecture can bring.

But such interest will only remain if enterprise architecture groups remember that effective architecture is about enabling smarter decisions.

Enabling management to make those decisions more quickly, by having access to the right information, in the right format, at the right time.

Of course, focusing on future state first (desired business outcome), helps to reduce the scope of current state analysis and speed up the delivery of value. This increases perceived value, while reducing organizational resistance to architecture.

  • Understand their goals, objectives and pain points, and then help them to express them in clear business outcome related terms. This will take time and skill, as many business users simply asking for system changes without clearly stating their actual objectives.
  • Review your current architecture efforts and tooling. Question whether you are providing or managing data the business does not need, whether you are working too deeply in areas that may not be adding value, or whether you have your vital architecture data spread across too many disconnected tools.

This blog post is an extract taken from Enterprise Architecture and Data Modeling – Practical steps to collect, connect and share your enterprise data for better business outcomes. Download the full ebook, for free, below.