DEV Community

Cover image for Introduction to Enterprise Architecture (EA)
Jin Vincent Necesario
Jin Vincent Necesario

Posted on • Originally published at c-sharpcorner.com

Introduction to Enterprise Architecture (EA)

Introduction

In today’s digital age, most businesses run and are dependent on technology. This technology comes in several forms, but software systems are most known.

As we all know, every company provides either products to sell or services. These companies are run by their owners, managers, or corporate C-suite officers, but they’re not necessarily technology experts.

These owners don’t make tech decisions. That’s why they need help to build and buy information system that runs their businesses. This is where the enterprise architecture comes in.
In this article, we’ll discuss what’s an enterprise architect and what they do.

OK, let’s get started then.

What is Enterprise Architecture (EA)?

The word enterprise represents any organization that uses software systems, and it is not limited to companies only. It can be government institutions, nonprofit organizations, non-governmental organizations, and charities.

Enterprise Architecture (EA) is a practice and a set of skills used to align technology strategy with business strategies. Moreover, EA deals with complex relationships between an enterprise/organization, its people, the business process it supports, and systems that automate these processes.

That’s why in corporate settings, business leaders rely on enterprise architects as trusted technology advisors.

In my own perspective, an enterprise needs EA not because of the IT project complexities, but because they bridge the communication gap between business stakeholders and developers.

Just try to imagine that project status could be not in good shape due to lack of communication between the developers and business stakeholders.

That’s why you’ll see EA acts as an interpreter, translating from business needs to solution designs and finally to enterprise systems.

Therefore, we can conclude that enterprise architects support business executives in translating their vision into technology strategies that help companies succeed.

Difference Between a Developer and an Architect?

Generally, most architects started their careers as software developers.

Not everyone would agree that being a software developer is a great career, especially if you don’t love building things within the software space and solving problems by translating business problems to code.

Do you want to become an architect in the future? Being a software developer is a good stepping stone.

Now, let’s focus on the difference between developers and architects.

In my opinion, developers focus on the trees, while architects focus on the forests. These trees represent the technology or related technology the developer focuses on, while the forests represent the array of connected systems the EA focuses on.

Another difference is that software developers, their first instinct is to write code to fulfill requests from the business.

That’s why if a company doesn’t have architects, business users interact directly with developers. That’s why everything is treated as a software problem.

While architects are skilled in asking the right questions that drive purpose and intent, EA helps to keep focus on delivering business value avoiding disruption.

For example, when business users ask for new systems or features, architects help them express what they really need in actual business outcomes.

Three Main Types of Architectural Scopes

Application Architects

Application architects are the closest to the software development team. These people are also known as software architects.

These people focus on a complex IT system composed of platforms, reusable components, and software. In simple terms, we can say that application architects mainly focus on engineering problems and technology solutions related to the particular platform they specialize in.

In general, most software senior or software engineering-leads usually become or are promoted to become the application architect of the team. That’s why this role can still write code. Also, what I like about these roles is testing some proof of concept that will eventually help the project progress with the current issue they’re facing.

Moreover, when not coding, testing, or designing new ideas, this role communicates with the development team to know their progress with the design implements. This ensures that the applications’ ongoing development is built according to the plans given or suggested by the software architect.

Solution Architect

Solution architects specialize in plugging working systems together to handle complex business workflows. You’ll see them in charge of bridging the gap between business problems and technology solutions. Therefore, we can say that they are in the middle of both application and enterprise-level concerns.

That’s why we can see them as sometimes a jack of all trades because of their narrow focus on individual applications but expand their knowledge and skills when needed to broader technical and strategic concerns.

Solution architects don’t require coding skills, but some of them do understand coding. That’s why they can communicate well with a developer team.

Enterprise Architect

Enterprise architects operate strategically, working with executives to achieve company goals. Moreover, their primary goal is to align technology with business strategy.

Here are things I’ve seen in the field of EA:

  • They maintain the holistic vision of the development initiatives
  • Harmonizing requirements across the large scale projects
  • Guiding agile teams through business and technical roadmaps.

Try to imagine that you’re a newly onboard EA on the organization. You start by looking into the company’s mission.

From there, you derive the vision and ask why the company wants to move in a specific direction? Once you have answered the why, you’ll eventually sit down, talk with the leadership, and determine how to align everything at the strategic level.

Benefits of Building an EA Team Within an Organization

Eventually, companies outgrow consulting, contracting, or outsourcing companies for strategic decision-making. This is when companies possibly decide to create an in-house EA team or department. I’ve seen many cases of this while working for an outsourcing company.

OK, maybe you’re asking: “What’s the point of having an EA team within the organization?”. To answer this, it basically starts with the alignment between the corporate mission and product development.

In most cases, organizations with an in-house development team usually focus on the technology and face many problems at hand. Over time, they can be disconnected from the real business value of the organization. That’s why having an EA team can help the organization focus on delivering real business value.

Another significant benefit is the constant evaluation of changing requirements, and the technology available to support their business requirements are constantly shifting. Practices like Agile and Agile-Architecture can keep the development adapt to change.

Lastly, the knowledge gathered, documented, and managed by the EA is valuable. This will help the organization centralize its knowledge storage and make it available to architects, developers, and business stakeholders.

Summary

In this article, we have discussed the following,

  • What is Enterprise Architecture (EA)?
  • Difference between a developer and an architect
  • Three main types of architectural scopes
  • Benefits of building an EA team within an organization

I hope you have enjoyed this article as I have enjoyed writing it.
Stay tuned for more. Until next time, happy programming!
Please don’t forget to bookmark, like, and comment.
Cheers, and Thank you!

Oldest comments (0)