Document directory
The boundaries between development and architecture are elusive. Some people tell you that it does not exist at all. The architecture is just a simple extension of the design process made by developers. Others think that this is a gap. developers who are highly abstract and do not fall into implementation details can bridge the gap. Usually, there is an operational balance between these two extreme points of view somewhere; in any case, how to switch from development to architect is an interesting question.
The key points that are often used to distinguish between software architecture and software design and development include the increase in scalability and abstraction, And the enhancement in the significance of making correct design decisions. The software architecture is to understand how a software system works as a whole from a global perspective and a macro perspective.
Even if this helps differentiate between software development and architecture, it does not help to understand how someone has upgraded from development to architecture. In addition, it cannot help identify who can become a good software architect. If you want to hire someone, how can you find them and whether you are a software architect.
Experience can be judged, but you need more in-depth understanding.
It is not easy to become a software architect overnight or to become a software architect. This is a responsibility, not a title. This is an evolutionary process, and you will gradually get the experience and confidence you need to assume this responsibility.
When looking for an architect, you need to consider the quality of all aspects. their past experience is often determined by their ability to take on this responsibility. Since software architects have diverse responsibilities, you need to gain a deeper understanding of their engagement, influence, leadership, and sense of responsibility in different fields. In general, in most projects, the software architecture can be divided into two phases: the definition of the architecture, and then its delivery.
Definition of software architecture
The architecture definition process looks simple and clear. What you need to do is to understand the requirements and design a system to meet the requirements. But it is actually not that simple. According to your different practices, there is a big gap between the responsibilities of the software architecture and how to take your responsibilities seriously. As shown in, the architecture definition part of this role can be further divided into different elements.
- Manage Non-functional requirements:Software projects often fall into the trap of asking users what they want and what they want, but seldom ask them what they need (or System Quality). Sometimes, stakeholders will tell us, "This system must be fast", but it is too subjective. Non-functional requirements should be clear, measurable, available, and testable if they are to be met. Most non-functional requirements are technical in nature and often have a significant impact on the software architecture. Understanding non-functional requirements is a very important part of the architect's responsibility, but assuming that these requirements are not necessarily a challenge for them. How many systems do you see that actually require 24x7 running?
- Architecture Definition:After capturing non-functional requirements, the next step is to start thinking about how you plan to solve these problems raised by stakeholders and define their architecture. To be fair, each software system has an architecture, but not every software system has a defined architecture. This is the key to the problem. The architecture definition process allows you to figure out how you plan to solve the problem while taking both requirements and restrictions into account. Architecture definition refers to introducing structures, guidelines, principles, and leadership into the technical aspects of software projects. A defined architecture works as a software architect, but designing a software system from the beginning is quite different from extending existing systems.
- Technology Selection:Technology Selection is usually an interesting exercise, but it also has a fair challenge, because you need to consider costs, licenses, supplier relationships, technical strategies, compatibility, collaboration, support, deployment, upgrade policies, and end-user environments. By combining these factors, it is often a nightmare to simply choose a client-like technology. The next question is whether these technologies are actually useful. Technology Selection is a complete risk management; When complexity or uncertainty is too high, risks should be mitigated, and risks should be introduced when there is a chance or benefit. Multiple factors need to be taken into account in technical decision making, and all technical decisions need to be checked and evaluated. This includes the main components of the software project and the class libraries and frameworks introduced during development. If you define an architecture, you also need to be confident that this technology is correct. There are also differences between developing new systems and adding new technologies to existing systems in technical evaluation.
- Architecture evaluation:If you design software, you need to ask yourself if your architecture is useful. For me, an architecture is successful. If it meets non-functional requirements and provides the necessary foundation for other parts of the Code, it also provides a sufficient platform for solving and existing business problems. One of the biggest problems of the software is its complexity and abstraction, which makes it difficult to imagine the runtime characteristics from the UML diagram or code itself. In the software development cycle, we have conducted many different types of tests, so that we can have confidence that our released systems can run normally at the launch. Why are we not doing the same with the architecture? If you can test your architecture, you can prove that it is effective. If you can do this as early as possible, you can reduce the risk of project failure, rather than simply hoping that everything will be fine.
- Architecture collaboration:No software is isolated from each other and requires many people to understand it. This includes direct development teams that need to understand and cut into the architecture, and other stakeholders who are interested in security, database, operation, maintenance, and support. To make a software project successful, you need to work closely with all system stakeholders to ensure that the architecture and environment are well integrated. Unfortunately, the current situation is that architecture collaboration with the development team rarely happens, not to mention external stakeholders.
Release of software architecture
The release of the architecture is the same. The degree of participation in successful software projects also determines the different responsibilities of the software architecture.
- Global View:To successfully implement an architecture, we need to have a global perspective and publicize and promote the vision throughout the software development lifecycle. If necessary, we can expand and improve the architecture throughout the project, responsible for successful release. If you define an architecture, it makes sense to participate in and maintain a constantly evolving architecture, rather than passing it to an execution group ".
- Leadership:A global perspective is one aspect of technical leadership, but there are other things that need to be done in the software project release phase. This includes taking responsibility, providing technical guidance, making technical decisions, and having the power to make these decisions. As an architect, you need technical leaders to ensure that everything is taken into account and the team is moving forward toward the right side. Software Architect positions require internal leadership. Although this sounds obvious, many project teams do not have the technical leadership they need, because architects think that a successful release is not necessarily a concern of them.
- Coaches and guides:In most software development projects, coaches and guidance are often ignored, and team members do not get the support they need. Although technical leaders guide the entire project, individuals often need help. In addition, coaches and guides provide a way to strengthen skills and help improve your career. This should be part of the software architect, and guiding the team architecture and design is completely different from helping them solve code problems.
- Quality assurance:Even the World's Best architecture and leadership, poor delivery is enough to make a project that has other conditions for success fail. Quality Assurance accounts for a large part of the architect's responsibilities, but it is not just a simple code check. For example, you need a baseline to ensure that new standards and work practices are introduced. From a software development perspective, this may include code standards, design principles and source code analysis tools, or even the use of continuous integration, automated unit testing, and code coverage tools. It can be said that the quality assurance of most projects is not enough, so you need to understand what is important and give it enough assurance. For me, the important part of a project includes the architectural focus, key, complex, or highly visible business. You need to pay attention to the effectiveness and realize that you cannot guarantee everything. You need to know that doing better than doing better.
- Design, development and testing:The last thing the software architect has to do is design, development, and testing. As a practical architect, you do not need to write code every day, but it does mean that you have been involved in the project and are actively helping to build and deliver it. So many times, why should I write code every day not become part of the responsibility of an architect? Most architects have code writing experience, so it makes sense to keep these skills fresh. In addition, architects can understand the pain and feelings of others in the team, so that they can better understand what their architecture looks like from the development perspective. Many companies have policies to prevent software architects from writing code, because architects are "too expensive to do cheap jobs", which is obviously a wrong attitude... if the architect has spent so much time building the project, why does it not allow the architect to take one more step to help the project achieve its final success? Of course, in some cases, it is unrealistic to include code levels. For example, a large project usually means a larger "view of the region" to consider it, and sometimes you just don't have time. But in general, a code-writing architect is more efficient and happy than simply watching.
Are you a software architect?
Whether you think that the boundaries between software development and architecture are just an illusion or a huge gap, the above stresses that people often have great differences in the experience level of the entire software architecture, it depends on how they work and how they take their responsibilities seriously. Most developers did not wake up on a Monday morning and declared themselves as a software architect. Of course I am not. My path to being a software architect is a gradual process. Even so, it is very likely that some developers have done some architecture work, regardless of their job title.
There is a big difference between contributing to the architecture of a software system and being responsible for defining it. Having continuous skills, knowledge, and experience across different fields constitutes the responsibility of the software architecture. It is up to you to bridge the boundaries between software developers and architects. But first, you must understand your experience to start the first stop of the architect journey.
About the author
You can think that Simon Brown is a code-writing software architect or a software developer who understands the architecture. When he doesn't use. Net or Java to develop software, Simon is usually doing consulting, guidance or training. Simon also wrote books about Java, gave speeches at industry activities, and integrated a training course called software architecture for developers, the course is based on the software architecture he described in the architecture of coding. You can find it via email or Twitter.
View Original English text: Are you a software architect?
