What is an Enterprise architecture?

Question

I am a web developer, I want to become software architect, and I learn everyday about it, but when I am learning software architecture I see TOGAF framework for enterprise architecture, I want to get solid understand in an enterprise architecture.

Answer 1

I have presented on Enterprise Architecture a few times over the past couple of years. One of the quotes (from myself) that I use in my talks is: "Just because I am an Enterprise Architect, that does not mean that I am an Enterprise Architect". That might seem like a strange quote but it's basically just a fun way to say that enterprise architecture can mean different things to different organizations and people.

Enterprise architects tend to work across a broad domain of concerns, occasionally focusing on specific aspects of a specific technology and/or business process. Some organizations (they tend to be the ones with a more mature EA practice) will have architects that work across all domains within the organization (or, enterprise - hence enterprise architect). Some organizations will have specific types of architects (e.g. applications architect, solutions architect, data architect, network/systems architect, business architect, etc.) that focus on a particular area. Having various types of architects within an organization is one way to "ease" yourself into the architecture space.

For example, the organization I work for has the role, Lead Developer. Each development team has a lead developer and they essentially act as applications architects (even if that is not their specific title). For someone new to that role, they focus on learning the business domain their team is typically responsible for. They also provide the overall architectural vision and design for the apps their team produces. And, they also work closely with the enterprise architects to ensure they are working within the parameters of the organization as a whole (i.e. not reinventing the wheel or making use of a technology or approach that does not fit within the enterprise architecture as a whole).

Starting out as a lead developer is one way to get your foot in the door, so to speak. There are other ways. For example, if you're interested in data architecture, then joining a BI team would be a great way to learn more about data architecture at scale. Joining a network team would go a long way toward gaining knowledge that could be applied as a network/systems architect.

You mention TOGAF in your question above but there are many architectural frameworks out there (TOGAF, Zachman, DoDAF, etc.). Depending upon your specific situation, a "canned" framework might make sense for your organization and it might not. However, becoming familiar with some of the available frameworks will give you insights into some of the common challenges faced by enterprise architects. In the end, however, you will want to do what is right for your organization. You might take bits and pieces from multiple frameworks and wrap them all up into your own framework. As with many challenges, do what works for you.

Along with everything else, keep in mind that enterprise architects tend to think strategically and keep a focus on the future. That does not mean that they do not think tactically or are not concerned with the "here and now". They just tend to have strengths when it comes to strategy and vision.

While this is a bit of a wordy answer, the reality is that nothing beats experience. If you want to become an enterprise architect then you should try to apply architectural practices to your everyday tasks. The more you work and act like an enterprise architect the more ready you will be when an opportunity presents itself.

Hope this helps!

Answer 2

If you want to be a software architect - aka Application Architect, then TOGAF is useful to know, but not necessary for you. Enterprise architects deal with things that impact the entire organisation, particularly things like Strategy & Planning. Organisational modelling, etc.

They can be sometimes involved as a governance role to ensure alignment with organisational design standards, or security standards. They can also sometimes be involved in setting organisational policy.

Either way - too many people assuming taking the "most senior looking" title will get them the best pay and the best life - this is not always true and an EA role is very very different to a software architect - even though they are both "Architects"

Now getting a solid understanding of Enterprise Archtiecture will be a challenge - because 1. its kind of undefined right now - or more accurately - there is around 460+ different models of what an Enterprise Architecture is - TOGAF only being one of them. 2. Most EAs like to get completely OCD around model definitions, and each one has a different OCD point of view exactly what they are - I should know, I'm one of them :)

One of the best general models I have found is DoDAF, but it sure isn't light bedtime reading. Wikipedia has a reasonably light definition though and it might be worth starting there if you haven't already

Answer 3

Enterprise Architecture (EA) entails the whole organization and possibly beyond. It includes Business Architecture, Information Architecture, Technology Architecture & Application Architecture. EA is strategic and thus it is "What" needs to be done.

Answer 4

Overview

Enterprise architecture focuses on the future state solution for : Current business problem , business strategy , business process improvement (BPI), business process re-engineering and business adventures. If you ask one enterprise architect what they are working on, most likely you are going to find out that they are working on one of these areas, unless they have a more specialized domain, which we cover later in this article.

“The What”

Enterprise Architecture does not prescribe the “how” only the what,

Deliverables

Depending on your company solution lifecycle standards and templates, your deliverable may be called “solution architecture”, “Enterprise Architecture blueprint” or some other name.

Architecture layers

It is a good practice to include in your deliverable minimum six architecture layers:

• Security: End to end view of your solution from security perspective, this captures authentication and access management, data in transit and at rest protection.
• Application: A view of your solution from the application perspective, includes domain specific programming language, and application design patterns and decisions for your font end, back-end and middle tier.
• Infrastructure: This layer shows a view of your running platform, it may include cloud, containerization and virtualization.
• Information: This captures your entire information lifecycle management from data modeling to acquisition, classification, and retirement.
• Network: This architecture layer depicts the network end points and their paths.
• Integration: This layer shows your data transportation and systems conversations, for example it shows your separations of data transportation from orchestration.

While these layers are not the only layers hat you can add to your architecture, you can add more as needed for example “business continuity” and “devops”, but all depends on the type of your organization and objectives.

The Enterprise Architect role

Being an Enterprise Architect (EA) entails command in multiple domains , however most of us in this industry started our careers in one domain such as development, networking, DBA, etc, an architect usually have expertise in at least one of the following and experience in the rest.

• Expertise in one programming language (expert level means very familiar with the language and design patterns specific to the language).
• Expertise in one database vendor ( Oracle, MSSql, DB2) expert level means - - Expertise in SQL , SQL:2016 being the latest standard in addition to server side language (PLSQL, TSQL)
• Experience in networking basic concepts of networking and knowledge of new trends such as software defined networks (SDN).
• Experience in integration patterns
• Experience in infrastructure such as cloud , virtualization and containerization
• Experience in information security: Identity and access management , Data in transit and data at rest protection.

In addition basic knowledge in : Data modeling, data warehousing, big data, Web UI frameworks, major cloud providers, compliance (ie: PCI, HIPPA), IPV4, IPV6, SOA.
And also helps if you have your own vision of the future landscape (ie: server-less , self-rendering services )

Architecture frameworks

There are multiple frameworks that depending on the situation may fit in your deliverables, these frameworks try to address the common architecture patterns in a prescriptive way.

• TOGAF
• Zachman
• DoDAF

---

To answer your question " what s the difference between system architecture, application, software architecture": Application architecture is one of the layers in your architecture. System architecture, software architecture, solution architecture can be used interchangeably. Just don't lose your the big picture .

Some of the inputs for the architecture are

• business strategy.
• use cases
• business cases.
• Business continuity strategy

• Compliance

  Some of the outputs are

• High level designs
  A vertical partition) of your architecture layers.

• Software specifications
  A prescriptive and technology oriented specifications of your solution.