
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).
Publishing the MSA(APIs) , SOA, BPEL strategies and best practices for orchestration and choreography.
Publishing the reporting strategies, tools and processes for the project and program.
Publishing the principles for adopting caches, message queues, change data strategies in the overall architecture.
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 –
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!
Â
