My name is @kazuis and I am an engineer at LITALICO Inc. I am mainly in charge of the enterprise system of welfare services for persons with disabilities provided by LITALICO.
This article is the 13th day article of "LITALICO Advent Calendar 2017".
When creating a new system, you may be wondering which language, middle and method to use. There is little sense of a cool summary of the process of determining a system architecture. Even in waterfall, there are many methods such as Scrum and books designed. And language and middleware information is overflowing on the Internet.
However, there is not much information on the key points for architecture selection during that time.
I will briefly summarize it with the meaning of organizing my thoughts.
The appropriate architecture should be different for each organization and project. I would like to write about the approach for finding the "just right" for each person and each company.
If you decide a large range with the system architecture, it will be difficult to write. This time, I will write only the elements related to the language and framework.
The architecture of the system depends greatly on "why you need the system". To put it a little exaggeratedly, is it a banking system or a mini-game for some event site? They do not have to have the same architecture.
First, you need to know why you want to build a system.
By collecting these, you will understand the requirements for the system. And you need to know what to make.
It is also important to have the same business flow and functional requirements. The most important thing is to know the "concept you want to cherish".
If the core domain does not have the proper architecture I don't know what the system is for. I think that it is often clearly defined as a system for users, but I think that there are few enterprise systems.
After that, you will need the information that you have performed the requirements analysis normally. If the reason for building a new system is systematic, before the system requirements To some extent, I want to change the language or change the infrastructure to the cloud I think it's often the goal to change the architecture.
Also, in the first place, the business flow is too fast and it is difficult to decide before proceeding with system development. It may be a difficult time. Here, I think it is enough to be able to determine whether to proceed based on requirements or to prioritize feedback.
System requirements
I personally like the RDRA analysis method because it is model-based. I use it while studying because it gives a better view of the entire system from the perspective of deciding the architecture. Model-based requirement definition technique Zenji Kanzaki
I want a function for developing new sales channels and products. For the time being, I want a system because I want to do XXX (speed) I want to greatly improve work efficiency.
The system is bloated and can no longer keep up with business expansion. I have accumulated technical debt and want to return it. The technology used is too old to be maintained and developed. Maintenance costs are bloated, so I want to improve efficiency.
In the future, I want to do XXX There is a difference between the realization of the system strategy and the current system.
Once the information is gathered, the next step is to decide how to solve the problem. The same is true even if there is no so-called requirement definition. Hearing and feeling the temperature to get an approximate feeling.
It is organized in terms that are common in business books such as people, goods, money, information, and time. I think that the amount of change in business, cost, and recruitment of developers are important considerations.
As a result of considering this kind of item, we will create a system strategy.
| Classification | item | Things to think |
|---|---|---|
| Man | Developer team size | Can it be done by one person or 100 people? |
| Man | Developer team skills | Can the development team make it? Can it be maintained? |
| Man | Ease of collecting developers | Is it easy to attract people by hiring? |
| mono | Is there an infrastructure constraint? | I want to use the cloud, but sometimes I can't. |
| mono | Number of business establishments, user scale such as people, etc. | How much consideration should be given to the introduction |
| mono | Cooperation with existing system | Migration is important. |
| mono | Cooperation with external system | Know the boundaries of your system. |
| Money | budget | If the ideal costs too much, it may not be possible. |
| Money | Business scale and its forecast | Systematize considering the amount of data and the amount of information |
| information | Model relationship | The domain division may be the system division. |
| information | Amount of information | Should data splitting be considered? |
| information | The speed at which information changes | If you don't know the speed of business change |
| information | Number of mission-critical tasks | Business systems with a lot of calculation processing |
| information | セキュリティが必要なinformation | How much important information you have, such as personal information |
| time | 初期リリースまでのtime | Development process may change during initial release and operation |
| time | Frequency of requests | How often do you request system changes? |
| time | System life cycle | Is it planned to operate for 10 years? Is it two years? |
First, determine the scope of the system.
Then determine the classification of the target system. It classifies whether it is a SoR (System of Record) or a SoE (System of Engagement).
SoR is a system that requires correct recording of transaction and accounting information.
SoE is a system that requires optimization for each user, such as My Page, which is mainly used by users.
If it is a SoR-like system, consider whether to choose a solid architecture. If it is a SoE-like system, consider an architecture and development process that can be developed with a sense of speed.
I think this can be different for each subsystem. If you adopt a microservices architecture, it's a different thing.
After deciding the classification, it was suitable for the life cycle Determine a system structure strategy that meets the initial requirements
If it is a SoR-like system, I think that a monolithic system may be used as long as the scale does not increase. Microservices have a high degree of difficulty in designing transactions. Consider creating a structure that requires data integrity.
If it is a SoE-like system, there should be many system change requests after the initial release. Decide that the architectural structure itself should be a structure that requires additional addition.
Once you know the structure of the system, you will decide the development language to behave in it. Is Java the most common when creating enterprise systems? It seems that the language and framework that engineers are good at are used in startups such as ventures.
For SoR-like systems, I prefer a solid language and framework, so Java is a good choice. Although system change requests are infrequent, there are regular change requests. The learning cost is a little heavy, but there are many good things that the structure change can be detected as a build error if there is a type. I think it is suitable for controlling the structure and state.
In the case of a SoE-like system, there are many requests for changes in business flow and usability, so speed is required. I like the language and framework that can be fixed and checked. I think it is good to build a mechanism that allows you to create while receiving feedback in Ruby and PHP. Even enterprise systems must be able to meet the demand for speed like Web services.
Of course, you can achieve the functionality when choosing a language or framework. The following three are the most important.
No matter what system you make, it is meaningless unless you can operate and maintain it. There is also a trend in frameworks. The framework you choose during development may be remembered five years later.
Therefore, it is not possible to select a language or framework that ignores the technical flow. It is necessary to make a choice that does not make a mistake in the technical flow, not the fashion.
The framework may be obsolete, but you need to make choices to improve the skills of your engineers. As the engineer's skill level increases, the system will remain healthy and can be easily rebuilt. And engineers who want to use a technical framework may come together. (Engineers don't like old frameworks ... new frameworks are motivating)
In recent years, I think that there is also such an aspect that the name Scala is raised by recreating a large system. (I like Scala!)
You are also responsible for completing and operating the system. How to balance that is the showcase of the architect's skill.
Even in an enterprise system, the business flow is fast. Even if you decide on an architecture in the early stages of development, it is not always correct in the life cycle of the system.
In the field of welfare for persons with disabilities, which is Ritalico's business, it is difficult to support the system because the national system is still changing.
We are aiming for an architecture that is easy to break and can be remade in detail.
Recommended Posts