Editor's note: This writer, Simon Brown, delivered the same keynote speech "software Architecture for Developers" in Qcon, London, in March.
The boundaries of development and architecture are elusive. Some people tell you that it doesn't exist at all, architecture is just a simple extension of the design process that developers do. Others see it as a chasm that can only be bridged by developers who are highly abstracted and not caught up in the details of implementation. In general, there is an operational balance somewhere between these two extremes of view; However, how to transform from development to architect is an interesting question.
The key points that are often used to differentiate between software architecture and software design development include increased scalability and abstraction, and enhancements that make the right design decisions meaningful. Software architecture is to understand how software systems work as a whole through a holistic view of the macro perspective.
Related Vendor Content
In the container age, how will cloud computing evolve next? How do smart devices span the boundaries of software, hardware, devices, and networks? Hands-on how to create a hybrid app framework from scratch. How should the security inspection system architecture be reconstructed?
Related Sponsors
Global Architect Summit, December 18-19th, Beijing International Convention Center, 80 percent registration.
Even if it helps to differentiate between software development and architecture, it does not help to understand how someone is being promoted from development to architecture. And it doesn't help to identify who can be a good software architect, if you want to hire someone, how do you look for them and if you're a software architect.
Experience can be judged, but you need a deeper understanding
To be a software architect is not an overnight or a promotion of a position can be easily achieved. It's a duty, not a title. This is an evolutionary process, and you will gradually get the experience and confidence you need to take on this responsibility.
When you look for an architect, you need to think about the qualities of each of them, and their past experience is often that they have the ability to take a good judgment of this responsibility. Because software architects have a variety of responsibilities, you need to get a deeper understanding of their engagement, influence, leadership, and sense of responsibility in different areas. In general, in most projects the software architecture can be divided into two phases, the definition of architecture, and then its delivery.
Definition of software Architecture
The schema definition process looks very straightforward. What you need to do is to understand the requirements and design a system to meet the requirements. But in fact it's not that simple, depending on your approach, there is a big gap between the responsibilities of the software architecture and how to take your responsibilities seriously. As shown, the structure definition section of this responsibility can be further subdivided into different elements.
- Managing non-functional requirements: Software projects often get bogged down by asking what users are asking for, what they want, but rarely asking what non-functional requirements (or system quality) they need, sometimes the stakeholder tells us, "This system must be fast," but it's too subjective. Non-functional requirements need to 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 software architectures. Understanding non-functional requirements is a very important part of the architect's role, but it is not necessarily a challenge for them to assume what these requirements are. How many systems do you see that really require 24x7 operation?
- Schema definition: After capturing non-functional requirements, the next step is to start thinking about how you intend to address these issues and define the architecture of the stakeholders. It is fair to say that every software system has a schema, but not every software system has a well-defined architecture. This is the key to the problem. The schema definition process gives you a clear idea of how you plan to solve problems with both requirements and constraints. Architecture definition is the technical aspect of introducing structure, principles, principals and leadership into software projects. Defining a schema is the work of a software architect, but designing a software system from scratch is quite different from the existing system extensions.
- Technology selection: Technology selection is often an interesting exercise, but it also has a fair challenge because you need to take into account all aspects of cost, licensing, vendor relationships, technical strategies, compatibility, collaboration, support, deployment, upgrade policies, and end-user environments. Combining these factors often leads to a simple choice like rich-client technology that goes into a complete nightmare. The next question is whether these technologies can really be useful. Technology selection is outright risk management; When complexity or uncertainty is too high, risk is mitigated and risks are introduced when opportunities or benefits are available. Technical decisions need to take into account a variety of factors, and all technical decisions need to be checked and evaluated. This includes the main components of the software project and even the class libraries and frameworks introduced in the development. If you define a schema, you also need to be confident that choosing the technology is the right one. There is also a difference between the development of new systems and the addition of new technologies to existing systems in the technical assessment.
- Architectural Evaluation: If you design the software, you need to ask yourself if your architecture is useful. For me, an architecture is successful if it satisfies non-functional requirements and provides the necessary foundation for other parts of the code, and provides a sufficient platform for solving and existing business problems. One of the biggest problems with software is that it is complex and abstract, which makes it difficult to visualize runtime features from UML diagrams or the code itself. We have a lot of different types of tests in the software development cycle, so we can be confident that the system we publish will work when it is launched. Why do we not do this to the architecture? If you can test your architecture, you can prove that it works. If you can do this early, you can reduce the risk of project failure, rather than simply hoping that everything will be okay.
- Architectural Collaboration: Any software is not isolated and requires a lot of 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, operations, maintenance, support, and so on. In order for a software project to succeed, you need to work closely with all of your system stakeholders to ensure that the architecture and the environment in which they are built are well integrated. Unfortunately, the current situation is that the architectural collaboration with the development team rarely occurs, let alone outside stakeholders.
Release of software architecture
The same is true for the release of the architecture, and the difference in the degree of participation of a successful software project also determines the different responsibilities of the software architecture.
- With a holistic perspective: To successfully implement an architecture, we need to have a holistic perspective and promote and disseminate the vision that runs through the software development lifecycle, develop and refine the project as necessary, and be responsible for successful release. If you define an architecture, it makes sense to participate in and maintain an evolving architecture, rather than choosing to pass it on to an "executive team."
- Leadership: Having a holistic 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 authority to make those decisions. As an architect, you need technical leadership to make sure everything is taken into account and that the team is moving in the right direction. While it may sound obvious that a software architect position requires internal leadership, many project teams do not have the technical leadership they need because architects believe that a successful release is not necessarily a matter of concern to them.
- Coaching and Mentoring: In most software development projects, coaching and mentoring are often not valued and team members are not getting the support they need. While technical leadership is a guide to the entire project, individuals often need help. In addition, coaching and mentoring provide a way to strengthen skills and help improve your career. This should be part of the software Architect's work, and directing the team architecture and design is quite different from helping them solve the code problems.
- Quality Assurance: Even the best architecture and leadership in the world, poor delivery is enough to fail a project with other success criteria. Quality assurance is a significant part of the architect's responsibilities, but it's not just a code check. For example, you need a baseline to ensure that this implies the introduction of new standards and work practices. From a software development perspective, this may include code standards, design principles, and source analysis tools, even using continuous integration, automated unit testing, and code coverage tools. It can be said that most project quality assurance does not do enough, so you need to figure out what is important and give it enough assurance. For me, an important part of a project includes an architectural focus, a critical, complex, or highly visible business. You need to focus on effectiveness and realize that you can't guarantee everything, knowing that it's better than not doing it.
- design, development, and testing: The last thing in the scope of the Software Architect's responsibilities is design, development, and testing. Being a hands-on architect does not require you 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. Having said so much, why should writing code every day not be part of an architect's responsibilities? Most architects have the experience of writing code, so it makes sense to keep these skills fresh. Moreover, architects can appreciate the pain and feelings of others on the team, which will give them a better understanding of what their architecture looks like from a development perspective. Many companies have policies that prevent software architects from writing code because architects are "too expensive to do cheap work", which is obviously a wrong attitude ... If architects have spent so much time and energy working on projects, why not allow them to take a step closer to helping the project achieve its ultimate success? Of course, in some cases getting involved in the code level is not realistic. For example, a large project usually implies a larger "global view" to consider it, and there may be times when you just don't have the time. But in general, an architect who writes code is more efficient and happier than just watching.
Are you a software architect?
Whether you think the boundaries between software development and architecture are just an illusion or a huge chasm, the above emphasizes that people tend to have very different levels of experience in the entire software architecture, depending on how they work and how seriously they look at their responsibilities. Most developers don't wake up on a Monday morning and announce themselves as a software architect. I'm certainly not, and my path to becoming a software architect is a gradual process. That being said, it is likely that developers have already done a part of the architecture, no matter what their job title is.
There is a big difference between making a contribution to the architecture of a software system and being responsible for defining it, and having a continuous, cross-cutting range of skills, knowledge and experience constitutes the responsibility of the software architecture. It is up to you to cross the boundaries of software developers and architects, but first you need to understand your level of experience before you can begin the first leg of the architect journey.
About the author
You can think of Simon Brown as a software architect who writes code or a software developer who understands architecture. When he didn't use it. NET or Java development software, Simon is usually doing consulting, coaching or training. Simon also wrote a book on Java, lectured in industry events, and integrated a training course called software Architecture for developers, based on the software architecture he described in coding the Architecture. You can find him by e-mail or Twitter.
View English Original: Is you a software Architect?
Original: Http://www.infoq.com/cn/articles/brown-are-you-a-software-architect
[Turn] Are you a software architect?
