How are architects made

How are architects made

This is the 25th day I participated in the Wenwen Challenge. For details of the event, please view: Wenwen Challenge

Software architect definition

  • The career development direction of software engineers:

  • Software Architect:
    • Software experts who make high-level design decisions and determine technical standards, including programming standards, tools, and platforms
  • Software Architecture:
    • The basic organization of the system, this organization is mainly reflected in its components, the relationship between components, the relationship between components and the environment, and the principles that determine system design and evolution
    • Architecture is the blueprint of the system, describing the structure and key decisions of the system
    • The architecture contains the functional and non-functional requirements of the system:
      • How is the system implemented?
      • How are systems and subsystems divided?
      • How do systems communicate?
      • How are system functions designed and interactive?
      • Contains important architectural decisions, system composition, functional design, technology selection, cost analysis, etc.
    • The basis of the architecture is to design a system that meets customer needs, which includes functionality, non-functionality, quality and constraints

  • The architect must be responsible for writing the most core and most difficult parts of the entire system, and design a team development method, and be able to see future changes based on programming experience
  • If a team needs an architect, it must be the one with the best code ability, who can be responsible for the development of the core business, and cannot be divorced from the actual business

What roles are included in the project:

  • Customer: The person who pays for the system development and pays attention to the business value of the system
  • User: People who use the system, pay attention to whether to meet the functional requirements, improve efficiency and ease of use, etc.
  • Project Manager: Responsible for project management, organization, coordination, communication and other management work
  • Demand Analyst: Responsible for demand-related work, such as business analysis, demand acquisition, demand research, demand management, writing demand specifications, etc.
  • System Architect: Responsible for overall system analysis, architecture planning, technology selection, architecture design of core functional requirements and non-functional requirements
  • System designer: based on the architecture model, carry out detailed design of core functions and non-core functions
  • Developer: Complete coding and unit testing according to the architecture design and detailed design, and reach the test standard
  • Testers: verify whether the development functions meet the requirements, such as functional testing, integration testing, performance testing, stress testing, security testing, regression testing, etc.
  • Operation and maintenance personnel: responsible for the deployment, deployment and daily maintenance of the deployment environment

Architect responsibilities

  • Architects need to establish an efficient and excellent system to complete the project within the specified time
  • The architect needs:
    • Identify definitions and confirm requirements
    • Decompose the system to form an overall structure
    • Correct technology selection
    • Develop technical specifications and effectively promote the implementation
  • The role of the architect:
    • Understand and resolve requirements
    • Create useful models
    • Confirm and refine the extended model
    • Management structure

Software architecture level

Application level

  • Lowest level architecture
  • Low level, but very detailed
  • This level of communication is generally carried out within a development team

Solution level

  • Middle layer of architecture
  • Focus on one or more applications that meet business needs, i.e. business solutions
  • Some of these designs are high-level, but most of them are low-level designs
  • This level of communication began to involve multiple development teams

Enterprise-level architecture

  • The highest level of the architecture
  • Focus on multiple design options
  • The design level of this architecture is high and abstract, so it also requires solution-level and application-level architects to refine this
  • This level of structure requires multiple organizations to communicate
  • The architect can be seen as the glue between different working groups:
    • Horizontal: Build a communication bridge between the business department and developers or different development teams
    • Vertical: Building a bridge between managers and developers
    • Technology: Integrate different technologies or applications

Solution Architect

Understanding of working methods
  • Understand and explore customer pain points, project definitions, and existing environmental management
  • Sort out high-level requirements and non-functional requirements
  • What solutions already exist for customer problems
  • Communication, proposal proposal, multiple iterations, delivery of the overall architecture
  • Architectural decision
Duties
  • From the customer view:
    • Strengthen high-level customer confidence: use architecture and solution capabilities to help customers choose relevant solutions
    • Solve customer middle-level problems: use relevant solutions to help customers solve business problems and obtain business value
    • Leading customers IT staff: technology leading, method leading, product leading
  • From the project view:
    • Docking management department: report on technical plans, progress, and technical communication
    • Docking PM, project PM: assist in project planning, personnel management, etc. Responsible for the guidance of all technical deliverables
    • Docking business departments and demand personnel: understand and explore pain points, help sort out high-level business needs, and guide demand processes
    • Docking development: product support, technical guidance, architecture guidance
    • Docking test: Cooperate with test plan and process development. Cooperate with performance test or non-functional test
    • Docking operation and maintenance: product support, operation and maintenance support
    • Docking configuration and environment: product support
    • Integration of other resources

Responsibilities of Software Architect

  • Define and determine the required development technology and platform
  • Define development standards, such as programming standards, tools, review procedures, test methods, etc.
  • Provide technical support for determining and understanding business needs
  • Design the system and make decisions based on needs
  • Discuss and record architecture definition, design and decision-making
  • Check and review the architecture and code, such as checking whether the patterns and programming standards determined in the early stage are correctly implemented
  • Collaborate with other departments and architects
  • Guidance and consultation for developers
  • Refine the high-level design and transform it into a lower-level design

  • According to the system design and implementation process:
    • Support the pre-sales or demand stage, provide conceptual architecture or technical consultation
    • System analysis, architecture design, technology selection, output architecture solutions
    • Instruct project team members to complete, develop, test and release in accordance with the architecture design
    • Develop or design development framework, formulate coding or programming specifications, design architecture prototypes, verify architecture prototypes
    • Organize technical or architectural training, and take my technical or architectural direction
    • Achieve the balance of the plan with the cost, communication with stakeholders, technical risk management, technical leaders
  • According to the project phase:
    • Pre-sales stage: provide business support, provide system solutions and architecture consulting
    • Demand stage: Together with demand analysts, participate in project communication, assist in completing technical or business consultation and demand models, and take into account the status of business experts
    • Architecture stage: system analysis and design, system abstraction, system model design, technology prototype, architecture prototype development, etc.
    • Design stage: guide the designer to complete the detailed design
    • Development stage: guide developers to implement design and solve technical problems
    • Test phase: guide testers to work, especially non-functional requirements testing
    • Release stage: Instruct the deployer to deploy according to the deployment architecture, and answer or feedback on the architecture issues during operation in a timely manner
    • Other tasks: technical selection, personnel training, technical guidance

Software architect workflow

  • The workflow of the architecture is the process and method of how a system goes from requirements, architecture to realization
  • Good architecture:
    • In addition to technical and architectural design capabilities, architects also need to have good and rich business knowledge
    • From the perspective of software engineering, architects must not only participate in the system architecture and design phases, but also participate in the requirements analysis phase, development, testing, release, and trial operation phases.
  • Demand analysis mainly includes demand model, architecture model, design model and solution model:
    • Demand model: Participate in demand analysis and demand model design, provide technical advice or guide demand definition, and provide solution guidance
      • Main participants: demand analysts, business analysts
      • Supporting participants: architects, designers
    • Architecture model: According to the demand model, the output architecture model
      • Select architecture objects: key processes, core use cases, and non-functional requirements
      • Process modeling: sort out key processes of requirements, analyze business objects, subsystems, and modules, and design system interaction processes
      • Domain modeling: sort out the objects designed in the business process, subsystem modules, partition subsystems, modules, core objects, communication mechanisms, transaction models, etc.
      • Output overall architecture: According to the domain model and business process model, combined with component architecture, deployment architecture, communication mechanism, output system body architecture scheme
      • Architecture verification: verify the usability of the architecture, which can be reviewed or actual test verification in the way of review or architecture prototype
      • Main participants: architects, architecture committee
      • Auxiliary participants: system designers, developers, testers
    • Design model: Under the guidance of the architect, complete the outline or detailed design of each subsystem, module, function, and interface according to the system architecture
      • Main participants: system designer, senior engineer
      • Supporting Participant: Architect
    • Solution model: architecture model, design model, architecture prototype and other unified architecture solutions
  • A complete system architecture includes:
    • Overall structure
    • Subsystem
    • Module
    • Function summary or detailed design
    • Communication mechanism
    • Transaction mechanism
    • Interface definition, including internal and external
    • Domain model
    • Business Process
    • Database Design
    • Middleware
    • Component architecture
    • Deployment architecture
  • System solution standard:
    • Meet functional and non-functional requirements
    • The scale and cost that meet the requirements of the project
    • Meet development, testing and release requirements

Software Architect Competency Model

General ability

Architectural thinking

Top-down architecture
  • Define the problem:
    • The most important thing in defining the problem is to define the customer s problem
    • Define the problem, especially identifying the key problem.
    • The key problem is to have a sense of the customer and be able to solve the customer's pain points, which can be measured and identified through a certain amount of data, and the key problems should be given priority
  • Add the time dimension to the problem definition:
    • Distinguish between solution and problem definition
  • Analyze the problem definition:
    • You need to think about the problem and then think about it, so as to truly grasp the essence of the problem, clarify and dig out the needs.
    • Make good use of first-principles thinking to analyze and think about problems
  • Problem solving principle:
    • Mission: Solve customer problems first
    • Vision: Only then can we solve our own problems
    • The emphasis is on what problems can be solved for customers, and then what can we become, and how to better serve customers
  • Make good use of a variety of methods to analyze customer problems:
    • Convert customer problems into capabilities that products and platforms need to provide
    • For example, what business capabilities can WMS provide?
  • Sort out existing processes and capability models:
    • Find the areas that need improvement, upgrade thinking and upgrade thinking really clarify the part of improvement
  • Define indicators:
    • Define indicators and be able to disassemble the indicators, and then perform mathematical modeling
  • Competence requirements are transformed into technical challenges:
    • Transforming the ability requirements into the technical staff's solution design requires a bottom-up architecture derivation
  • Innovation:
    • Innovation can be business innovation, product innovation, technological innovation, or operational innovation
    • Upgrading thinking, upgrading thinking, using first-principles thinking to help you discover different innovation possibilities in business, products, and technology
    • Philosophy thinking is the soul thinking of architects
Deriving the application architecture from the bottom up
  • 1. according to the business process, the system sequence diagram is decomposed, and the modules are summarized according to the sequence diagram, so as to obtain a module with a larger granularity, and the entire system architecture is constructed through the combination or aggregation of the modules.
  • The derivation of the application logic architecture has 4 sub-paths:
    • Business concept architecture: derived from business concept models and business processes
    • System model: derived from business conceptual model
    • System flow: from business process
    • Non-functional system support: comes from the demand for performance, stability, and cost
  • The three main factors that most affect the landing of logical structure into physical architecture:
    • effectiveness
    • stability
    • performance
  • From logical architecture to physical architecture, we must first make clear quantitative requirements for efficiency, stability and performance
  • Bottom-up depends on deduction and induction:
    • If the product plan is clear, the programmer needs to understand the business requirement and derive the architecture based on the product plan, generally using a bottom-up method. Domain modeling is this bottom-up analysis method
  • Deduction: Deduction is logical deduction, the lower the level, the more deduction is needed
    • From use case to business model is deduction
    • From business model to system model is also deduction
    • According to the current problems, it is also deductive to deduce that some stability measures need to be implemented.
  • induction: Induction is to classify things according to a certain dimension. The higher the level, the more classification is needed
    • The problem space module division belongs to induction
    • Some logical structures also belong to induction
    • According to a bunch of stability problems, the corresponding operations that are required before, during and after the event are summarized in the time dimension.
Domain Driven Design Architecture
  • Domain division design steps:
    • Analyze user demand scenarios and identify use cases in all dimensions of the business
    • Analyze the robust graph of the model and identify all the entity objects in the business scenario
      • Robust graph:
        • A method used in the requirements design process-robustness analysis
        • Robust analysis allows designers to have a clearer and more comprehensive understanding of requirements
        • Usually used for software architecture analysis after requirements analysis and before requirements design, mainly focusing on the design and analysis of functional requirements
        • The requirement specification is its input information, and the design model is its output information
        • It is the first step in the transition from functional requirements to design solutions, focusing on identifying the high-level responsibility modules that make up the software system and planning the relationship between the modules
        • Robust graphs contain three types of graphs:
    • Domain division, classify all identified entity objects
    • Evaluate the rationality of domain division and optimize
Based on data-driven design architecture
  • With the development of IoT, big data and artificial intelligence, the previous domain-driven architecture often fails to meet the needs or achieve the expected results.
  • In the application scenario of big data:
    • From domain analysis and upgrading to business architecture, application architecture, data architecture and technical architecture based on big data statistical analysis results
    • Need to have the basis of mathematical statistical analysis and the ability of BI, and use data thinking to structure the system
    • For example, Ali's data analysis platform Caiyunjian and Cainiao's data analysis platform FBI

Professional competence

  • Architects of enterprise-level applications: load balancing, clustering, distributed, high concurrency, high availability, easy management, etc., theoretical capabilities and hands-on coding capabilities need to be improved at the same time. Focus on design ideas and design patterns, and be unremitting for cutting-edge technologies Pursue and delve into it, so that we can make a reasonable decision when selecting the technical architecture
    • Data layer: The focus is on the choice of cluster scheme
      • For example, MySQL cluster, there are many cluster solutions, and you need to choose a solution that suits your business: such as multi-master, master-slave, read-write separation
      • Do you still need to do high availability, do you use lvs, or zookeeper
      • Do you need mycat class middleware to manage the database or do data sharding, etc.
    • Service layer:
      • Choosing Dubbo is mainly used for high-concurrency systems. Microservices allow the team to develop less coupling, and each cares about their own modules and publishes them as services.
      • Traditionally use SpringMVC+RESTful
      • The choice of cache, you can use memcached, ehcache, redis
    • Application layer: choose a framework that suits the team
    • Network layer: understand F5 and the like
    • deploy:
      • Do you need to deploy with Docker? The open source Docker container makes the deployment lightweight and easy to expand a node. It can be used for scenarios with high concurrency and high scalability requirements, and one-click deployment can be achieved
      • Whether you need load balancing, you can choose hard load F5 or soft load nginx
      • The soft load scheme can be apache+tomcat, and session replication needs to be considered
      • You can also choose lvs+haproxy, package release, use maven proficiently, establish your own maven private server, and guide project members to use maven release
    • Security: Most security issues are solved at the network layer, but application security cannot be ignored
      • Need to consider SQL injection, authorization and authentication
      • The key security problem comes from the framework itself, try to solve the application vulnerabilities in the open source framework
    • Other aspects: automated testing, version management, big data, artificial intelligence

Required skills

design
  • Theoretical level:
    • Understand basic design patterns
    • Study patterns and anti-patterns
    • Understand quality metrics
  • Practical level:
    • Try to understand different technology stacks
    • Analyze and understand application patterns:
      • View current popular frameworks
      • Learn many patterns in practice
      • Understand how to apply patterns in the framework and why you should do it
      • Delve into the code and understand how it is implemented
decision making

Architects need to make decisions to guide the project and even the entire company in the right direction

  • Distinguish the priority:
    • Conceptual integrity
    • consistency
  • priority
  • Recognize your abilities and clarify your responsibilities
  • Evaluate multiple options
simplify
  • Multi-directional observation solution
  • Divide and conquer
  • Refactor
Programming
  • Development side projects:
    • A large number of programming languages, frameworks, tools, processes and practices
  • Try only what needs to be tried
recording
  • Architecture Document
  • Clean code
  • Generate documentation when possible:
    • Use tools to generate documentation: Swagger, RAML
  • Remember as many necessary things as possible, with as little content as possible:
    • Is all the necessary information to understand the file included
    • What information is really needed and what can be omitted
  • Learn more about the architectural framework

Growth mode

Breadth
  • Breadth: The architect should have a comprehensive and clear understanding of the mainstream technology system in the field. Each technology does not require in-depth understanding, but must guide the three levels of each technology
    • The origin of each technology, why does this technology appear? What kind of problem is this technology used to solve?
    • What is each technology? What are the basic components of the technology?
    • What are the advantages and disadvantages of the same technology to solve the same problem? Which scenario is more suitable? Only by clearly understanding the advantages and disadvantages of the same type of technology can we use more reasonable technology in technology selection
  • Breadth learning method: learn three levels of content through search engines one by one for each mainstream technology
height
  • Height: Architects should have the ability to build abstractions from messy information
    • Business abstraction: able to abstract core business entities from the complex requirements of software and products, and establish reasonable relationships between business entities
    • Technology abstraction: Able to hierarchically abstract complex technical architecture, service abstraction or microservice abstraction, component abstraction, and establish a reasonable relationship for calls between layers and services
  • High learning method: Deeply understand and learn object-oriented, design patterns, and ponder the design principles and design ideas of excellent open source frameworks
depth
  • Depth: The architect has an in-depth understanding of mainstream technologies
    • Have a basic and comprehensive understanding of the principles and operating mechanisms of mainstream technologies
    • At least have an in-depth understanding of one technology, be an expert in this technology, and be familiar with the source code
width
  • Width: Architects must be familiar with current technological frontiers and hotspots, and be able to use new technologies to solve problems. Such as microservices, big data, cloud computing, artificial intelligence
  • Width learning method: Subscribe to related technical consultations, learn regularly, and learn more about the technology related to the work you are responsible

Software architect technical ability

  • The software architect must be able to solve the problem: in a system, if many modules are disassembled, which machines should be deployed on
    • Slow SQL optimization
    • Memcache cache
    • Load balancing
    • Hot standby, cold standby, dual active
  • According to different application needs, design different strategies, and at the same time standardize these scenarios, and become a standard that the entire team must follow:
    • Penetrate DB
    • Failure strategy
  • The choice of each technical framework has been discussed, verified, tested, and finally implemented in the whole team:
    • Tuscany
    • Scallop
    • Hadoop
    • ActiveMQ
    • Erlang
    • hertrix
    • DevOps
  • Architect responsibilities:
    • Need to understand from front to back
    • Need to develop key technical details and give best practices
    • Need to understand all popular solutions in the industry
    • Can these plans be taken over, and they are also applicable to their own scenarios?
  • The architect needs to be proficient in:
    • distributed
    • Nginx
    • F5
    • Microservice
    • Cache
    • Persistence
    • message queue
  • Architects need to be familiar with:
    • The most commonly used solutions in all technical details must not be missed or over-designed
  • Architects also have to shoulder the task of fixing open source software bugs. You need to look at the source code, understand the ideas of the open source framework, and then find the places that may cause problems, and then fix them.
  • Architects need to understand all the underlying things in an effective time, TCP/IP detailed explanation
  • There is no architect who does not understand the business, all architectures depend on the business:
    • All architects must also write business code
    • If you don t use what you design in a real project, you will not understand the rationality of the architecture design.

General framework

TOGAF
  • TOGAF: The Open Group Architecture Framework
  • TOGAF emphasizes business goals as the driving force of the architecture and provides a repository of best practices:
    • TOGAF architecture development method ADM
    • TOGAF architecture content framework
    • TOGAF reference model
    • ADM framework development method guidelines and technology
    • Enterprise continuum
    • TOGAF competence framework
ADM
  • ADM is an iterative sequence of steps to develop an enterprise-wide architecture approach:

  • Architecture content framework:

  • Reference model:

  • ADM guidelines and technology:
    • Architecture iteration stage:
    • Use ADM in different level areas:

  • Stakeholder classification:

  • Enterprise Continuum:
    • Architecture guidance and support solutions:
      • basis
      • Universal system
      • Industry organization specific
  • Competence framework:

DODAF
  • DODAF is an organizational mechanism that controls "EA development, maintenance, and decision generation" . It is an overall structure for unified organization of "team resources, description and control of EA activities"
    • DODAF covers all business areas of DoD
    • Defines a standard method for representing, describing, and integrating many architectures within the scope of DoD to ensure that the architectures are comparable and evaluated
    • Provides the basis for the understanding, comparison, integration and interoperability of the system family Fos and the system SoS common architecture, and provides rules and guidelines for the development and expression of architecture descriptions
  • The core of DODAF is 8 viewpoints and 52 models:

  • Panoramic Viewpoint AV
    • A top-level overview of the architecture description related to all viewpoints
    • Provide general information about the architecture description:
      • Scope of architecture description:
        • professional field
        • time frame
      • The background of the architecture description:
        • regulations
        • Tactics
        • technology
        • program
        • Description of related goals and ideas
        • Combat Concept CONOPS
        • Environmental conditions

  • Capability Viewpoint CV
    • Concentrates on the organizational goals related to the overall vision. These visions are able to carry out a specific course of action or achieve the desired effect under specific standards and conditions, and use various means and methods to complete a set of tasks.
    • Provides a strategic background and corresponding high-level scope for the capabilities described in the architecture description, which is more comprehensive than the scenario-based scope defined in the operational concept diagram
    • These models are high-level, and describe capabilities in terms that are easy for decision makers to understand, so as to communicate strategic ideas for the evolution of capabilities
  • Operational Viewpoint OV
    • It collectively reflects the organization, task, or action performed to complete the DoD mission and the information that must be exchanged between each other
    • Describe the exchange of information:
      • species
      • Frequency
      • nature
      • What tasks and activities are supported by information exchange
  • Service Viewpoint ScvV
    • Centralized reflection of the systems, services and intertwined functions that provide support for combat operations
    • The DoD process includes operations, operations, intelligence and infrastructure functions
    • SvcV functions and service resources and elements can be linked to the architecture data in OV . These system functions and service resources support combat operations and promote information exchange
  • System Viewpoint SV
    • Concentrate on information that supports automated systems in combat operations, cross-links and other system functions
  • Digital Viewpoint DIV
    • Data and Information Viewpoint DIV: Refers to the data and information viewpoint
    • Reflects the business information requirements and structured business process rules in the architecture description
    • Describe the relevant information exchanged with the information in the architecture description, such as attributes, characteristics and interrelationships
  • Standard viewpoint StdV
    • The smallest set of rules used to control the arrangement, interaction and interdependence of various components or elements of the system
    • The purpose is to ensure that the system can meet a specific set of operational requirements
    • Provide implementation guidelines for technical systems, establish common building blocks based on engineering specifications, and develop product lines
    • include:
      • technical standard
      • Executive convention
      • Standard option
      • Standard rules
      • Standard Specification
    • These standards can form a document profile of the management and control system and system or service elements in the specific architecture description
  • Project Viewpoint PV
    • It collectively reflects how the project organically forms an orderly combination of procurement projects
    • Describe the relationship between multiple acquisition projects, each acquisition project is responsible for delivering specific systems or capabilities