Enterprise Architecture

What architecture is about: providing options, analyzing options, and choosing the best option to solve the problem.

Architecture starts with the customer requirements, translate these into specifications for a product or a service. 

Enterprise Architecture (EA) : It’s the sum of strategy, business, and technology.

EA focus on the business goals, supported by technology.

If customers were demanding new products or services. 

Who were these customers? 

Why did they want new products? 

Where were these customers located? 

Where could new customers be found and how could a company increase market share? 

Was a company ready to scale? 

Were systems prepared to scale?

Types of Architecture Diagrams:

• Conceptual Architecture Diagram: Basic technical diagram, highlights the relationships between key components, used to show direction of the solution and isolate domain areas.
• Logical Architecture Diagram: After the Conceptual diagram(s). Logical diagrams describe how a solution works in terms of function and logical information. It illustrates connectivity between applications and therefore the flow or sequence between components. The value is that this helps instruct the software development teams on how to implement a solution.
• Physical Infrastructure Architecture Diagram: This depicts physical elements that enable the infrastructure team to do their work including server models/VMs/Containers, databases/storage, network, zones, systems and sub-systems, and connectivity. This is very detail oriented.
• Sequence Diagram: This illustrates the steps required to complete a process; vertically list the components and use horizontal lines to show the interactions as steps between the components.
• Systems Context Diagram: for business user’s, shows the systems involved and excludes systems that are not.

Free website to design application Architect 

• https://app.diagrams.net/
• https://sequencediagram.org/
• https://editor.swagger.io/

Enterprise Architecture Components: 

Organizational Architecture: It addresses where people sit in the organization and what their tasks are in alignment with the strategy of the organization. 

Business architecture: defines the purpose of the enterprise, the different functions, and critical processes needs to operate the business.

Application architecture: lays out the patterns to build and operate the applications. defines the integration between applications.
The application architecture should follow the business architecture.
For example, business architecture has a business requirement to create a dashboard for market and customers to show market insights, and customer satisfaction surveys (CSAT).
this will reflect to application architecture, to create a relation between BI and customer relationship systems.

Data or information architecture: defines the data models [input, output], including how data is stored and securely transported between systems.

Technological architecture (IT): This architecture defines the infrastructure that hosts the applications and the data. include all technical elements in details such as network , compute, storage, and interfaces.

Enterprise Architecture Positions

System architecture (Infrastructure Architecture):  create a low level detail describe how systems are built and configured include software and hardware components, describing exactly what type of hardware is used and what software, operating systems and middleware. 

Just mentioning that a system runs Linux is not sufficient in this architecture; 

it must mention the used Linux version and how the operating system is configured, what security policies have been applied. 

This is equal to the Technological Architecture that we defined in EA Components. 

Technical architecture (Software architecture): This architecture contains the details on the technical landscape and shows how systems are related to each other. It shows the data flows, applications, and services used to fulfill solution requirements. As an example, the technical architecture shows how an application is connected to a specific database or how the application is communicating to the outside world, using Internet gateways or other connections. This is mapped to the data and application architecture component. The details of the configuration of the database server are part of the system architecture. The technical architecture will show what instances the database holds (think of databases with customer data, where every region of the enterprise has its own database instance); the system architecture will tell that the server runs SQL on top of a Windows operating system and in what versions.

Solution architecture: This architecture is about fulfilling specific business requirements and aims on creating value. It shows how the technical architecture and the systems are brought together to create a solution addressing a specific need of customers. So, we have a technical solution showing what databases the enterprise has and how they functionally look like, and we have a system architecture telling that the database is running Windows and SQL. But that’s not a solution. A solution answers the question how systems and technical architectures help solve a business issue or problem. In this case, the business requirement might have been to provide a solution to store customer data per region in a database. That resulted in a solution choosing for a specific setup of the database and how this setup can be technically fulfilled. System and technical architecture must be aligned with the business architecture.

Enterprise architecture: holds the business strategy, defines the governance on architecture on various levels, and drives the digital transformation of the entire enterprise. This architecture doesn’t just cover the one solution for regional databases holding customer information, but for every system in the enterprise landscape. The enterprise architecture forms the guardrails for any other architecture in the enterprise, including a clear definition of processes to work with architecture.

Quality Function Deployment steps(QFD) [Six Sigma management strategy] :

1- Product planning: Identify and prioritize customer requirements, using the Voice of the Customer (VOC).

2- Product design: Ideas and concepts are developed, leading to product specifications.

3- Process planning: Define how the product must be developed.

4- Process control: The actual production is planned, including testing and validation against the specifications as set in the VOC. In this stage the House of Quality (HOQ) is used for validation.

From Monolith to Modern and Micro

Monolith systems are designed as “one piece” and are very hard to change. New requirements that would lead to new features and changes create risks,limit the speed of changes.

by time, System architecture will start to deviate from the original architecture making it even harder to innovate and address changing business needs while keeping the quality, availability, and reliability of the systems intact. This makes it mandatory to review and redesign the architecture of these monolithic systems; otherwise, they will slow down change or even cause business changes to come to a full stop.
Imagine what happens if the business strategy needs to be changed?

In microservices, each functionality is captured by a separate service. Presenting data or content is a separate service that can now connect to various platforms that hold data. If one platform is not responding, the presentation service can connect to another platform and make sure that the service to the customer is still delivered. 

A microservice architecture consists of loosely coupled elements, but it also means that building and operating teams will be loosely coupled.

Benefits of Microservices:

- Agility: Teams don’t develop an entire application, but only develop a service, team only needs to worry about that specific service, This decreases the development time dramatically.

- Resiliency: decreases the risks of a single point of failure. 

- Scalability: Microservices are developed in such way that they can be deployed in multiple applications and systems. That makes them scalable.

- Business Impact: development cycles are shorter and systems suffer less from downtimes. Less downtime means lower costs, customers will be happier since services are less interrupted and products continuously improved.

But keep in mind, Amazon paper   at Mar 22, 2023 and this link also, concludes that 

"Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis. Moving our service to a monolith reduced our infrastructure cost by over 90%. It also increased our scaling capabilities."

Models:

1) BAIT model: describe Business, Application, Information, and Technology

2) Zachman Framework: a methodology to describe complex things, it provide insights in how the enterprise operates.

3) TOGAF:

provide a step-by-step approach on how to do an architecture [ADM Cycle]. 
Architecture Development Method (ADM) cycle

TOGAF reasoning:

- What business problem are we solving?

- What interface (application) needed to get the information?

- What information needed to solve the business problem?

- What technology needed to solve the business problem in the most optimized way?

4) IT4IT Framework : focus to deliver value, develop and deliver products and services based on market and customer demand.

Main value streams:

- S2P or Strategy to Portfolio:  alignment business strategy and the IT portfolio that required for strategy.

- R2D or Requirement to Deploy: high-quality results for business while focusing on reusability, agility, and collaboration across IT.

- R2F or Request to Fulfill: optimizing delivery of services, experience of the user.

- D2C or Detect to Correct: maintain the value for the user. It uses IT service management (ITSM) processes such as incident management, problem management, configuration management, and change management.  D2C supports in service-level monitoring, detection, and remediation of issues so that the user is not impacted by issues.

5) Open Agile Architecture (O-AA)

Requirements to become an agile enterprise:

- Get rid of silos and aim for interdisciplinary collaboration, focused on the best outcome for the customer.

- To become agile, teams must be empowered to take decisions for themselves. Therefore, teams must be skilled to spot opportunities and quickly identify and classify risks.

Change management is something different than feature management. 

New features come from requirements. Architect should validate 

1) Impact of requirements in terms of the overall business strategy. 

2) Does feature adding value? 

3) What is the impact of developing new features? 

4) What resources are required, what are the costs, and what is the value driver? 

Change control aspects:

• Scope

• Time

• Resources

• Risks

• Stakeholder views/ resistance

• Costs

• Quality