This is the 25th day of my participation in Gwen Challenge

Software architect definition

• Career Direction of Software Engineer:

• Software Architect:
  • Make high-level design decisions and identify technical standards, including programming standards, tools and platforms for software experts
• Software Architecture:
  • The basic organizational structure of a system, which is embodied in its components, the relationships between components, the relationships between components and the environment, and the principles that determine the design and evolution of the system
  • An architecture is a blueprint for a system that describes its structure and key decisions
  • The architecture includes the functional and non-functional requirements of the system:
    • How is the system implemented?
    • How are systems and subsystems divided?
    • How do systems communicate with each other?
    • How are system functions designed and interacted?
    • This includes important architectural decisions, system composition, functional design, technology selection, cost analysis, and more
  • The foundation of architecture is to design systems that meet customer needs, including functional and non-functional as well as quality and constraints

• The architect must be responsible for writing the core and hardest parts of the entire system, and design a way for the team to work together and see the future changes based on the programming experience
• If there is a need for an architect on a team, it must be someone with the best code skills, who can take care of the core business and not be divorced from the real business

What roles are included in the project:

• Customer: The person who pays for the development of the system and focuses on the business value of the system
• Users: the users of the system pay attention to whether the system meets functional requirements, improves efficiency and ease-of-use, etc
• Project Manager: responsible for project management, organization, coordination, communication and other management work
• Requirements analyst: responsible for requirements related work, such as business analysis, requirements acquisition, requirements research, requirements management, writing requirements 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: Detailed design of core and non-core functions based on architectural models
• Developer: complete coding and unit testing according to architecture design and detailed design, and meet the testing standards
• Testers: Verify that development features meet requirements, such as functional testing, integration testing, performance testing, stress testing, security testing, regression testing, etc
• O&m personnel: responsible for setting up, deploying, and routine maintenance of the deployment environment

Architect responsibilities

• The architect needs to establish an efficient and excellent system to complete the project within the specified time frame
• The architect needs to:
  • Identify definitions and validate requirements
  • System decomposition to form the overall architecture
  • Correct technology selection
  • Develop technical specifications and effectively promote implementation
• Architect’s role:
  • Understand and parse requirements
  • Create useful models
  • Identify and refine the extension model
  • Management structure

Software Architecture hierarchy

Application level

• The lowest level architecture
• Low level, but detailed
• This level of communication usually takes place within a development team

Solution level

• The middle tier of the architecture
• Focus on one or more applications that meet business requirements, known as business solutions
• Some of these designs are high level, but most are low level
• This level of communication began to involve multiple development teams

Enterprise architecture

• The highest level of architecture
• Focus on multiple design options
• The high-level and abstract design of this architecture also requires refinement by both the schema and application level architects
• This level of architecture requires multiple organizations to communicate

• The architect can be seen as the glue between different working groups:
  • Horizontal: Bridge communication between business units and developers or different development teams
  • Vertical: Bridge the gap between managers and developers
  • Technology: Integration of different technologies or applications

Solution architect

Working mode understanding

• Understand and explore customer pain points, project definition, existing environmental management
• Sort out high – order and non-functional requirements
• What solutions to customer problems already exist
• Communication, proposal, multiple iterations, delivery of the overall architecture
• Architectural decisions

Duties and responsibilities

• From the customer view:
  • Build customer confidence in senior management: use architecture and solution capabilities to help customers select relevant solutions
  • Solve middle level customer problems: use relevant solutions to help customers solve business problems and gain business value
  • Leading customer IT staff: technology leading, method leading, product leading
• From the project view:
  • Contact management department: report technical plan, progress, technical communication
  • Contact PM, project PM: assist in project planning, personnel management, etc. Responsible for direction of all technical deliverables
  • Contact with business departments and demand personnel: understand and dig out pain points, help sort out advanced business requirements, and guide the process of demand
  • Docking development: product support, technical guidance, architecture guidance
  • Docking test: cooperate with test plan and process development. Cooperate with performance testing or non-functional testing
  • O&m: product support, O&M support
  • Interconnection Configuration and environment: Supported by the product
  • Integration of other resources

Software architect responsibilities

• Define and identify the required development technologies and platforms
• Define development standards, such as programming standards, tools, audit processes, test methods, etc
• Provide technical support to identify and understand business requirements
• Design the system and make decisions based on requirements
• Document discussions on architectural definitions, designs, and decisions
• Review and review the architecture and code, such as checking that the patterns and programming standards identified earlier are being implemented correctly
• Collaborate with other departments and architects
• Guidance and consultation to developers
• Refine the high-level design and transform it into a lower-level design

---

• According to the system design to achieve the process:
  • Support pre-sales or requirements phase, provide conceptual architecture or technical advice
  • System analysis, architecture design, technology selection, output architecture solutions
  • Instruct project team members to complete, develop, test and release architectural design
  • Develop or design development frameworks, develop coding or programming specifications, design architectural prototypes, validate architectural prototypes
  • Organize technical or architectural training, put me in technical or architectural direction
  • Achieve solution balance with cost, stakeholder communication, technical risk management, technical leader
• By project stage:
  • Pre-sales stage: provide business support, system solutions and architecture consulting
  • Requirements phase: participate in project communication with requirements analyst, assist in technical or business consultation and requirements modeling, as well as business expert
  • Architecture stage: system analysis and design, system abstraction, design of system model, technical prototype, development of architecture prototype, etc
  • Design stage: guide designers to complete detailed design
  • Development stage: guide developers to implement according to design and solve technical problems
  • Testing phase: Instructs testers to work, especially non-functional requirements testing
  • Release phase: Guide the deployer to deploy according to the deployment architecture, answer or feedback the runtime architecture questions in time
  • Other work: technical selection, personnel training, technical guidance

Software architect workflow

• Architecture workflow is the process and method of how a system goes from requirements, architecture to implementation
• Good structure:
  • In addition to technical and architectural design skills, the architect is required to have sound business knowledge
  • From the perspective of software engineering, architects should not only participate in the system architecture and design stage, but also participate in the requirements analysis stage, development, testing, release, commissioning stage
• Demand analysisMainly includesRequirements model, Architecture model, Design Model and solution model:
  • Demand model:Participate in requirements analysis and requirements model design, provide technical advice or guide requirements definition, provide solution guidance
    • Key players: Requirements analyst, business analyst
    • Supporting participants: architects, designers
  • Architectural model:Output architecture model according to requirements model
    • Select architecture objects: key processes, core use cases, and non-functional requirements
    • Process modeling: Sort out the key process of requirements, analyze business objects, subsystems and modules, and design the interactive process of the system
    • Domain modeling: sorting out design objects, subsystem modules, partition subsystems, modules, core objects, communication mechanisms, transaction models, etc
    • Output overall architecture: according to domain model and business process model, combined with component architecture, deployment architecture, communication mechanism, output system architecture scheme
    • Architectural validation: Verification of the usability of an architecture, either by review or by actual testing of an architectural prototype
    • Key participants: architect, architecture committee
    • Supporting participants: system designers, developers, testers
  • Design model:Under the guidance of the architect, complete the outline or detailed design of each subsystem, module, function, interface according to the system architecture
    • Key participants: System designer, senior engineer
    • Supporting participant: architect
  • Solution model: Architecture model, design model, architecture prototype and other unified architecture solution
• A complete system architecture includes:
  • The overall architecture
  • The subsystem
  • The module
  • Functional summary or detailed design
  • Communication mechanism
  • Transaction mechanism
  • Interface definitions, both internal and external
  • The domain model
  • The business process
  • Database design
  • The middleware
  • Component architecture
  • Deployment architecture
• System solution standards:
  • Meet functional and non-functional requirements
  • Scale and cost to meet project requirements
  • Meet development, testing and release requirements

Software architect competency model

General ability

Architectural thinking

Build the architecture from the top down

• Defining the problem:
  • The most important part of defining the problem is defining the customer’s problem
  • Define the problem, especially identify the key problems.
  • The key problem is to have a sense of the customer, to be able to solve the pain points of the customer, to measure and identify the key problems through certain data, and to give priority to the solution
• Add time dimension to problem definition:
  • Distinguish between solution and problem definition
• Definition of analysis problem:
  • It is necessary to raise the level of thinking on the problem and then raise the dimension of thinking, so as to really grasp the essence of the problem, clarify and excavate clear needs
  • Think analytically using first principles thinking
• Principles of problem solving:
  • Mission: solve customer problems first
  • Vision: Then you can solve your problems
  • The emphasis is on what specific problems can be solved for customers, and then what can we become, so as to better serve customers
• Use a variety of methods to analyze customer problems:
  • The ability to translate customer problems into products and platforms needs to provide
  • For example, what business capabilities can warehouse system WMS provide
• Comb through existing process and capability models:
  • Find out what needs to be improved, and ascending thinking and ascending thinking really identify what needs to be improved
• Defining indicators:
  • Define indicators and be able to disassemble indicators and then conduct mathematical modeling
• Capability appeals turn into technical challenges:
  • The transformation of competency appeal into technical personnel’s solution design requires a combination of bottom-up architectural derivation
• Innovation:
  • Innovation can be business innovation, product innovation, technology innovation, or operation innovation
  • Ascending thinking, ascending dimension thinking, using first-principles thinking to help me find different innovation possibilities in business, product and technology
  • Philosophical thinking is the soul thinking of architects

  

Derive application architecture from the bottom up

• First, according to the business process, the system sequence diagram is decomposed, and modules are summarized according to the sequence diagram, so as to obtain modules with larger granularity. The whole system architecture is constructed through the combination or aggregation of modules
• The derivation of the application logic architecture has four subpaths:
  • Business conceptual architecture: Derived from business conceptual models and business processes
  • System model: Derived from business conceptual model
  • System flow: Derived from service flow
  • Non-functional system support: derived from performance, stability, and cost requirements
• There are three main factors that most affect the landing of a logical structure into a physical architecture:
  • The efficiency of
  • The stability of
  • performance
• Moving from logical architecture to physical architecture requires explicit quantification of efficiency, stability, and performance
• Relying on deduction and induction from the bottom up:
  • If the product solution is clear, the programmer needs to understand the business requirements and derive the architecture from the product solution, typically using a bottom-up approach. Domain modeling is such a bottom-up approach to analysis
• Interpretation:Deduction is logical deduction, and the lower you go, the more deduction you need
  • Going from use cases to business models is deductive
  • Moving from a business model to a system model is also deductive
  • Based on the current problems, it is also deductive to deduce that some stability measures need to be implemented
• Conclusion:Induction is categorizing things according to a certain dimension, and the higher the level, the more need to categorize
  • Problem space module division belongs to induction
  • Logical architectures can also be inductive
  • The corresponding operation required to generalize before, during, and after from a bunch of stability problems is to generalize in terms of the time dimension

  

Domain-driven design architecture

• Design steps of domain division:
  • Analyze user requirement scenarios and identify use cases in all dimensions of the business
  • Analyze the model robust graph to identify all entity objects in the business scenario
    • Robust figure:
      • A method used in requirements design – robustness analysis
      • Through robust analysis, designers can understand the requirements more clearly and comprehensively
      • It is usually used for software architecture analysis after requirement analysis and before requirement design, mainly focusing on functional requirement design and analysis
      • The requirements specification is its input information and the design model is its output information
      • It is the first step of the transition from functional requirements to design solutions, focusing on identifying the high-level responsibility modules that constitute the software system and planning the relationship between modules
      • The robust graph contains three kinds of graphs:
  • Domain division, which classifies all recognized entity objects
  • Evaluate the rationality of domain division and optimize it

Based on data driven design architecture

• With the development of loT, big data and artificial intelligence, the previous domain-driven approach to architecture often fails to meet the needs or achieve the desired results
• In the application scenarios of big data:
  • From domain analysis to business architecture, application architecture, data architecture and technical architecture based on the results of big data statistical analysis
  • It is necessary to have the foundation of mathematical statistical analysis and THE ability of BI, and to frame the system with data thinking
  • Such as Caiyunjian, Alibaba’s data analysis platform, and FBI, Cainiao’s data analysis platform

Professional ability

• Architects of enterprise applications:Load balancing, clustering, distribution, high concurrency, high availability, easy management and so on, theoretical ability and hands-on coding ability need to be improved at the same time. Pay attention to design ideas and design patterns, for cutting-edge technology, to pursue and study, so as to make reasonable decisions in the selection of technical architecture
  • Data layer:The key lies in the choice of cluster scheme
    • For example, in the MySQL cluster, there are many cluster solutions. You need to select a solution that meets the service requirements, such as multi-active, active-standby, and read-write separation
    • Do you still need to do high availability, LVS, or ZooKeeper
    • Whether need myCAT class middleware to manage database or do data sharding and so on
  • Service layer:
    • Dubbo is mainly used for high-concurrency systems. Microservices reduce the coupling degree of team development, and they care about their modules and release them as services
    • Traditionally, use SpringMVC+RESTful
    • Cache options can be memcached,ehcache, or redis
  • Application layer: Select the framework that fits the team
  • Network layer: Know about F5 and the like
  • Deployment:
    • Whether Docker deployment is needed, open source Docker container makes deployment lightweight, easy to expand a node, can be used for high concurrency, high scalability requirements of the scene, can achieve one-click deployment
    • Whether load balancing is required, you can choose hard load F5 or soft load Nginx
    • The soft load solution can be Apache + Tomcat, and session replication needs to be considered
    • You can also choose LVS + HaProxy, package and publish, be skilled in using Maven, establish your own Maven private server, and guide project members to publish using Maven
  • Security:Most security problems are solved at the network layer, but application security cannot be ignored
    • You need to consider SQL injection, authorization
    • The key security issues come from the framework itself, trying to solve application vulnerabilities in the open source framework
  • Other aspects: automated testing, version management, big data, artificial intelligence

Essential skill

design

• Theoretical level:
  • Understand basic design patterns
  • Look at patterns and antipatterns
  • Understand quality measures
• Practical level:
  • Try to understand the different technology stacks
  • Analyze and understand application patterns:
    • View the current popular frameworks
    • Learn many patterns by doing
    • Understand how to apply patterns to the framework and why
    • Dig deep into the code and see how it works

Decision making

The architect needs to make decisions that guide the project and even the company in the right direction

• Prioritize:
  • Conceptual integrity
  • consistency
• priority
• Identify your abilities and responsibilities
• Evaluate options

To simplify the

• Multifaceted view of the solution
• Divide and conquer
• refactoring

programming

• Development side project:
  • Lots of programming languages, frameworks, tools, processes and practices
• Try only what needs to be tried

record

• Architecture documentation
• Clean code
• Generate documentation where possible:
  • Generate documentation using tools: Swagger, RAML
• Remember as much as necessary and as little 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 way

breadth

• Scope:The architect should have a comprehensive and clear understanding of the dominant technology architecture in his field. Each technology does not require in-depth understanding, but must guide the three layers of each technology
  • Where did each technology come from and why did it arise? What problem is this technology supposed to solve?
  • What is each technology? What are the basic components of technology?
  • What are the pros and cons of the same technology to solve the same problem? Which scenario is better suited? Only with a clear understanding of the advantages and disadvantages of the same type of technology can a more reasonable technology be used in technology selection
• Breadth learning approach: learn about the major technologies at three levels through search engines

highly

• Height:The architect should have the ability to create abstractions from the clutter of information
  • Business abstraction: Ability to abstract core business entities from complex requirements of software and products and establish rational relationships between business entities
  • Technical abstraction: The ability to perform hierarchical abstraction of complex technical architectures, service abstraction or microservice abstraction, component abstraction, and establish rational relationships between layers and services invocation
• Highly learning methods: In-depth understanding and learning of object orientation, design patterns, and pondering the design principles and design ideas of excellent open source frameworks

The depth of the

• Depth:The architect has an in-depth understanding of mainstream technologies
  • Have a basic and comprehensive understanding of the principle and operation mechanism of mainstream technology
  • Have a deep knowledge of at least one technology, be an expert in that technology, and be familiar with source code

The width of the

• Breadth: The architect needs to be familiar with current technology frontiers and hot spots, and be able to use new technologies to solve problems. Such as microservices, big data, cloud computing, artificial intelligence
• Broad learning methods: subscribe to relevant technical consulting, learn regularly, and learn more about the technology related to the job

Software architect technical skills

• A software architect is a problem solver:In a system, if many modules are dismantled, which machines should be deployed on
  • Slow SQL optimization
  • Memcache caching
  • Load balancing
  • Hot backup, Cold backup, hypermetro
• Design different strategies for different applications, and formalize these scenarios into standards that the entire team will follow:
  • Through the DB
  • Failure of strategy
• Each technical framework was chosen, discussed, validated, tested, and finally implemented across the team:
  • Tuscany
  • Scallop
  • Hadoop
  • ActiveMQ
  • Erlang
  • hertrix
  • DevOps
• Architect responsibilities:
  • It needs to be understood from the front to the back
  • Key technical details need to be worked out and best practices need to be given
  • You need to know all the popular solutions in the industry
  • Can these schemes be taken over and also applicable to their own scenes
• The architect needs to be proficient in:
  • distributed
  • Nginx
  • F5
  • Micro service
  • The cache
  • persistence
  • The message queue
• Architects need to be familiar with:
  • The most common solution in all the technical details should not be omitted or over-designed
• The architect is also tasked with fixing open source software bugs. You need to look at the source code, understand the thinking behind the open source framework, and then look for things that might cause problems and fix them
• The architect needs to understand all the underlying stuff,TCP/IP, in an effective amount of time
• There is no architect who does not understand the business, and all architectures depend on the business:
  • All architects must also write business code
  • If you don’t use your own design in real projects, you won’t understand the rationality of architectural design

A common architectural framework

TOGAF

• TOGAF: The Open Group Architecture Framework
• TOGAFEmphasize business goals as drivers of the architecture and provide a repository of best practices:
  • TOGAF architecture development approach ADM
  • TOGAF architecture content framework
  • TOGAF reference model
  • ADM architecture development methodology guidelines and techniques
  • The enterprise continuum
  • TOGAF capability Framework

ADM

• ADM is an iterative sequence of steps to develop an enterprise-wide architecture approach:

• Architecture Content framework:

• Reference model:

• ADM Guidelines and Techniques:
  • Architecture Iteration phase:

  

  • Use ADM in different horizontal areas:

  

• Classification of stakeholders:

• Enterprise continuum:
  • Architecture guidance and support solutions:
    • basis
    • General system
    • Industry organization specific

    

• Capability Framework:

DODAF

• DODAFIt’s a control“EA Development, Maintenance and Decision Generation”The organization mechanism is unified organization“Team resources, description and control of EA activities”The overall architecture of
  • DODAF covers all areas of the DoD’s business
  • Defines standard methods for representing, describing, and integrating many architectures within the DoD scope to ensure that architectures are comparable and evaluated
  • It provides a basis for understanding, comparing, integrating and interoperating common architectures between system family Fos and system SoS, and provides rules and guidelines for developing and expressing architecture descriptions
• At the heart of DODAF are eight viewpoints and 52 models:

• Panoramic view AV
  • A top-level overview of the architecture description associated with all viewpoints
  • Provides general information about the architecture description:
    • Scope of architecture description:
      • Professional field
      • Time frame
    • Context for architecture description:
      • doctrine
      • tactical
      • technology
      • The program
      • Description of related goals and ideas
      • Combat concept CONOPS
      • Environmental conditions

• Competency perspective CV
  • It focuses on the organizational goals related to the overall vision, the ability to carry out a specific course of action or achieve desired results under specific standards and conditions, and the use of a variety of means and methods to accomplish a set of tasks
  • Provides the strategic context and corresponding high-level scope for the capabilities elaborated in the architecture description, which is more comprehensive than the concept-based scope defined in the operational concept map
  • These models are high-level, describing capabilities in terms that decision-makers can easily understand in order to communicate strategic ideas on the evolution of capabilities
• Combat viewpoint OV
  • The focus reflects the agencies, tasks, or actions performed to fulfill DoD missions and the information that must be exchanged with each other
  • Describing the exchange of information:
    • species
    • The frequency
    • The nature of the
    • What tasks and activities are supported by the information exchange
• Service viewpoint ScvV
  • It focuses on the systems, services, and interwoven functions that support combat operations
  • DoD processes include operational, operational, intelligence, and infrastructure functions
  • SvcVFeature and service resources and elements can be linked toOVArchitecture data in. These system functions and service resources support combat operations and facilitate information exchange
• System view SV
  • Centralize information that supports automated systems, interlinks, and other system functions in combat operations
• Count the letter viewpoint DIV
  • Data viewpoint DIV: data and information viewpoint
  • Reflects the business information requirements and structured business process rules in the architecture description
  • Description Architecture describes information related to the exchange of information, such as attributes, characteristics, and relationships

  

• Standard viewpoint StdV
  • The smallest set of rules governing the orchestration, interaction, and interdependence of components or elements of a system
  • The goal is to ensure that the system meets a specific set of operational requirements
  • Provide implementation guidelines for technical systems, establish common building blocks and develop product lines based on engineering specifications
  • Include:
    • The technical standards
    • Perform routine
    • Standard options
    • Standard rules
    • Standard specification
  • These standards can form documents governing systems and system or service elements in a specific architecture descriptionprofile
• Project perspective PV
  • Focuses on how projects organically form an orderly portfolio of acquisition projects
  • Describes the relationships between multiple acquisition projects, each responsible for delivering a specific system or capability