Architectural design, creation of terms of reference for applications, SaaS services, e-Commerce projects

Designing an architecture, creating a technical solution, selecting components and services

15%cost of product development is system design
9key design artifacts
200team hours for the average project
Read more
Awards 6 awards 4 nominees in UI/UX
Raitings Profile Evergreen — Clutch Raiting Evergreen — CMSMagazine Profile Evergreen — Behance All All

The essence of system design as a service

To begin the development, you must first prepare the project documentation. In the case of simple projects, prototype , a brief functional specification and user stories are enough to development team. In most cases, for solutions created on the basis of ready systems do not need a lot of project documentation, because there are already commonly used components and it is clear what should be done and how it should work. The system that lies at the basis (cms, crm, lms, erp, etc.) already contains a set of basic functions and it is not necessary to cover all details.

In the case of developing SaaS and complex systems from scratch, new products or the integration of enterprise systems, the task becomes more complicated, and more work is needed to get the full development requirements. Therefore, we consider the system design stage as a service, in which we include project documents (artifacts) that bring benefits to customers.

Let's not design?

      
  • Why waste time designing if there is Lean Methodology?     

    "Without wasting time, we'll quickly start developing" or "Eric Ries in the Lean Startup book says, that you do not need to plan, you need to make a product faster." – This is what clients sometimes say to us.


     Yes, it really seems that Lean, SCRUM and other iterative methods eliminate the need to think about the whole product, and in general it is possible to start working earlier than in the waterfall, and it will be faster and cheaper than designing for a long time, then start the development, make some space ship and realise that we fail.

    However, the essence of the question is the answer: poor design really only leads to chaos and confusion on the project. To understand when designing is really necessary, imagine an example from ordinary life. Suppose you are building a house. If you bought a standard prefab house and it is assembled by experienced builders, special design service is not particularly needed - builder's experience covers all cases. If you are building big residential building, the design plays a big role and the demand for the level of builders also increases. And if you are building the world's largest skyscraper, or the most environmentally friendly house in the world, then the design is your main value, and without a project, "just starting to build" you will never build it. Think about what would happen if high-tech facilities, such as airports or nuclear power plants were built without design?


    This analogy is also true for IT. There are simple projects where everything is obvious and you can "just do it" with enough experience, but really interesting and unusual projects require careful approach and deep study before the first line of code is written. Moreover, this does not in any way contradict the iterative and flexible development methodologies - SCRUM, Lean and other well-known techniques do not in any way imply a rejection of design. Rather, it is about the fact that you need to abandon the redundant design where possible. But the attempt to abandon the design altogether and begin to implement an incomprehensible and ill-conceived solution can turn out to be much more waste.

        
      
  •   
  •     We need to start faster, we do not have time for this!     

    Then use the ready-made solutions. They are made to quickly get the result. The good news is that now there are a lot of ready-made solutions and components that make it easy to implement almost any idea. The truth is that the selection of these most ready solutions is also part of the design. And the bad news is that for really breakthrough ideas, there are usually no ready-made components, or if they not fit well together, you risk starting a project with an initially wrong choice of technologies and not finish it in principle.

        
      

15% of the budget

– part of a system design in the total cost of the product

System design aims to reduce indeterminacy

In fact, every document in the project is a description of what should be implemented, from different points of view (business, users, technical and others).

The project should be designed so that all remaining indeterminacy will be overlapped by the developer experience and capabilities of specific systems and components. Then you understand that in the end you will get what you intended. Accordingly, the more novelty in the project, the more complex ideas you want to implement and the more performers will be involved in the project, the more you need to plan and design in order to avoid the impact of accidents or lack of expertise.

“I do not want to pay for the project to find out that the implementation of my idea costs 10 times more than I thought!”

We understand. But you probably know that 70% of IT projects freeze in the process? System design saves you from expensive illusions. The good news is that even knowing that the project is more expensive or more technically difficult than you originally thought, nothing forces you to stop it - you can always simplify it, test the hypothesis on a minimal version, as suggested by Eric Ries in Lean Startup, you can find an investment or try a step-by-step launch. Here you decide what degree of risk and indeterminacy you want to take. If you are ready for increased risk, then minimize the costs of designing and look for someone who has similar experience to somehow secure the project from failure.

Why do you still need to design?

      
  • Anyway, the project does not close 100% of the questions, why should I do it?     

    You are right, system design is not exactly what you can do once and work on this project until the end of development. There is even a scientific explanation from the theory of system analysis. The fact is that everything we work with falls under the notion of a "complex system" and complex systems have many unpleasant features that make it difficult to set requirements and predict the flow of the project. Therefore, you need to soberly assess the benefits of the project and not to do too detailed and redundant projects, stopping in essence on the minimum level of design required for a particular task. Then the project will not be too expensive and can remove 70-80% of the uncertainty, which already significantly increases the chances of success. That is, the question again comes down to the level of risk acceptable to you. The less you want to risk your idea and time, the more accurately you need to approach design.

        
      
  •   
  •      I do not understand anything about this, for me this system design has no value, in fact the design phase is needed to you to do what I need, so why should I pay for it?     

    If it somehow resonates with your thoughts - it means that you saw bad designs and did not see good ones. Tell me, do you represent the realization of your idea with clarity in every detail? 90% of people will say "yes, I imagine, but there are some minor issues, that are not completely clear to me and require clarification" (10% say "no, I understand in general terms, I will be happ to get your help, guys, so that I understand better how it should work). If you belong to the first group, then tell me if you ever faced with the fact that in the process of clarifying the details, you develop your idea until you finally decide to do it in a fundamentally different way than you thought was right from the start, while you are very Happy with the result?

    If at you such happened, you understand that it is possible, only deeply penetrating into details and concrete realization. We will take care of these details. The whole process will be extremely clear to you and will lead to the fact that your idea will become better and you will understand much more deeply how and what will be done and what you will receive as a result.


    The design includes a large layer of advisory work, during which we share the experience of Evergreen, the experience of successful launches of our clients' projects and fresh solutions that you can apply for the benefit of your idea. Are you interested in the technical partner involved in the success of your project, who will share with you his experience and help to identify weaknesses and enhance the benefits of your idea? If you already have experience in business, I think that you know what it's worth.


    We include in the project the minimum required set of documents (artifacts) that clarify and disclose details of the implementation of your idea and do not include anything superfluous. Are you interested in finding the best and most cost-effective way to implement it?

        
      
  •   
  •     Show what to write and how, give a template, and we'll fill it ourselves!     

    This is an extreme approach to design. Evergreen agrees with the Ministry of Health that self-treatment is dangerous for your (project) health. Of course in IT everything is much clearer and you can learn everything, the only question is the speed of this training and risks. Designing is a process aimed at reducing your risks, and a project by template is one big risk, because it does not often contain even half of the requirements and data required for development.

    If you still want to take a chance, use our Specification check list

        
      

System design artifacts

slogan-img

Scroll to see other reasons

  1. The overall project concept includes a vision of the project, analysis of the competitive environment, the business need and the business idea of the project.
  2. Product Boundaries determine what should eventually turn out and that we do not plan to cross (if we cross these boundaries, it will be another product).
  3. An approximate calculation of profitability and choice of the implementation method based on a possible payback.
  4. UI prototype and detailed user stories created to describe all the details of user interaction with our system.
  5. Analysis and description of business processes (BP) of the designed system . As a result of the analysis, we create the following documents, depending on the project:
    • user stories of the top level of abstraction
    • use cases to describe interaction scenarios between multiple systems /persons /entities
    • user flow - scripts of the user's work with the system (combine the user stories and the cases, show the complete process from beginning to end)
  6. General technical concept of the project
    • Choosing the type of architecture (monolith or micro-/nano-services)
    • Decomposition of monolithic architecture into components (for example: downloading files, sending mail, working with documents, chatting).
    • The general component-oriented technical scheme of the project. Interaction of components among themselves. (For example, you can upload from the gallery and from the chat room)
    • Non-functional system requirements: security, availability (browsers and OS), scalability, performance (server loads), constraints (business rules and corporate policies), etc.
  7. Detailed technical architecture
    • Description of the necessary services for the component. R&D and selection of compatible services. (An example for uploading files requires an API service through which to send and receive files.)
    • Breakdown for microservices
    • Scheme of interaction of services/microservices
  8. Technology stack
    • The choice of software implementation stack for each component. R&D for compatibility.
    • The solution of tech cases.
    • Selecting a hardware implementation stack (if needed)
    • Recommendations for setting up and launching the project on production
    • Compatibility analysis of UI interfaces and services
  9. Designing the stages of development and implementation of the project : the scheme of development stages is divided into stages and grouped by components/services.
  10. Process organization and team required for project implementation
  1. The overall project concept includes a vision of the project, analysis of the competitive environment, the business need and the business idea of the project.
  2. Product Boundaries determine what should eventually turn out and that we do not plan to cross (if we cross these boundaries, it will be another product).
  3. An approximate calculation of profitability and choice of the implementation method based on a possible payback.
  4. UI prototype and detailed user stories created to describe all the details of user interaction with our system.
  5. Analysis and description of business processes (BP) of the designed system . As a result of the analysis, we create the following documents, depending on the project:
    • user stories of the top level of abstraction
    • use cases to describe interaction scenarios between multiple systems /persons /entities
    • user flow - scripts of the user's work with the system (combine the user stories and the cases, show the complete process from beginning to end)
  6. General technical concept of the project
    • Choosing the type of architecture (monolith or micro-/nano-services)
    • Decomposition of monolithic architecture into components (for example: downloading files, sending mail, working with documents, chatting).
    • The general component-oriented technical scheme of the project. Interaction of components among themselves. (For example, you can upload from the gallery and from the chat room)
    • Non-functional system requirements: security, availability (browsers and OS), scalability, performance (server loads), constraints (business rules and corporate policies), etc.
  7. Detailed technical architecture
    • Description of the necessary services for the component. R&D and selection of compatible services. (An example for uploading files requires an API service through which to send and receive files.)
    • Breakdown for microservices
    • Scheme of interaction of services/microservices
  8. Technology stack
    • The choice of software implementation stack for each component. R&D for compatibility.
    • The solution of tech cases.
    • Selecting a hardware implementation stack (if needed)
    • Recommendations for setting up and launching the project on production
    • Compatibility analysis of UI interfaces and services
  9. Designing the stages of development and implementation of the project : the scheme of development stages is divided into stages and grouped by components/services.
  10. Process organization and team required for project implementation

Do you want to design new application or service?

Let us know what kind of project you want to create or develop. Feel free - we will be happy to advise on any professional issue and will do it absolutely for free, just give us a call or fill out the form.