top of page

14. The Art of Software Development

How is the art of software development executed?

14. The Art of Software Development

I was ruminating over my participation in the Information Technology sector for over 2 decades. I have player several roles – some formal and some informal – Software Engineer, Programmer Analyst, full stack developer, Senior Associate, Project Manager, Technical Architect, Solution Architect, Enterprise Architect, Business Analyst, Technical Analyst, Technical content creator, Train the trainer architect etc.,

I have seen how the product and application creation cycles along with IT project management and Devops culture has evolved over a period. And I thought of writing this blog focussing on a enterprise class software product creation effort.


Please refer to this article for additional information - https://www.mayoan.com/technology/13.-starting-an-it-company .

 

Management Efforts:

It all starts with management needs. Say for example, the management sees a strategic risk of their information systems not in a modern state and hence is not scalable as per the potential calculated.


Some of the strategic risks that may be considered by the board, governance and management are:

  • Competitive pressure

  • Emerging new markets

  • Emerging new products

  • Financial stress

  • Mergers & Alliances

  • Sell offs and divestitures

  • Emerging new marketing channels

  • Changing economic landscapes

  • Changing legal/regulatory environments

  • Technological/scientific breakthroughs

  • Black swan events

  • Changing demands

  • Zeitgeist

  • Global Events of significance


So, they create a program charter and allocate a budget for the entire program and duration. Quick roles and responsibilities along with management level RACI matric is created. The IT committee, CxOs including CIOs and CTOs sign off on the charter. This charter is then given to the CIO/CTO to draw the stages and boundaries at a higher level.

The program tracking will be on a on-going basis.

 

The CIO/CTO Efforts:

Program/Project kick-off, allocating senior roles and responsibilities, management reporting cadence, Infosec Policy to be followed, CyberSec Policy to be followed, Data Security and Privacy Policy to be followed, Program risk assessments and cadence, Enterprise frameworks, Industry standards and guidelines etc., are all finalized and the WIP moves to the Chief Enterprise Architect in-charge. Interface with other horizontals and BUs are fine-tuned or upgraded.

The task is then handed over to the Program management team.

The program tracking will be on a on-going basis.

Some of the technical risk areas handled by this offices includes:

  • Aligning the IT strategies to the company strategies

  • Avoiding being technically outdated

  • Intelligently adopting the latest trends to the benefit of the company and its businesses

  • Continually upgrading the cybersec operations as per the industry norms

  • Continually upgrading the knowledge management processes and platforms as per the latest industry norms

  • Strategizing on outsourcing/off-shoring and other hybrid models

  • Developing policies related to subject areas such as WFH, device management (BYOD included), Training costs, certifications and certificates, on-site/off-site meetings, etc.,

  • Choosing and adopting the right frameworks and guidelines as harnesses for the IT function

  • Keeping a check on any potential threats emerging from legal complications in areas such as IPRs.

 

The Program Management Team (PMT) Efforts:

The PM team assembles the rest of the team; Necessary trainings are organized. All needed resources are on-boarded as per the team loading plan. Necessary software, hardware and licenses are obtained. VMs, MSCs, Physical security, logical security etc., as per the relevant policies are arranged. Roles and responsibilities are assigned. Project plans, Product back logs etc., are drawn up. Scrum ways of working perhaps was also planned to be adopted. Other aspects such as requirements(epics, stories, requirements, product backlogs, scrum logs etc.,), time sheet management, account management, management reporting, revenue recognition, project/program expense tracking, HRD, other stake holder management, program risk management, quality management, delivery management etc are handled by this team and they may use and enforce the use of project tracking software for plans, requirements, time sheets, accounts, budgeting, collaboration, communications, presentations and travel & leisure. Frameworks like PMP, ITIL, Prince 2, SAFe, etc., may be adopted by this team.

https://algocademy.com/blog/79-essential-tips-for-succeeding-in-collaborative-coding-projects/

The program tracking will be on a on-going basis. Based on the decisions above the PMT then delegates the task to other program managers(s), project managers(s), product managers(s), business analysts, etc.,


Some of the project risk areas tackled by PMT are:

  • Cost control and budgeting

  • Scheduling

  • Quality management

  • Delivery metrics

  • Mile-stones and scoping related

  • Project resource management

  • Team performance evaluation related

  • Team morale related

  • Stakeholder management

  • Communication strategies

  • Documentation

  • Takeovers and Handoffs

  • Team skills upgrade and update related

  • Quality checking of processes (like QM, devops, scrum, lean, etc.,) under execution with continuous improvements

  • Third party engagements

  • Maintaining approved list of vendors

The Chief Enterprise Architect (CEA) Efforts:

First thing he considers is the ballpark estimations' on budget and schedules. He also red lines the non-negotiable requirements and drop-dead finish lines along with any strategic constraints.

He has to consider and finalize on the below aspects:


1.  What strategic risks are being mitigated? What other strategic risks are being addressed?

2.  Is this project duplicating any effort already being executed either in full or in part?

3.  Any legal implications and/or management goals and objectives to be considered?

4.  Should the project be outsourced or developed in-house or a combination of both?

5.  Are there any reference architectures? Are there any standards, protocols and frameworks to be considered for use?

6.  Should the project use COTS (commercial off the shore) product or should the product be built from the scratch? If so, what components can be reused?

7.  What are the NFRs (Non-Functional Requirements)?

8.  What platform/language/vendor support should be used?

9.  Should we adopt in-house data centres, or go for cloud or select hybrid model?

10.  What are the program/project metrics?

11.  What are the goals of MVP/definitions-of-done?

12.  What are the program milestones?

13.  What are the communication strategies for the RACI and other management staffs?

14.  Should any changes to the HR policies and procedures be affected?

15.  What are the program risks?

16.  What lessons learned in the past projects/programs can be highlighted?

 

 

Frameworks like TOGAF, Zachman Framework, FEAF etc., may be adopted by this team. Certain GRC/CyberSec frameworks like NIST, ISO 27001 etc., can also be recommended to be used by this team.

This can be done on an ongoing basis. Continuous improvements must be enforced and tracked. Based on the decisions above the CEA then delegates the task to other enterprise architect(s), technical architect(s) and solution architect(s).

 

Some of the technology risk areas sorted out by the architect teams are:

  • Consolidation of IT artefacts VMs, Containers, other hardwares

  • Consolidation of SasS products by promoting platforms and reusable component architectures

  • Reducing the digital attack surfaces to contain cyber threats

  • Technological obsoletions' - both hardware and software

  • Maintaining product life cycles

  • Knowledge Management

  • Onboarding, training/certifications , technical career path related

  • Maintaining the right program/project metrics

  • NOC/SOC/threat hunting, QRT related cybersec postures

  • Operational continuity and business continuity management related

  • Third party integration related

  • Data governance related

  • Evaluating list of technical vendors and maintaining the approved list

  • Other general areas falling under IT operational risks

 

The Technical/Solution Architects Efforts:

The following may be contributed by the technical and solution architects for the product development efforts.

1.      Cloud/On-prem/Hybrid Adoption Deployment Architecture comprising of patterns like

a.      Cloud Native Architecture Patterns

b.      Cloud Hybrid Architecture Patterns

 

2.      Software Architecture comprising of

Patterns and best practices as mentioned in sample references below:

a.      https://www.geeksforgeeks.org/software-engineering/types-of-software-architecture-patterns/

b.      https://redrocket.software/blog/10-software-architecture-patterns-you-must-know-about

 

Patterns and best practices as mentioned below as applicable to the business and project needs:

c.   Systems Engineering

d.   Systems Design

e.   Component Architecture

f.    Data/database/artifact storage patterns and best practices

g.   EAI (Enterprise Application Integration) concepts/designs as applicable to the business and project needs

h.   Coding pattern s like GoF, SOLID principles and adoption of 12 factor framework.

 

3.      Publishing the runbook on staging POCs (proof of concepts)

4.      Publishing the policies on data archival, retrieval and restoration.

5.      Publishing the policies around data governance, data lineage, data audit requirements

6.      Publishing the full list of approved open-source software along with license models permitted for use

7.      Publishing the full list of software to be used for code version control, code quality check, code security

check, Devops pipeline, quality management and for management reporting

8. Publishing the full list of software vendor tools and integration platforms, processes, protocols,

integration points for the product

8.      Publishing the design principles and identifying the list of tools for running a DevOps pipeline

9.    Publishing the design principles on bug tracking and restoration and how to link them to scrum

iterations and requirements (RTM matrix adoption).

  1. Publishing the MSA(APIs) , SOA, BPEL strategies and best practices for orchestration and choreography.

  2. Publishing the reporting strategies, tools and processes for the project and program.

  3. Publishing the principles for adopting caches, message queues, change data strategies in the overall architecture.

  4. Publishing the principles of continuous monitoring and control and distributed tracing and practice as per the demands of the perceived use of the software.


The Rest of the Team Efforts:

1.   Quality team to ensure that quality norms are met as applicable to functional testing, automation testing, integration testing, module testing, pre-prod testing etc., Some of the testing methods that are in vogue are in the below link –

https://fullscale.io/blog/software-testing-methodologies/

 

 

2.   Coders to complete programming/review tasks as per some of the development team agile strategies such as –

https://en.wikipedia.org/wiki/Agile_software_development

 

3.      Business Analysts to document requirements in a principled manner as outlined in –

https://sfia-online.org/en/tools-and-resources/bodies-of-knowledge/babok-a-guide-to-the-business-analysis-body-of-knowledge

BABOK standard is maintained by www.iiba.org

 

4.      DevOps team members to maintain the product pipelines for CI/CD purposes.

https://devops.com/ and

https://en.wikipedia.org/wiki/DevOps

 

5.    Other personnel like CyberSec managers/analysts, Infosec Managers etc., play a crucial role too in the software development areas.


6.      Finally some specialist roles like UI/UX designers, data architects, network architects, security

architects, front end developers, DB admins, SVC (Source version control) leads, platform architects

can exist as per the specialist needs of the project/program.


Copyright © 2023-2048 Vijayabhaskar Natarajan. All rights reserved

Hari Om!

 

© 2048  Powered and secured by Wix

bottom of page