SDLC in 2022: How to implement it

I had the chance to meet lot of different persons across many company in the software industry. Something that all have in common are the struggling for a team to cooperate and align on the same IT Strategy.

Team leaders face the challenge to put in place a Framework that all the team would agree to follow. Having lots of product, business line, or third party integrations make it even harder. The concept behind SDLC is to define your processes to build your own piece of codes. SDLC is taking an important part of the DevOps culture where the famous management method “deming cycle" is part of the company IT strategy. It's divise in 4 blocs called PDCA, for Plan, Do, Check and Act. The Act is the idea of continuous improvment, gathering feedback to loop the process.

• Ideation
• Analysis and design
  • Gather functional informations
  • Non-Functional informations
  • Design your Landscape
  • Microservices trap
  • Architectural Patterns
• T/B Driven Developpment
  • TDD
  • BDD
  • Code Review
• Continuous Integration and Deployment
  • CI
  • CD & CDE
• Maintenance
  • Monitoring
  • Alerting

1. Ideation

Design software from scratch can be a tedious task, and the difficulty and complexity grow over time. But we can agree that it starting by an idea, often broad by the sponsor, executive, or the Product Owner.

The idea is then nurture to extract specifications from it. Lot of brainstormng sessions, along with UX research to create customer journey are a good way to do that. If some hardcore tech is required, you can do a Proof Of Concept (PoC) to valaidate the more appropriate solution to achived the product vision.

2. Analysis and Design

The second phase is critical for the success of your product development. This is where the software architecture is outline. Architecture is the discipline to design the important stuff to build sustainable and resilient solutions.

I notice that this step is by far the less structured in many organization. Most of the time the architecture stay in the head of principal engineer.

I seen hundreed of projects as a consultant. One factor that's consistent among all, are the less the architecture is throughfuly designed, the more the complexity and time to implement increase, as well as the spreaeding lack of knowledge in the team.

There are many benefit to invest time on a design phase:

• Improve knowledge management accross the team
• Challenge the design with other peers
• Anticipate decisions align with the product vision
• Improve overall quality
• Reduce implementation effort by anticipation

Gather functional informations

Before starting to draft your architecture, you will need to identify the functional requirements and goals. You’ll probably have to run through the team brainstorming notes and summarize them on a functional design document.

• List the hard dependencies to third party system:
• How the solutions would be deliverd and uses?
  • WebApp
  • Mobile APP
  • Desktop APP
  • IoT system
• Did we need real time communication?
• How often client / server has to exchange informations?
• What’s the flow and data model communication?

Non-Functional informations

• List the technical limitation if that’s matter for the design of your system:
• Technical knowledge or limitation of the internal team related to a specific stack or programming language.
• Avoid vendor lock-in to keep replicable infrastructure in other cloud provider.
• Usability:
  • What’s the UX and accessibility criteria to respect
• Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
  • Efficiency: Once users have learned the design, how quickly can they perform tasks?
• Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
• Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
• Satisfaction: How pleasant is it to use the design?
• Efficiency:
  • Define the acceptance criteria regarding the performance of your application
  • The SLO (Service Level Objective)
  • 99.95% availability
  • 300ms response time
• Reliability:
  • Define the acceptance criteria regarding the availabilities and SLA of your applications.
  • What’s the SLO (Service Level Object) and SLA (Service Level Agreement)
• Scalability:
  • Able to serve millions of users
  • Reduce infrastructure cost by consuming only what's needed (Model Pay As You Go)
• Security Policies:
  • MFA Authentication
  • Standard oAuth / openId protocol
  • RBAC rules

Design your Landscape

The IT landscape is a set of elements that serves as fabric to support business operations of the enterprise.

Designing a landscape should be reserved to experienced engineer as it required broad knowledge. I recommend the following pre-requisite:

• 3 years of experience programming and shipping software in production
• Client / Server communication
• Data modeling and Domain Driven Design mindset
• Infrastructure System Administration / Public Cloud knowledge
• Continuous Integration and deployment solutions

Microservices trap

With Docker and Kubernetes, cloud native solutions has changed a lot of how we design software these days. On top of that, public cloud leader also innovate to provide PaaS and IaaS with more features, reliability and security.

Function As Service (FaaS) and Serverless solutions enable enterprise to be more focus on software then infrastructure maintenance. But this adds a lot of complexity of how to keep a consistent architecture without ending in spaghetti.

10 years ago, when I wanted to design a system, a Frontend and Backend application manually deployed to single Linux server was enough to serve my E-Commerce website.

If your asking yourself in how many services you should split your application you are probably on the wrong path. Don’t try design your system around microservices.

You have to design services around your system. The intrinsic value of microservices is to serve a single purpose and ease maintainability and evolution over time.

You have to think of really independent and self-sufficient service, turn dependency in more explicit data model as expected input. And if it's related to the same data domain, you probably don't need different service.

The more services you will design, the more maintenance and interoperability you would need to be added. The complexity and time required to maintain such a system is not something to take underestimate . Be careful of not having a cascade of dependency between your services.

As a simple example, let say you are a E-Commerce vendor and have three services, Customer, Order and Shipping. The Shipping service has a method to manage shipment life cycle.

• Do not pass the ID of Customer to the shipping service, it would require the Shipping service to call the Customer service to retrieve the address.
• You should define specific object for the address and pass only the address on the shipping service. It's better to let the Order service dealing of how to store and retrieve the shipping address.

Architectural pattern

Architectural pattern are reusable solution to address various issues in software engineering, such as:

• Microservices
• Hexagonal architecture
• Event driven architecture
• Layers
• SOA (Service Oriented Architecture)

Those patterns are well known and the containerization tsunami broad Microservices at the first place. But it’s not a silver bullet, don’t rush on the first pattern trying to implement it because it seems cool. You will probably end’up in a messy and wrong implementation.

You’ll have to learn it first, make a PoC, challenge the integration with the vision of where you want to lead your design.

Try stay pragmatic in your decision and keep thing simple as possible. As the well-known KISS ( Keep It Simple Stupid ). It's actually the hardest part to keep thing small and not ending up in a hundred of components.

Avoid to overthink optimization for things that’s not required or would never be developed. I’ve seen that a lot with local cache optimization, like creating in memory cache that’s cleared every minute to avoid requesting multiple time the database, when in fact there are too few request per minute per visitor to benefit of the functionality.

We are in 2022, continuous deployment are part of our daily work, your architecture has to evolve and change, maybe not at a structured level but you’ll certainly had to change important component or re-work some part. that’s the hard work of maintaining a software architecture.

Don’t be afraid to refactor code, that’s how iteration for quality improvement works.

Last year I had to re-develop two times a Big Data Architecture for a solution to automate workflow of data aggregation, including intelligence analysis where millions of metrics in near real time are aggregated on a dashboard. We would have never reach the final design the first time without experiencing the first.

3. T/B Driven Development

TDD

You're about to start a spring, all the specifications done, you are ready to hands on some coding. Something that will help you is to start implementing some testing first,

In case you are not aware of, TDD and BDD are practice of implementing testing scenario before developing the functionality. But in reality it’s the iteration process between testing and coding.

To be honest, TDD is not working very well to frontend application, expect if you have specific piece of code that can be unit tested. But in regard to the backend it would help you to keep clean code and single responsibility.

Let say you have to parse a plain text and create a specific file format with it.

With the TDD, you will first have to think of what kind of method to create and how structure your code to unit test.

The first method would consist in sanitization, taking a requestBody as input and returning a struct / object as output while having to do some type conversion and error handling.

You can start by creating different payload and output expectation in your test cases.

At this point, your test execution will fail, and you can start coding the method until the test pass with success. Along the coding new idea may come and assertions would be added or modified.

You have to get that TDD is part of the daily work, it’s more a practice of developing than a practice of testing.

BDD

As a fellow DevOps evangelist, Behavior Driven Development is my favourite, but it is also the more difficult to adopt as it would require team collaboration and BA/PO commitment.

You will drive your coding base on the behavior of the usability of the application. BDD has to be express in a natural language like english because it needs to be explicit, easy to understand and written by non coders people.

I recommend the usage of Cucumber and the Gherkins syntax to create powerful automated case scenarios.

Based on the scenario write by the team, the developers would be able to generate testing case that will execute the assertions.

It’s pretty easy to implement and don’t require lof of effort. The most difficult part would be the automation of the execution in an immutable environment where the application and database has to be run and seed.

Code Review

One of the person in the team has proudly finished to develop a user story of the sprint. Before merging the component with the rest of the code base, you may want to have some four eyes check that will bring you these benefits:

• Senior developer advice to share knowledge and best practice
• Improve code quality
• Improve security
• Avoid shipping shadow IT components
• Share knowledge of the code produce

4. Continuous Integration and Deployment

CI

The code review often happened on the Pull Request or also called Merge Request. This PR is special branch resulting of the merge of the new code with the code base.

Every commit associate to that PR will trigger the CI platform associate:

• Gitlab CI
• GitHub Actions
• CircleCI
• Travis

The CI platform help you to design immutable and replicable environment to build, test and deploy your software. There are very few limit today of what can do an integrations pipeline.

CD & CDE

The software deployment strategy depend on the target of your software. Deploying a mobile apps, web application, desktop, or IoT application, each of them have very specific strategy of when and how to perform the deployment.

The Continuous Delivery (CD) is associate to concept of the artifact delivered at the end of the Sprint. It's piece of code that is working and can be executed. This artifact can then be deployed to the target, manually or automated.

In Continuous Deployment (CDE), we are pushing the deployment phase automatically. There are no human process involve, right after the build, it deploys in the same integration pipeline. It’s working well for webapps where everything is running on the cloud and can be trigger and replaced instantly.

5. Maintenance

Congratulation, your application is now in production, but that’s not it, most of the IT team would consider they work DONE and it’s now the OPS job to keep it up and running.

Well in DevOps culture, we have gather feedback to fix trouble ASAP as a team. We all now that complex infrastructure is not maintained by system administrator only, speculation when most the time the issues come from miss a configuration or application error.

Monitoring

Monitoring the application is critical, your team needs to know when a server request return http 500 error, or have long running call that’s finished in timeout, or even just checking logs to analyse unexpected behavior.

Alerting

Most of the time people stop there, but a monitoring is useless without alert someone to care for. It’s always better to intercept and troubleshoot error before the end user is manifesting himself to you. Most of your customer would rather prefer to shout out your app and call your names on social media rather then contact you about application issues.

I need you to pledge me something, please..... DO NOT configure EMAIL Alerting! Expect to worsen climate change by filling your team inbox with a hundred of thousand of mails, nobody will read them, and most of it would create a trash filter to ignore them.

When troubles will come, people would just react by saying they have not seen it. I recommend you to have proper tools to centralize incident and do some escalation to team members that’s concerned.

Try to keep a tool that the team would adopt and use every day, I always recommend to look first at the tools that you already use. Create a dedicated channel in your Slack with a bot or a specific project in your Jira to manage incident are a good way to do it.

Feedback

Thanks for reading me, this article summarize lot of experience of my past 10 years, feel free to reach out on Twitter if you have questions or comments about the post.