What is Microservice Architecture

Microservices architecture is a style that structures an application as a collection of services. This breaks all processes into its own service, where each service has its own container with its own data storage, does not share data. The inverse is monolith architecture which builds all capabilities into a single executable and process. This is a server-side system based on a single application to develop and manage.

Microservices vs. Monolith Architecture
Microservices vs. Monolith Architecture


Microservices implements smart endpoints uses no complex middle-ware the brain lay in the application and the network just help to route information.

Some characteristics of microservices architecture are:

  • Componentization via services
  • Organized around business capabilities
  • Decentralized data management
  • Designed for failure

Advantages of using microservices are:

  • A team can choose an any language for the service
  • Less risk in change
  • Partial Development
  • Independent Scaling
Monolith Microservices
Simple Complex
Whole Development Partial Development
No availability when other services failed Some availability when other services fail
Preserves modularity
Multiple platforms

What is a chaos monkey?

A chaos monkey is a tool that randomly stops services in the infrastructure during the data, while services are being monitored. Since Failure will happen in any disturbed services having a chaos monkey will force developers to anticipate how that failure would happen and how it will be handled. Since failure will happen in any distributed system telling a chaos monkey into an infrastructure will make people more aware of the fact that things will break by forcing it to happen, then monitoring and recovery can handle the event. This effects how to code is designed and written to become more robust. This is chaos engineering which is the discipline of experimenting on a software system in production in order to build confidence in the system’s capability to withstand turbulent and unexpected conditions.

Netflix’s chaos monkey repository on GitHub

What is Conway’s Law?

Conway’s law states that an “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” This is based on the reasoning that for a software module to function, multiple authors must communicate frequently with each other. Thus, the software interface structure of a system will reflect the social boundaries of the organization that produced it. In microservices, there is a lot of variation on how big the size of each team and the number of services to support should be.



IBM Cloud. (2019, Febuary 26). What are Microservices? Retrieved from Youtube: https://www.youtube.com/watch?v=CdBtNQZH8a4

Richardson, C. (n.d.). Retrieved from microservices.io: https://microservices.io

Thoughtworks. (2015, January 31). Martin Fowler – Microservices. Retrieved from Youtube: https://www.youtube.com/watch?v=2yko4TbC8cI

ThoughtWorks. (n.d.). Martin Fowler. Retrieved from http://www.thoughtworks.com: https://www.thoughtworks.com/profiles/martin-fowler

Wikipedia. (2020, February ). Conway’s law. Retrieved from Wikipedia: https://en.wikipedia.org/wiki/Conway%27s_law


Software Engineering Process Framework

Software engineering process framework activities are complemented by several umbrella activities. The umbrella activities of a software process are:

Software tracking and control

Using project management software during the lifespan of the project helps to monitor work on each module, forecasting the development time, estimating required human and technical resource hours, and calculating a critical path for the project.

Risk management

Risk is an event that may or may not occur. Risk management is the process for identifying, assessing, and prioritizing risks of different types which might endanger the assets and earning capacity of a business. Once a risk has been identified, the risk manager will create a plan to minimize or eliminate the impact of negative events. Many project managers recognize that risk management is important because achieving a project’s goal depends on planning, preparation, results, and achieving strategic goals.

Software quality assurance (SQA)

Quality is defined as the sum of the total characteristics of a software entity that bears on its ability to satisfy or implied needs. The purpose of software project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Managing the quality of a software project and its development processes must meet the requirements and satisfy the user’s experience.

A software package must conform to the written requirements of the project’s processes and deliverables. When the project is “fit for use,” the product can be used as it was intended, ensuring the product will satisfy the needs for which it was developed for. In the end, the customer will decide if the quality of the software is acceptable or not.

Formal Technical Reviews (FTR)

After completing each module, it is good practice to review the completed module conducted by the technical staff. The purpose is to detect quality problems and suggest improvements before they propagate to the next activity. The technical staff will focus on the quality of the software from the customer viewpoint.


Project and product measures are used to assist the software team in delivering the required software. This helps to ensure the stakeholder’s requirements are met. Since software itself cannot be measured directly, it is possible to measure a project by direct and indirect factors.  Examples of direct measurement are cost, lines of code, size of software. An example of an indirect measurement would be the quality of software.

Software configuration management (SCM)

A set of activities designed to control changes by identifying parts of the system that are likely to change, establishing relationships, defining mechanisms for managing different versions of the project.

  • Revision control
  • Establishment of baselines.

Re-usability measurement

Re-usability measurement defines a criterion for product reuse. Backing up each part of the software project can be corrected, or any kind of support can be given to them later to update or upgrade the software.

Work product preparation and production (models, documents, logs, forms, lists)

Documents that include project planning and activities to create models, documents, logs, forms, and lists are carried get started here.

The Software Life Cycle

A framework is a Standard way to build and deploy applications. The Software Process Framework is a foundation of complete software engineering process. A generic process framework encompasses  five activities which are given below one by one:

Communication: Understand stakeholder intent and requirements.

Always prepare for meetings.  If the project domain is unfamiliar, do some research on the topic and provide the findings to other members of the team so everyone understands the topics discussed. Appoint a person in charge of every meeting, prior to each meeting. Face-to-face meetings work better, but sometimes not always an option. Take notes, meeting minutes, and document decisions. Distribute notes and decisions to attendees. Upload the documents to a share network resource, in case you need to review prior decisions and notes. Always stay focused throughout the meeting; modularize the discussion. Once something is agreed to, move on; move on even if not agreement, or no clarity (table item). Listen to the needs of the client, do not start to form answers until they are finished. Thus,  there is less of a change you might miss an important detail. Use professional body language: do not roll your eyes nor shake your head.


Project management software can be used during the lifespan of the project to monitor work on each module, forecasting the development time, estimate required human and technical resource hours, and calculating a critical path for the project. Over planning wasted time, and under planning creates chaos. Work with the stakeholder to understand what is and is not in the scope of project.  Involved stakeholders in discussions, when appropriate. They will help to set priorities, deadlines, which keeps the project on time and on budget. Iterate on the planning, don’t try to do everything at once. Break down tasks into small tasks and have plan how to complete each one. Incorporate risk management throughout each phase of the project; consider what risks are possible as you plan and be realistic.

Managing the quality of a software project and its development processes must meet the requirements and satisfy the user’s experience. Define how you will achieve quality and accommodate change. Track the project of each iteration of the project often;  make adjustments each time plan reviewed. Don’t leave team members out of planning.


Adapt models from another project to this one, making needed changes. Explain why you are building each model and build a useful model, not perfect model. Thus, the built model so they can be changed. Do not create models that are not needed, this may waste time and take the project out of scope. When presenting a model ask for feedback on the model by all team members. Encourage team members to share feeling about the state of the model. Ask them what they like and what they do not like.  Using structure charts during the implementation of a system will show users the program modules and the relationships among them. Structure charts consist of rectangle that represent the program modules, with arrows and other symbols that provide additional information. This helps when the analysts and programmers understand the purpose of each module during the designing and testing each module before being run on the entire system.


Programmer can use the principles of software engineering to manage and improve the quality of the finished system. Working from a specific design, a program will use the purposed programming language to transform the program logic into a program module which the rest of the group can work on simultaneously. To simplify the integration of system components and reduce code development time an integrated development environment (IDE) will make programming easier. Coding each program must be tested to make sure it will function correctly, after the programs will be tested in groups, and finally running the entire system.

Before you write first line of code, make sure you understand problem to be solved and the design principles. Choose the best programming language for this problem, then select programming environment. Select data structures to match design and keep conditional logic simple and minimal. Follow coding standards at your site for variable names, this will help ensure the code can be easily maintained in the future. Write self-documenting code to help yourself and other developments. Create unit tests to help reduce bug and problems in the software. Create nested loops so they can be easily tested. A successful test is one that discovers a bug.


Once delivered to the client see if the client can provide feedback on how the application is work. Using the basis of the clients feedback we modify the products for supply better product. To ensure a successful deployment, if possible, try to use a staged deployment model:

#1- Development: A local developer’s workstation.

#1 – Testing: An integration environment where developers merge changes to test that they work together to create a working application. Unit testing will need to be performed on an individual program or modules. This will help to identify and remove execution errors that could cause the program to terminate abnormally, and logic errors that could have been missed during the desk checking. Integration testing will need to occur on two or more programs that might depend on each other.

#3 – Staging: This is where tested changes are run against a production-equivalent environment with data to ensure the application will work properly

#4 – Production – The live production environment.

If an environment of stage is not kept up to date this can lead to out of data testing and possible incorrect environment factors causing promoting a model or application to fail, thus causing rollback  in development.

Software Quality Management

Quality is defined as the sum of the total characteristics of a software entity that bears on its ability to satisfy or implied needs. The purpose of software project quality management is to ensure that the project will satisfy the needs for which it was undertaken. Managing the quality of a software project and its development processes must meet the requirements and satisfy the user’s experience. Businesses often make quality management a serious discipline a major component of their IT risk reduction strategy.

A software package must conform to the written requirements of the project’s processes and deliverables. When the project is “fit for use” is when the product can be used as it was intended, ensuring the product will satisfy the needs for which it was developed for. In the end the customer will decide of the quality of the software is acceptable or not. Design of experiments is a technique that helps to identify which variables have the most influence on the overall outcome of a process for understanding which variables affect the final outcome is an important part of quality planning.

There are many scope aspects of IT projects that affect the quality of a project are. The biggest aspect is the system’s functionality, the degree to which a system performs its intended function. A system must contain the features that have characteristics which are appealing to the intended user. After the user interacts with a system it must generates outputs which are shown on the screens and reports, it is important to define clearly what the screens and reports look like for a system. A system’s performance will address how the software package will perform to the customer’s intended use. To design a system with high-quality performance, project stakeholder must address many issues. Reliability is the ability of a product or service to perform as expected under normal conditions. Lastly, maintainability addresses the ease of performing maintenance on a product. If a software system breaks down after being implementing within a system, project team must review the project to fix the problem to give the user a future satisfying experience.

Planning quality management is the ability to anticipate situations and prepare actions that bring about the desired outcome. Having a plan for the software development life span help to stop a lot of the issues which comes from developing a software system. The first step is to define the quality to match the requirements of both the business and achieving a satisfying user experience. The second step is to broadcast a simple quality metrics, this helps to reduce defeats, as well as keeping the quality on the minds of the whole development team and expose when efforts fall short. Another possible step it to keep fine tuning the project’s goals to make sure the requirements are being meet and each user test of the system has a satisfying experience. Getting the requirements right the first design phase means the software would need to be reworked less and less retesting and troubleshooting code to test for bugs. Designing a simple application helps to lessen the risk for bugs and is easier to test and rework if needed.

Coupling and Cohesion


Coupling is the degree of interdependence between software modules, and how closely connected the relation of two modules are. Modules should be as independent as possible from other modules, thus any changes to modules do not heavily impact other modules. Implementing a higher coupling relationship in modules would they are dependent on the inner workers of other modules. This would make changes harder to coordinate and increasing probably of functionality errors. By using low coupling, is often a sign of a well-structured system design. Changes are easier made to the internals of modules without the possibility of impact on other modules in the system. Code is easier to write, test and maintain since modules are not interdependent on each other.

Types of Coupling:

  • Data Coupling – the components are independent to each other and communicating through data.
  • Stamp Coupling – the complete data structure is passed from one module to another module.
  • Control Coupling – if the modules communicate by passing control information, then they are said to be control coupled
  • External Coupling – the modules depend on other modules.
  • Common Coupling – the modules have shared data such as global data structures.
  • Content Coupling – one module can modify the data of another module or control flow is passed from one module to the other module.



Cohesion often refers to the degree to which the elements of a module belong together. Everything in a module is meant to work together. The elements within the module are directly related to the functionality that module is meant to provide. Software can easily design, write, and test our code since the code for a module is all located together and works together. Low cohesion would mean that the code that makes up some functionality is spread out all over the code-base.

Types of Cohesion:

  • Functional Cohesion – every essential element for a single computation is contained in the component.
  • Sequential Cohesion – an element outputs some data that becomes the input for other element
  • Communicational Cohesion – two elements operate on the same input data or contribute towards the same output data
  • Procedural Cohesion – elements of procedural cohesion ensure the order of execution.
  • Temporal Cohesion – elements are related by their timing involved.
  • Logical Cohesion – elements are logically related
  • Coincidental Cohesion – the elements are not related



A class to open a bank account would not try to handle both a savings account and checking account opening. High cohesion would say those go into different classes, yet low coupling says modules should not be dependent on each other.

In a higher cohesion software design was chosen implementing a class for checking and another for savings, would allow for an easier maintain of the bank account module. Also adding future features to one or two both classes, would be able easier to accomplish and less prone to software logic errors.

In a low coupling design, all states and behaviors of each account would have to be implementing. This would create a very lengthy module, and thus harder to maintain for future developers

Documentation with a Software Project

How a project design is getting documented in the SSDs, the operation contracts, the class diagrams, the sequence diagrams, and the communication diagrams?

The more documentation the better to help future developer maintain and upgrade the code. Many people who might be part of the project might not have a coding background but will need to understand what is being implementing and how to stage the project.


What is the team that documents are also doing the coding?

It would depend on the size of the team and scope of the project. It the team changes or new people join the team they will need to get up to speed on which stage the project is and what their part would be. Also, if there is an error in project and the developer is no one with the project, the new document available will help any future developer to understand and fix and broken parts to the code.


Do you think it is overkill if these documents are sent overnight to offshore, and code returned the next morning, as a regular part of the development process?

It’s not overkill be would it depend on the reason behind sending the code to a remote team. Also, it would be depending on the how detailed and organized the documents are. If there is an error in the logic or implementation the returned code would have minimal or no benefit on the project or module. This is the return for sandbox testing and staging development

Domain Model vs. Design Model

A domain model is a conceptual model and solution independent. This resulting from a domain and requirements in system analysis, or inception, phase of a development project. This will provide visual representation of the class within the domain, basic relationship between domain classes, and any key attributes of the class. Domain models are also called:

  • Conceptual models
  • Domain object models
  • Analysis Object Models

Using a domain model creates a blueprint saving time by help the design team will gain a better understanding of the system requirements reducing complexity, testing, maintainability. The system will have less bugs and better meet user requirements faster within the project timeline.

Domain Model

A design model is a logical model and platform independent resulting from system design activities in the elaboration phase. This will describe how everything works together, are connected, and interact with each other. design model.

Design Model

Use cases and capturing functional requirements in system

Being able to capture all the functional requirements a case might have would depend the item the class is representing. Some real work items a developer or team might be able to predict any behavior or states it might have at any given time or sets or time, other item might be more difficult. There is always unforeseeable behaviors and states of any system where the development team will actively update a system accommodate such states or behavior. Also, human error is always a factor when developing a system when sometime anything can and will happen.

A simple use case for a finite-state machine can be in exactly one of a finite number of states at any given time. Example: a turnstile is a gate with three rotating arms at waist height, one across the entryway. Initially the arms are locked preventing a person from passing through. Depositing a token in a slot on the turnstile unlocks the arms, allowing a single person to push through. After they passes through, the arms are locked again until another coin is inserted. Developing a use case becomes increasingly more difficult to implement for non-deterministic finite automaton where a machine can move to any combination of the states in the machine. Thus, the exact state to which the machine moves cannot be determined

Functional requirements that might not be able to document using UML and Activity diagrams would be unknown input sources, unexpected event, or human error. One or all these factors may present themselves depending on what functions, scale, and scope of the system. Some requirements might be harder to anticipate, and document early in the development process. A good development team should always work with the client and/or user to anticipate any requirements and error which might occur.

Agile Methodology vs. Waterfall Model

Waterfall project methodology


A model in which every stage of a product’s life cycle takes place in sequence and emphasizes a logical progression of steps. Before moving to the next phase, there is usually a review and sign off process to ensure that all defined goals have been meet. Ideal for projects that have a specific documentation and fixed requirements, estimated timeline, ample resources, and well understood technology.

7 non-overlapping stages

  1. Requirements
  2. Analysis
  3. Design
  4. Coding/Implementation
  5. Testing
  6. Operating/Deployment
  7. Maintenance


  • Upfront documentation and planning stages allow for large or shifting teams to remain informed and move towards a common goal
  • Forces structured and disciplined organization
  • Simple to understand, follow, and arrange tasks
  • Defines milestones and deadlines


  • Design is not adaptive to change
  • Delays testing until end of development life cycle
  • Does not consider error correction
  • Does not handle requests for change, scope adjustments or updates


Agile Methodology

1 Fzz56Ps_vQSTPHDO9IomXw.png

An approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-function teams and their customers/end users. Contains a set of different projects that are iterations of different stages; focused on improving the quality and feedback from users.


  • The client is involved throughout the project and can give feedback to change the product and its features as best suitable for the business and the client.
  • Change requests are easier to implement as the agile methodology follows an adaptive planning method, with plenty of room to accommodate change requests as they come.


  • Requires experience and quick decision-making ability to accept some changes and postpone other changes for the next sprint.
  • Does not work well if the client or the team does not understand agile methodology and could not keep up with the fast-paced environment.
Agile Waterfall
Iterations Stages
Constant Business Interaction Communication is varied between high/low iterations
Scrum master Project Manager
Can go back to previous iteration Cannot go back to previous stages
Increased speed Increased Quality
Flexible Structed and rigid