Journey of software engineering at NashTech
As you know, NT has worked in software outsourcing and product builds for customers in over the world for over 20 years now. During that time, we have experienced many software development methodologies from waterfall to agile development methodology. It helps us to streamline how we can consult, design, develop, and deploy software for our customers as well as requires use to integrate it into our Software Development Life Cycle (SDLC) to reflect changes in software development methodologies around the world. The trend is a shift from predictive to rigid, iterative, agile, and adaptive methods by applying standard waterfall models, spiral waterfall models, and eXtreme Programming (XP) [1].
Basically, we divide our software development services into 2 types: brownfield and greenfield software development.
Brownfield software development: Brownfield development is a term commonly used in the information technology industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems. This implies that any new software architecture must take into account and coexist with live software already in situ [2].
Greenfield software development: a greenfield project could be one of developing a system for a totally new environment, without concern for integrating with other systems, especially not legacy systems. Such projects are deemed higher risk, as they are often for new infrastructure, new customers, and even new owners [3].
Let’s see the full NashTech SDLC picture below:
A1: System Assessment
As the definition of brownfield software development, it requires us to do an assessment of a whole system. What can be found in platform governance, policy and security, cost management, quota and budget management, automation tasks and tools, performance indicators and as-is state, reliability, changes in scalability, cost-effectiveness, security, and accelerated adoption?
A2: Cloud adoption strategy and roadmap
Then we must do a plan with our customers to define the cloud adoption strategy and roadmap, and what can we do here is prioritize what works can be done first and later, choose the best computing and deployment models such as hybrid cloud, multi-cloud, cloud-first, cloud-only, cloud-native adoptions. And the important things are seat with the customer to design the buy-or-build software, components, or even cloud services for the current business.
A3: Cloud migration
The next step of this brownfield software development is to do a cloud migration strategy by applying some modern models and mechanisms [4]. The 6 Rs of Cloud Migration are normally used to help us on this journey [5].
B1: Business needs and technical strategy
With greenfield software development, we can see we normally start from the planning phase with our customers which happens in the onshore site where our technical consultants will work with the customer to define business needs and technical strategies, TOGAF methodology might use in this phase to figure out the landscape of the whole enterprise system of customer [6]. We try to capture what as-is, and what customers want for the new platform/software to serve their business needs. And based on that, we define the product roadmap, and the epics for the software. In this phase, we might need some BA to help clarify and based on the experience justify and scope of work of the product.
B2: High-level design and roadmap
After the first phase with technical consultants/experts, we quite know about what customer needs and what they expect from the new platform/software, and in the next step we transfer this knowledge to the solution architect/technical architect team to elaborate more about the technical requirements needs for the project. In this phase, we might use NashTech’s NFRs to capture and extends more software quality attributes (e.g., ‘ities’ attributes) for the project to make sure the software that we build for our customer with high quality and less security risk and vulnerability as well as aligns with performance, reliability, flexibility, portability standards in the software development nowadays. UML [7], 4+1 Views Models [8], and C4 Models [9] can be leveraged to visualize and model the holistic views as well as the software components for the project. All the artifacts need to be documented in a Software Architecture Document (SAD) – This follows strictly the CMMI (Capability Maturity Model Integration) process of software development which is integrated into our SDLC. Finally, SAD needs to be reviewed and approved by the customer before we start to design and develop the project in the next steps.
A4, B3: Cloud solution design
In both brownfield and greenfield software development, we will land at the solution design phase (normally customers want to use cloud platforms and services nowadays). In this phase, we normally inherit and apply agile methodology which means we divide projects into smaller sprints, work in distributed nature way (onshore and offshore sites), and certainly we loop back in each sprint based on the roadmap in the earlier phases defined with the customer. During these sprints, we start to implement and deploy the product features (based on product epics) and roll out them through the development, testing, staging, and production environments with a promotion mechanism. DevOps culture and model with modern CI/CD pipelines and Infrastructure as Code (IaC) are strict forces in every project in NashTech right now, and the DevSecOps model to shift left automation tasks into development for quick and fail-fast discovery risks and vulnerabilities are also encouraged by NashTech technical team [10].
Let’s talk about software design and architecture, as far as we know, all projects right now require the use of cloud-platform and services to modern/build software and project in around 5 years now. At NashTech, we are training and guiding our technical architect/team leader/developers about cloud well-architected framework in AWS and Azure cloud platforms covering many aspects of distributed system design, operation excellence, security, reliability, performance efficiency, and cost optimization to make sure our workforce well-known about the best practices when design, development, deployment, and operation software in effective ways. Clean Architecture is also trained by our developers for 2 years now to make sure they must be aware of the software component’s coupling and high cohesion [11]. And this kind of architecture aims to help software be easy to maintain and extend in the future (adaptive model trend). And on a higher level, we have been consulting and working on many Microservices projects in Event-driven Architecture since 2018 [12][13]. The serverless model is also prominent and used for projects to build some kinds of popular event-driven architecture with it.
A5, B4: Monitoring and Observability
At NashTech, we’ve had numerous projects that required increased efficiency in operation and supervision. To address this, our technical team proactively developed toolkits that accelerate the application of observability. These toolkits are particularly helpful for projects built according to the microservices model. Depending on specific characteristics, the accelerator comes in two types:
If you’re working on projects that utilize platforms like Azure or AWS, the accelerator toolkit can help you make the most of the monitoring and observability features already built into these cloud platforms. This is because they are optimized for integration and management in operation. Of course, customers also have the option to use third-party solutions like Data Dog, New Relic, Lightstep, and Dynatrace. The available commercial toolkits have many integrated features that can help reduce implementation time, making it a great advantage for businesses.
NashTech offers a range of accelerators to help customers save costs and customize observability features as per customer-specific requirements. These accelerators are based on open-source platforms such as Prometheus and Grafana LGTM Stack, and ELK Stack (Elastic Logstash and Kibana).
A6, B5: Continuous improvement by evaluating and optimizing system
By going along with the customer in the journey of software development, we encourage the continuous improvement process for the project that we work on with the customer. By adding some monitoring tools as well as SRE best practices in customer production (in case the customer wants us to help them), then we can continuous improvement gradually in both brownfield and greenfield software development.
That’s for today. We will be writing a series of how-to in NashTech blogs to get you to know more about what we are and the reason why we are opinionatedly with these approaches over 20 years in software design and development for our customers.
References:
[1]: https://www.umsl.edu/~sauterv/analysis/f06Papers/Hutagalung/
[2]: https://en.wikipedia.org/wiki/Brownfield_(software_development)
[3]: https://en.wikipedia.org/wiki/Greenfield_project
[6]: https://prod.opengroup.org/togaf
[7]: https://en.wikipedia.org/wiki/Unified_Modeling_Language
[8]: https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
[9]: https://c4model.com/
[10]: https://en.wikipedia.org/wiki/DevOps
[11]: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
[12]: https://microservices.io/
[13]: https://en.wikipedia.org/wiki/Event-driven_architecture